完整內容在此, 幹話王_Docker 環境中用 Pumba 進行混沌測試

Chaos Engineering

「混沌不是深淵，而是發現系統韌性的鏡子」

混沌工程是什麼，不是什麼？

最常見的誤解是混沌工程只是隨機地破壞營運環境中的事物。

只要可以幫助我們確信系統可以抵禦突發事件的方法其實都可以稱為混沌工程。混沌工程主要透過實驗性的方法，從而建立對系統抵禦營運環境中突發事件能力信心的工程。換句話說，混沌工程是一種透過主動注入故障來驗證系統韌性的方法，目標是在真實故障發生前暴露系統脆弱性。

混沌工程 v.s. 故障演練 v.s. 測試 的差別

混沌工程實驗聽起來與另外兩個很像, 但目的其實差異很大。

• 混沌工程 v.s. 測試

測試目的是關注已知的斷言是否通過. 混沌工程關注的是發現更多未知的暗債。

• 混沌工程 v.s. 故障演練

故障演練側重於操練已知的故障應對流程, 混沌工程側重透過實驗發現更多未知的暗債。

在營運環境上執行實驗, 會有風險

其實任何有人在使用的系統都會有所謂的暗債, 未知的意外可能發生, 這些都是不可預測的. 即使我們不主動引入故障風險, 其實這些風險本來就存在著, 不是不會發生只是時候未到. 所以混沌實驗要定義最小化爆炸半徑來進行實驗.

其次團隊文化也不該一昧要求工程團隊不能也不應該出現任何問題或失誤. 一但有這樣強硬的規範定案下去, 以後在未知的故障出現時, 大部分會出現甩鍋情況, 耽誤了更多發現更多暗債以及設計防範措施的時間.

嘗試看看

團隊如果有以下理由的話，不坊考慮實踐混沌工程試試看︰

• 確定風險與成本，並設定 SLI、SLO 與 SLA。

• 在整體上測試系統（相比於端對端的測試，更加全面）。

• 找到團隊忽略的**湧現性（Emergence）**特性。在複雜系統中，服務與組件之間的複雜交互可能導致意想不到的系統行為。例如，多個服務自己正常運作，但組合在一起時於高負載下出現極大的延遲或故障發生。

實驗的 4 個步驟︰

定義穩態指標

定義什麼是正常的，這取決於該系統跟目標。你可以是沒有刮傷的車以 80 KM 的速度上陽明山，也能是其他的條件視為正常。最常見的大概是「9x %的使用者可以在 xxx ms 內訪問系統的 API」。要定義哪些穩態指標，應該直接由業務策略來驅動設計的。能參考 Alex 的 Implementing Service Level Objectives: A Practical Guide to SLIs, SLOs, and Error Budgets 一書。

但我們前面有說混沌工程是更加全面的。其實很多因素都會影響這個指標。例如系統程序是否獲得足夠的 CPU time 與 memory？或者這些資源正在被其他程序佔用著。是不是 kernel 把 CPU 分配給令一個更高優先權的程序？諸如此類的。

設計實驗假設

在這階段，我們要把直覺塑造成一個可驗證的假設，在一個明確定義的問題出現時，你的系統會發生什麼情況的有根據的猜測。系統會繼續工作嘛？還是逐漸變慢？變慢了多少？

現實中容易出問題的場景大概常見的如下︰

• 環境事件（斷電、水災、地震…）

• 硬體故障（CPU, Mem, Disk, Switch、變壓器）

• 系統資源（CPU, Mem, 硬碟空間、頻寬）

• 軟體問題（Bug, Crash, Leak, Hack attack)

• 系統瓶頸

• 不可預期的湧現性特性

• 硬體的 bug

• 人為失誤（設定錯誤、不小心關機….）

最簡案例

o11y 顯示的是我們跟使用者是否能夠成功調用 API。穩態指標是 API 都能成功的回覆。實驗假設是如果 cache 失效了，依然能獲得回覆。執行實驗，發現現在版本存在缺陷，新版本修復後正常。

常見誤區澄清表

Pumba(a)

Pumba 是一個針對 Docker 容器進行混沌測試的工具，可以終止容器（kill、stop、remove），模擬網路問題（netem）、對容器的 cgroup 資源進行壓力測試（stress）等。

完整內容在此, 幹話王_Docker 環境中用 Pumba 進行混沌測試