分布式系统保障—混沌工程—初识
原文作者：?朱小廝的博客
原文地址：混沌工程（Chaos Engineering）初識
|
目錄
一、概述
二、混沌工程的五大原則
三、混沌成熟度模型（Chaos Maturity Model）
四、混沌工程的目標——韌性架構
五、混沌工程實踐
六、混沌實驗工具整理
七、混沌工程案例
混沌工程是在分布式系統上進行實驗的學科，目的是建立對系統抵御生產環境中失控條件的能力以及信心。
一、概述
工程師團隊最不愿碰到的便是大半夜被電話叫醒，開始緊張地查驗問題，處理故障以及恢復服務。也許就是因為睡前的一個很小的變更，因某種未預料到的場景，引起蝴蝶效應，導致大面積的系統混亂、故障和服務中斷，對客戶的業務造成影響。特別是近幾年，盡管有充分的監控告警和故障處理流程，這樣的新聞在 IT 行業仍時有耳聞。問題的癥結便在于，對投入生產的復雜系統有多少信心。監控告警和故障處理都是事后的響應與被動的應對，那有沒有可能提前發現這些復雜系統的缺陷呢？
?
混沌工程在分布式系統上進行由經驗指導的受控實驗，觀察系統行為并發現系統缺陷，以建立對系統在規模增大時因意外條件引發混亂的能力和信心。
1. 混沌工程的發展簡史
2008年8月， Netflix 主要數據庫的故障導致了三天的停機， DVD 租賃業務中斷，多個國家的大量用戶受此影響。之后 Netflix 工程師著手尋找替代架構，并在2011年起，逐步將系統遷移到 AWS 上，運行基于微服務的新型分布式架構。這種架構消除了單點故障，但也引入了新的復雜性類型，需要更加可靠和容錯的系統。為此， Netflix 工程師創建了 Chaos Monkey ，會隨機終止在生產環境中運行的 EC2 實例。工程師可以快速了解他們正在構建的服務是否健壯，有足夠的彈性，可以容忍計劃外的故障。至此，混沌工程開始興起。
?
圖中展示了混沌工程從2010年演進發展的時間線：
2010年 Netflix 內部開發了 AWS 云上隨機終止 EC2 實例的混沌實驗工具：Chaos Monkey
2011年 Netflix release了其猴子軍團工具集：Simian Army
2012年 Netflix 向社區開源由 Java 構建 Simian Army，其中包括 Chaos Monkey V1 版本
2014年 Netflix 開始正式公開招聘 Chaos Engineer
2014年 Netflix 提出了故障注入測試（FIT），利用微服務架構的特性，控制混沌實驗的爆炸半徑
2015年 Netflix release了 Chaos Kong ，模擬AWS區域（Region）中斷的場景
2015年 Netflix 和社區正式提出混沌工程的指導思想 – Principles of Chaos Engineering
2016年 Kolton Andrus（前 Netflix 和 Amazon Chaos Engineer ）創立了 Gremlin ，正式將混沌實驗工具商用化
2017年 Netflix 開源 Chaos Monkey 由 Golang 重構的 V2 版本，必須集成 CD 工具 Spinnaker（持續發布平臺）來使用
2017年 Netflix release了 ChAP （Chaos Automation Platform, 混沌實驗自動平臺），可視為應用故障注入測試（FIT）的加強版
2017年 由Netflix 前混沌工程師撰寫的新書“混沌工程”在網上出版
2017年 Russell Miles 創立了 ChaosIQ 公司，并開源了 chaostoolkit 混沌實驗框架
2. Chaos Monkey & Simian Army
為了更好的理解混沌工程，這里我們再著重介紹一下Chaos Monkey和Simian Army。Chaos Monkey 通過關停一個或多個虛擬機來模擬 service 實例的失效。Chaos Monkey 的名字來源于其工作的方式：如同一只野生的、武裝了的猴子，在數據中心釋放后，造成的嚴重破壞。
Chaos Monkey 的原則：避免大多數失效的主要方式就是經常失效。失效一定會發生，并且無法避免。在大多數情況下，我們的應用設計要保證當服務的某個實例下線時仍能繼續工作，但是在那些特殊的場景下，我們需要確保有人在值守，以便解決問題，并從問題中進行經驗學習。基于這個想法，Chaos Monkey 僅會在工作時間內被使用，以保證工程師能發現警告信息，并作出適當的回應。
混沌工程實驗像 Chaos Monkey 只是殺殺機器而已？這是錯誤的理解。回溯混沌工程發展的時間線，業界對混沌工程的理解是逐步深入的。Netflix 開發的 Chaos Monkey 成為了混沌工程的開端，但混沌工程不僅僅是 Chaos Monkey 這樣一個隨機終止 EC2 實例的實驗工具。隨后混沌工程師們發現，終止 EC2 實例只是其中一種實驗場景。因此， Netflix 提出了 Simian Army 猴子軍團工具集，除了 Chaos Monkey 外還包括：
- Chaos Gorilla：Chaos Monkey的升級版，模擬整個Amazon Availability Zone的故障，以此驗證在不影響用戶，且無需人工干預的情況下，能夠自動進行可用區的重新平衡。
- Chaos Kong：Chaos Gorilla的升級版，模擬整個region（一個region由多個Amazon Availability Zone組成）的故障。
- Latency Monkey：在RESTful服務的調用中引入人為的延時來模擬服務降級，測量上游服務是否會做出恰當響應。通過引入長時間延時，還可以模擬節點甚至整個服務不可用。
- Conformity Monkey：查找不符合最佳實踐的實例，并將其關閉。例如，如果某個實例不在自動伸縮組里，那么就該將其關閉，讓服務所有者能重新讓其正常啟動。
- Doctor Monkey：查找不健康實例的工具，除了運行在每個實例上的健康檢查，還會監控外部健康信號，一旦發現不健康實例就會將其移出服務組。（隔離出服務，并且給相關人員足夠的糾錯時間，最終再關閉。）
- Janitor Monkey：查找不再需要的資源，將其回收，這能在一定程度上降低云資源的浪費。
- Security Monkey：這是Conformity Monkey的一個擴展，檢查系統的安全漏洞，同時也會保證SSL和DRM證書仍然有效。
- 10-18 Monkey：進行本地化及國際化的配置檢查，確保不同地區、使用不同語言和字符集的用戶能正常使用Netflix。
使用 Simian Army 進行混沌工程實驗，看起來似乎已經很完美。類似像 Latency Monkey 的引入，由于服務之間的調用鏈傳遞，到最后這個小的擾動到底會引發多大的故障，沒有人可以預測。在生產上做這樣不可控的實驗，是很危險的。隨著故障注入測試（FIT，Failure Injection Testing）的提出，社區開始關注利用應用架構的特性（特別是微服務架構）來控制實驗的爆炸半徑，比如 Netflix 使用 Zuul 強大的流量檢查和管理功能，將受影響的請求隔離到特定的測試帳戶或特定設備，避免100％的混亂。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）
進一步分析發現， FIT 的執行過程也影響了整個系統的監控指標，即實驗群體與其他非實驗群體的統計指標混合不可分辨：無法確定實驗的進行時間，無法評估其影響是否超過了系統本身的噪音。為了進一步的區分，則需要進行更多更大的實驗，這將有可能給用戶帶來不必要的中斷。因此需要對實驗集群和非實驗群集的流量配比進行精細控制，同時因應無人值守的實驗要求，則引入微服務架構中的斷路器，如其超出預定義的誤差預算，自動結束實驗。這就是為何 Netflix 提出了新的 ChAP 以加強故障注入測試。
綜上所述，混沌工程的發展不是一蹴而就的， Chaos Monkey 是其開端，但社區對混沌工程的理解在逐步深入，從對基礎設施的擾動（ EC2 實例隨機終止等），到利用應用網關控制爆炸半徑，再到精細化流量配比以區分影響，直至引入斷路器實現真正的無人值守。
混沌工程9年來的發展，由淺入深，由基礎設施演進到應用架構，不是單單運維看看就好。今天，許多公司(包括Google、Amazon、Microsoft、Germlin Inc.、University of California、Github、Thoughtworks等）都使用某種形式的混沌工程實驗，來提高現代架構的可靠性。
混沌工程也同樣適用于傳統行業，如大型金融機構、制造業和醫療機構。交易依賴復雜系統嗎？有大型銀行正在使用混沌工程來驗證交易系統是否有足夠的冗余。是否有人命懸一線？在美國，混沌工程在許多方面被當做模型應用在了臨床試驗系統中，從而形成了美國醫療驗證的黃金標準。橫跨金融、醫療、保險、火箭制造、農業機械、工具制造、再到數字巨頭和創業公司，混沌工程正在成為復雜系統改進學科的立足點。
3. 混沌工程與傳統測試之間的區別
混沌工程和傳統測試（故障注入FIT、故障測試）在關注點和工具集上都有很大的重疊。譬如，在Netflix的很多混沌工程實驗研究的對象都是基于故障注入來引入的。混沌工程和這些傳統測試方法的主要區別在于：混沌工程是發現新信息的實踐過程，而故障注入則是對一個特定的條件、變量的驗證方法。當你希望探究復雜系統如何應對異常時，對系統中的服務注入通信故障（如超時、錯誤等）不失為一種很好的方法。但有時我們希望探究更多其他的非故障類的場景，如流量激增、資源競爭條件、拜占庭故障（例如性能差或有異常的節點發出有錯誤的響應、異常的行為、對調用者隨機性的返回不同的響應，等等）、非計劃中的或非正常組合的消息處理等等。因為如果一個面向公眾用戶的網站突然收到激增的流量，從而產生更多的收入時我們很難稱之為故障，但我們仍然需要探究清楚系統在這種情況下的影響。
和故障注入類似，故障測試方法通過對預先設想到的可以破壞系統的點進行測試，但是并沒能去探究上述這類更廣闊領域里的、不可預知的、但很可能發生的事情。在傳統測試中，我們可以寫一個斷言（assertion），即我們給定一個特定的條件，產生一個特定的輸出。測試一般來說只會產生二元的結果，驗證一個結果是真還是假，從而判定測試是否通過。嚴格意義上來說，這個過程并不能讓我們發掘出對于系統未知的、尚不明確的認知，它僅僅是對我們已知的系統屬性可能的取值進行測驗。而實驗可以產生新的認知，而且通常還能開辟出一個更廣袤的對復雜系統的認知空間。混沌工程是一種幫助我們獲得更多的關于系統的新認知的實驗方法。它和已有的功能測試、集成測試等以測試已知屬性的方法有本質上的區別。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）
混沌工程實驗的可能性是無限的，根據不同的分布式系統架構和不同的核心業務價值，實驗可以千變萬化。下面是部分混沌實驗的輸入示例：
- 模擬整個云服務區域或整個數據中心故障；
- 跨多實例刪除部分 Kafka 主題來重現生產環境中發生過的問題；
- 挑選一個時間段，和針對一部分流量，對其涉及的服務間調用注入一些特定的延時；
- 方法級別的混亂（運行時注入）：讓方法隨機拋出各種異常；
- 在代碼中插入一些指令可以允許在這些指令之前運行故障注入；
- 強制系統節點間的時間不同步；
- 在驅動程序中執行模擬 I/O 錯誤的程序；
- 讓某個 Elasticsearch 集群 CPU 超負荷。
4. 實施混沌工程的先決條件
在引入混沌工程之前先要確定你的系統是否已經具備一些彈性來應對真實環境中的一些異常事件，像某個服務異常、網絡閃斷、瞬間延遲提高等。混沌工程非常適合揭露生產系統中的未知缺陷，但如果確定混沌工程實驗會導致系統出現嚴重的問題，那么運行這樣的實驗是沒有任何意義的。你需要先解決這個缺陷，然后再引入混沌工程，然后你不僅能繼續發現更多不知道的缺陷，還能提高對系統真實彈性水平（resilient）的信心。=引入混沌工程的另一個先決條件是監控系統，你需要用它來判斷系統當前的各項狀態。如果你沒有對系統行為的可見能力，那么也就無法從實驗中得出有效的結論。
二、混沌工程的五大原則
為了具體地解決分布式系統在規模上的不確定性，可以把混沌工程看作是為了揭示系統缺陷而進行的實驗。破壞穩態的難度越大，我們對系統行為的信心就越強。如果發現了一個缺陷，那么我們就有了一個改進目標。避免在系統規模化之后問題被放大。
以下原則描述了應用混沌工程的理想方式，這些原則來實施實驗過程，對這些原則的匹配程度能夠增強我們在大規模分布式系統的信心。
1. 建立一個圍繞穩定狀態行為的假說（Build a Hypothesis around Steady State Behavior）
“穩定狀態”是指系統正常運行時的狀態。具體來說，系統的穩定狀態可以通過一些指標來定義，當系統指標在測試完成后，無法快速恢復穩態要求，可以認為這個系統是不穩定的。指標可以分為系統指標和業務指標。系統指標（如CPU 負載、內存使用情況、網絡 I/O等）有助于幫助我們診斷性能問題，有時也能幫助我們發現功能缺陷。在混沌工程中，業務指標通常比系統指標更有用，因為它們更適合衡量用戶體驗或運營。業務指標通常回答這樣的問題：
- 我們正在流失用戶嗎？
- 用戶目前可以操作網站的關鍵功能嗎？例如在電商網站里為訂單付款，添加購物車等。
- 目前存在較高的延遲致使用戶不能正常使用我們的服務嗎？
- Netflix使用客戶點擊視頻流設備上播放按鈕的速率作為指標，稱為“視頻每秒開始播放數（SPS）”，在文末會有相關介紹。
如果你還不能直接獲取和業務直接相關的指標，可以暫時先利用一些系統指標，比如系統吞吐率，錯誤率，pct99延遲等。你選擇的指標和業務關系越強，得到的可以采取可執行策略就越強。同樣重要的是，在客戶端驗證服務產生的告警可以提高整體效率，而且可以作為對服務端指標的補充，以構成某一時刻用戶體驗的完整畫面。
定義好指標并理解其穩定狀態的行為之后，你就可以使用它們來建立對實驗的假設。思考一下當你向系統注入不同類型的事件時，穩定狀態行為會發生什么變化。例如，你向某個服務增加請求數，其穩定狀態是被破壞還是保持不變？如果被破壞了，你所期待系統該如何表現？我們的假設可以是實驗措施不會使系統行為偏離穩定狀態，比如：向我們的系統中注入的事件不會導致系統穩定狀態發生明顯的變化。最后我們還需要思考一下這個問題：如何衡量穩定狀態行為的變化。即便你已經建立了穩定狀態行為模型，你也需要定義清楚，當偏離穩定狀態行為發生時你要如何測量這個偏差。只有定義清楚“正常”的偏差范圍，才可以獲得一套驗證假設的完善的測試集。
2. 多樣化真實世界的事件 （Vary Real-world Events）
每個系統，從簡單到復雜，只要運行時間足夠長，都會受到不可預測的事件和條件的影響。例如負載的增加、硬件故障、軟件缺陷、還有非法數據（有時稱為臟數據）的引入。我們無法窮舉所有可能的事件或條件，但常見的有以下幾類：
- 1.硬件故障；
- 2.功能缺陷；
- 3.狀態轉換異常（例如發送方和接收方的狀態不一致）；
- 4.網絡延遲或隔離；
- 5.上行或下行輸入的大幅波動以及重試風暴；
- 6.資源耗盡；
- 7.服務之間的不正常的或者預料之外的組合調用；
- 8.拜占庭故障；
- 9.資源競爭條件；
- 10.下游依賴故障。
也許最復雜的情況是上述事件的各類組合導致系統發生異常行為。要徹底阻止對可用性的各種威脅是不可能的，但是我們可以盡可能減輕這些威脅。在決定引入哪些事件時，我們應當估算這些事件發生的頻率和影響范圍，然后權衡引入他們的成本和復雜度。我們不需要窮舉所有可能對系統造成改變的事件，只需要注入那些頻繁發生且影響重大的事件，同時要足夠理解會被影響的故障域（故障的影響范圍和隔離范圍被稱為故障的故障域）。
3. 在生產環境中運行實驗 （Run Experiments in Production）
根據環境與流量模式的不同，系統運行效果亦將受到影響。由于運行效果可能隨時改變，因此我們應將對實際流量進行采樣作為獲取可靠請求路徑的惟一方法。為了保證系統運行方式的真實性以及同現有部署系統間的關聯性，混沌工程原則強烈建議您直接面向生產流量進行實驗。
即便你不能在生產環境中執行實驗，你也要盡可能的在離生產環境最接近的環境中運行。越接近生產環境，對實驗外部有效性的威脅就越少，對實驗結果的信心就越足。
4. 持續自動化運行實驗 （Automate Experiments to Run Continuously）
當今的系統越來越復雜，這意味著我們無法預先地知道生產環境的哪些變動會改變混沌工程實驗的結果。基于這個原因，我們必須假設所有變動都會改變實驗結果。在共享狀態、緩存、動態配置管理、持續交付、自動伸縮、時間敏感的代碼等等的作用之下，生產環境實際上處在一個無時不在變化的狀態。
最開始執行混沌實驗，可能就是手動執行，但是實驗的手動運行工作屬于勞動力密集型任務，因此難以長久持續。相反的，我們應該自己投入精力來開發混沌工程的工具和平臺，以期不斷降低創建新實驗的門檻，并能夠完全自動運行這些實驗。
5. 最小化爆炸半徑 （Minimize Blast Radius）
混沌實驗通過很多方法來探尋故障會造成的未知的、不可預見的影響，關鍵在于如何讓這些薄弱環節曝光出來而不會意外造成更大規模的故障。我們稱之為最小化“爆炸半徑”。當我執行混沌實驗時，一般先只作用于很少的用戶之上，這樣的風險也最小，他們不能代表全部生產流量，但他們是很好的早期指標。當自動化實驗成功之后，就需要擴大實驗范圍：運行小規模的擴散實驗，再進行小規模的集中實驗，最后就是大規模無自定義路由的實驗。擴大實驗范圍的目的是進一步暴露小范圍實驗無法發現的一些問題。
除了不斷擴大實驗范圍，在實驗造成過多危害時及時終止實驗也是必不可少的。有些系統設計會使用降級模式來給用戶帶來稍小的影響，這還好，但是當系統完全中斷服務的時候，就應該立即終止實驗。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）
我們也會經常運行本來只會影響一小部分用戶的測試，卻由于級聯故障無意中影響到了更多的用戶。在這些情況下，我們不得不立即中斷實驗。雖然我們絕不想發生這種情況，但隨時遏制和停止實驗的能力是必備的，可以避免造成更大的危機。為了讓盡可能高效地應對實驗發生不可預期的情況，我們要避免在高風險的時間段運行實驗。例如我們只在所有人都在辦公室工作的時間段運行實驗。
三、混沌成熟度模型（Chaos Maturity Model）
標準化混沌工程定義的一個目的是，在執行混沌工程項目時，我們有標準來判斷這個項目做得是好是壞，以及如何可以做得更好。混沌工程成熟度模型（CMM）給我們提供了一個評估當前混沌工程項目成熟度狀態的工具。把你當前項目的狀態放在這個圖上，就可以據此設定想要達到的目標，也可以對比其他項目的狀態。
CMM 的兩個坐標軸分別是“熟練度（Sophistication）”和“接納度（Adoption）”。缺乏熟練度時，實驗會比較危險、不可靠、且有可能是無效的。缺乏接納度時，所做的實驗就不會有什么意義和影響。要在適當的時候變換在兩個不同維度的投入，因為在任何一個時期，要發揮混沌工程項目的最大效果需要在這兩個維度上保持一定的平衡。
1.混沌工程實驗熟練度等級
熟練度可以反映出，在你的組織中混沌工程項目的有效性和安全性。項目各自的特性會反映出不同程度的熟練度，有些完全不具備熟練度，而有些可能具備很高的熟練度。
可以基于實驗成熟度等級的8個方面進行混沌實驗可行性評估。
2. 混沌工程實驗接納度等級
接納度用來衡量混沌工程實驗覆蓋的廣度和深度。接納度越高，暴露的脆弱點就越多，你對系統的信心也就越足。
四、混沌工程的目標——韌性架構
“故障是注定的，隨著時間的流逝，一切終將歸于失敗”。我們必須接受故障發生是新常態的想法，處在部分故障的系統正常運行是完全可行的。當我們處理多達幾十個服務實例的小型系統時，100％的健康運行通常是正常狀態，故障則是一種特殊情況。然而，在處理大規模系統時，即100％的健康運行幾乎是不可能實現的。因此，運維的新常態便是接受部分故障。處在部分故障中的系統要求仍能正常運行對外提供服務，這就需要架構本身具備 Resilient 能力，這里的Resilient即為韌性（具備恢復能力）。
混沌工程就是利用實驗提前探知系統風險，通過架構優化和運維模式的改進來解決系統風險，真正實現上述韌性架構，降低企業損失，提高故障免疫力。
韌性架構的重要特征：
- 冗余性：架構的設計要增加冗余性，以便提高該系統的整體可用性。
-
擴展性：架構的設計必須要考慮擴展性，即啟用 Auto Scaling ，根據需求動態擴展資源（ 而不是手動執行） ，確保可以滿足各種流量模式。
- 不可變基礎設施：不可變基礎設施指的是，每次部署都會替換相應的組件，不做更新。應用部署則使用金絲雀發布（俗稱灰度發布），以減少部署新版本應用時出現故障的風險。使用這種技術，可以在真實的生產環境中進行測試，并在需要時進行快速回滾。
- 避免級聯故障：級聯故障指的是因依賴關系引發的局部故障導致整個系統崩潰（俗稱蝴蝶效應）。架構設計必須考慮級聯故障的處理方式：
- 轉移切換：當一個集群宕機時，所有的流量都轉移到另一個集群，如跨可用區切換，或者跨區域切換。
- 重試退避：指數退避算法逐漸對客戶端重試請求減速，避免網絡擁塞，同時添加抖動保證性能。
- 超時機制：過載請求會將連接耗盡，導致系統宕機。超時機制的引入，服務的質量會下降但不至于系統全面崩潰。
- 冪等操作：由于暫時的錯誤，客戶端可能多次發送相同的請求，可能導致系統處理錯誤。冪等操作，一種可以反復重復的操作，沒有副作用或應用程序的失敗，可以消除上述隱患。
- 服務降級：當服務器壓力劇增的情況下，有策略地減少或退化部分服務，以此釋放服務器資源以保證核心任務的正常運行，如只讀模式、停用耗時耗資源的功能等等。
- 拒絕服務：請求過載時，按優先級開始丟棄相應的請求。
- 服務熔斷：若某個目標服務調用過慢或者有大量超時，直接熔斷該服務的調用，對于后續調用請求，不在繼續調用目標服務，直接返回響應，快速釋放資源，待目標服務情況好轉則恢復調用。
- 無狀態應用。無狀態應用是自動擴展和不可變基礎設施的先決條件，要求應用必須獨立于先前的請求或會話，處理所有客戶端請求，并且不會存儲在本地磁盤或內存中。
- 基礎設施即代碼。基礎設施即代碼可減輕繁瑣的手工配置和部署任務，由于可用完全相同的方式反復執行，因此解決了隨時間推移引發的配置漂移問題，當有故障發生，基礎設施的恢復快速且有效。同時可對基礎架構以代碼的形式進行版本控制，管理其更新、審核、驗證和回溯分析。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）
五、混沌工程實踐
完整的混沌工程實驗是一個持續性迭代的閉環體系，大致分為以下幾個步驟：
- 確定初步的實驗需求和實驗對象；
- 通過實驗可行性評估，確定實驗范圍；
- 設計合適的觀測指標；
- 設計合適的實驗場景和環境；
- 選擇合適的實驗工具和平臺框架；
- 建立實驗計劃，和實驗對象的干系人充分溝通，進而聯合執行實驗過程；
- 搜集預先設計好的實驗指標；
- 待實驗完成后，清理和恢復實驗環境；
- 對實驗結果進行分析；
- 追蹤根源并解決問題；
將以上實驗場景自動化，并入流水線，定期執行；之后，便可開始增加新的實驗范圍，持續迭代和有序改進。
1. 實驗可行性評估
在前面的提及了混沌成熟度模型CMM，從熟練度和接納度對實驗技術的成熟度做了定下分析。此處的實驗可行性評估，依照這個可行性評估模型，會針對具體的實驗需求和實驗對象進行細致評估。常見的一個形式是對照“可行性評估問題表”，對實驗對象的干系人進行訪談。可行性評估問題表的內容會包含以下幾個方面：
- 架構抵御故障的能力：通過對實驗對象的架構高可用性的分析和評估，找出潛在的系統單點風險，確定合理的實驗范圍。
- 實驗指標設計：評估目前實驗對象判定業務正常運行所需的業務指標、應用健康狀況指標和其他系統指標。
- 實驗環境選擇：選擇實驗對象可以應用的實驗環境：開發、測試、預生產、生產。
- 實驗工具使用：評估目前實驗對象對實驗工具的熟悉程度。
- 故障注入場景及爆炸半徑：討論和選擇可行的故障注入場景，并評估每個場景的爆炸半徑。
- 實驗自動化能力：衡量目前實驗對象的平臺自動化實施能力。
- 環境恢復能力：根據選定的故障注入場景，評估實驗對象對環境的清理和恢復能力。
- 實驗結果整理：根據實驗需求，討論確定實驗結果和解讀分析報告的內容項。
2. 觀測指標設計與對照
觀測指標的設計是整個混沌工程實驗成功與否的關鍵之一。在進行混沌工程實驗過程中，系統可觀測性已成為一種“強制性功能”，良好的系統可觀測性會給混沌工程實驗帶來一個強有力的數據支撐，為后續的實驗結果解讀、問題追蹤和最終解決提供了堅實的基礎。以下是常見混沌工程實驗的觀測指標類型：
- 業務性指標：價值最大，探測難度最大
- 應用健康指標：反映應用的健康狀況
- 其他系統指標：較易獲取，反映基礎設施和系統的運行狀況
指標對照是指將“觀測指標”與“指標的穩定狀態”進行對照。很多的用戶還是無法定義一個合適的業務指標，如無法準確定義一個穩定狀態，那么我們也可以退而求其次，使用多個指標進行聯合分析來對照。
3. 實驗場景和環境的設計
實驗場景和環境的設計要努力遵循以下三大設計目標：
- 在生產環境運行實驗
- 持續自動化運行實驗
- 最小化實驗場景的“爆炸半徑”
實驗場景（故障注入）設計
實驗環境設計
實驗環境的不同，帶來不同的業務風險。生產環境的業務風險最大，開發環境的業務風險最小，其他依次類推。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）
建議用戶在生產環境上進行混沌工程實驗，當然前提是這些實驗場景和工具已經在開發、測試和預生產環境得到了驗證。當然在生產環境上進行混沌工程實驗也不是強制的，用戶可以選擇適合自己的推進節奏，逐步向生產環境靠攏。因為實驗越接近生產環境，從結果中學到的越多。同時，為了體現實驗對照的效果，在生產環境進行的混沌實驗可以通過真實生產流量分支的方式，組建控制組和對照組，以此區分故障注入的影響，從一定程度上控制了爆炸半徑。對于非生產環境的混沌工程實驗，可采用模擬生產流量的方式，盡量和生產流量相似，來驗證實驗場景和工具的可靠性。
六、混沌實驗工具整理
七、混沌工程案例
1. Netflix: SPS
某些組織有非常明確的，和收入直接相關的實時指標。例如像 Amazon 和 eBay 會跟蹤銷售量，Google 和 Facebook 會跟蹤廣告曝光次數。由于 Netflix 使用的是按月訂閱模式，所以沒有這類指標。Netflix也會測量注冊率，這是一個重要的指標，但是只看注冊率不能反映整體系統的健康狀況。Netflix真正想要的是一個可以反映當前活躍用戶的滿意狀況的指標，因為滿意的用戶才有可能連續訂閱。可以這么說，如果當前和系統做交互的用戶是滿意的，那么我們基本可以確定系統目前是健康的。
遺憾的是，Netflix目前還沒找到一個直接、實時的可以反映用戶滿意度的指標。Netflix會監控客服電話的呼叫量，這或許是一個可以間接反映客戶滿意度的指標，但是從運營角度出發，我們需要更快、更細粒度的反饋。Netflix 有一個還不錯的可以間接反映用戶滿意度的指標——播放按鈕的點擊率。Netflix管這個指標叫做視頻每秒開始播放數，簡稱為 SPS（Starts per sencond）。SPS 很容易測量，而且因為用戶付費訂閱服務的直接目的就是看視頻，所以 SPS 應該和用戶滿意度密切相關。這個指標在美國東海岸下午 6 點會明顯高于早上 6 點。Netflix就可以據此來定義系統的穩定狀態了。
相比某個服務的 CPU 負載來說，Netflix 的可靠性工程師（SREs）更關注 SPS 的下降：SPS 下降會立刻向他們發送告警。CPU 負載的尖刺有時重要有時不重要，而像 SPS 這樣的業務指標才是系統邊界的表述。這才是需要關注并驗證的地方，而不是那些像 CPU 負載類的內部指標。
在 Netflix，SPS 也不是一個和人體體溫一樣的穩定指標，它也隨著時間波動。下圖描繪的就是 SPS 隨時間變化的波動情況，可以看出，它有一個穩定的模式。這是因為人們習慣于在晚餐時間看電視節目。因為 SPS 隨時間的變化可以預期，所以我們就可以用一周前的 SPS 波動圖作為穩定狀態的模型。Netflix 的可靠性工程師們總是將過去一周的波動圖放在當前的波動圖之上，以發現差異。就像下圖中當前的圖線是紅色，上一周的圖線是黑色。
你所處的行業決定了你的指標是否以一種可以預期的方式隨時間波動。例如，如果你負責一個新聞網站，流量的尖刺可能來源于一個大眾關注度高的新聞事件。某些事件的尖刺可以預期，比如選舉、重大賽事，但是其他類型的事件不太可能被預測到。在這一類場景中，準確描述系統的穩定狀態將會非常復雜。無論哪種情況，描述穩定狀態都是建立有意義假設的必要前提。
2. 阿里巴巴ChaosBlade
2012 年阿里內部就上線了 EOS 項目，用于梳理分布式服務強弱依賴問題，同年進行了同城容災的斷網演練。15 年 實現異地多活，16 年內部推出故障演練平臺 MonkeyKing，開始在線上環境實施混沌實驗，然后 18 年輸出了 ACP 專有云產品 和 AHAS 公有云產品，其中 AHAS 旨在將阿里的高可用架構經驗以產品的形式對外輸出，服務于外部。19 年推出 ChaosBlade 項目，將底層的故障注入能力對外開源，同年也推出混沌實驗平臺專有云版本 AHAS Chaos。
ChaosBlade 中文名混沌之刃，是一款混沌實驗實施工具，支持豐富的實驗場景，比如應用、容器、基礎資源等。工具使用簡單，擴展方便，其遵循社區提出的混沌實驗模型。具體可以參考：阿里巴巴混沌測試工具ChaosBlade兩萬字解讀。
總結
以上是生活随笔為你收集整理的分布式系统保障—混沌工程—初识的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式计算—MapReduce、Spar
- 下一篇： Windows系统中安装Python模块