品質保障體系主要分為線下問題的攔截和線上問題的召回兩部分，監控作為線上問題召回的核心手段，承載着舉足若輕的戰略地位。
制定目标
背景
通過線上故障和使用者回報整體分析發現：随着公司内部多個業務線的發展，業務複雜度越來越高，現有監控和業務等名額欠缺關聯，功能類問題及「埋點」等問題發現周期長，導緻無法及時止損，是以亟需一套完整的資料監控體系以便可以及時發現線上問題，保障業務能夠線上上穩定運作。
目标
能夠從業務線出發，設計、梳理出一套合理準确的通用資料監控體系建設方案，進而應用到其他業務場景，指導不同業務線的資料監控體系建設，提高品質保障能力。
資料監控體系的建設需要建立全面可靠的效果度量名額，以此衡量監控體系建設效果：
- 建立核心業務資料監控體系，核心業務名額、性能等相關名額 100% 覆寫。
- 保障核心業務名額、核心功能的異常彈框和異常界面展示相關名額的品質穩定性，相關異常問題發現周期降低至小時級。
- 建立資料監控名額設定的流程規範：全場景規範統一。
存在的挑戰
在資料監控體系建設過程中，主要面臨如下兩類挑戰：
（一）制定有效可靠的監控體系建設方案：
- 監控名額的确定：保障核心功能的監控名額覆寫度是監控體系的重要前提。
- 監控次元和手段：建構資料監控體系，最重要的一點是需要定義合理的監控次元和手段。
- 統計方式：不同類型的監控名額，采取合理的統計方式非常重要，否則容易引入噪音，誤導決策。
- 報警門檻值：如何結合實際的業務名額和名額資料波動确定合理的報警方式和門檻值尤為重要，否則容易誤報、錯報和漏報。
- 診斷分析：根據報警資訊如何快速診斷定位是監控體系的價值所在。
（二）監控體系的落地與營運：
保障跨團隊合作的任務執行效果以能夠達成項目目标，實作價值。
解決方案
針對上述兩類挑戰，本章節從監控體系的建設方案、監控體系的落地與營運兩部分展開說明解決方案的整體思路。
（一）監控體系建設方案
監控體系建設方案主要分為監控名額的确定、監控能力、監控建設以及問題處理四部分。
第一部分：監控名額
監控名額的确定，核心思想是通過梳理業務場景，同時結合名額分層，進行确定不同類别的監控名額：業務名額、可用性名額、性能名額。
以業務驅動的自頂向下的分層資料監控體系，主要包括：業務層監控、應用層監控和系統層監控三層。
業務層監控在監控體系中是最直覺的名額，它可以監控使用者使用業務的真實情況和業務的健康狀态，與業務結果直接挂鈎。
應用層監控是監控體系的核心，監控的是和服務穩定性、業務系統性能密切相關的軟體系統運作名額，主要分為可用性名額和性能名額兩類：響應時間、流量、錯誤率/成功率、錯誤碼。
- 響應時間：用戶端側響應時間統計和服務端側響應時間統計，用戶端計算端到端的耗時，包括服務端執行耗時、網絡互動耗時等。服務端耗時隻包含服務提供方的執行耗時。
- 流量：衡量流經網絡的請求數量，可能是 http 請求也可能是 RPC 請求，也可能是發送到處理隊列的消息。
- 成功/失敗率：主要是不同功能接口調用成功/失敗的機率。
- 錯誤碼：主要統計不同功能請求失敗之後的不同狀态錯誤碼。
系統層監控是監控體系的底層，主要由研發和運維同學關注，重點監控的是運作軟體系統的硬體裝置的相關名額。
其中系統層監控主要指的是機器資源或者中間件運作狀态相關的監控，該部分一般有比較成熟的配套運維監控政策和報警規範，是以在此處重點讨論前兩個和業務關聯性更高的名額體系建設。
第二部分：監控能力
整體監控體系當中，現有平台能夠支援什麼能力的監控方式以及針對不同名額選取合适的監控方式也極為重要。目前知乎現有監控主要分為如下幾個類型，不同種類監控的适用不同的監控名額和資料源，現針對幾種監控詳細介紹一下不同類型監控的能力。
用戶端實時監控，針對産品名額拆解的核心業務埋點以及參與應用層名額計算的技術埋點，主要包括核心業務場景及細粒度埋點名額、業務性能名額及業務可用性名額：
特性：
1. 借助用戶端的埋點上報進行監控，更加貼近使用者側的感覺，埋點資料更加豐富，可以做到監控使用者所有的操作流程，同時還可以發現一些服務端無法監控的場景問題，建設全面的業務監控。
2. 可以更快速、更及時的發現問題，針對可能出現的線上問題反應更靈敏。
3. 同時由于線上流量的波動性較大，是以會給監控配置帶來一定的困難，需要監控系統可以降低噪音，減少誤報。
平台：Grafana + firing 報警等。
用戶端離線監控，針對數倉表的日次元彙總資料進行監控，主要關注産品名額對應的業務名額：
特性：
1. 資料來源為已進行初步資料處理的數倉表，比較适合天次元統計的産品關注的業務名額，通過對離線資料進行天次元統計，進而降低資料波動性帶來的影響。
2. 但是因為是離線資料，同時是 T+1 的資料，比較滞後，發現問題也就會有延遲。
平台：DQC「離線資料分析平台」。
服務端實時監控，主要關注請求成功率的 log 日志等資訊，監控服務可用性和性能名額，主要指接口的請求量、耗時以及接口成功率：根據服務端的接口請求情況和打點資料進行監控，更加關注應用提供給使用者的能力是否滿足一定的 SLA，可以比較友善的發現服務端問題。
第三部分：監控建設
基于上述監控名額分層和監控平台能力認知一背景前提，下面主要闡述一下監控建設的核心要素。
Grafana 監控大盤
GF 大盤配置方案核心要素主要包括：監控次元、資料聚合方式等。
監控次元
設定合理的監控次元，能清晰、直覺的了解不同細分次元下的資料情況，能夠有效幫助下鑽次元的分析。監控次元主要利用業務特定次元和通用次元核心思想進行拆解，通用次元我們主要指 APP 版本和手機系統等。
在設定次元時還需要考慮名額壓力的問題，否則就會出現報表查詢慢、查詢報錯等問題：
- 控制次元的數量，次元越少，查詢速度越快。
- 控制每個次元值的個數，不要攜帶高次元的變量在名額裡，比如：使用者 id，請求 ip，随機 id，task id 之類的都是不應該攜帶的。
- 如果次元比較重要但是值比較多，可以考慮限定取值的範圍，比如頁面次元的值會比較多，限定取量最大的 top 頁面。
資料聚合方式
監控資料往往是一個波動的數值，當我們需要處理監控資料時，通常需要借住統計手段來輔助分析。常見監控資料的統計方式有原始值（observation），最大值/最小值（max/min），平均值（avg），數量（count），百分比（%），百分位（percentile）。
針對不同類型的監控名額，采用合理的統計方式非常關鍵，否則容易引入噪音，誤導決策。例如：統計某應用叢集級别響應時間，如果隻統計平均響應時間，容易被幾個極高或極低值幹擾，進而導緻均值資料偏高或偏低，這種情況使用百分位更為合适。通常用 50 分位，95 分位，99 分位三擋，能很好排除極值幹擾，展現叢集真實響應時間水位。
報警政策
報警政策核心是檢查項名額的确定、查詢結果資料預處理方式及門檻值設定。
檢查項名額的确定主要依賴于 grafana 大盤配置的資料聚合名額 & 名額的計算方式，常見的名額計算方式主要有直接取值、同環比，函數參考：https://graphite.readthedocs.io/en/latest/functions.html
查詢結果資料預處理方式分為五種：最大值、最小值、平均值、總值、最後一個值。
門檻值設定：分為單個門檻值和動态門檻值。單個門檻值表示隻要滿足目前設定的門檻值就會報警。動态門檻值可以根據設定的時間進行不同時間範圍動态報警。
Grafana 大盤和監控報警平台配置結束後，需要在每一個環節進行資料 check & 修正，最後通過報警規則的試運作，進行報警政策的優化以及資料彙總修正。
第四部分：問題進行中心
值班機制
建立 & 确定值班組的成員，确定值班政策，并配置到報警規則中，確定在報警發生時有對應的值班同學及時響應，做出相應的動作，避免線上問題的發生。
報警分析
收到報警通知後，需要分析原因，目前需要人工去分析，可以采用以下幾種方式進行分析：
- 應用層名額：失敗率、錯誤率之類的報警，直接分析錯誤碼監控報表，可以直接定位錯誤碼。
- 業務層名額：在監控報表中下鑽具體次元分析，細分哪些次元下出現的名額異常，進而縮小排查範圍。
（二）落地與營運
- 品質保障營運手段：通過裡程碑拆解明确任務責任人和完成節點，并輔助通過項目周會營運機制確定任務的落地效果與方案的疊代優化。
- 團隊協同 & 外部關聯：與 RD、PM 側成立資料監控體系品質建設摸排小組，持續推動優化監控體系的建設。
- 業務推廣：前期通過試點業務的落地進行監控體系建設方案的效果衡量與優化，進而由點及面推廣至其餘業務。
效果總結
整體來說，資料監控體系建設已取得階段性進展，所有結果均符合預期。我們可以通過資料監控體系提高線上問題的召回和發現能力，進而提升品質保障體系的全面性和可靠性，最終服務于線上品質。
-
體系建設上：
在社群消費場景 0-1 建設資料監控體系，落地 n+ 業務，核心名額覆寫率 100%，主要展現在：
1. 「業務覆寫度」以社交業務為試點，進而在消費側推廣，共落地 n+ 業務。
2. 「名額覆寫率」核心名額覆寫度 100%。
3. 「大盤 & 報警配置」共完成相關業務大盤配置 200+ 項，報警 300+ 項。
-
發現問題能力上：
社群消費場景通過營運資料監控體系，累計攔截問題 * 次，有效問題 * 個 。
1. 用戶端實時監控：目前核心場景問題發現時長已能通過報警達到小時級感覺問題能力。
2. 用戶端離線監控：建設産品業務名額問題發現能力。
3. 服務端實時監控：目前服務端穩定性品質問題發現效率已能達到十分鐘級感覺問題能力。
作者:紅丸子靜靜
出處:https://zhuanlan.zhihu.com/p/614526578