對于很多大型企業（如阿里巴巴）來說，經過多年的技術演進，系統工具和架構已經高度垂直化，服務器規模也達到了比較大的體量。當服務規模大于一定量（如10000臺）時，小概率的硬件故障每天都會發生。這時如果需要人的干預，系統就無法可靠的伸縮。

為此每一層的系統都會面向失敗做設計，對下游組件零信任，確保在故障發生時可以快速的發現和處理。但這些措施在故障發生時的有效性、故障恢復工具的真實容災能力、處理問題人員的熟練度，溝通機制、容災措施對上層的影響等問題，平時并沒有太多的機會驗證，往往都是在真實故障中暴露。

故障演練就是這個背景下誕生的，沉淀通用的故障場景，以可控成本在線上故障重放，以持續性的演練和回歸方式的運營來暴露問題，不斷驗證和推動系統、工具、流程、人員能力的提升，從而提前發現并修復可避免的重大問題，或通過驗證故障發現手段、故障修復能力來達到縮短故障修復時長的作用。

故障演練驗證，是指基于混沌工程的故障演練實現對業務系統的驗證。演練可以分為有損演練和無損演練，一般通過低頻的有損演練發現業務架構問題、驗證業務容災能力，通過高頻的無損演練實現對業務的監控發現/報警響應、組織應急等能力進行驗證。

演練方案設計理論基礎

技術型故障分析歸納，大致可以按照IaaS、PaaS、SaaS的層次進行歸類。

上面的分類是一個宏觀視角，不是一個系統設計的視角。所以可以對故障模型再做一次升級，并得到一些推論：

• 故障是來自于硬件（如IaaS層），軟件（如PaaS或SaaS）的故障。并且有個規律，硬件故障的現象，會在軟件故障現象上有所體現。

• 故障隸屬于單機或是分布式系統之一，分布式故障包含單機故障。

• 對于單機或同機型的故障，以系統為視角，故障可能是當前進程內的故障，比如：如FullGC，CPU飆高； 進程外的故障，比如其他進程突然搶占了內存，導致當前系統異常等。對于大多數無損突襲演練的故障模擬，只需要關注故障對當前系統的影響，而不是真的需要外部產生故障。

• 此外，還有一類故障，可能是人為失誤，或流程不當導致，這部分不做重點討論。

常見的故障類型都可以映射到這個故障模型中，模擬故障的演練系統及方案也可以基于該模型進行設計。在設計演練方案的過程中，可以考慮在模型中每個環節進行故障注入，驗證故障應急方案。

不同演練類型和目標

根據演練過程對線上業務的影響，演練可分為有損演練和無損演練。由于對業務的影響不同，兩種演練可以進行的演練頻次、可實現的業務驗證目標都有不同。

有損演練是指直接在線上真實業務環境注入異常進行演練，演練模擬的真實有效性高，為了平衡業務影響一般會選擇最核心場景、在業務最低峰期做演練，而且演練頻次相對較小，例如為了驗證多活容災能力的機房斷網演練，一般是一個月一次的演練頻次；無損演練是指在一套無線上真實業務流量的隔離環境做演練，配合壓測模擬流量注入異常進行演練，由于業務無損，可以支持較高頻次的演練，比如為了類比/形變復現線上類似故障、驗收故障復盤的改進action、演練監控感知能力/報警響應能力等，可以組織對不同業務團隊輪流參與的每周1次的高頻演練。

故障演練實踐參考

阿里巴巴集團借助混沌工程實現了無損演練和有損演練的常態化執行，縮短建設大規模演練實施的進程、加速演練執行效率，讓業務更聚焦在架構/流程風險識別與系統優化/容災能力建設上，保障混沌工程實驗投入產出比最大化。

生產環境做三大類場景的低頻演練：

• 機房斷網演練，通過對業務資源的IP級別編排，實現先單個業務斷網演練驗證，再逐步擴大業務范圍、直至所有業務的機房斷網演練，保證線上多活容災能力的持續有效性，避免因業務迭代、基礎設施/中間件變化導致的多活容災能力失效問題；

• 全民掃雷收集發現的線上重大架構/業務問題的模擬驗證以及修復后的驗收；

• 一年左右一次的生產突襲演練，一般由CTO操作注入，驗證從監控感知發現->報警快速響應->高效組織應急->定位排查止損的全鏈路故障處理流程。

仿真環境（常態引流1%線上流量的全鏈路灰度環境，或者新業務建設環境）做高頻的模擬演練：

• 各業務自身監控感知能力/報警響應速度的演練驗證；

• 各業務的歷史故障形變/抽象的場景，在本業務和其它業務做回放演練驗證，以及歷史故障重要改進措施的演練驗收；

• 各業務組織應急協同能力以及各類預案有效性演練驗證。