无需点击许可的自我修复自动化系统：凌晨3点仍能正常工作的门控装置
为定时执行的代理任务设计无人值守的自动修复机制：通过外部监控机制、可逆的操作流程、金丝雀发布模式以及有证据支撑的状态报告来实现。
一旦一个团队运行了数十个定时任务和代理会话，接下来的需求就很明显：当某个任务或其运行环境出现错误时，它应该能够自行修复根本原因，或者启动一个独立的会话来处理问题，而无需在深夜让人工逐一审批每一步操作。这个目标本身是合理的。但风险在于，为了快速实现这一目标而取消审批环节或自动化操作流程，可能会将小故障演变成影响整个系统的重大事故，甚至还可能出现虚假的故障已解决信号。本指南将介绍如何在确保关键区分标准——即某个操作是否可撤销——的前提下，实现真正的无人值守修复。
取消审批环节后会出现什么问题
在自动化操作中，有两种故障模式会反复出现，在构建任何系统之前都值得研究。
正确的命令，大规模执行时出错
想象一下，某个语音指令或聊天命令被错误转录，从而触发了拥有调度器控制权的自动化流程。大约五秒钟内，它就关闭了146个预定任务，包括所有本应察觉异常的监控程序。系统并未出现任何故障，只是按照指令立即大规模地执行了操作。
解决办法是一条简单易记的规则：任何批量操作、会关闭整类任务的指令，或是无法撤销的操作，在执行前都必须先显示一条确认信息。这条信息会说明将影响哪些内容以及回滚操作需要付出什么代价。阅读这条信息只需一秒钟，而没有它的话，从故障中恢复则需要一小时甚至更长时间。
基于意图撰写的恢复报告
第二次故障更为隐蔽。此类事件发生后，恢复记录会显示类似“30个任务已全部恢复”的字样。几天后，通过实时调度器检查却发现仍有27个任务处于禁用状态，其中包括配置备份、同步监控和会话监视功能。状态描述实际上是根据操作员的主观意图编写的，并非系统实际显示的情况。
这便形成了一条严格的报告规则：只有在与反映该状态的命令输出一同出现时，才能使用“N个任务已全部恢复”这样的表述。若没有相关证据，应如实记载为“已发送恢复命令”。
这就是自动修复功能的核心风险。那些不查看结果就宣称任务已恢复的修复工具，其实比根本没有修复工具还要糟糕，因为它们不仅未能解决故障，还给出了一切正常的虚假信息。
无人值守修复的五条规则
1. 常规程序无法自行修复
如果某个常规程序出现故障，其内置的自我修复逻辑通常也会同时失效，两者会一起默默出错。修复功能应位于更外层的层级：一个独立的进程，理想情况下应在另一台机器上，从外部监控该常规程序。
它应该监控的是程序输出的时效性，而非退出码。那些以状态0退出且未写入任何内容的任务，在通过退出码检查时看起来完全正常。这类任务很可能数周都无人察觉。而时效性检查（“报告文件的生成时间在26小时以内”，“表格中的最后一行是今日数据”）恰恰能发现那些被退出码掩盖的故障。
2. 对操作进行分类，而非仅做审批
“夜间禁止任何人手动批准”这一要求是合理的，但自动点击批准功能的机器人并非正确解决方案。它抹去了真正重要的那条界限——即区分可撤销操作与不可撤销操作的界限，而且偏偏在无人监督时以最快速度这么做。此外，它还隐藏了决策过程：其实仍有人判定这些操作是安全的，只是点击功能掩盖了做出该决定的人及其时间。
可行的替代方案是将操作本身分为不同等级：
- 自动执行，无需人工干预，随时均可：重启卡住的服务、重新注册失效的计划任务、清除过期的锁定、重新运行可重试的导入操作、重建索引。这类操作都有边界限制、可逆且重复执行安全。
通过这样的设置，第一层级可在夜间完全自主运行，第三层级则会在早晨的报告中进行处理，而不会在凌晨3点有人去点击任何操作。同样重要的是，凌晨3点也不会发生任何不可逆转的操作。
将分类信息记录下来，可以让信任决策清晰可见、可审查，并且能存储在同一个文件中便于修改。这相当于允许点击器所赋予的信任程度，且存储在可审计和测试的位置。如需更深入地了解代理的风险等级及审批机制，请参阅我们的指南：权限、审批机制与风险等级。
3. 先从测试节点开始，再推广到全部节点
同时推送到所有节点的修复方案本身就是一个故障点：如果修复有误，所有节点都会立即出问题。应分步骤进行部署：
- 先将变更应用到某个节点
- 通过查看实际状态来验证，而非依赖返回码
- 再将变更应用到另一类型的节点
- 最后才推广到所有节点
在开始之前就为回滚操作命名，这样恢复工作就能成为既定的流程，而非在压力下的临时应对措施。
4. 不要为首次故障就设计修复装置
自动修复机械很容易大量出现，因为似乎每个偶发错误都值得配备专属机器人。设定阈值可以控制这一趋势——问题首次出现时，只需在日志中记录一条带日期的条目；只有当同一类故障第三次出现，并且有明确的需求方时，才会构建相应的修复装置。
如果没有这样的规则，相关开销可能会急剧上升。有一支团队对自己开展的工作进行统计后发现，其中82%都属于“元工作”：即为管理其他机械而设计的机械。修复自动化正是最容易陷入这种恶性循环的领域。
5. 为每个启动的会话提供独立的简要说明
由监督机制在凌晨4点启动的会话并不具备发现问题的进程所拥有的上下文信息。应向该会话提供一份包含以下内容的简报：
- 出了什么问题
- 相关证据
- 已尝试过的解决方案
- 可处理范围的界限
- 完成标准的定义
人们常常忘记设定处理范围这一界限。如果没有它，过于积极的处理者会擅自修复那些并非被要求处理的关联问题，从而导致原本有限的修复工作演变成未经审核的广泛改动。
当一个处理者批准另一个处理者时
一种常见的建议是让一个代理批准另一个代理的操作，例如在共享聊天中，由主管代理告知工作人员可以继续进行。已有可用于以这种方式启动会话的现成工具。这种模式适用于第一层级的操作。而对于那些在凌晨3点时无法区分其特殊性的第三层级操作，也正是通过这种方式来处理的。一旦操作能够根据可逆性进行分类，代理间的审批就能安全使用，因为主管只能批准分类已允许的操作。
关键要点
- 将修复工作置于被修复对象之外，通过输出内容的新鲜度而非退出码来判断系统状态。
- 用基于可逆性和影响范围的书面操作分类来替代点击审批的方式。
- 对于大规模、全类别或不可逆的指令，需要求提供一行确认信息，说明操作范围及回滚成本。