AIOps 自动化巡检：报告要能指出下一步动作

张

张建站

2026/7/3 2:18:06

10分钟阅读

AIOps 自动化巡检报告要能指出下一步动作一、巡检报告不是指标截图结论很多 AIOps 巡检系统的输出是一份很长的报告CPU、内存、磁盘、网络、错误率、响应时间……全都贴在报告里。看起来很全面但值班人员看完报告后仍然不知道下一步应该做什么。AIOps 巡检的核心价值不是自动生成报告而是自动生成可执行的建议。一份好的巡检报告应该能回答三个问题发现了什么异常为什么会出现下一步应该做什么如果只回答第一个问题那只是信息搬运三个都回答了才是智能巡检。我们在落地 AIOps 巡检时发现下一步动作的质量比异常检测准确率更重要。一个准确率 99% 的系统如果给出的建议是请联系管理员处理那对值班人员的帮助很有限一个准确率 90% 的系统如果给出的建议是执行kubectl rolout restart deployment/order-service那价值会大很多。二、巡检报告的结构化设计flowchart TD A[采集指标/日志/链路数据] -- B[异常检测 AI 模型] B -- C[生成异常事件] C -- D[关联拓扑与变更记录] D -- E[生成根因候选] E -- F[生成建议动作] F -- G[结构化报告] G -- H[推送值班人员] H -- I{确认执行?} I --|是| J[自动执行或创建工单] I --|否| K[记录反馈用于模型优化] style E fill:#f9f,stroke:#333 style F fill:#bfb,stroke:#333 style G fill:#bbf,stroke:#333一份可执行的巡检报告应该包含以下结构{ report_id: inspection-20240702-001, generated_at: 2024-07-02T03:15:00Z, overall_status: warning, summary: 检测到 3 个异常其中 1 个需要立即处理, anomalies: [ { id: anomaly-001, service: order-service, metric: http_request_latency_p99, current_value: 2.3s, expected_range: 150ms-300ms, severity: P1, detected_at: 2024-07-02T03:10:00Z, root_cause_candidate: { summary: 数据库慢查询导致接口延迟升高, confidence: 0.85, evidence: [ 数据库慢查询日志显示在 03:08-03:12 期间SELECT * FROM orders WHERE user_id? 耗时 2.1s, 同一个时间段order-service 的数据库连接池使用率从 40% 升高到 95%, 没有检测到发布或配置变更 ] }, suggested_actions: [ { action: 为 orders 表的 user_id 字段添加索引, priority: 1, automation_level: manual, estimated_fix_time: 15min, runbook: https://wiki.example.com/order-db/add-index-runbook }, { action: 临时方案重启 order-service 释放连接池, priority: 2, automation_level: auto, risk: low, command: kubectl rolout restart deployment/order-service -n production } ] } ] }关键设计点root_cause_candidate必须带证据不能只说可能是数据库问题要给出具体的慢查询 SQL、时间点、关联指标。suggested_actions要分优先级哪个动作先执行哪个风险低可以自动执行automation_level要明确有些动作可以自动执行比如重启无状态服务有些必须手动比如修改数据库索引。三、建议动作的准确性AI 不能凭感觉给建议AIOps 给出建议动作时最大的风险是建议是错误的但看起来很合理。比如AI 看到数据库连接池满可能会建议扩大连接池配置但真正的原因可能是慢查询导致连接不释放扩大连接池只会让问题更严重。我们在实践中规定所有 AI 给出的建议动作必须能通过反事实推理检验。反事实推理模板如果我们执行了这个动作预期会发生什么有没有可能这个动作会让情况更糟如果情况更糟我们的回滚方案是什么# 建议动作验证器简化版 from dataclasses import dataclass from typing import List, Optional dataclass class SuggestedAction: action: str priority: int automation_level: str # auto / manual risk: str # low / medium / high command: Optional[str] None estimated_fix_time: Optional[str] None runbook: Optional[str] None def validate(self, context: dict) - List[str]: 验证建议动作的合理性返回警告列表 warnings [] # 检查1自动执行的动作必须是低风险 if self.automation_level auto and self.risk ! low: warnings.append(f自动执行动作 {self.action} 的风险等级为 {self.risk}不建议自动执行) # 检查2有 command 的动作command 必须白名单验证 if self.command: if not is_command_safe(self.command): warnings.append(f命令 {self.command} 不在白名单中可能存在安全风险) # 检查3高优先级动作必须有 runbook if self.priority 1 and not self.runbook: warnings.append(f高优先级动作 {self.action} 缺少 runbook值班人员可能不知道怎么执行) return warnings def is_command_safe(command: str) - bool: 检查命令是否在白名单中 safe_commands [ kubectl rolout restart, kubectl scale, systemctl restart, # ... 其他安全的命令模板 ] return any(command.startswith(safe) for safe in safe_commands)四、从报告到执行闭环才是价值巡检报告生成后如果不能转化为实际的处置动作那它的价值就大打折扣。我们在 AIOps 巡检系统中设计了三种执行模式模式一完全自动执行低风险动作比如重启无状态服务、清理临时文件、调整日志级别这类低风险动作可以在报告生成后自动执行然后通知值班人员已自动处理。# 自动执行器简化版 class AutoActionExecutor: def __init__(self): self.dry_run True # 默认干运行模式 def execute(self, action: SuggestedAction) - bool: if action.automation_level ! auto: raise ValueError(f动作 {action.action} 不支持自动执行) if action.risk ! low: raise ValueError(f动作 {action.action} 风险等级为 {action.risk}不允许自动执行) if self.dry_run: print(f[DRY RUN] 会执行: {action.command}) return True # 实际执行 import subprocess result subprocess.run( action.command, shellTrue, capture_outputTrue, textTrue, timeout300 ) if result.returncode 0: print(f✅ 自动执行成功: {action.command}) return True else: print(f❌ 自动执行失败: {result.stderr}) return False模式二半自动执行中风险动作比如扩容 Pod 数量、调整限流阈值这类动作会生成工单并附上执行命令和预期效果。值班人员确认后点击执行按钮即可。模式三手动执行高风险动作比如修改数据库配置、回滚版本、清理数据库这类动作只提供建议和 runbook 链接必须由值班人员手动执行。五、总结AIOps 自动化巡检的核心价值不是自动生成报告而是自动生成可执行的建议并尽可能自动化执行。报告要结构化建议动作要分优先级和风险等级执行要形成闭环。落地时的关键三点报告必须指出下一步动作、建议动作必须通过反事实推理检验、执行要分自动化级别。做到这三点AIOps 巡检才是真正减负做不到就只是用 AI 生成了一份更长的报告。