作者 | 穹谷
導讀：從上篇開始，我們進入到了高可用的章節，上篇提到的熔斷能力，是曆年保障大促當天晚上整個系統不被洪峰流量打垮的法寶。本文将重點介紹為什麼我們要做混沌工程以及如何使用 ChaoBlade 工具和 AHAS 平台快速實施混沌工程。
前言
從上篇開始，我們進入到了高可用的章節，上篇提到的熔斷能力，是曆年保障大促當天晚上整個系統不被洪峰流量打垮的法寶，本篇介紹的措施與熔斷有不一樣的地方，一個是線上洪峰來臨時的保護措施，它更多的是流量低峰或者在專門的演練環境中，針對可能遇見的各類故障，采取演練的手段，來窺探對業務的影響；它的主要目的是讓我們自己更加了解自己業務系統的薄弱環節，以便來對症下藥增強系統的高可用能力。
為什麼需要混沌工程？
任何一個系統都會有未曾可知的故障出現，拿現代工藝已經很好的磁盤來說，有統計資料的磁盤最低的年故障率都可達到 0.39% 。即便是這麼底層基礎設施，也會有這麼高的不确定性。
尤其當下大部分的服務形态都是分布式架構，在分布式系統架構下，服務間的依賴日益複雜，更很難評估單個服務故障對整個系統的影響；并且請求鍊路長，監控告警的不完善導緻發現問題、定位問題難度增大；同時業務和技術疊代快，如何持續保障系統的穩定性和高可用性受到很大的挑戰。
1. 雲原生系統挑戰更大
談到雲原生，可以說雲原生是一個理念，主要包含的技術有雲設施、容器、微服務、服務網格、Serverless 等技術。雲設施指公有雲、專有雲和混合雲等，是雲原生系統的基礎設施，基礎實施的故障可能對整個上層業務系統造成很大影響，是以說雲設施的穩定性是非常重要的。
容器服務的挑戰可以分兩大類：一類是面向 K8s 服務提供商，服務是否穩定；另一類是面向使用者，配置的擴縮容規則是否有效，實作的 CRD 是否正确，容器編排是否合理等問題。
分布式服務的挑戰主要是複雜性，單個服務的故障很難判斷對整個系統的影響；service mesh，sidecar 的服務路由、負載均衡等功能的有效性，還有 sidecar 容器本身的可用性。
一些新興的部署模式的挑戰如 serverless，現在基本上都是函數加事件的形式，資源排程是否有效，而且 serverless 服務提供商屏蔽了一些中間件，你能掌控的是函數這些服務，那麼你可以通過混沌工程去驗證你函數調用的一些配置，比如逾時配置、相關的一些降級政策等這些是否合理。
以上技術都有相同的共性，比如彈性可擴充、松耦合、容錯性高、還有一些易于管理，便于觀察這些特性。是以說在雲原生時代，通過混沌工程可以更有效的推進系統的“雲原生”化。
2. 每個職位都需要懂混沌工程
混沌工程是一種思想，它讓系統中的每個參與者都學會去考慮一件事情：如果所依賴的某服務中斷了服務該怎麼辦？對于以下四類人群而言，意義尤顯突出：
- 對于架構師來說，可以驗證系統架構的容錯能力，我們需要面向失敗設計的系統，混沌工程的思想就是踐行這一原則的方式；
- 對于開發和運維，可以提高故障的應急效率，實作故障告警、定位、恢複的有效和高效性；
- 對于測試來說，可以彌補傳統測試方法留下的空白，之前的測試方法基本上是從使用者的角度去做，而混沌工程是從系統的角度進行測試，降低故障複發率；
- 對于産品和設計，通過混沌事件檢視産品的表現，提升客戶使用體驗。是以說混沌工程面向的不僅僅是開發、測試，擁有最好的客戶體驗是每個人的目标，是以實施混沌工程，可以提早發現生産環境上的問題，并且可以以戰養戰，提升故障應急效率和可以使用體驗，逐漸建設高可用的韌性系統。
混沌工程實操
在一次完整的演練流程中，需要先做好計劃，對相關的演練計劃有一個行為預期；演練相關計劃的同時，我們推薦的最佳實踐是需要配合有業務的自動化測試，每演練一次需要全方位的跑完自動化測試用例，這樣才能全面的了解真正的業務産生時對業務造成的影響：
在上面的圖中描述了一次完整的故障演練需要經過的步驟，其中最重要的一步的實踐是如何“執行預制混沌實驗”？因為這一步需要一個專業的工具，在業内目前最流行的工具是 Netflix 的 Chaos Monkey 和阿裡巴巴開源的
ChaosBlade，我們接下來主要是介紹如何使用 ChaosBlade 來完成一次演練。
1. 使用 ChaosBlade 去做
是阿裡巴巴一款遵循混沌實驗模型的混沌實驗執行工具，具有場景豐富度高，簡單易用等特點，而且擴充場景也特别友善，開源不久就被加入到 CNCF Landspace 中，成為主流的一款混沌工具。目前包含的場景有基礎資源、應用服務、容器服務、雲資源等。ChaosBlade 下載下傳解壓即用，可以通過執行 blade 指令來執行雲原生下微服務的演練場景，下面是模拟 Kubernetes 下微服務中資料庫調用延遲故障。
2. 使用 AHAS 故障演練平台去做
AHAS 故障演練平台是阿裡雲對外部使用者開放的雲産品，使用方式可參考
官方文檔。其底層的故障注入能力大部分來源于 ChaosBlade 實作，另一部分使用自身小程式擴充實作。AHAS 相比于 ChaosBlade，除了簡單易用的白屏操作之外，還實作了上層的演練編排、權限控制、場景管理等，而且還針對微服務新增應用次元演練，簡化演練成本，優化演練體驗。
結尾
混沌工程是一種主動防禦的穩定性手段，展現的是反脆弱的思想，實施混沌工程不能隻是把故障制造出來，需要有明确的驅動目标。我們要選擇合适的工具和平台，控制演練風險，實作常态化演練。
阿裡巴巴内部從最早引入混沌工程解決微服務的依賴問題，到業務服務、雲服務穩态驗證，進一步更新到公共雲、專有雲的業務連續性保障，以及在驗證雲原生系統的穩定性等方面積累了比較豐富的場景和實踐經驗；這一些經驗沉澱我們都通過開源産品以及雲産品
AHAS一一對外輸出。
相關文章推薦：
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 —— 開發篇》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 部署篇(開發部署）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 部署篇(工具部署)》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可灰階）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 診斷（線上聯調）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可監控）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可復原）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（優雅上下線）》
- 《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 高可用（熔斷）》
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”