AIOps 自动修复边界：能自动做，不代表该自动做

AIOps 自动修复边界：能自动做，不代表该自动做

一、自动修复最怕过度自信

AIOps 不只会发现异常，还可能自动执行修复：重启 Pod、扩容副本、切流量、清理磁盘、回滚发布。自动修复能缩短故障时间，但也可能造成二次事故。问题不在自动化本身，而在边界是否清楚。

能自动做，不代表该自动做。先定义哪些动作允许自动执行，哪些必须人工确认。

二、先给动作分级

flowchart TD A[修复动作] --> B[低风险] A --> C[中风险] A --> D[高风险] B --> E[自动执行] C --> F[自动建议 + 人工确认] D --> G[只生成 Runbook]

低风险动作比如重启无状态副本、清理临时文件，可以自动执行；中风险动作比如扩容、切流量，需要确认；高风险动作比如删数据、改安全策略，只能给建议。

auto_remediation_policy: restart_stateless_pod: auto scale_deployment: require_confirm delete_data: forbidden

策略要写在系统里，不要靠值班人员临场判断。

三、自动动作要有前置条件

restart_pod_conditions: pod_crash_loop: true deployment_replicas_above: 2 no_recent_restart_within_minutes: 10

同样是重启 Pod，也要看副本数、最近是否重启过、是否影响核心流量。如果只有一个副本，自动重启可能造成更长不可用。

自动修复还要有频率限制。系统如果不断重启同一个服务，说明根因没有解决，应停止自动修复并升级人工处理。

四、修复后要验证

自动执行动作后，必须验证指标是否恢复。只执行不验证，系统不知道自己有没有帮忙。

post_fix_validation: check_error_rate: true check_latency: true check_pod_ready: true rollback_if_worse: true

如果修复后指标变差，要能停止继续动作，必要时回滚。自动化不应该一条路走到黑。

还要记录审计。谁触发、为什么触发、执行了什么、结果如何，都要能查。自动修复也要承担责任链。

最后，自动修复要从建议模式开始。先让系统生成建议，由人确认并反馈；当某类建议长期稳定有效，再逐步放开自动执行。这样更符合生产系统的成熟路径。

自动修复还要有熔断。如果同一类修复在短时间内连续失败，系统应该停止继续执行，转为人工处理。否则自动化会把错误动作重复很多次。

remediation_circuit_breaker: max_failures_per_hour: 3 disable_action_minutes: 60 notify_oncall: true

还要设置影响面限制。自动扩容最多扩到多少，自动重启最多重启多少 Pod，自动切流量最多切多少比例，都要有上限。没有上限的自动修复，本身就是高风险操作。

最后，所有自动修复策略都应该定期复盘。业务变了、架构变了、容量变了，旧策略可能不再安全。AIOps 不是写一次规则，而是持续运营。

自动修复还要区分环境。开发、预发可以大胆尝试自动动作，生产必须更保守。策略从预发验证到生产启用，也应该走发布流程，而不是直接改规则。

remediation_env_policy: staging: auto_for_medium_risk production: auto_only_low_risk require_policy_review: true

还要把用户影响纳入判断。某个 Pod 异常但没有用户流量，自动重启可以慢一点；核心链路错误率上升，则需要更快动作。AIOps 不能只看资源状态，也要看业务指标。

最后，自动修复系统本身也要可观测。策略命中次数、执行成功率、误修复率、人工接管次数，都是评估它是否可靠的指标。

五、总结

AIOps 自动修复要按风险分级，设置前置条件、频率限制、执行审计和修复后验证。

自动化不是越多越好。边界清楚，自动修复才是救火工具；边界不清，它会变成新的火源。