自癒系統是自動化的最高階：系統自己偵測故障、自己恢復，不需要人（甚至不需要外部腳本）介入。關鍵前提不是「消滅故障」，而是承認故障必然發生，把恢復做到快到人來不及反應。
🧠 Intuition
TIP
把 failover 當成特性而非例外。與其想辦法「避免切換」，不如假設它一定會發生，投資在「30 秒內自動切換」——這正是把系統從「需要人救」推向「自己會好」的分界。
- 自癒屬於自動化五階中的第 5 階（自主系統）：不是外部腳本幫忙修，而是系統內建偵測與恢復能力。
- 案例「Decider」：MySQL master 手動 failover 要 30–90 分鐘、只能保 99% 可用度；自動化後 95% 的 failover（含計畫性與意外）能在 30 秒內完成——恢復速度快到符合錯誤預算。
- Borg 把機器故障的處理變成近乎 no-op：把叢集當受管資源海，task 跨機搬遷是內建特性，損壞修復、OS 升級對 SRE 幾乎無感。
- Workbook 的角度：把重複性的 toil 回應自動化——但要先識別與衡量 toil、評估自動化風險、從人工支撐的介面逐步過渡到自助與全自動。
⚖️ Tradeoffs
全自動自癒 — 恢復快，但人會失去手感
- 好處：常見故障的 MTTR 大幅下降、決策速度遠超人類，錯誤預算守得住。
- 風險：自動化覆蓋越廣，人越少直接操作——一旦自癒邏輯本身失效，人已無能力接手（航空、工業領域都有對應教訓）。
- 對策：保留人類的可觀測性與介入通道、演練手動路徑，別讓自動化變成無人看得懂的黑箱。
冪等修復 vs 盲目重跑 — 自癒的正確姿勢
- 自癒動作必須冪等：同一修復重複套用結果一致，否則「測試→修復→再測試」的延遲會產生時靈時不靈、把系統帶進不一致狀態。
- 不能依賴隱含的安全訊號：把「空集合」當成「全部」曾釀成大規模誤刪；自癒邏輯要對危險操作設界限、要「很吵」地通報。
- 代價：把恢復設計成冪等、有界、可觀測需要前期工程；但這是自癒能被信任的前提。
🔑 Takeaways
- 自癒＝自動化第 5 階的自主系統：自己偵測、自己恢復；前提是承認故障必然、把恢復做到夠快。
- 擁抱 failover 為特性（Decider 30 秒）、把機器故障處理變 no-op（Borg 資源海），並自動化重複性 toil 回應。
- 自癒動作要冪等、有界、可觀測，且別讓人完全失去手感——自動化失效時仍要能接手。
No notes yet — jot your takeaways or Q&A here.