什麼是混沌工程 (Chaos Engineering)? 為什麼業界都在用?

當提到混沌工程，最可能會聯想到的詞是混沌猴 (Chaos Monkey) 與猿猴大軍 (Simian Army) 等一系列由 Netflix 所開源的混沌工程工具。雖然早在 Netflix 推出混沌猴之前，業界早已有類似的實踐方式，但是最早開始用混沌 (chaos) 這個名詞，甚至讓混沌工程成為業界顯學，非 Netflix 莫屬。

Netflix 在 2010 年開始，在內部推出混沌猴，之所以命名為混沌猴，是想像有一隻狂暴的猴子，跑進資料中心當中搞破壞，例如把伺服器的電線拔掉、把磁碟啃壞。而 Netflix 可靠性工程團隊的目標，是即使出現這麼一隻混沌猴，也能確保 Netflix 提供給終端使用者的服務不會中斷。

由於 Netflix 整體的架構是依賴於 AWS，所以最開始混沌猴是模擬 AWS 的服務實例故障。但在實務中，會導致事故的原因有很多種，所以除了最初的混沌猴，Netflix 進一步推出猿猴大軍，例如延遲猴 (Latency Monkey) 用來模擬某個 RESTful API 的延遲性增加後，不會影響整體服務。

在混沌猴被證實有幫助後，Netflix 團隊進一步拓展，把混沌猴升級成混沌金剛 (Chaos Kong)。原本混沌猴是終止單一實例，而混沌金剛則是模擬整個 AWS 區域都被關閉，確保假如 AWS 某個區域掛掉 (歷史上曾有過幾次全球事故正是因為這個原因)，系統能順暢地切換到別的區域，讓服務不受影響。

前面提到，在混沌工程這個詞被標準化之前，各家公司也有相似的實踐方式。舉例來說，Amazon 著名的以應對事故聞名的災難大師 (Master of Disaster) Jesse Robbins，在 Amazon 中推出 GameDay 的演練，在演練中會模擬資料中心遇到災害、服務的依賴被阻斷、網路被切斷等不同狀況，觀察系統是否能夠有足夠的韌性應對。

混沌工程的價值為何?

在初步了解混沌工程的簡史後，讓我們進一步來談混沌工程能為軟體團隊帶來什麼價值。

混沌工程就像軟體系統的疫苗一樣，打疫苗是刻意注入病毒，而混沌工程則是刻意注入故障。但這樣有意為之的行為，反而能夠協助提升系統的免疫力。在可控的範圍當中刻意注入故障，不論是終止實例、錯誤配置檔或是注入延遲，都可以讓團隊了解目前的系統韌性是否足夠。

在實務上，事故可能發生在任何想得到、想不到的地方，可能是機器所在的資料中心可能出事、網路傳輸過程可能出事、第三方依賴可能會出事、某個配置錯誤可能會出事。因此，透過混沌工程的方式來驗證，能夠讓團隊更有信心不擔心事故發生。

舉例來說，假如有混沌猴的搗亂後，系統還能順利運作 (例如即使某個 AWS 區域整個被關閉，Netflix 仍能順利將影片串流給觀眾)，那軟體團隊就能說對自家的系統韌性有足夠信心。

更進一步說，由於混沌工程多半是預先規劃執行，所以是在可靠性工程團隊上班時間，假如在注入故障時真的造成事故，團隊也能第一時間處理。這會好過假如事故是在下班時間出現，臨時把值班工程師叫醒處理來得好。

對於有一定規模的軟體產品來說，如果在生產環境中任何事故，都可能造成極大損失。因此，混沌工程帶給團隊的信心，讓 Netflix 等公司，在軟體工程部門底下，都會設立專門的混沌工程師 (Chaos Engineer) 團隊。

混沌工程如何幫助 Netflix 度過大規模實例重啟

前面談到，混沌工程可以帶給軟體工程團隊信心，先前 Netflix 團隊曾在 Cassandra Summit 中分享 (連結)，當年 AWS 曾告知 Netflix 團隊，因為他們發現某個安全漏洞，所以需要重啟所有的 EC2 實例，這代表 Netflix 透過 EC2 跑的所有 Cassandra 節點都會被重啟。

這種大規模重啟對於可靠性工程團隊來說，是會讓人冷汗直流的事件，因為不能保證所有的實例在重啟過程都不會出錯。假如有實例沒有順利重啟，Netflix 團隊需要偵測到，以及要把導向該實例的請求轉到其他實例。

這聽起來簡單，但實際如果沒有跑過一次流程，也無法確保整個偵測與導流會是順的。為了在實際的重啟日到來前，累積足夠的信心，Netflix 團隊透過混沌工程，先小規模模擬幾個 Cassandra 節點出問題，然後確保出問題的節點能被偵測到、新的實例會被開啟，以及請求會被順利導向新的實例。

在實際執行後，他們發現有流程中有一些問題，但在實際重啟日前解決。到了實際重啟日，全球 218 個節點被重啟，結果真的有 22 個出問題，但 Netflix 已經跑通的流程，讓沒有成功重啟的節點，也能順利地被處理。

從這個例子中，我們可以看到混沌工程帶來的價值；因為有混沌工程，在實際重啟日來臨時，Netflix 的工程師可以自在安心、免於焦慮。

如何執行混沌工程?

Netflix 的工程團隊有出一本《Chaos Engineering》專書 (連結)，書中有談到透過四個步驟，來執行混沌工程。

混沌工程的第一步，是先定義穩定狀態 (steady state)，理想上是寫下能夠量化的指標。舉例來說，Netflix 團隊用的指標包含每秒的影片播放數量、上游服務的 API 延遲與錯誤率、系統的吞吐量等。這類似於 SLO 的設定 (不熟 SLO 設定的讀者，推薦回顧 SLO 是什麼? 如何為團隊設定 SLO? 一文)。

除此之外，在選擇要先執行哪類故障注入時，可以先思考「哪個面向最可能出問題」以及「哪個面向出問題後影響會最大」。以批判的角度看待自己的系統，並試著找出潛在弱點，並優先以該面向做為混沌工程的核心聚焦點。

設定完穩定狀態後，接著就要建立假設。這個步驟就像在做實驗一樣，要建立所謂的虛無假設 (null hypothesis)；換句話說，會假設在注入錯誤後，不會影響到穩定狀態。舉例來說，可以設立「即使注入故障到主快取，也不會影響系統的延遲」這個假設。

建立虛無假設後，要找到足夠的證據來拒絕該假設，如果無法成功拒絕，就代表假設成立。所以在執行混沌工程時，要盡可能打破「即使注入故障到主快取，也不會影響系統的延遲」這個假設，假如無法打破，就代表真的不會影響到系統。

接著，就要透過注入不同的故障，來去打破前一步驟設立的假設。以「即使注入故障到主快取，也不會影響系統的延遲」這個假設來說，可以透過不同方式來影響主快取，例如大量增加未命中快取的請求、用大量請求轟炸主快取的負荷。

在實際採取不同手段後，最後一步驟是具體評估，看假設是否被打破。以上面的例子來說，如果透過各類方式影響主快取後，仍無法影響系統的延遲，那就可以證明「即使注入故障到主快取，也不會影響系統的延遲」這個假設是成立的。

當然，假如在試圖打破假設的過程中，真的打破假設了，例如真的影響到系統的延遲，那這時候需要立即停止。與此同時，團隊需要開檢討會，來討論為什麼系統被影響、如何改善來避免被影響。

閱讀更多

在了解完執行混沌工程的流程後，相信大家可能會想知道執行時有哪些注意事項。我們在 E+ 成長計畫的主題文有更詳細的說明，感興趣的讀者，歡迎加入 E+ 後閱讀。對更深入了解這個主題，以及其他前後端開發、軟體工程、AI 工程主題感興趣的讀者，歡迎加入 E+ 成長計畫一起成長 (連結)。