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

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

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

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

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

檢測

我們先從檢測開始。

資源

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

• CPU
• 內(nèi)存
• 磁盤
• 網(wǎng)絡(luò)

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

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

應(yīng)用

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

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

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

依賴

應(yīng)用系統(tǒng)運行除了依托的環(huán)境，還會有對其他應(yīng)用或數(shù)據(jù)庫、緩存、消息隊列等這些基礎(chǔ)服務(wù)的依賴。每種依賴都需要單獨去分析依賴的強弱、可替代性，并提供其可用率、性能等基本監(jiān)控指標(biāo)，為診斷提供依據(jù)。

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

收集

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

收集的方式無外乎兩種：

• Agent 采集上報
• 應(yīng)用主動上報

對于系統(tǒng)資源和一些使用的開源軟件，一般都是 Agent 采集上報到中心服務(wù)器，而自研的應(yīng)用多采用主動上報方式的，最后在中心監(jiān)控平臺上提供抽象視圖呈現(xiàn)。如下圖，一個針對 Redis 集群的數(shù)據(jù)收集整合視圖，視圖最高按集群提供整體數(shù)據(jù)監(jiān)視，若有異?？上裸@到具體集群中某一臺機器上。

告警

監(jiān)測數(shù)據(jù)收集上來后，如何去分析、預(yù)警這是一個乍一看簡單實際很不簡單的事情。

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

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

在應(yīng)激式報警的基礎(chǔ)上，增加分析和診斷邏輯，形成針對應(yīng)用系統(tǒng)特有的分級診斷式告警。這種告警是一般通用監(jiān)控預(yù)警系統(tǒng)做不了的，而需要應(yīng)用系統(tǒng)自己在通用數(shù)據(jù)收集和告警的基礎(chǔ)上來做?？上У氖沁@目前還只是一個設(shè)想，但方向我感覺是沒錯的。

預(yù)案

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

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

...

最后總結(jié)下，一份高可用系統(tǒng)的的保養(yǎng)指南包括下面四個方面：

• 檢測
• 收集
• 告警
• 預(yù)案

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

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

研發(fā)水平的體現(xiàn)在于工具的打造和使用。

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