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 自动修复要按风险分级设置前置条件、频率限制、执行审计和修复后验证。自动化不是越多越好。边界清楚自动修复才是救火工具边界不清它会变成新的火源。