Chaos Engineering：系統的可持續性

Chaos Engineering： 系統的可持續性

1）為什麼混沌工程

• 檢驗有關系統行為的假設並驗證SLO；
• 發現隱藏的SPOF，不正確的taymout/retrai，級聯效應；
• 訓練團隊：遊戲日，運行手冊，通訊；
• 形成「默認可持續性」而不是「希望更好」的文化。

重要的是：Chaos Engineering ≠「打破一切」。這是一種科學方法：steady-state →假設→實驗→結論→改進。

2）實驗的基本周期

1.Steady-state（基線）： 哪個SLI穩定?（例如，99歲的≤500 ms的成功。95%).

2.假設： 如果失去一個AZ，p95將增加<10％，並且≥99可用性。9%.

3.實驗：有計劃的folt,帶有有限的blast radius和停止標準。
4.觀察：度量/跟蹤器/logi，burn-rate SLO，商業SLI（例如成功存款）。
5.改進：捕獲發現，更改時間限制/路由，更新運行手冊。
6.自動化/倒退：我們在時間表中重復，我們在CI/CD和遊戲日日歷中添加。

3）安全欄桿（安全第一）

Blast radius：從狹窄開始-單個pod/實例/路線/namespace。
Guardrails：在SLO燃燒率（快速/緩慢），後退限制，QPS限制，事件預算上。

停止條件： 「如果error-rate> X%或p99> Y ms N分鐘-立即停止和滾回。」

窗口：通話工作時間，通知的攤牌，冷凍版本。
通訊：IC/Tech lead/Comms,清晰的渠道（戰爭室）,消息模板。

4）失敗類別和假設思想

網絡：延遲/jitter/損失，部分端口下降，服務/PSP之間的「翻轉」通信。
編譯器/節點：進程殺死、CPU過熱、文件描述符用盡、連接池狹窄。

存儲和DB： 光盤後端的增長,lag復制,停止一個陰影/領導,分裂腦.

依賴性：外部API降級,提供商限制,5xx/429激增。

變更管理： 發行失敗,幻燈片不好,部分滾動.

外圍：CDN降級，DNS/Anycast漂移，WAF/機器人保護失敗。
區域/AZ：完全損失或「部分」事件（稍微更糟且不可預測）。

5）工具和技術

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.

雲：AWS Fault Injection Simulator （FIS）,雲端的Fault Domains。
網絡/代理：Toxiproxy （TCP毒藥）,tc/netem, iptables, Envoy fault （delay/abort）, Istio fault injection。
過程/節點：「stress-ng」，cgroups/CPU-throttle，disk fill。
流量路由：GSLB/DNS重量,用於假冒檢查的金絲雀/藍綠色切換。

6）腳本示例（Kubernetes）

6.1 路線上延遲/abort （Istio VirtualService）

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

假設： 客戶端taymauts/retrai和CB將保持p95 <300 ms和error-rate <0。5%.

6.2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

假設：平衡器和HPA可補償單個實例的損失，而不需要p99> 20％的增長。

6.3網絡混亂（延遲到數據庫）

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

假設：池/taymout/緩存將減少影響；p95付款將保留≤ SLO。

6.4磁盤填充

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

假設：在路線退化之前，定位/配額/異位數的輪換將起作用。

7）K8s外實驗

7.1 Toxiproxy（本地/集成）

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7.2 Envoy HTTP故障（周長/mesh）

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7.3 AWS FIS（想法示例）

Auto Scaling Group的「殺死」N％ EC2實驗，人為地提高EBS-latency，並在單個AZ中禁用NAT-GW。
根據CloudWatch SLO度量標準的內置停止標準。

8）混亂期間的觀察度量

SLO/SLI: fraction of good requests, p95/p99, burn-rate.

RED模型沿著關鍵路線（Rate, Errors, Duration）。
池：等待p95連接,utilization。
DB：lag復制品，鎖定，漂移p95查詢。
網絡：retransmits，RTT，dscp/ecn行為。
業務SLI：交易成功（存款/支票），回報/錯誤百分比。
跟蹤：選擇性跟蹤（exemplars）,發布註釋的相關性。

9）與SLO/Error-budget的集成

在錯誤預算內規劃實驗：混亂不應「擾亂」季度目標。
Burn-rate alerta作為自動殺手開關。
報告：「多少預算被燒毀」，「steady-state的哪些缺點」。

10）遊戲日（練習）

劇本：簡短的傳說（例如「東地區丟失」），註射步驟，SLO目標，角色，時間。
評分：RTO/RPO實際，通信質量，運行簿正確性。
復古：有所有者和時間表的改進列表,更新文檔/dashbords。

11）自動化和CI/CD

Smoke-chaos：每次發布時都會進行短暫的堆叠測試（例如，每條路線1 pod-kill+200毫秒延遲）。
每晚/每周：報告較重的場景（5-15分鐘）。
促銷門：如果p95/錯誤>金絲雀的閾值是自動回滾。
實驗目錄存儲庫（YAML+runbook+SLO-thresholds）。

12）反模式

「打破無欄桿」：沒有停止標準，沒有呼叫→真正事件的風險。
一次性促銷而不是過程。
沒有腳步狀態的混亂：目前尚不清楚什麼可以算作成功/失敗。
註射延遲時，多余的回火→ DDoS。
忽略業務SLI：付款/訂單失敗時的「technar」成功。
缺乏後期分析和改進的所有者。

13）實施清單（0-45天）

0-10天

定義steady-state SLI（定制+業務）。
選擇工具（Chaos Mesh/Litmus/Toxiproxy/FIS）。
描述欄桿：爆炸射線，停止標準，窗口，角色。

11-25天

啟動第一個實驗：pod-kill, 100-200毫秒延遲至關鍵的apstream, drop 1%數據包。
自定義burn-rate alerta,將kill-switch與停止條件相關聯。
舉辦第一個遊戲日，收集復古和小說。

26-45天

添加AZ/依賴級別腳本（外部PSP, DD-lag）。
自動化舞臺上的夜間混亂；準備「季節性」腳本。
實驗目錄和指導/SRE的定期報告。

14）成熟度量

≥80％的關鍵路線具有描述的實驗和步進狀態度量。
自動殺手開關在超過p99/error-rate閾值時觸發。
每季度-AZ/區域級別的遊戲日；≥1次/多月-目標依賴情景。
MTTR在改進周期後下降，「釋放↔事件」相關性降低。
實際故障中「意外」跌落的比例→趨於零。
Dashbords以KPI（burn-rate，恢復時間，成功的DR活動比例）的形式顯示「彈性」。

15） guardrails和stop觸發器的示例

停止： 'http_req_failed> 1%'3分鐘,'p99> 1000 ms' 3窗口,'deposit_success <99。5%`.

降低爆炸射線：自動回滾清單，恢復GSLB重量，禁用故障註射。
停止命令：單個按鈕/腳本,並設置原因。

16）文化和過程

混亂是SRE節奏的一部分，不是「極端」。
透明的報告、漏洞識別、糾正措施。
呼叫培訓，與客戶/合作夥伴進行通信模擬。
與SLA/SLO和預算掛鉤：混亂應該增加而不是破壞可靠性。

17）結論

Chaos Engineering將「九號希望」轉變為可證明的可持續性。制定步進狀態，放下欄桿，打破小而可控的欄桿，觀察SLO和商業SLI，捕捉並自動化改進。然後，真正的失敗將成為事件驅動的：可預測的RTO，受保護的錯誤預算以及團隊在不驚慌的情況下行動的意願。