Netflix 把 Chaos Monkey 放在 business hours 執行，核心責任是同時驗證系統韌性與團隊反應能力。若只在離峰或隔離環境跑故障注入，很多真實依賴與協作問題不會被看見。

問題場景

團隊常把 chaos 排在低流量時段，理由是比較安全。這種做法雖然降低短期風險，但也降低驗證價值：人員不在位、依賴流量特徵不同、通訊鏈條沒被真正測到。最後得到的是工具可執行，不是服務可承受。

驗證機制

Business-hours chaos 是把風險放進 guardrails 內驗證，風險範圍是收斂的。

機制核心問題控制方式
時段限制事故處理人力是否在線僅在可支援時段啟動
實驗範圍限制是否影響過大 blast radius先從小範圍服務群組啟動
停止條件何時立即結束實驗明確 abort trigger 與 rollback 路徑
事後回寫是否有把結果回寫到工程控制面固定接 [8.22 evidence write-back]

這個機制的本質是「在可控邊界內接近真實情境」，而不是追求更大故障。

可觀測訊號

訊號判讀重點對應章節
abort trigger latency停止條件是否能即時生效6.20
on-call handoff quality值班與指揮鏈條是否順暢8.2
steady-state drift實驗期間是否偏離穩態6.22
communication lag內外部更新是否跟上變化8.4

常見陷阱

常見誤解是「business hours chaos 比較危險，所以應該避免」。真正風險在於沒有 guardrails，而不是時段本身。若有明確範圍、停止條件與值班協調，business-hours 測到的結果反而更接近真實事故。

下一步路由

先在 6.19 Reliability Readiness Review 檢查實驗前置條件，再到 6.20 寫 guardrails 與 abort 條件。實驗結果回寫 8.6 Drills and On-call Readiness 與 8.22。

引用源