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