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

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

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

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

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

檢測

我們先從檢測開始。

資源

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

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

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

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

利用

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

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

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

依賴

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

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

搜集

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

搜集的方式無外乎兩種：

• Agent 收集上報
• 利用主動上報

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

告警

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

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

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

在應(yīng)激式報警的基礎(chǔ)上，增加分析和診斷邏輯，構(gòu)成針對利用系統(tǒng)獨(dú)有的分級診斷式告警。這類告警是1般通用監(jiān)控預(yù)警系統(tǒng)做不了的，而需要利用系統(tǒng)自己在通用數(shù)據(jù)搜集和告警的基礎(chǔ)上來做。惋惜的是這目前還只是1個假想，但方向我感覺是沒錯的。

預(yù)案

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

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

…

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

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

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

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

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

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

寫點(diǎn)程序世間的文字，畫點(diǎn)生活瞬間的畫兒。
微信公眾號「瞬息之間」，遇見了無妨就關(guān)注看看。