作者：京東保險 鄭飛

背景介紹

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

一、了解可觀測性

1.1 什么是可觀測性

維基百科定義：

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

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

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

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

??

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

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

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

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

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

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

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

??

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

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

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

??

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

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

二、質量保障目的

目標

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

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

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

范圍

1.涵蓋所有關鍵應用服務和基礎設施。

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

三、質量保障思路

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

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

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

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

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

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

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

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

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

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

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

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

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

?統(tǒng)計學監(jiān)控的思維，從日志聚合角度計算出系統(tǒng)整體、分接口的可用性?？捎眯缘陀陬A期或存在環(huán)比內大幅下降則可能是系統(tǒng)出現(xiàn)異常

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

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

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

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

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

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

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

??

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

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

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

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

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

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

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

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

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

......

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

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

短期：

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

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

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

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

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

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

長期：

特點：依賴研發(fā)規(guī)范日志打?。ㄒ粋€請求至少需要有開始和結束的打?。?/p>

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

應用可用性 = （時間段內的全量流量 - 時間段內的報錯流量） / 時間段內的全量流量

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

??

2. 可觀測性維度思考

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

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

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

??

2.1 模塊級可觀測性

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

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

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

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

聯(lián)動報警

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

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

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

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

故障定位

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

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

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

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

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

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

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

2.3 感知及展示

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