2.2.4 體系化度量

1.度量的意義

管理大師彼得·德魯克說過：“如果你無法度量它，你就無法管理它。”要想做到有效管理，就難以繞開度量問題。實際上，人們容易傾向于關注那些容易度量的元素，而忽略那些難以度量的元素。容易度量的并不一定是最重要的，相反，那些難以度量的可能才是最重要的。度量是一把雙刃劍。度量具有極強的牽引作用，可能引導你成功，也可能引導你失敗。它會激勵你重視并改善那些能夠度量的元素，但也可能因為你忽視了那些無法度量的元素而使之惡化。

DevOps的推廣打破了傳統開發與運維之間的壁壘。全員以產品交付為最終目標，全面提高效率，完成業務需求。久而久之，消費者就會產生這樣的潛意識：買了DevOps產品工具，企業就具備了DevOps能力。雖然DevOps工具提供了一個全新的視角去審視整個公司的人員配置、業務流程、企業文化等，打通了開發與運維信息壁壘，把以前的信息孤島變成高速公路，但并不意味著可以高枕無憂了，因為高速公路也會堵車！

在微服務架構應用廣泛的時代，只有將DevOps全生命周期的重要度量指標連接起來，提供從業務需求、開發、測試、運維等各種視角的參數，才能使得管理者準確把握產品市場定位，在產品發展的每個時期進行合理的資源配置，預測風險產品的關鍵風險，懂得取舍、不斷試錯，保持利潤的最大化。

“度量驅動運維”（Metrics-Driven Operation）即在運維過程中，平臺監控、運維及優化都建立在度量的基礎上。

2.度量提高可觀測性

可觀測性（Observability）其實并不是一個新詞，早在幾十年前就被廣泛地用于控制理念中，用來描述和理解自我調節系統。隨著新一代技術如容器、微服務、Serverless等的迅速應用，系統之間的訪問關系越來越復雜，一個核心業務系統可能會運行成百上千個微服務，導致傳統的監控技術和工具很難跟蹤微服務應用之間的通信路徑和相互依賴關系。因此，系統內部的可見性變得越發重要。

可觀測性其實與監控系統很像，可以說其本質是一樣的，同樣在解決一個問題：度量企業的基礎設施、平臺和應用程序等，以及了解它是如何運行的，運行狀態是否正常。但兩者應對的問題域卻完全不同，監控告訴我們哪些系統或組件是正常工作的，可觀測性告訴我們系統或組件為什么不工作了。度量是一個可深可淺的詞，比如回到這樣一個問題：你的應用是可觀測的嗎？可能某些人會給出肯定的答案，他們認為應用可觀測就是監控應用的健康狀態。對于Kubernetes里的容器來說，使用Prometheus就可以開箱即用地監控它。沒錯，狀態是能夠被監控的，通過監控系統可以知道某個時刻的活動狀態，但微服務之間的關聯關系以及某個微服務容器出現問題后產生的影響我們并不清楚。

量化目標是一切工作的起點，所有運維工作都應圍繞服務水平目標（Service Level Objective，SLO）指標進行規劃、執行、跟蹤及反饋。其中在業務規劃階段，我們通常會選擇合適的服務等級指標（Service Level Indicator，SLI），并設定對應的SLO。圍繞業務側關注的SLI、SLO，運維團隊會拆解成各個管控指標和相關活動去完成。關于SLI的定義，Google提出了VALET（Volume、Availability、Latency、Error和Ticket）方法，這5個單詞就是SLI指標的5個維度。

?Volume（容量）：代表服務承諾的最大容量是多少，比如常見的QPS、TPS、會話數、吞吐量以及活動連接數等。

?Availability（可用性）：代表服務是否正常或穩定，比如請求調用HTTP 200狀態的成功率、任務執行成功率等。

?Latency（時延）：代表服務響應是否足夠快，比如時延是否符合正態分布，須指定不同的區間，比如常見的P90、P95、P99等。

?Error（錯誤率）：代表服務有多少錯誤率，比如5××、4××，以及自定義的狀態碼。

?Ticket（人工干預）：代表是否需要人工干預，比如一些復雜故障場景需要人工介入來恢復服務。

根據SLO定義業務相對應的SLI后，跟蹤SLO的達成情況，時刻提醒還有多少錯誤預算、是否應該調整業務版本發布的策略或節奏，更加聚焦人力在質量管控方面的優化。我們可以對接監控與ITSM系統，獲取故障單據、影響時長等數據，自動計算SLO相關的指標，定期統計并做團隊反饋。

3.度量體系成熟度

運維服務能力評估是面向業務用戶的自服務的評估，按照運維架構能力建設和管理的進化歷程，運維服務成熟度可以分為4個級別。

1）基本級：依據《信息技術服務運行維護標準》（GB/T 28827.1）（以下簡稱《標準》）實施滿足業務需求的運維服務管理，日常的運維活動實現有序運行。對標準的實施不要求全面性和系統性，而是根據業務發展情況，采用《標準》提供的方法。

2）拓展級：依據《標準》實施運維服務管理，實施標準要求的全面性和系統性，并能與業務發展情況相結合，形成較為完善的人員、過程、技術和資源等方面的管理制度，并有效實施。

3）改進級：在全面和系統實施《標準》的基礎上，從保障運維服務交付質量的角度出發，形成完善的運維服務體系，建立人員、過程、資源和技術等能力要素協同改進的制度體系。

4）提升級：在全面和系統實施《標準》的基礎上，從量化提升運維服務能力的角度出發實施有關運維服務質量評價。組織能夠基于信息技術服務業務綜合發展的需要，實現全面量化的運維服務能力管理，形成推動業務服務變革的機制。

運維服務能力度量體系要求運維服務能力達到運維成熟度的提升級別，即從量化出發評價運維服務價值與質量。運維服務能力度量指標示例見表2-1。

4.度量驅動改進

運維的體系化度量整體架構圍繞CMDB、監控、ITSM等運維系統數據、用戶數據、業務數據與第三方數據進行數據治理與分析計算，構建應用健康檔案與人員服務水平畫像，結合指標管理規范的約束，以業務為導向進行度量指標的規劃、設計和優化，實現精準化運營，如圖2-9所示。

在該理念架構的指導下，企業可以建設數字化的運維度量指標體系，持續改進運維各個活動與過程。度量驅動改進主要關注運維全生命周期中各種度量數據的收集、統計、分析和反饋，通過可視化的度量數據客觀反映運維目標的達成情況，以全局視角分析系統約束點，并在團隊內部共享信息，幫助設立客觀、有效的改進目標，并調動團隊資源進行優化改造，如圖2-10所示。同時對行之有效的改進內容進行總結和分享，幫助組織更大范圍受益于改進項目的效果，打造學習型組織和信息共享機制，不斷驅動持續改進和價值交付。