Maxkit: Chaos Engineering

2018/03/12

Chaos Engineering

Chaos Engineering 是一個在分散式系統中進行實驗測試的準則，透過這樣的方法，可提升系統在正式環境中處理災難性異常的能力，對系統的穩定性更有信心。

大型的分散式系統已經改變了傳統的軟體工程方法，現在的網路服務目標都是以快速彈性的開發方式提供新的服務，對於開發人員來說，面對這樣複雜的服務系統，在將軟體更新到正式環境之前，到底有多大的信心，可以在更新後，不將系統弄壞。

在三十年前，Jim Gray 提出要提高可靠性 availability 的方法，就是使用驗證過的軟體跟硬體，然後就可以不用再管他。但現今對於提供 Internet Service 的公司來說，持續改變，增加新功能的網路服務，不能再用這樣的方法。

Netflix 在 2012/7/20 發佈了 Chaos Monkey 專案，它的作用是可以隨機刪除在正式環境中運作的 VM instance and container，原因是：要避免失敗最好的方法，就是平常就要經常失敗。這有點像是不定時的災難演習，讓工程師跟開發人員，平常就能習慣災難，這樣自然而然就能建造出一個穩定的系統，不會在意外真正發生時，人仰馬翻。

Chaos Monkey 只會在平日週一到週五 9:00~15:00 運作，Netflix 在應付一般的異常狀況，一兩個 VM 斷線並不會導致系統失效，當然如果真的發生問題，也能因為該問題而受惠，因為這樣的問題可以影響系統設計，並解決問題。

隨著這些網路服務大廠針對「正式環境的破壞」實驗越來越熟悉，他們認為這樣的破壞概念，應該要更正式地成為一個新興的服務及產業，也就是 "Chaos Enginerring"，簡單地說，Choas Engineering 就是在分散式系統上的實驗工程，用來建立網路服務正式環境的災難處理能力。這些實驗包含硬體故障、客戶端服務量突然暴增、設定參數異常等等，這也是 PRINCIPLES OF CHAOS ENGINEERING 所要說明的內容。

CHAOS IN PRACTICE

Chaos Engineering 就是要簡化系統弱點實驗的程序。實驗要遵循以下四個步驟

定義"穩定狀態"的系統測量值，用來表示系統是否正常運作的量測數值
假設該穩定狀態會持續發生在實驗組及對照組
找出現實世界發生的災難事件，例如 server crash、硬體故障、網路異常等等
嘗試反證，無法找出實驗組及對照組的"穩定狀態"之間的差異。換句話說，就是嘗試不讓實驗組及對照組的"穩定狀態"之間的量測數據不同。

如果 "穩定狀態" 的數據越穩定，就表示系統讓人更放心。如果有未經測試的弱點，那就有改善的目標。

ADVANCED PRINCIPLES

要運用 Choas Engineering，還要注意以下的使用原則

面對 Steady State Behavior 提出假設

要注意系統輸出的可量測數值，而不是系統的內部屬性。可透過 proxy 量測一段時間內的數據，系統的 throughput, error rate, latency percentiles 都是 steady state behavior 可觀察的 metrics。Chaos 可幫助我們證明系統穩定可靠，而不是去了解系統如何運作。
真實世界的意外事件

Chaos variables 就是真實世界可能發生的事件，有可能是 server crash，軟體回應異常，網路流量異常上升，任何會影響 "steady state" 的事件，都是 Chaos experiment 的實驗變因。
在正式環境中進行實驗

系統的行為會根據運作環境及網路流量而不同，為確保 Chaos experiment 是針對正式環境，強烈建議要用真正正式環境的 traffic 進行實驗。
自動化持續的實驗

讓 chaos engineering 自動並持續在正式環境中運作
限制影響的範圍

在正式環境實驗有可能會造成某些客戶使用的異常，但這些異常都只會造逞短暫的不便。