作者：京東保險 鄭飛

背景介紹

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

一、了解可觀測性

1.1 什么是可觀測性

維基百科定義：

?控制理論中的可觀察性（observability）是指系統可以由其外部輸出推斷其其內部狀態的程度。系統的可觀察性和可控制性是數學上對偶的概念。可觀察性最早是匈牙利裔工程師魯道夫·卡爾曼針對線性動態系統提出的概念[1]?[2]。若以信號流圖來看，若所有的內部狀態都可以輸出到輸出信號，此系統即有可觀察性。

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

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

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

??

注：圖片來源于網絡

可觀測性運作模式可看作是：觀察-判斷-優化-再觀察

1.2 可觀測性和監控的區別

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

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

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

從性能上看，監控和可觀測性之間的區別可從以下四個方面進行區分：

??

注：圖片來源于網絡

監控是為了提高系統可觀察性而執行的操作 可觀測性：屬于系統的一個屬性，能有效的反應出系統的健康狀況

1.3 可觀測性和監控的聯系

??

注：圖片來源于網絡

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

二、質量保障目的

目標

1.實現對系統和應用的全面監控，能主動探測出系統運行健康狀況。

2.快速定位和解決系統異常，能先于用戶發現問題并能提供問題修復決策。

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

范圍

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

2.包括應用、服務器、網絡、數據庫等，不局限于技術層面，更需要考慮業務數據層面。

三、質量保障思路

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

1. 監控基礎底座

1.1 監控維度思考

監控是為了提高系統可觀察性而執行的操作，通常我們建設的監控能力包含以下幾個方面：

?資源層監控：

?對硬件、網絡帶寬等資源使用層面的監控。通常由運維側主導。

?服務穩定性：

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

?業務功能監控：

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

?業務數據監控：

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

?日志聚類監控：

?統計學監控的思維，從日志聚合角度計算出系統整體、分接口的可用性。可用性低于預期或存在環比內大幅下降則可能是系統出現異常

1.2 測試團隊重點建設監控項

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

1.2.1 業務功能監控

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

讀接口：由于不涉及臟數據的產生，可直接在生產環境監控驗證。

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

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

??

為什么要用引流做監控？

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

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

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

1.2.2 業務數據監控

業務數據是產品最終的價值體現，數據的有消息、正確性、健康性最終能反應出系統的穩定性。針對保險業務，我們其實可以做很多業務數據層面的監控，例如：

?核心數據量（單量、保費等核心數據的實時性）

?業務數據正確性的檢查計算（例如保費=稅+稅后費用，出現不等則是錯誤數據）

?核心數據走向趨勢，當天退保比例高于某個閾值，或者環比高于某個閾值

......

1.2.3 日志聚類監控

跟業務數據的重要性一樣，通過日志也能間接的反應出系統運行的穩定性狀況，由于對日志進行聚類監控本身依賴應用日志的規范性，所以這里非為短期內可落地和長期改造的兩個思路。

短期：

特點：不依賴研發測改造，可以根據現有日志聚類出報錯類型。

監控邏輯：根據固定閾值觸發報警。舉例：如果某一個錯誤類型批量出現超過設定的閾值，需要報警。

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

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

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

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

長期：

特點：依賴研發規范日志打印（一個請求至少需要有開始和結束的打印）

監控邏輯：全量拉取生產日志進行日志清洗和計算，統計應用可用性

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

引申價值：由此可計算出天級可用性、小時級可用性、10min級可用性。同時規范的logid可以作為入口系統出現異常時，向下追蹤的依據。

??

2. 可觀測性維度思考

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

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

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

??

2.1 模塊級可觀測性

模塊及的可觀測性用來檢測單系統、單模塊的系統穩定性，主要提供核心數據的趨勢分析參考，理想狀態能實現以下類型的警告信息

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

2.2 系統級可觀測性

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

聯動報警

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

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

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

聯動報警不止能應用在系統及可觀測性中，針對傳統的監控方式也可以根據模塊間的關閉進行聯動報警。

故障定位

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

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

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

數據分析

多系統之間的業務交互最終表現在數據流上，在具備了系統應用間的聯動能力以后，可以對關鍵數據進行核對或者分析轉化率

數據核對可以提供不同系統間數據一致性的校驗

數據轉化可以看出同一筆數據在不同系統間的流動，可以引申出一些業務敏感數據的對比等

2.3 感知及展示

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