摘要
在當(dāng)今數(shù)字化轉(zhuǎn)型步伐不斷加快的時(shí)代，IT應(yīng)用系統(tǒng)的穩(wěn)定運(yùn)行成為了企業(yè)的業(yè)務(wù)正常運(yùn)轉(zhuǎn)的重要基礎(chǔ)，因此，運(yùn)維管理體系的構(gòu)建也從圍繞著數(shù)據(jù)中心轉(zhuǎn)向圍繞著應(yīng)用系統(tǒng)方向，首個(gè)專門面向應(yīng)用運(yùn)維的理論體系——SRE，由Google發(fā)布后，受到了越來越多的企業(yè)的青睞，很多國(guó)內(nèi)企業(yè)已經(jīng)紛紛效仿Google建立SRE團(tuán)隊(duì)，旨在為各個(gè)業(yè)務(wù)應(yīng)用系統(tǒng)提供更好的穩(wěn)定性保障能力，為業(yè)務(wù)保駕護(hù)航。
企業(yè)轉(zhuǎn)型與快速發(fā)展帶來的業(yè)務(wù)異構(gòu)化必然導(dǎo)致了IT環(huán)境的多樣化異構(gòu)化，在不同業(yè)務(wù)架構(gòu)和應(yīng)用架構(gòu)下，IT踐行SRE理念、建設(shè)一個(gè)先進(jìn)的穩(wěn)定性平臺(tái)也必然是一個(gè)循序漸進(jìn)的過程，本文主要參考SRE中的部分核心理論，從運(yùn)維標(biāo)準(zhǔn)化和技術(shù)工具層面闡述如何建設(shè)穩(wěn)定性能力。
關(guān)于SRE和穩(wěn)定性
SRE的理論很多人都已經(jīng)比較熟悉，最早是Google的一本書《Site Reliability Engineering: How Google Runs Production Systems》分享了他們?nèi)绾螛?gòu)建、部署和運(yùn)維監(jiān)控他們龐大的軟件系統(tǒng)。
SRE提出的目標(biāo)：
只要是軟件，就可能存在bug或者各種運(yùn)行上的問題。而SRE就是聚焦于的軟件系統(tǒng)的穩(wěn)定性運(yùn)行。
SRE提出的管理體系：
SRE提出了要有服務(wù)質(zhì)量目標(biāo)（SLO）、on-call輪值、變更和事故管理、故障復(fù)盤、應(yīng)急響應(yīng)機(jī)制等一系列的管理手段。
SRE提出的組織體系：
SRE強(qiáng)調(diào)以軟件工程的方式來解決這些穩(wěn)定性問題，SRE團(tuán)隊(duì)中所有的人都具有軟件開發(fā)能力，其中50% ~ 60%是純軟件工程師，40% ~ 50%既具備軟件開發(fā)技能，又具備運(yùn)維技術(shù)（PS：如果運(yùn)維能有這樣的人員配比，感覺“永不宕機(jī)”指日可待）。
SRE提出的技術(shù)體系：
人員能力目標(biāo)太難達(dá)到，我們還是從“事”的角度出發(fā)吧。Google認(rèn)為SRE的職責(zé)在于負(fù)責(zé)軟件系統(tǒng)的可用性、時(shí)延、性能、效率、變更管理、監(jiān)控、應(yīng)急響應(yīng)和容量管理相關(guān)的工作。
前面提到，在企業(yè)IT環(huán)境異構(gòu)化的情況下，穩(wěn)定性能力建設(shè)絕不是一個(gè)簡(jiǎn)單的話題，它需要標(biāo)準(zhǔn)化、流程化、數(shù)據(jù)化，需要將ITOM的配置、監(jiān)控、自動(dòng)化、流程等能力融合，需要我們結(jié)合多年的運(yùn)維經(jīng)驗(yàn)和不斷涌現(xiàn)的各種運(yùn)維技術(shù)來逐步構(gòu)建、升華。
穩(wěn)定性能力建設(shè)的基礎(chǔ)
首先，標(biāo)準(zhǔn)化先行。
運(yùn)維界現(xiàn)在在大談AIOps，但我們知道，除了關(guān)鍵的AI算法能力外，有質(zhì)量的數(shù)據(jù)也是AI的基礎(chǔ)。對(duì)于運(yùn)維來說也是如此，高質(zhì)量的運(yùn)維數(shù)據(jù)是AIOps落地的基礎(chǔ)，高質(zhì)量的運(yùn)維數(shù)據(jù)不會(huì)憑空出現(xiàn)，需要IT標(biāo)準(zhǔn)化。同樣，穩(wěn)定性的踐行，要求我們實(shí)現(xiàn)一定程度的標(biāo)準(zhǔn)化。
對(duì)于大部分企業(yè)來說，由于處于數(shù)字化轉(zhuǎn)型高速發(fā)展的階段，并且由于歷史的原因，業(yè)務(wù)應(yīng)用架構(gòu)短期內(nèi)很難以實(shí)現(xiàn)標(biāo)準(zhǔn)化，異構(gòu)化一定是一種常態(tài)，那運(yùn)維在標(biāo)準(zhǔn)化訴求面前是否就束手無策了呢，其實(shí)未必，我們?nèi)匀豢梢哉业搅硪粭l標(biāo)準(zhǔn)化的道路，就是把我們的運(yùn)維基礎(chǔ)能力抽象、標(biāo)準(zhǔn)化，來適配各種不同的業(yè)務(wù)架構(gòu)。
01 CMDB標(biāo)準(zhǔn)化
CMDB標(biāo)準(zhǔn)化有以下兩個(gè)基本原則：
以應(yīng)用為中心建設(shè)CMDB，并且標(biāo)準(zhǔn)應(yīng)用部署拓?fù)淠Ｐ停鐦I(yè)務(wù)-環(huán)境-子系統(tǒng)-集群-模塊（參考下圖），讓其能支撐傳統(tǒng)、分布式、云原生等各種應(yīng)用架構(gòu)。
從配置消費(fèi)（發(fā)布、監(jiān)控、自動(dòng)化等）角度出發(fā)，在CMDB中標(biāo)準(zhǔn)化應(yīng)用系統(tǒng)及其相關(guān)資源的模型信息，如應(yīng)用進(jìn)程、API、網(wǎng)站、應(yīng)用調(diào)用關(guān)系，應(yīng)用關(guān)聯(lián)的數(shù)據(jù)庫(kù)，容器工作負(fù)載、容器集群和命名空間配置模型等等（參考下圖）
除了上述兩點(diǎn)之外，在運(yùn)維新時(shí)代，要做好一個(gè)CMDB，不僅僅是工具，還需要配套的標(biāo)準(zhǔn)規(guī)范、組織、流程，這里不進(jìn)行一一贅述，有興趣的同學(xué)可以翻閱過往的文章：
【深度好文】以應(yīng)用為中心的CMDB究竟應(yīng)該如何設(shè)計(jì)？
【深度好文】回歸本質(zhì)，重新認(rèn)識(shí)CMDB ——CMDB項(xiàng)目建設(shè)思考
02 監(jiān)控標(biāo)準(zhǔn)化
在以業(yè)務(wù)系統(tǒng)穩(wěn)定性為目標(biāo)的前提下，我們對(duì)監(jiān)控提出了新的要求：
監(jiān)控對(duì)象標(biāo)準(zhǔn)化
監(jiān)控系統(tǒng)需要與以應(yīng)用為中心的CMDB打通，監(jiān)控系統(tǒng)中的監(jiān)控對(duì)象來自于CMDB中標(biāo)準(zhǔn)化管理的應(yīng)用資源對(duì)象，從而具備以應(yīng)用視角的監(jiān)控展現(xiàn)和分析能力。
監(jiān)控指標(biāo)標(biāo)準(zhǔn)化
每個(gè)應(yīng)用系統(tǒng)所提供的業(yè)務(wù)功能各不相同，應(yīng)用系統(tǒng)的架構(gòu)和資源組成也多種多樣，但我們?nèi)钥梢孕枰獜母鱾€(gè)層次、各個(gè)維度來抽象出一套相對(duì)通用的應(yīng)用系統(tǒng)可觀測(cè)性指標(biāo)（見下圖）。
03 能力標(biāo)準(zhǔn)化
經(jīng)過抽象之后，自動(dòng)化運(yùn)維的底層能力主要包括以下幾種：
命令通道能力
提供基于os之上的各種命令執(zhí)行通道，如shell、bat、perl、sql等等。
文件通道能力
提供快速的文件傳輸能力。
數(shù)據(jù)通道能力
提供標(biāo)準(zhǔn)的數(shù)據(jù)采集框架支持各種類型數(shù)據(jù)采集，如日志、系統(tǒng)性能、數(shù)據(jù)庫(kù)、腳本和自定義協(xié)議采集等。
API通道能力
提供統(tǒng)一的API Gateway來管理和對(duì)接各個(gè)業(yè)務(wù)系統(tǒng)或運(yùn)維系統(tǒng)的接口。
持續(xù)拓展能力
其他自定義協(xié)議對(duì)接。
04 運(yùn)維場(chǎng)景標(biāo)準(zhǔn)化
要實(shí)現(xiàn)穩(wěn)定性的目標(biāo)，還需要不斷積累各種標(biāo)準(zhǔn)化運(yùn)維場(chǎng)景能力，如故障分析場(chǎng)景、故障自愈場(chǎng)景、應(yīng)急處置場(chǎng)景。
其次，標(biāo)準(zhǔn)化之后，我們還需要考慮流程化，比如CMDB的配置入庫(kù)流程，監(jiān)控告警的處理閉環(huán)流程，發(fā)布變更流程，故障處理流程、故障復(fù)盤及知識(shí)庫(kù)沉淀的流程等等。
最后，數(shù)據(jù)化則是穩(wěn)定性踐行的關(guān)鍵基礎(chǔ)，舉個(gè)故障分析定位的例子，一個(gè)故障可能是配置變更或軟件版本更新導(dǎo)致，可能是依賴的外部服務(wù)故障導(dǎo)致，可能是自身的數(shù)據(jù)庫(kù)、進(jìn)程或代碼運(yùn)行問題導(dǎo)致，定位問題的過程，一定要能夠整合這些配置、流程、監(jiān)控等數(shù)據(jù)，才能實(shí)現(xiàn)一定程度的故障分析定位自動(dòng)化。這里額外提一下，在當(dāng)前企業(yè)架構(gòu)多樣化的情況下，基于AI的告警收斂和關(guān)聯(lián)，只是故障分析中的一個(gè)能力組成，而不是理想主義者所期望的，基于AI去分析海量告警信息就能直接實(shí)現(xiàn)根因定位。
如何建設(shè)穩(wěn)定性平臺(tái)
基于SRE的理論，應(yīng)用運(yùn)維應(yīng)該打造自己的穩(wěn)定性保障平臺(tái)。“穩(wěn)定性”仍然是一個(gè)比較泛的概念，因此我們可以從它的反面——“故障”來切入。
結(jié)合ITIL中事故管理和問題管理的理論，應(yīng)用運(yùn)維構(gòu)建故障分析和處置平臺(tái)能力，可以參照以下故障管理的閉環(huán)進(jìn)行開展：
01 故障預(yù)防階段
1. 需要基于標(biāo)準(zhǔn)化的CMDB和監(jiān)控告警系統(tǒng)構(gòu)建容量分析體系，以提前預(yù)測(cè)發(fā)現(xiàn)應(yīng)用性能瓶頸，避免故障發(fā)生（見下圖）
2. 積累標(biāo)準(zhǔn)化的和應(yīng)用個(gè)性化的應(yīng)急處置自動(dòng)化預(yù)案，以便于應(yīng)用在發(fā)生故障時(shí)可以快速恢復(fù)
3. 根據(jù)應(yīng)用高可用架構(gòu)標(biāo)準(zhǔn)，自動(dòng)評(píng)估各個(gè)應(yīng)用系統(tǒng)的架構(gòu)可用性能力
4. 針對(duì)關(guān)鍵的業(yè)務(wù)系統(tǒng)，構(gòu)建混沌工程來檢驗(yàn)業(yè)務(wù)系統(tǒng)對(duì)故障的自動(dòng)屏蔽和消除能力，并不斷積累通用的混沌工具場(chǎng)景
02 故障發(fā)現(xiàn)階段
1. 從Metric、Logging、Tracing三種方式實(shí)現(xiàn)應(yīng)用系統(tǒng)的全方位監(jiān)控和告警
2. 基于自動(dòng)化的能力實(shí)現(xiàn)應(yīng)用系統(tǒng)組件和業(yè)務(wù)功能的主動(dòng)健康檢查
3. 基于單指標(biāo)異常檢測(cè)的算法實(shí)現(xiàn)一定程度的故障預(yù)測(cè)能力。
03 故障分析和定位階段
要實(shí)現(xiàn)故障的分析定位，首先，我們得對(duì)應(yīng)用系統(tǒng)故障源有清晰和全面的了解。根據(jù)多個(gè)行業(yè)及客戶的調(diào)研數(shù)據(jù)，應(yīng)用系統(tǒng)的故障一般會(huì)有以下幾種來源：
A、基礎(chǔ)設(shè)施可用性問題
包括域名不可達(dá)、網(wǎng)絡(luò)設(shè)備或主機(jī)故障、主機(jī)磁盤空間爆滿、進(jìn)程卡死或停止等。
B、基礎(chǔ)設(shè)施性能問題
包括數(shù)據(jù)庫(kù)、中間件、消息隊(duì)列、負(fù)載均衡、操作系統(tǒng)等遇到性能瓶頸等。
C、應(yīng)用調(diào)用鏈問題
由一個(gè)服務(wù)引發(fā)了另一個(gè)服務(wù)的異常。
D、代碼異常問題
業(yè)務(wù)邏輯設(shè)計(jì)或代碼隱藏缺陷引發(fā)的可用性或性能問題，或由于變更更新引發(fā)的應(yīng)用故障。
在標(biāo)準(zhǔn)化的CMDB、監(jiān)控和流程等運(yùn)維體系的基礎(chǔ)上，我們希望故障分析和定位系統(tǒng)，能夠結(jié)合以上這些運(yùn)維經(jīng)驗(yàn)幫我們排查和定位問題：
從應(yīng)用視角進(jìn)行基本可用性分析
從應(yīng)用視角進(jìn)行基礎(chǔ)資源問題分析
基礎(chǔ)資源問題分析展示
從應(yīng)用視角進(jìn)行用戶體驗(yàn)問題分析
從應(yīng)用角度進(jìn)行應(yīng)用性能問題分析
應(yīng)用運(yùn)行日志告警展示
故障影響分析能力
基于CMDB中應(yīng)用調(diào)用關(guān)系、資源關(guān)聯(lián)關(guān)系提供故障傳播鏈，展示故障上游受影響組件和下游可能的故障源組件。
容量分析能力
根據(jù)容量分析能力判斷當(dāng)前資源容量是否能夠支撐業(yè)務(wù)訪問量或交易量。
近期變更前后關(guān)鍵指標(biāo)對(duì)比分析
獲取近期變更數(shù)據(jù)，展示和對(duì)比變更前后應(yīng)用系統(tǒng)關(guān)鍵的可用性和性能指標(biāo)數(shù)據(jù)。并結(jié)合故障時(shí)間點(diǎn)進(jìn)行關(guān)聯(lián)分析。
故障匯總與定位看板
匯總展示關(guān)鍵指標(biāo)告警及分析結(jié)果。
04 故障處理階段
- 根據(jù)應(yīng)用架構(gòu)特征，提供快速的限流降級(jí)、服務(wù)熔斷的微服務(wù)自動(dòng)化運(yùn)維能力
最后，在故障復(fù)盤階段，除了分析相關(guān)的RPO/MTTR/SLA等指標(biāo)，還需要通過流程等手段沉淀新故障場(chǎng)景到知識(shí)庫(kù)中，以不斷提升故障分析和處置能力。
