又過了一年 618，六月是公司一年一度的大促月，一般提前一個月各系統就會減少需求和功能的開發，轉而更多去關注系統可用性、穩定性和管控性等方面的非功能需求。大促前的準備工作一般叫作「備戰」，可以把線上運行系統想象成一輛車，大促即是它即將面臨的一次嚴峻駕駛考驗。

每次去長途自駕旅行時，我會把車送去對車況做一個全面的檢測。汽車工業的歷史有一百多年了，而車的構造組成部件又相對固定，已經形成了規范且全面的檢查事項，我在保養檢查手冊上看到的檢查項目包括：

• 輪胎
• 剎車
• 燈光
• 電瓶
• 油液
• 雨刷
• 底盤
• 電路
• 濾清器
• 隨車工具

上面簡單列了每一個檢查大項，而里面又包括一些細節的小項。當技師按這個檢查項目列表執行一遍后沒有發現問題，就是得出車況良好的結論。然而軟件系統的組成部件并不像汽車那樣固定，不同的軟件系統可能千差萬別，這方面有點像「人」的特性，每個人是不同的，但又是有共性的，所以醫學才能為人建立共同的檢測標準，但又需要考慮差異化并針對個體建立健康檔案，這樣才能根據檢測結果作出相對準確的診斷。

結合這次 618 備戰準備，考慮系統的共性和個性，我想嘗試看看能不能抽象出一個針對此類商業在線應用所需的高可用系統保養指南，按此對系統做一個全面地檢測后得到對系統運行的一個整體性認識，幫助更好的診斷系統可能潛藏的問題，以便做出及時的優化改進。

檢測

我們先從檢測開始。

資源

系統應用運行總是需要依托于硬件物理資源，操作系統提供了一些基本的資源使用消耗情況，包括：

• CPU
• 內存
• 磁盤
• 網絡

操作系統提供的僅僅是單機的資源使用情況，而在一個分布式系統中我們通常需要更高維度的資源使用報告，按集群，按應用等，所以這需要我們自己去做在單機粒度上的聚合和可視化呈現。

CPU 除了機器整體使用情況，最好能監測到進程級的使用，若一個進程內的 CPU 消耗明顯不正常，需要有捕捉到進程內線程 CPU 使用的方法。內存以 Java 應用為例，會更多關心 JVM 內部的內存使用和 GC 情況；而類似 Redis 這樣的內存數據庫則更多關注其內存的增長趨勢。磁盤 I/O 是存儲類應用（SQL/NoSQL 數據庫）關注的重點，而對于大部分服務類應用一般只會打打日志，只關心磁盤存儲容量的消耗。網絡，站在應用的角度主要關心可靠性（丟包率、延時）、帶寬和連接數。

應用

由于應用的形式千差萬別，我們先看共性的方面。共有的方面主要包括：

• 服務 Performance 性能指標。
  比如 API 的每秒調用量（TPS），處理延時（TP99，TP=Time Percentage)，可用率（系統成功執行次數占比）
• 服務 SLA 滿足率。
  SLA 是 Service Level Agreement（服務等級協議）的縮寫，通過靜態評估得到要承接預期量的用戶數時，各應用服務需要保證的并發能力、延時標準，并和實際搜集的數據對比得出評估服務 SLA 能否滿足。
• 服務 HA 可用率。
  服務是否業務強制需要？可用率要求有多高，必要情況下是否可降級？
• 服務 Isolation 隔離性。
  輕、重處理業務流程如何隔離？同、異步業務流程如何隔離？重要、次要的業務間如何隔離？
• 服務 Extension 擴展性。
  無狀態服務理論上可以無限橫向擴展，但實際大部分無狀態服務僅僅是把狀態外移到類似緩存和數據庫中，橫向的擴展瓶頸點就轉移到了緩存或數據庫的橫向擴展能力上。

上面屬于在應用層能抽象出的共性點，但對于具體的業務邏輯則屬于個性的地方，這就需要具體問題具體分析。比如，若實現采用了類似像異步內存隊列的方式，是否可以顯性化監測？但若想通過代碼巡檢來發現這樣的個性化場景，投入產出比低，也不太現實。所以，今年 618 我們采用了針對主要業務流程的梳理問答方式，主要用于重新思考代碼實現流程，發現一些潛在邏輯炸彈。所謂邏輯炸彈，就是在正常時一切良好，但遇到某些邊界條件可能導致系統性能急劇下降甚至宕機，在今年的備戰中確實發現了兩枚這樣的邏輯炸彈，幸甚。

依賴

應用系統運行除了依托的環境，還會有對其他應用或數據庫、緩存、消息隊列等這些基礎服務的依賴。每種依賴都需要單獨去分析依賴的強弱、可替代性，并提供其可用率、性能等基本監控指標，為診斷提供依據。

強依賴的高可用通常使用主、備方案，而弱依賴除了主、備還可以在特定情況下通過解除依賴實現業務降級，這有點像壁虎斷尾求生的場景。

收集

前面從資源、應用、依賴三個大類來全面檢測評估系統，但檢測是需要數據收集支持的。而以上三類檢測項目的數據來源都不一樣，在一個大型的分布式環境下就需要將其整合匯總提供面向更高層次的抽象視圖。

收集的方式無外乎兩種：

• Agent 采集上報
• 應用主動上報

對于系統資源和一些使用的開源軟件，一般都是 Agent 采集上報到中心服務器，而自研的應用多采用主動上報方式的，最后在中心監控平臺上提供抽象視圖呈現。如下圖，一個針對 Redis 集群的數據收集整合視圖，視圖最高按集群提供整體數據監視，若有異常可下鉆到具體集群中某一臺機器上。

告警

監測數據收集上來后，如何去分析、預警這是一個乍一看簡單實際很不簡單的事情。

當汽車沒油了就會亮一個燈提醒你加油，胎壓不足了再亮另外一個燈提醒你加氣，總之汽車的保養手冊上畫了一大堆指示燈提醒或警示你不同的注意事項，簡單直接明了。但我們前面說了軟件系統更像一個人，每年我去醫院體檢，一共幾十項大小檢查，總有那么幾項指標數字不正常，醫生有時也沒法簡單根據一兩項指標異常就能開出正確的診斷處方。

目前的通用監控預警系統一般只能根據收集的各類系統指標，設定一個合理范圍，若偏離合理范圍則發出告警。此類一一映射式的告警，僅僅完成了最初階段的任務，提醒研發去及時響應。這里面存在的問題就是，當在一個大規模分布式應用系統中，若有一個核心系統出現問題，很可能引發連鎖反應，導致告警風暴產生。在這樣的風暴中，研發有時也是抓瞎，到處都在喊著火，人人手上都有一個滅火器，卻不是知道該往哪里噴。這種情況一方面只能自己做好系統防火隔離帶，另一方面就是增強報警分析診斷。

在應激式報警的基礎上，增加分析和診斷邏輯，形成針對應用系統特有的分級診斷式告警。這種告警是一般通用監控預警系統做不了的，而需要應用系統自己在通用數據收集和告警的基礎上來做。可惜的是這目前還只是一個設想，但方向我感覺是沒錯的。

預案

預案就是假如某意外事件發生那么我們就執行某個措施，將意外造成的損失減至最低，迅速恢復系統運行。這是建立在能快速診斷的基礎上。前面告警一節說了，若沒有針對應用特有的分級診斷式告警，后續的分析、決策是很耗時的，很難達到快速恢復系統的預期目標。

把針對應用日常運營的常見問題歸類并做到告警、分析、決策和預案執行程序化后，才有可能真正真正滿足 4 個 9 或以上的系統可用性。

...

最后總結下，一份高可用系統的的保養指南包括下面四個方面：

• 檢測
• 收集
• 告警
• 預案

最終要做的就是把這四件事都做成程序化、系統化和自動化的，其中唯一需要人工參與的，我認為只有代碼分析一項，這也是程序員的最大價值所在。經歷了本次 618 后，我們還才完成了一半多點，只是半自動化，路漫漫其修遠兮。

以前忙于業務開發，每到大促都是停下或減緩業務需求來還真正的技術負債，記得好像誰說過這樣一句話：

研發水平的體現在于工具的打造和使用。

后面，我想應該需要繼續做下去的就是不斷打磨工具，讓工具可以無人值守的隨時為系統做好保駕護航。