為自動復原設定安全邊界

恢復已知狀態

自動復原（self-healing）會自動偵測已定義故障，並嘗試已授權的復原操作。例如重新啟動失敗程序，或替換不健康執行個體。操作必須符合故障與服務狀態模型。

Kubernetes 可以替換失敗的工作負載執行個體，並使實際狀態符合宣告狀態。但這不會修正錯誤的應用程式邏輯，也無法處理每種儲存故障。基礎架構復原與軟體正確性需要不同檢查。Kubernetes 自動復原。

先定義目標，再選機制。恢復匯出，代表符合條件的工作能正確完成。容器正在執行，只是其中一個前提。

代理程式可以在復原後提出修正，但該提案是新的軟體變更，不得從復原控制器繼承無上限權限。

檢查失敗時，控制器也不得修改自己的成功條件。否則系統可能回報改善，實際服務卻沒有改善。

以下政策為虛構範例。數字用來示範設計選擇，不是建議預設值。

政策欄位	虛構匯出工作程序規則
觸發條件	工作程序心跳已消失 90 秒，且仍有排隊工作
前提條件	另一個工作程序健康；相依服務檢查通過；沒有疑似入侵或完整性故障
允許操作	使用目前核准的產物，替換一個工作程序
狀態保護	工作使用持久儲存，以及經過驗證的等冪金鑰
上限	15 分鐘內最多替換兩次；任何時候都不超過一個
冷卻時間	替換後等待五分鐘，才可再次嘗試
成功條件	合成資料工作正確完成，且受影響佇列開始減少
停止並升級處理	任一前提不成立、達到上限，或無法驗證成功

使用最小權限身分。記錄政策版本、觸發證據、操作、資源和結果。提供獨立的控制器停用方式，並指定接收升級通報的人員。

重試可能重複產生副作用。工作程序可能儲存檔案後，在確認工作完成前停止。允許再次執行前，驗證等冪性。參考雲端原生故障範例。

重試也可能加重已過載的相依服務。使用有限次嘗試、逾時和適當退避。避免所有執行個體同時重試。AWS 說明退避與隨機抖動為何能減少這種放大效應。重試指引。

用三個案例測試虛構政策。單一工作程序停止時，應能復原。資料庫中斷時，應阻止重複替換。完整性故障尚未釐清時，應停止自動化並請求應變決定。

也要檢查遙測缺漏。沒有心跳，可能代表工作程序故障，也可能是蒐集路徑故障。控制器需要足以支持操作的證據，不能只相信 AI 的解釋。

記錄經驗證的復原、失敗嘗試、升級通報、重複工作，以及使用者受影響時間。在相近條件下，與先前維運方法比較。

將底層缺陷保留為工程工作。反覆重啟有記憶體洩漏的程序，可能降低眼前影響，但洩漏仍然存在。繼續閱讀持續改善，將觀察連結到長期有效的修正。