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