AWS 雲上混沌工程實踐之啟動篇-知識星球

亞馬遜 AWS 官方部落格開通了混沌工程專欄，此為首篇介紹混沌工程的文章。從混沌工程的基本概念出發，對現實中混沌工程實踐的突出困惑做了分析和解答，並以混沌工程的演進時間線為例，詳述了混沌工程社群的發展，不是一蹴而就，而是在實踐中逐步深入對混沌工程的理解：從最初對基礎設施的擾動實驗（Chaos Monkey），發展出整套猴子軍團 Simian Army，為控制實驗的爆炸半徑提出故障註入測試（FIT），再到精細化流量配比以對照區分，直至引入斷路器實現真正的無人值守。

工程師團隊最不願碰到的便是大半夜被電話叫醒，開始緊張地查驗問題，處理故障以及恢復服務。也許就是因為睡前的一個很小的變更，因某種未預料到的場景，引起蝴蝶效應，導致大面積的系統混亂、故障和服務中斷，對客戶的業務造成影響。特別是近幾年，儘管有充分的監控告警和故障處理流程，這樣的新聞在 IT 行業仍時有耳聞。問題的癥結便在於，對投入生產的複雜系統有多少信心。監控告警和故障處理都是事後的響應與被動的應對，那有沒有可能提前發現這些複雜系統的弱點呢？

混沌工程 Chaos Engineering

在分散式系統上進行由經驗指導的受控實驗，觀察系統行為併發現系統弱點，以建立對系統在規模增大時因意外條件引發混亂的能力和信心。

混沌工程發展簡介

2008年8月， Netflix 主要資料庫的故障導致了三天的停機， DVD 租賃業務中斷，多個國家的大量使用者受此影響。之後 Netflix 工程師著手尋找替代架構，併在 2011 年起，逐步將系統遷移到 AWS 上，執行基於微服務的新型分散式架構。這種架構消除了單點故障，但也引入了新的複雜性型別，需要更加可靠和容錯的系統。為此， Netflix 工程師建立了 Chaos Monkey ，會隨機終止在生產環境中執行的 EC2 實體。工程師可以快速瞭解他們正在構建的服務是否健壯，有足夠的彈性，可以容忍計劃外的故障。至此，混沌工程開始興起。

混沌工程演進時間線

圖中展示了混沌工程從 2010 年演進發展的時間線：

2010 年 Netflix 內部開發了 AWS 雲上隨機終止 EC2 實體的混沌實驗工具：Chaos Monkey
2011 年 Netflix 釋出了其猴子軍團工具集：Simian Army
2012 年 Netflix 向社群開源由 Java 構建 Simian Army，其中包括 Chaos Monkey V1 版本
2014 年 Netflix 開始正式公開招聘 Chaos Engineer
2014 年 Netflix 提出了故障註入測試（FIT），利用微服務架構的特性，控制混沌實驗的爆炸半徑
2015 年 Netflix 釋出 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 釋出 ChAP （混沌實驗自動平臺），可視為應用故障註入測試（FIT）的加強版
2017 年由Netflix 前混沌工程師撰寫的新書“混沌工程”在網上出版
2017 年 Russell Miles 創立了 ChaosIQ 公司，並開源了 chaostoolkit 混沌實驗框架

今天，許多公司包括 FANG，都有自己的 Chaos Engineer ，使用某種形式的混沌工程實驗，來提高現代架構的可靠性。由於混沌工程的目的是給複雜的分散式系統引入擾動，並觀察系統行為，藉此發現系統弱點。因此，混沌工程實驗中涉及的可行性調研、實驗場景和環境的設計與計劃、工具的選型和配合方式、系統行為的觀測方法、以及找到問題後如何改善系統架構和運維樣式，都需要科學的分析和有經驗的混沌工程專家指導。根據筆者的觀察，多數使用者對混沌工程實踐躊躇不前，總繞不開下麵這幾個問題：

問題 1：混沌工程是不是隻適合像 FANG 這樣技術成熟的大公司，擁有複雜的分散式系統，很強的研發和運維能力？

答：否。混沌工程進行的是探索系統複雜性的開放實驗，目的是改善原有的系統架構和運維樣式，加強業務服務的健壯性。沒有像 FANG 那樣複雜的分散式系統，一樣需要混沌工程實踐來達到健壯性的目的，只是混沌工程設計實施的複雜性不同、實踐的成熟度不同：技術成熟的大公司，由於其系統的複雜性更大，無法完全理解透徹其上下游紛繁的依賴關係，因此更需要藉助混沌工程實踐，並利用自身較強的研發和運維能力，來深入瞭解系統行為以提高穩定性。另外，從資源獲取的角度上看，在雲上實施混沌工程實驗，對其他公司而言，更加便捷有效。

問題 2：混沌工程實驗像 Chaos Monkey 只是殺殺機器而已，運維看看就好了吧？

答：否。回溯混沌工程發展的時間線，業界對混沌工程的理解是逐步深入的。Netflix 開發的 Chaos Monkey 成為了混沌工程的開端，但混沌工程不僅僅是 Chaos Monkey 這樣一個隨機終止 EC2 實體的實驗工具。隨後混沌工程師們發現，終止 EC2 實體只是其中一種實驗場景。因此， Netflix 提出了 Simian Army 猴子軍團工具集，除了 Chaos Monkey 外還包括：

Latency Monkey 在 RESTful 客戶端到伺服器通訊中引入隨機延遲，以模擬服務降級並測量上游服務是否正確響應。
Conformity Monkey 在發現不符合最佳實踐的實體時將其關閉。
Doctor Monkey 會在每個實體中執行健康檢查，同時也透過其他外部監控指標來檢測不健康的實體。一旦檢測到不健康的實體，將它們從服務中刪除，並且在實體所有者找到問題的原因後終止。
Janitor Monkey 搜尋未使用的資源並按規則處理，以確保AWS上的環境資源有效避免浪費。
Security Monkey 在發現安全違規或漏洞時，如發現未正確配置的AWS安全組，並終止使用該違規安全組的實體。此外，還會確保所有的 SSL 和 DRM 證書有效且無需續訂。
10-18 Monkey （l10n-i18n）針對多個區域和國家的客戶提供服務的實體，檢查有關語言和字符集的配置。
Chaos Gorilla 模擬了 AWS 可用區域（AZ）的中斷，以驗證服務是否會自動平衡至可用的 AZ，而無需人工幹預，也不會給使用者帶來可見的影響。

使用 Simian Army 進行混沌工程實驗，看起來似乎已經很完美。類似像 Latency Monkey 的引入，由於服務之間的呼叫鏈傳遞，到最後這個小的擾動到底會引發多大的故障，沒有人可以預測。在生產上做這樣不可控的實驗，是很危險的。隨著故障註入測試（FIT）的提出，社群開始關註利用應用架構的特性，特別是微服務架構，來控制實驗的爆炸半徑，比如 Netflix 使用 Zuul 強大的流量檢查和管理功能，將受影響的請求隔離到特定的測試帳戶或特定裝置，避免 100％的混亂。

進一步分析發現， FIT 的執行過程也影響了整個系統的監控指標，即實驗群體與其他非實驗群體的統計指標混合不可分辨：無法確定實驗的進行時間，無法評估其影響是否超過了系統本身的噪音。為了進一步的區分，則需要進行更多更大的實驗，這將有可能給使用者帶來不必要的中斷。因此需要對實驗叢集和非實驗群集的流量配比進行精細控制，同時因應無人值守的實驗要求，則引入微服務架構中的斷路器，如其超出預定義的誤差預算，自動結束實驗。這就是為何 Netflix 提出了新的 ChAP（混沌實驗自動平臺）以加強故障註入測試。

綜上所述，混沌工程的發展不是一蹴而就的， Chaos Monkey 是其開端，但社群對混沌工程的理解在逐步深入，從對基礎設施的擾動（ EC2 實體隨機終止等），到利用應用閘道器控制爆炸半徑，再到精細化流量配比以區分影響，直至引入斷路器實現真正的無人值守。混沌工程 9 年來的發展，由淺入深，由基礎設施演進到應用架構，不是單單運維看看就好。

問題 3：混沌工程實驗的概念聽著很吸引人，可是不知道從而下手。有沒有什麼實際可落地的框架和工具呢？

答：筆者有幸參與了混沌工程的革新實踐，總結起來對混沌工程的理解有兩點特別重要：

儘量減少實驗的爆炸半徑（故障註入測試的引入）
為了確保不會破壞生產業務，工程團隊需“精心策劃”混沌工程實驗

混沌實驗不只是測試，而是生成新知識的過程（ Chaos Monkey -> Simian Army -> FIT -> ChAP ），混沌工程試驗不僅僅是測試系統的一個案例。另一方面，混沌工程是一種產生新知識的方法。正是因為現代軟體系統往往太複雜，任何人都無法完全理解它們，所以工程師透過混沌工程實驗以揭示系統的更多面。

當然混沌工程實驗有其自身的技術門檻，因此必須專家的指導並配以完善的混沌實驗框架和工具。此為整個系列的首篇，後面筆者會深入探討有關混沌工程實驗中涉及的可行性調研、實驗場景和環境的設計與計劃、工具的選型和配合方式、系統行為的觀測方法、以及找到問題後如何改善系統架構和運維樣式等等問題 – stay tune for next episode!

本文轉載自亞馬遜AWS官方部落格，原文連結：https://aws.amazon.com/cn/blogs/china/aws-chaos-engineering-start/

AWS 雲上混沌工程實踐之啟動篇

朋友會在“發現-看一看”看到你“在看”的內容

朋友將在看一看看到

釋出到看一看

相關推薦

熱門標籤

熱門文章

分享創造快樂