当你的排查助手变成了AI大模型辅助根因分析在线上故障排查中的应用周一早上9点15分我刚端起咖啡告警群就炸了——用户服务持续报502上游三个业务线投诉说登录功能挂了。传统排查流程大概是看Grafana → 查日志 → 看APM → 看变更 → 推理 → 定位。这一套下来熟练工也要15-30分钟。但今天不一样。我打开内部排查平台我们叫它OpsCopilot输入故障服务名AI已经自动聚合好了异常指标、关联日志和最近变更。三分钟后它给出了分析建议。这篇文章就聊聊大模型在线上故障排查中的落地实践——不是画饼是真的在生产环境跑了大半年的方案。一、运维排查的信息过载困境线上故障排查最大障碍不是没数据而是数据太多。一次普通的P1故障你可能需要看数据来源数据量级关键信息占比Prometheus指标2000时间序列1%Elasticsearch日志500万条/小时0.1%Jaeger链路追踪10万Span/分钟0.5%K8s事件50条/分钟约5%变更记录日均50次约10%人工从这些数据中找到关键线索就像大海捞针。二、AI辅助排查的核心设计总体思路思维链多步推理我们不是简单地把数据丢给大模型问怎么回事而是设计了一套思维链Chain-of-Thought的排查流程Step 1: 故障定界 → 这个故障影响谁入口出口 Step 2: 数据聚合 → 异常指标有哪些错误日志什么内容 Step 3: 关联分析 → 异常指标和最近变更有关吗 Step 4: 根因推理 → 给出Top 3可能根因 Step 5: 排查指引 → 下一步应该查什么Step 1故障定界器# fault_boundary.py — 故障定界 class FaultBoundaryDetector: 确定故障的影响边界 def detect_boundary(self, service_name: str, start_time: str) - dict: # 查询服务拓扑确定上下游依赖 upstream self.get_upstream_services(service_name) downstream self.get_downstream_services(service_name) # 检查各服务的健康状态 boundary { entry_point: service_name, affected_upstream: [], affected_downstream: [], unaffected: [] } for svc in upstream downstream: status self.check_service_health(svc, start_time) if status degraded: boundary[affected_downstream if svc in downstream else affected_upstream].append(svc) else: boundary[unaffected].append(svc) return boundary # 示例输出 boundary { entry_point: user-service, affected_upstream: [api-gateway], affected_downstream: [user-db], unaffected: [order-service, payment-service] } # 推理故障在下游数据库影响了user-service进而影响了api-gatewayStep 2上下文聚合器# context_aggregator.py — 多源数据聚合 class ContextAggregator: 聚合故障上下文供LLM分析 def aggregate(self, service_name: str, boundary: dict, time_range: tuple) - dict: context { service: service_name, boundary: boundary, time_window: { start: time_range[0].isoformat(), end: time_range[1].isoformat() }, clues: [] } # 1. 提取异常指标只提取有异常的减少噪声 anomaly_metrics self.get_anomaly_metrics(service_name, time_range) for metric in anomaly_metrics: context[clues].append({ type: metric, source: prometheus, summary: f{metric[name]} 从 {metric[baseline]} 突变为 {metric[current]}, severity: metric[severity] }) # 2. 提取关键错误日志去重只保留前5种模式 error_patterns self.cluster_error_logs(service_name, time_range) for pattern in error_patterns[:5]: context[clues].append({ type: log, source: elasticsearch, summary: f发现{pattern[count]}条同类错误: {pattern[sample]}, severity: high }) # 3. 检查最近变更 recent_changes self.get_recent_changes(service_name, time_range[0] - timedelta(hours2)) for change in recent_changes: context[clues].append({ type: change, source: cmdb, summary: f{change[operator]} 在 {change[time]} 执行了 {change[action]}, severity: change.get(risk, low) }) return contextStep 3-5LLM多步推理引擎# llm_reasoning.py — LLM推理引擎 import json from openai import AsyncOpenAI class OpsCopilotEngine: 运维AI助手核心推理引擎 def __init__(self): self.client AsyncOpenAI( base_urlhttp://llm-service:8000/v1, api_keysk-xxxx ) self.model qwen2-72b-instruct async def run_diagnosis(self, context: dict) - str: 执行完整的诊断链路 # 第一步关联分析 correlation_prompt f你是一位SRE工程师正在排查线上故障。 请分析以下线索之间的关联关系 故障服务{context[service]} 影响边界{json.dumps(context[boundary], ensure_asciiFalse)} 时间窗口{context[time_window]} 发现的线索按时间排序 {json.dumps(context[clues], ensure_asciiFalse, indent2)} 请分析 1. 哪些线索可能是因果链中的一环 2. 哪些线索可能是独立事件 3. 线索之间是否存在时间上的先后关系 correlation await self._llm_call(correlation_prompt) # 第二步根因推理 root_cause_prompt f基于以下关联分析结果和原始线索给出Top 3可能的根因 关联分析{correlation} 线索清单 {json.dumps(context[clues], ensure_asciiFalse, indent2)} 请按以下格式输出 ## 可能根因按概率从高到低 ### 根因1[名称] - 概率XX% - 证据[引用线索编号] - 推理过程[因果链描述] ### 根因2[名称] - 概率XX% - 证据[引用线索编号] - 推理过程[因果链描述] ### 根因3[名称] - 概率XX% - 证据[引用线索编号] - 推理过程[因果链描述] ## 推荐排查步骤 1. [第一步做什么] 2. [第二步做什么] 3. [第三步做什么] return await self._llm_call(root_cause_prompt) async def _llm_call(self, prompt: str) - str: 调用大模型 response await self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是资深SRE工程师基于数据做严谨推理。}, {role: user, content: prompt} ], temperature0.1, max_tokens2000 ) return response.choices[0].message.content三、真实案例用户服务502故障故障定界输出入口: api-gateway异常 ↓ 目标: user-service异常 ↓ 依赖: user-db异常 redis-cluster正常 初步结论故障在下游数据库影响user-service后传导到api-gatewayAI诊断输出## 可能根因按概率从高到低 ### 根因1数据库连接池耗尽 - 概率75% - 证据① user-db活跃连接数从50飙升至200② user-service日志出现 cannot acquire JDBC connection③ 该服务近期未上线新版本 - 推理过程连接数持续上升 → 达到连接池上限 → 新请求获取不到连接 → 请求阻塞超时 → upstream服务感知到502 ### 根因2慢SQL导致连接长时间占用 - 概率15% - 证据① user-db慢查询数从2/min升至120/min② 某SQL执行时间从5ms升至2.3s - 推理过程某SQL执行计划变化 → 全表扫描 → 长时间占用连接 → 有效连接数减少 → 等效于连接池耗尽 ### 根因3上游突发流量 - 概率10% - 证据① api-gateway入口流量突增300%② 其他下游服务无异常 - 推理过程突发流量 → 数据库连接数飙升 → 超过连接池阈值 → 部分连接超时 ## 推荐排查步骤 1. 立即执行kubectl exec -it user-db-0 -- mysql -e SHOW PROCESSLIST 查看当前数据库连接状态 2. 定位慢SQL检查mysql-slow.log中的TOP SQL 3. 如果确认连接池耗尽临时增大数据库的 max_connections 和应用的连接池大小 4. 长期修复添加数据库连接数的HPA告警和限流措施实际结果按照排查指引第一步执行SHOW PROCESSLIST后发现大量Waiting for table metadata lock的连接。进一步定位发现是凌晨的一次DDL变更ALTER TABLE未提交事务阻塞了后续所有查询。根因是变更操作未规范执行这是根因列表中没出现的新线索——AI明确指出了首次排查方向。四、实践经验与局限做对了的结构化提示词让AI按固定格式输出便于后续自动处理多步推理取代单次问答先关联分析再根因推理准确率提升约40%约束输出范围temperature设为0.1减少幻觉踩过的坑坑1AI过度自信 - 现象明明证据不足LLM也会强行给出分析 - 解决在Prompt中增加如果证据不足请明确指出不确定项 坑2上下文过长 - 现象全量日志和指标数据远超LLM上下文窗口 - 解决先做聚类和摘要只把关键线索送入LLM 坑3延迟不稳定 - 现象LLM API偶尔延迟到30s - 解决增加超时处理和降级策略超时则只展示聚合数据五、落地效果过去6个月的生产数据统计指标使用AI前使用AI后MTTR平均修复时间28min12min首次排查正确率62%78%需要升级专家的故障比例35%18%值班工程师满意度6.5/108.5/10结语大模型辅助排查不是要把运维工程师优化掉。它做的是把信息搜索和初步分析的时间从20分钟压缩到2分钟让你能把更多精力花在判断和决策上。就像自动驾驶一样——L2级别的辅助仍然需要你手握方向盘、时刻关注路况。但有了辅助你会开得更轻松、更安全。本文作者侯万里万里侯云原生运维工程师专注于AI驱动运维智能化和故障自愈体系建设