AI 运维实战指南：自动化排障时如何保持系统掌控力

AI 运维实战指南：自动化排障时如何保持系统掌控力

引入 AI 进行自动化排障的核心矛盾，不在于模型能否准确识别故障，而在于工程师是否在高度自动化中逐渐丧失了对系统底层的直觉与掌控力。要在效率与人机协作之间找到平衡，我倾向于采用“灰度执行”与“上下文深度注入”相结合的策略，确保 AI 只是辅助判断而非黑盒接管。

AI 排障的隐性风险

在日常运维中，我观察到许多团队在使用 AIOps 工具后，虽然平均修复时间（MTTR）下降了，但工程师对告警的敏感度却在退化。当 AI 自动决定重启某个高负载容器并成功恢复服务时，我们往往只看到了结果，却错过了理解“为什么负载会突然飙升”的过程。

这种风险长期累积会导致一种现象：当出现 AI 从未见过的新型故障时，团队会陷入彻底的瘫痪。因为底层的系统认知已经外包给了算法，而算法本身并不具备可解释性。

策略一：实施分级执行机制

为了避免 AI 成为“黑盒管理者”，我会在自动化脚本中设置严格的执行层级。并不是所有的自动修复都应该由 AI 直接触发。通常我会将排障动作分为三个等级：

1. 只读诊断：AI 仅收集日志、拓扑图和指标，生成报告供人审核。
2. 建议式干预：AI 提供修复方案，但必须由人工点击确认才能执行。
3. 自动执行：仅限已知风险极低的动作，如清理临时缓存或重启无害的侧车代理。

以下是一个简单的配置示例，用于定义哪些命令允许自动执行，哪些必须人工介入：

auto_exec_rules:
  - action: restart_sidecar
    risk_level: low
    allow_auto: true
  - action: rollback_deployment
    risk_level: high
    allow_auto: false
    requires_approval: true
  - action: scale_out_nodes
    risk_level: medium
    allow_auto: true
    condition: cpu > 85% AND duration > 5m

通过这种机制，我确保了在高风险操作前，工程师始终拥有最终否决权。

策略二：强制注入上下文

AI 排障最大的短板在于它往往缺乏业务上下文。如果直接让 AI 读取监控数据，它可能会给出一个技术上正确但业务上灾难性的建议。

在我的实践中，我要求所有排障 Agent 在执行前必须先读取“系统健康基线”和“当前业务状态”。这意味着我们需要建立一个结构化的知识图谱，将依赖关系、近期变更和历史故障案例以向量形式存储。

例如，当一个异常发生时，我会在提示词中强制注入过去 24 小时内所有的相关变更日志：

context = get_recent_changes(hours=24)
system_state = get_current_health_metrics()
prompt = f"""
当前系统状态：{system_state}
近期变更：{context}
请分析根因并给出修复建议，注意避免影响正在进行的支付批处理任务。
"""
```n
这种人为强加的“约束条件”，能有效防止 AI 在解决一个问题的同时引发更大的业务中断。

## 保持人工参与感

最后，我认为保持系统掌控力的关键在于“参与感”。即使 AI 能够自动完成 90% 的排障工作，我也要求工程师必须定期复盘 AI 的决策日志。

我建议每周进行一次“故障复盘会”，专门讨论 AI 误判的案例。这不仅能帮助团队修正模型偏差，更重要的是能迫使工程师重新审视那些被 AI 掩盖的系统细节。只有当人依然能够独立理解系统行为时，AI 才能真正成为一个强大的工具，而不是一个危险的替代者。

## 相关阅读 / 下一步

如果你想深入了解如何构建可解释的 AIOps 体系，可以继续阅读《基于 LLM 的可观测性平台架构设计》；对于想要落地的团队，《自动化排障脚本的最佳实践与陷阱》也是一份不错的实战参考。