Chaos Engineering

1）基本原則

Steady State作為原始假設。明確定義規範（例如： p95 <200 ms, error rate <0。3%,成功率為>99.5%).

隔離變量。在可能的情況下一次改變一個因素，以因果關系效果和改善。
度數。從安全環境中的小幅度開始→我們擴大了覆蓋範圍和強度。
Guardrails.SLO/Alert/錯誤預算中的顯式停止條件。
可重復性。實驗必須確定性地復制（腳本/清單/IaC）。
道德與安全。風險實驗中沒有真實的個人數據和財務交易。

2）什麼是「穩定狀態」

• p50/p95/p99關鍵尾礦。
• 成功交易和關鍵路徑轉換的比例。
• Error rate，taymauts，「shed」查詢比例（飽和時切斷）。
• 自我修復率（MTTR），抗逆轉（無風暴）。
• 域不變量：不存在「資產負債表中的缺點」，一次執行付款，報告日的一致性等。

3）註射目錄（我們打破了）

網絡：延遲，抖動，丟失/復制，帶寬限制，TLS懸崖，DNS翻轉。
計算：CPU過載，內存/GC壓力，描述符用盡，clock skew。
存儲：高p95 I/O，ENOSPC，領導者/復制副本故障，分裂大腦和揮之不去的fsync。
依賴性：5xx/429，「緩慢成功」，外部API降解，限額。
數據：消息/跳過、訂單外、「骯臟」記錄、版本沖突。
操作：未能成功發布/config、錯誤字幕、過期證書、密鑰輪換。
人和過程：負責人無法進入，手動應用程序延遲，不正確的運行簿。

4）實驗設計（模板）

1.假設： 「在p99 主要API的+300毫秒貨幣服務下<450毫秒，打開斷路器，≤ 15分鐘前給出樣式響應。」

2.註射：故障輪廓（類型/振幅/持續時間）和目標輪廓。

3.度量/標記： 標記'chaos。experiment_id`, `phase=inject|recover`.

4.Guardrails： abort在'error_rate> 2%'或p99> SLA × 2超過1分鐘。
5.結果/結論：觀察，錯誤，改進，工作計劃和重新運行列表。

5）可觀察性： 必須做什麼

Tracing：通過依賴性的查詢路徑；降級段被標記。
資源指標：CPU, heap/GC, FD, Disk IOPS/lat, network bandwidth,隊列深度。
業務指標：轉換/交易成功，被抵消交易的份額。
事件的標記：破發者的發現/關閉，撤退及其預算，DB領導者的切換。
實驗小組：帶有guardrails閾值和「紅色按鈕」流產的實時dashboard。

6）Guardrails和安全

技術：上限錯誤率/上限,成功運營比例下降,DLQ增長。
組織：時間窗口，電話參與，「一個區域-一個實驗」原則。
數據/合規性：只有合成或非人格化的套件；禁止導致違反監管的測試。
回滾：完成的滾回/無障礙標誌/軟阻塞流量過程。

7）必須表現出的可持續性模式

Taymout預算和jitter's retrai（無風暴）。
半開路（半開路）和指數恢復電路斷路器。
Bulkheads：按臨界值隔離池（付款vs分析師）。
Backpressure和rate-limit：可預測的低優先級截止。
同步緩存，防止「預熱風暴」。
副作用和具有補償作用的傳奇的冪等性。
用於數據恢復的法定量，feylover和抗熵。

8）腳本示例（草圖）

8.1慢成癮（YAML）

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8.2 DB領導者的損失

註射：停止領導/強制連任。
等待：暫時禁止記錄,從法定人數讀取,WAL/Otbox安全,自動復制恢復,沒有雙重記錄。

8.3 ENOSPC在日誌光盤

註射：磁盤填充率高達95-100%。
等待：緊急輪換日誌,保護關鍵日誌,禁用非關鍵眼鏡,警報和自動修復。

8.4爆破流量+著陸

註射：× 3 RPS 5分鐘熱內含素。
預期：丟棄低優先級，穩定p95「核心」，沒有回避級聯。

9） CI/CD中的自動化

每個版本的牛排中都有Chaos-smoke（安全振幅上的短註射）。
夜間運行通過實驗目錄（矩陣服務×故障類型）。
門：如果「穩定性低於閾值」（例如,成功後退的比例低於95%）,則會阻止發布。
文物：報告，草圖，CPU/heap長笛圖，指標和configs的快照。

10）遊戲日（遊戲日）

• 角色：實驗主持人，度量觀察者，回滾操作員，業務代表。
• 腳本：緩存降級、部分AZ/區域故障、「不良發布」、外部提供商不可用。
• 結果：在跑步簿中發現的空白，差速器的改進，SLO調整和撤退預算。

11）數據、事件和ML混亂

數據流：重復測試，遺漏，訂單出局，延遲；測試等效算盤和DLQ策略。
存儲：索引降級、熱分區、鎖定沖突、故障復制。
ML： Fitch Store延遲,回滾到基線模型,降低輸入質量（drift）-系統必須「輕輕鈍」而不是掉落。

12）反模式

沒有可觀察性的混亂：你是「盲人」，結論是投機性的。
立即註射，沒有堆棧和鵝毛筆。
「一個大實驗」對一切同時發生-目前還不清楚到底是什麼工作。
雜亂無章的混亂行動，沒有假設，在小說之後回避。
僅專註於基礎架構-被遺忘的業務不變性。
忽略人/過程：Alerts, on-call, runbook是系統的一部分。

13）實踐的成熟度（模型）

1.Ad-hoc：一次性註射局部。
2.舞臺混亂：腳本目錄，可重復運行，行進板。
3.發行混亂：每個發行版，門和報告中的煙霧混亂。
4.有限制的散裝混亂：交通擁擠，嚴格的護欄，準備回滾。
5.持續穩定性：自動實驗，SLO控制，改進為工作流程。

14）與建築實踐集成

抗藥性測試：混沌實驗補充了斷層註射和退化場景。
負載測試：組合的負載+故障實驗檢測級聯和風暴後。
Policy as Code/RBAC/ABAC： guardrails、回滾步驟和限制作為策略。
同意/隱私管理：不允許違反數據處理模式的實驗。
Geo體系結構：對區域偽造者的混沌檢查以及將數據綁定到轄區。

15）迷你食譜（偽代碼）

Breaker+降解

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

限量+著色

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

異位副作用

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16）建築師支票清單

1.由Steady State和Guardrails定義？

2.是否有腳本目錄（網絡/CPU/存儲/依賴性/數據/操作）?

3.可觀察性是否涵蓋資源，潛伏期，業務不變性？

4.Taymauts/retrai/breakers/limiters/bulkheads包括和參數化?

5.準備了運行手冊和「紅色按鈕」？
6.牛排和夜間實驗中有混沌煙霧嗎？
7.在遊戲日中規定了「安全」窗口和角色？
8.實驗是可復制的（IaC/腳本），結果是可轉換的？
9.改進是由任務捕獲的，正在進行轉發？
10.涵蓋了數據和ML流水線，不僅僅是HTTP？

二.結論

Chaos Engineering將「意外事件」轉換為可預測的場景。抗藥性假說，受控註射，強硬的guardrails，豐富的觀察力和戒律是降低發布風險並增強對平臺信任的工具。因此，該團隊了解系統的邊界，即使處於故障狀態，也可以優雅地降級並快速將服務返回給用戶。