作者：京東保險 鄭飛

背景介紹

目前質(zhì)量團(tuán)隊正在積極建設(shè)和完善應(yīng)用監(jiān)控能力，旨在能及時發(fā)現(xiàn)并解決問題，為線上服務(wù)穩(wěn)定性保駕護(hù)航。隨著可觀測性概念的逐漸普及，監(jiān)控的建設(shè)也有了新的挑戰(zhàn)和使命。本文將探討在可觀測性背景下，作為一個測試人員在質(zhì)量保障中的一些思路和個人思考，以及為什么要區(qū)別于研發(fā)維度的可觀測性，測試團(tuán)隊維度的可觀測性建設(shè)又能為業(yè)務(wù)帶來哪些價值。

一、了解可觀測性

1.1 什么是可觀測性

維基百科定義：

?控制理論中的可觀察性（observability）是指系統(tǒng)可以由其外部輸出推斷其其內(nèi)部狀態(tài)的程度。系統(tǒng)的可觀察性和可控制性是數(shù)學(xué)上對偶的概念。可觀察性最早是匈牙利裔工程師魯?shù)婪颉た柭槍€性動態(tài)系統(tǒng)提出的概念[1]?[2]。若以信號流圖來看，若所有的內(nèi)部狀態(tài)都可以輸出到輸出信號，此系統(tǒng)即有可觀察性。

在軟件領(lǐng)域中，可觀測性是從系統(tǒng)內(nèi)部出發(fā)，基于白盒化的思路去監(jiān)測系統(tǒng)內(nèi)部的運行情況。其貫穿應(yīng)用開發(fā)的整個生命周期，通過分析應(yīng)用的指標(biāo)、日志和鏈路等數(shù)據(jù)，構(gòu)建完整的觀測模型，從而實現(xiàn)故障診斷、根因分析和快速恢復(fù)。

Gartner將可觀測性定義為軟件和系統(tǒng)的一種特性，它允許管理員收集有關(guān)系統(tǒng)的外部和內(nèi)部狀態(tài)數(shù)據(jù)，以便他們回答有關(guān)其行為的問題。然后，I&O、DevOps、SRE、Support等團(tuán)隊可以利用這些數(shù)據(jù)來調(diào)查異常情況，參與可觀察性驅(qū)動的開發(fā)，并提高系統(tǒng)性能和正常運行時間。雖然可觀察性處于早期階段，截至 2020 年只有不到 10% 的企業(yè)采用它，但 Gartner 預(yù)測，到 2024 年，30% 的基于云架構(gòu)的公司將采用可觀察性技術(shù)。

OpenTelemetry組織提出了可觀測性依賴的三大“支柱”：

??

注：圖片來源于網(wǎng)絡(luò)

可觀測性運作模式可看作是：觀察-判斷-優(yōu)化-再觀察

1.2 可觀測性和監(jiān)控的區(qū)別

從核心出發(fā)點來講，傳統(tǒng)的監(jiān)控和可觀測性，背后解決的是同樣的問題：能及時、準(zhǔn)確的掌握系統(tǒng)的運行狀況，提升對系統(tǒng)運行的控制能力和故障處理能力。

?監(jiān)控（Monitoring）：收集、分析和使用信息來觀察一段時間內(nèi)的運行進(jìn)度，并且進(jìn)行相應(yīng)的決策管理的過程，監(jiān)控側(cè)重于觀察特定指標(biāo)。

?可觀測性（Observability）：通過分析系統(tǒng)生成的數(shù)據(jù)理解推演出系統(tǒng)內(nèi)部的狀態(tài)，并提供數(shù)據(jù)、技術(shù)決策層面的支持。

從性能上看，監(jiān)控和可觀測性之間的區(qū)別可從以下四個方面進(jìn)行區(qū)分：

??

注：圖片來源于網(wǎng)絡(luò)

監(jiān)控是為了提高系統(tǒng)可觀察性而執(zhí)行的操作 可觀測性：屬于系統(tǒng)的一個屬性，能有效的反應(yīng)出系統(tǒng)的健康狀況

1.3 可觀測性和監(jiān)控的聯(lián)系

??

注：圖片來源于網(wǎng)絡(luò)

監(jiān)控能夠檢測到系統(tǒng)中的錯誤，可以說是外部對業(yè)務(wù)應(yīng)用系統(tǒng)的主動行為，而可觀測性能夠理解問題發(fā)生的原因，也就是說在增添了業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求的同時，還建立應(yīng)用運行時產(chǎn)生的數(shù)據(jù)之間的關(guān)聯(lián)。

二、質(zhì)量保障目的

目標(biāo)

1.實現(xiàn)對系統(tǒng)和應(yīng)用的全面監(jiān)控，能主動探測出系統(tǒng)運行健康狀況。

2.快速定位和解決系統(tǒng)異常，能先于用戶發(fā)現(xiàn)問題并能提供問題修復(fù)決策。

3.提供實時以及歷史可對比數(shù)據(jù)反映出系統(tǒng)的運行狀況，，支持技術(shù)決策。

范圍

1.涵蓋所有關(guān)鍵應(yīng)用服務(wù)和基礎(chǔ)設(shè)施。

2.包括應(yīng)用、服務(wù)器、網(wǎng)絡(luò)、數(shù)據(jù)庫等，不局限于技術(shù)層面，更需要考慮業(yè)務(wù)數(shù)據(jù)層面。

三、質(zhì)量保障思路

上邊提到了監(jiān)控和可觀測性的區(qū)別和聯(lián)系，本文提到的質(zhì)量保障思路是以業(yè)務(wù)監(jiān)控作為基礎(chǔ)底座，拓展數(shù)據(jù)可觀測性的能力，旨在解決傳統(tǒng)監(jiān)控被動防御的缺點，結(jié)合可觀測性下的采集、聚合、追蹤提供問題定位、風(fēng)險預(yù)測、系統(tǒng)決策的能力。

1. 監(jiān)控基礎(chǔ)底座

1.1 監(jiān)控維度思考

監(jiān)控是為了提高系統(tǒng)可觀察性而執(zhí)行的操作，通常我們建設(shè)的監(jiān)控能力包含以下幾個方面：

?資源層監(jiān)控：

?對硬件、網(wǎng)絡(luò)帶寬等資源使用層面的監(jiān)控。通常由運維側(cè)主導(dǎo)。

?服務(wù)穩(wěn)定性：

?服務(wù)或接口的可用性等，例如UMP監(jiān)控。通常由研發(fā)側(cè)主導(dǎo)。

?業(yè)務(wù)功能監(jiān)控：

?重點關(guān)注系統(tǒng)對外提供的功能是否正常，測試需重點關(guān)注的部分

?業(yè)務(wù)數(shù)據(jù)監(jiān)控：

?重點關(guān)注跟業(yè)務(wù)特性強(qiáng)相關(guān)的數(shù)據(jù)，根據(jù)數(shù)據(jù)正確性、數(shù)據(jù)走向趨勢能間接的反映出系統(tǒng)健康度是否有下降或存在潛在風(fēng)險

?日志聚類監(jiān)控：

?統(tǒng)計學(xué)監(jiān)控的思維，從日志聚合角度計算出系統(tǒng)整體、分接口的可用性。可用性低于預(yù)期或存在環(huán)比內(nèi)大幅下降則可能是系統(tǒng)出現(xiàn)異常

1.2 測試團(tuán)隊重點建設(shè)監(jiān)控項

由于資源層監(jiān)控和服務(wù)穩(wěn)定性監(jiān)控一般會由運維或研發(fā)主導(dǎo)，為了避免重復(fù)造輪子，這里不做單獨的討論，只討論從測試視角要重點建設(shè)的監(jiān)控能力

1.2.1 業(yè)務(wù)功能監(jiān)控

接口功能：從接口維度進(jìn)行監(jiān)控，監(jiān)控核心接口功能是否正常，其中：

讀接口：由于不涉及臟數(shù)據(jù)的產(chǎn)生，可直接在生產(chǎn)環(huán)境監(jiān)控驗證。

寫接口：由于寫接口可能會產(chǎn)生臟數(shù)據(jù)，在保險側(cè)業(yè)務(wù)上禁止此種操作，而且即使使用測試賬號也會產(chǎn)生于生產(chǎn)環(huán)境差異巨大的不真實數(shù)據(jù)，所以我們無法使用直接在生產(chǎn)環(huán)境直接操作寫接口。這里想到的一個方案是【測試反哺】，具體思路為：用預(yù)發(fā)環(huán)境反哺生產(chǎn)驗證。理論上預(yù)發(fā)環(huán)境版本號一定 >= 生產(chǎn)環(huán)境，預(yù)發(fā)環(huán)境由于新提測的內(nèi)容導(dǎo)致監(jiān)控探測失敗，可看作是對歷史功能的回歸驗證不通過，其中有兩種情況： 1. 預(yù)期內(nèi)失敗：功能變更對接口產(chǎn)生的影響，這時需要同步修改監(jiān)控內(nèi)容 2. 非預(yù)期內(nèi)失敗：新提測內(nèi)容，影響了原有的功能，可看作是提測的需求bug

而關(guān)于接口監(jiān)控的場景，這里想到了一種引流監(jiān)控的思路，即用真實的用戶請求驗證功能的正確性（替換關(guān)鍵信息，不暴露真實用戶數(shù)據(jù)）。

??

為什么要用引流做監(jiān)控？

按照傳統(tǒng)的接口監(jiān)控方式，通常會寫一個監(jiān)控case然后周期性執(zhí)行。這樣寫的弊端是高度依賴測試人員對業(yè)務(wù)的了解程度，也很難保障業(yè)務(wù)場景覆蓋的完整性，而隨著系統(tǒng)的迭代一個接口的功能場景可能會被擴(kuò)展出很多，如果測試人員只了解其中的一個或某幾個場景，按照習(xí)慣會添加這幾個場景的監(jiān)控case，但是不熟悉的場景可能就會一直缺少對應(yīng)的監(jiān)控。

場景覆蓋：從用戶可感知元素角度反推監(jiān)控項case

這種思路比較像黑盒測試，即不關(guān)注具體的數(shù)據(jù)、業(yè)務(wù)處理流程，更貼近用戶的真實操作，把自己想像成一個真實的用戶，用戶在使用產(chǎn)品的時候能看到什么，能操作哪些頁面、按鈕？這些操作背后對應(yīng)的功能是什么，從視角上的可見反推到不可見的應(yīng)用背后。

1.2.2 業(yè)務(wù)數(shù)據(jù)監(jiān)控

業(yè)務(wù)數(shù)據(jù)是產(chǎn)品最終的價值體現(xiàn)，數(shù)據(jù)的有消息、正確性、健康性最終能反應(yīng)出系統(tǒng)的穩(wěn)定性。針對保險業(yè)務(wù)，我們其實可以做很多業(yè)務(wù)數(shù)據(jù)層面的監(jiān)控，例如：

?核心數(shù)據(jù)量（單量、保費等核心數(shù)據(jù)的實時性）

?業(yè)務(wù)數(shù)據(jù)正確性的檢查計算（例如保費=稅+稅后費用，出現(xiàn)不等則是錯誤數(shù)據(jù)）

?核心數(shù)據(jù)走向趨勢，當(dāng)天退保比例高于某個閾值，或者環(huán)比高于某個閾值

......

1.2.3 日志聚類監(jiān)控

跟業(yè)務(wù)數(shù)據(jù)的重要性一樣，通過日志也能間接的反應(yīng)出系統(tǒng)運行的穩(wěn)定性狀況，由于對日志進(jìn)行聚類監(jiān)控本身依賴應(yīng)用日志的規(guī)范性，所以這里非為短期內(nèi)可落地和長期改造的兩個思路。

短期：

特點：不依賴研發(fā)測改造，可以根據(jù)現(xiàn)有日志聚類出報錯類型。

監(jiān)控邏輯：根據(jù)固定閾值觸發(fā)報警。舉例：如果某一個錯誤類型批量出現(xiàn)超過設(shè)定的閾值，需要報警。

這種監(jiān)控最大的問題在于閾值設(shè)定的不合理會產(chǎn)生漏報或批量的誤報。

所以需要一段時間的試錯，前期閾值設(shè)定的保守一些，用一段時間的數(shù)據(jù)評估出一個相對合理的閾值，同時由于數(shù)據(jù)的積累，后續(xù)的報警策略也可以擺脫單獨的固定閾值方式，使用閾值+趨勢分析的策略進(jìn)行報警。

引申價值：近一周或一個月內(nèi)報錯數(shù)量統(tǒng)計對比，如果某天報錯突然增多，則預(yù)示可能存在風(fēng)險（百分比上漲監(jiān)控）。

報警Demo：【警告】10min內(nèi) {投保年齡錯誤} 類型報錯數(shù)量超過100，大于設(shè)定閾值90，請排查系統(tǒng)是否有異常！

長期：

特點：依賴研發(fā)規(guī)范日志打印（一個請求至少需要有開始和結(jié)束的打印）

監(jiān)控邏輯：全量拉取生產(chǎn)日志進(jìn)行日志清洗和計算，統(tǒng)計應(yīng)用可用性

應(yīng)用可用性 = （時間段內(nèi)的全量流量 - 時間段內(nèi)的報錯流量） / 時間段內(nèi)的全量流量

引申價值：由此可計算出天級可用性、小時級可用性、10min級可用性。同時規(guī)范的logid可以作為入口系統(tǒng)出現(xiàn)異常時，向下追蹤的依據(jù)。

??

2. 可觀測性維度思考

集團(tuán)的PFinder (problem finder) 是UMP團(tuán)隊打造的新一代APM（應(yīng)用性能追蹤）系統(tǒng)，非常貼合可觀測性的概念，目前研發(fā)團(tuán)隊也在陸續(xù)的將應(yīng)用接入到PFinder。

那為什么測試團(tuán)隊要做區(qū)別于研發(fā)維度的可觀測性？又該如何去做？

避免重復(fù)造輪子！作為測試人員應(yīng)該對系統(tǒng)的功能是否可用、業(yè)務(wù)數(shù)據(jù)是否正確有高度的敏感性。測試團(tuán)隊的可觀測行建設(shè)與監(jiān)控緊密結(jié)合。通過配合監(jiān)控建設(shè)，結(jié)合可觀測性給出系統(tǒng)診斷、分析、定位的能力。

??

2.1 模塊級可觀測性

模塊及的可觀測性用來檢測單系統(tǒng)、單模塊的系統(tǒng)穩(wěn)定性，主要提供核心數(shù)據(jù)的趨勢分析參考，理想狀態(tài)能實現(xiàn)以下類型的警告信息

報警Demo：【可疑】核心數(shù)據(jù)xxx從【xxxx-xx-xx】服務(wù)上線后，出現(xiàn)連續(xù)x天數(shù)據(jù)下降，請相關(guān)注是否存在異常。

2.2 系統(tǒng)級可觀測性

根據(jù)日志采集系統(tǒng)，聚合出當(dāng)前模塊、下游模塊的數(shù)據(jù)流走向。當(dāng)任何一個模塊的監(jiān)控項出現(xiàn)報警時，能及時通知并且能攜帶出一定的問題排查和定位結(jié)論。同時能進(jìn)行不同系統(tǒng)之間的數(shù)據(jù)核對。

聯(lián)動報警

可觀測性具有系統(tǒng)及觀測的特點，也就是說它能更全局的看到到整個系統(tǒng)不同模塊的狀態(tài)，所以應(yīng)該具備很強(qiáng)的模塊聯(lián)動性。

通常在一個業(yè)務(wù)系統(tǒng)中，葉子節(jié)點的異常會導(dǎo)致上游服務(wù)的異常。例如應(yīng)用A 調(diào)用 應(yīng)用B完成業(yè)務(wù)處理，當(dāng)應(yīng)用B發(fā)送異常時，會影響到應(yīng)用A，傳統(tǒng)的監(jiān)控方式是對各自的應(yīng)用做監(jiān)控，此時如果應(yīng)用B本身的監(jiān)控不完善，很難第一時間排查出問題的根因，甚至在應(yīng)用B監(jiān)控完善的情況下，如果AB信息沒有及時共享，也很難第一時間定位問題。在這種情況下建設(shè)聯(lián)動報警的能力，除了能發(fā)現(xiàn)上游服務(wù)的問題，還能引申聯(lián)動探測出子模塊的異常，可以有效縮短問題定位和修復(fù)的時間。

具體思路為：當(dāng)上游應(yīng)用發(fā)生異常時，可嘗試向下游子模塊進(jìn)行探測，在報警信息中匯總出所有發(fā)現(xiàn)異常的模塊信息，給問題定位人員提供直觀的排查方向。

聯(lián)動報警不止能應(yīng)用在系統(tǒng)及可觀測性中，針對傳統(tǒng)的監(jiān)控方式也可以根據(jù)模塊間的關(guān)閉進(jìn)行聯(lián)動報警。

故障定位

在具有聯(lián)動報警能力的基礎(chǔ)上，報警信息中可提供更準(zhǔn)確的故障內(nèi)容

舉例：應(yīng)用A 調(diào)用 應(yīng)用B完成業(yè)務(wù)處理，某次B應(yīng)用上線后A應(yīng)用某些功能不可用

報警Demo：【錯誤】應(yīng)用A XXX功能異常，本服務(wù)數(shù)據(jù)、日志計算未發(fā)現(xiàn)明顯異常，下游應(yīng)用B探測出可疑異常日志{日志關(guān)鍵信息}，下游應(yīng)用最近上線日期為【xxxx-xx-xx】，請及時排查。

數(shù)據(jù)分析

多系統(tǒng)之間的業(yè)務(wù)交互最終表現(xiàn)在數(shù)據(jù)流上，在具備了系統(tǒng)應(yīng)用間的聯(lián)動能力以后，可以對關(guān)鍵數(shù)據(jù)進(jìn)行核對或者分析轉(zhuǎn)化率

數(shù)據(jù)核對可以提供不同系統(tǒng)間數(shù)據(jù)一致性的校驗

數(shù)據(jù)轉(zhuǎn)化可以看出同一筆數(shù)據(jù)在不同系統(tǒng)間的流動，可以引申出一些業(yè)務(wù)敏感數(shù)據(jù)的對比等

2.3 感知及展示

不論是監(jiān)控還是可觀測性，都需要通知和展示，這部分計劃結(jié)合最近在做的業(yè)務(wù)監(jiān)控大屏做展示，后續(xù)再提供一個通用的報警服務(wù)，提供郵件、消息、語音的多通道報警能力。