作者：京東保險 鄭飛
背景介紹
目前質量團隊正在積極建設和完善應用監控能力，旨在能及時發現並解決問題，為線上服務穩定性保駕護航。隨著可觀測性概念的逐漸普及，監控的建設也有了新的挑戰和使命。本文將探討在可觀測性背景下，作為一個測試人員在質量保障中的一些思路和個人思考，以及為什麼要區別於研發維度的可觀測性，測試團隊維度的可觀測性建設又能為業務帶來哪些價值。
一、瞭解可觀測性
1.1 什麼是可觀測性
維基百科定義：
控制理論中的可觀察性（observability）是指系統可以由其外部輸出推斷其其內部狀態的程度。系統的可觀察性和可控制性是數學上對偶的概念。可觀察性最早是匈牙利裔工程師魯道夫·卡爾曼針對線性動態系統提出的概念[1][2]。若以訊號流圖來看，若所有的內部狀態都可以輸出到輸出訊號，此係統即有可觀察性。
在軟體領域中，可觀測性是從系統內部出發，基於白盒化的思路去監測系統內部的執行情況。其貫穿應用開發的整個生命週期，透過分析應用的指標、日誌和鏈路等資料，構建完整的觀測模型，從而實現故障診斷、根因分析和快速恢復。
Gartner將可觀測性定義為軟體和系統的一種特性，它允許管理員收集有關係統的外部和內部狀態資料，以便他們回答有關其行為的問題。然後，I&O、DevOps、SRE、Support等團隊可以利用這些資料來調查異常情況，參與可觀察性驅動的開發，並提高系統效能和正常執行時間。雖然可觀察性處於早期階段，截至 2020 年只有不到 10% 的企業採用它，但 Gartner 預測，到 2024 年，30% 的基於雲架構的公司將採用可觀察性技術。
OpenTelemetry組織提出了可觀測性依賴的三大“支柱”：
注：圖片來源於網路
可觀測性運作模式可看作是：觀察-判斷-最佳化-再觀察
1.2 可觀測性和監控的區別
從核心出發點來講，傳統的監控和可觀測性，背後解決的是同樣的問題：能及時、準確的掌握系統的執行狀況，提升對系統執行的控制能力和故障處理能力。
從效能上看，監控和可觀測性之間的區別可從以下四個方面進行區分：
注：圖片來源於網路
監控是為了提高系統可觀察性而執行的操作 可觀測性：屬於系統的一個屬性，能有效的反應出系統的健康狀況
1.3 可觀測性和監控的聯絡
注：圖片來源於網路
監控能夠檢測到系統中的錯誤，可以說是外部對業務應用系統的主動行為，而可觀測效能夠理解問題發生的原因，也就是說在增添了業務應用系統自身的要求的同時，還建立應用執行時產生的資料之間的關聯。
二、質量保障目的
目標
範圍
三、質量保障思路
上邊提到了監控和可觀測性的區別和聯絡，本文提到的質量保障思路是以業務監控作為基礎底座，擴充資料可觀測性的能力，旨在解決傳統監控被動防禦的缺點，結合可觀測性下的採集、聚合、追蹤提供問題定位、風險預測、系統決策的能力。
1. 監控基礎底座
1.1 監控維度思考
監控是為了提高系統可觀察性而執行的操作，通常我們建設的監控能力包含以下幾個方面：
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 感知及展示
不論是監控還是可觀測性，都需要通知和展示，這部分計劃結合最近在做的業務監控大屏做展示，後續再提供一個通用的報警服務，提供郵件、訊息、語音的多通道報警能力。