为自愈设置安全边界

恢复已知状态

自愈会自动检测已定义故障，并尝试获授权的恢复操作。例如，重启故障进程或替换不健康实例。操作必须适合故障和服务的状态模型。

Kubernetes 可以替换失败的工作负载实例，并使实际状态符合声明状态。但这不能修正错误的应用逻辑，也不能解决所有存储故障。基础设施恢复与软件正确性需要不同检查。参见 Kubernetes 自愈。

先定义目标，再选择机制。恢复导出意味着符合条件的工作能够正确完成。容器正在运行，只是一个前提。

区分三类修改

智能体可以在恢复后提出修复，但这个提议是新的软件变更，不能从恢复控制器继承无限权限。

检查失败时，控制器也不得修改自己的成功标准。否则，系统可能报告改善，却没有改善服务。

启用前写明恢复策略

以下策略是虚构的。数字用于说明设计选择，不是推荐默认值。

使用最小权限身份。记录策略版本、触发证据、操作、资源和结果。提供独立禁用控制器的方法。明确接收升级请求的人工负责人。

既测试成功恢复，也测试失败路径

重试可能重复副作用。任务处理进程可能保存文件后，在确认任务之前停止。允许再次执行前，验证幂等性。参见云原生故障示例。

重试也可能加重依赖过载。限制尝试次数，使用超时和适当退避。避免所有实例同步重试。AWS 解释了退避和抖动为何有助于减少这种放大效应。参见重试指南。

用三种情况测试虚构策略。单个任务处理进程停止时，应能恢复。数据库不可用时，应阻止重复替换。完整性故障尚不明确时，应停止自动化，并请求响应决定。

也检查遥测缺失。没有心跳，可能是任务处理进程故障，也可能是采集路径故障。控制器需要足以支持操作的证据，而不是对 AI 解释的信心。

衡量策略是否有帮助

记录已验证恢复、失败尝试、升级处理、重复工作，以及用户受影响的时长。在相似条件下，将它们与先前运维方式比较。

将底层缺陷保留为工程工作。反复重启内存泄漏进程，可以减少当前影响，但泄漏仍然存在。继续学习持续自我改进，将观察转化为持久修复。