★ FEATURED ARTICLE 做运维这些年我见过太多AIOps产品从惊艳到吃灰的完整周期。告警压缩、异常检测、根因推荐每个名词听起来都很硬核可真到故障现场用起来常常是平台说是根因A老师傅扫一眼就知道是根因B。直到ChatGPT这类大模型出现在大众视野我才意识到过去AIOps缺的从来不是算法而是“理解力”。所谓AIOps新时代不是用一堆炫酷图表吓唬人而是让大模型看懂日志、看懂告警、看懂历史工单再辅助人去做决策和执行把自动化真正推到故障处置环节。这篇文章我想把大模型进入智能运维后能落地的场景、搭建流程和踩坑经验摊开讲适合正在做监控、告警、on-call体系以及想引入大模型能力但不知道怎么下手的运维和平台工程师。1. 为什么AIOps需要大模型——传统智能运维的三个死穴1.1 告警压缩只是降噪解释不了“为什么”传统AIOps做得最多的一件事是告警降噪。规则引擎、聚类算法、动态阈值确实能把一天几万条告警压到几百条可压完之后人还得一条条看。问题出在“为什么”这三个字上。比如一块磁盘使用率超过90%阈值模块触发告警但真正的原因是日志文件被某个程序无限制写入而不是用户数据在增长。阈值和聚类算法只能告诉你“磁盘满了”却无法把“日志堆积、分区占用、服务写IO下降、接口超时”这条因果链讲出来。大模型的核心能力恰好是语义理解和因果表达。给模型喂入同一时间窗口的告警、日志摘要和变更记录它能用自然语言把链路串起来先发生了什么影响了什么建议先查哪里。这是我们第一次在AIOps系统里看到“可解释的降噪”。从实际体验看值班人员对这类输出的信任度远高于过去那种“关联规则命中”的机械提示因为人知道自己能顺着模型给出的线索去复核而不是面对一个黑盒结论。1.2 根因定位总在依赖老师傅故障响应中最贵的资源是人。新同学面对告警风暴手忙脚乱老师傅五分钟定位靠的是几年的故障经验积累。传统手段想把经验沉淀下来于是做规则依赖树、做调用链分析可规则依赖树要人工维护链路关系会随架构调整不断变化最后经验还是躺在老员工的脑子里。大模型在这里的价值是把文档、工单、runbook、历史复盘内容变成可对话的知识。值班人员可以直接问“以前遇到过Redis缓存穿透吗最后怎么处理的”模型从历史故障库中找出相似案例再按“现象、原因、方案”的结构给出回答。这并不替代老师傅而是把老师傅的判断依据打包带到每一位值班人员手边降低整个团队对单点经验的依赖。1.3 历史工单和复盘是一座没被开采的金矿绝大多数基础设施团队都积累了海量故障复盘记录和工单但这些东西平时几乎没人翻。原因是检索难故障复盘散落在维基、文档、群聊记录里工单系统虽然有搜索但输入几个关键词返回几百条似像非像的结果翻起来比重新排查还累。RAG技术出现之后这个问题有了很直观的解法。把历史工单、复盘报告、SOP手册切分后放进向量库让值班人员用自然语言去问模型带着相关原文片段给出回答。运维知识第一次实现了“按需调度”而不是靠人肉记忆或CtrlF。这也是我认为大模型与AIOps结合最容易被低估的价值点它激活的不是新数据而是那些已经存在很久、只是沉睡着的存量知识。2. 大模型进入运维后真正落地的四个场景2.1 告警摘要与值班通知升级第一个落地方案是告警摘要。监控系统仍然负责原始采集和规则触发大模型只承担一件事把一个时间段内合并后的告警组翻译成一段人话。比如过去值班群在凌晨三点弹出八十条告警现在模型会输出订单服务在02:10开始出现接口超时伴随Redis连接池耗尽告警排查建议先确认Redis慢查询和连接数再回看订单服务最近一次变更记录当前疑似依赖组件故障而非代码问题。这个效果非常直接。我们上线的第一个版本只做了摘要没有任何自动处置能力但值班同学的体验立刻不一样了。过去他们要自己从八十条告警里挑重点现在系统已经把线索排好了队。关键边界是大模型不替代监控只消费监控产出。告警采集、阈值判断、时序数据存储这些脏活累活仍然由传统监控体系完成模型负责最后一公里的“翻译”。这样才能保证即使大模型服务挂掉原始告警还能正常推送。2.2 知识库问答把历史工单变成对话第二个场景是运维知识问答。值班人员在处理故障时经常要回忆类似问题或者去翻技术方案文档。我们的做法是把历史工单、故障复盘、wiki文档、甚至变更评审记录全部切分成片段写入向量库。用户提问之后系统先从向量库召回相关片段再把片段交给大模型做总结回答。为什么用RAG而不是微调因为运维知识更新太快。今天的新故障下周可能就过时如果用微调每几天就要训练一次成本高且难以维护。RAG只需要更新向量库里的文档内容模型本体不用动非常适合故障知识持续积累的场景。我们在实践中还有一个体会问答是否好用七成取决于片段切得是否合理。这个后面在搭建部分会详细说。2.3 自动化脚本生成与runbook执行第三类是让大模型参与自动化执行。最常见的形式是自然语言转脚本或转查询值班人员在工单里回复一句话“查一下支付服务过去一小时的P99耗时分位值”模型生成对应的PromQL查询或Python脚本经过人工确认后执行把结果填回工单。再进一步是runbook执行。很多故障处置手册是流程化的先看A指标再查B日志条件满足就重启C服务。传统做法是做成固定编排但现实场景里有很多分支条件。大模型可以在每个分支上做判断决定下一步调哪个脚本相当于把静态runbook变成了动态的决策流。这里要划一条红线涉及变更、重启、清理数据的动作必须有审批环节绝对不能放任模型自己执行这一点我在后面踩坑部分还会展开讲。2.4 故障协同群里的AI值班助理第四个场景是把大模型接进即时通讯工具做成故障群里的机器人。故障发生时机器人被拉进群自动完成几件事把当前告警汇总成开场报告按时间线排列关键事件每当有人在群里提问“是不是数据库的问题”机器人会检索历史故障库和当前上下文给出一个带证据的建议回答。这个场景带来的提升比想象中大。故障处理过程中沟通成本往往很高大家反复对齐“现在什么状态、看过哪些项、接下来谁负责”。AI助理相当于一个实时记录员和信息索引器把散落在群里的信息变成结构化时间线。要注意的是机器人读取群消息必须有权限边界并且所有交互都要留审计日志不能把内部故障信息随意送到不可信的服务。我们目前只让机器人做“分析建议”不做任何执行操作执行仍然由人在群里确认后发起。3. 从零搭建一套最小可用的LLMAIOps框架3.1 拆分模块不要一上来就搞大而全平台很多人一听说大模型能做运维第一反应是规划一个庞大的智能运维平台把监控、日志、变更、工单全部重构。我的建议恰恰相反先拆模块再按最小闭环跑通。一个最小可用的LLMAIOps框架至少需要五个部分。告警接入层从监控系统拉取告警事件做时间窗口聚合和规则预筛。事件归一化把不同来源的告警统一成标准结构包括级别、标题、主机、时间、详情、来源。模型接入层封装大模型服务的调用统一处理鉴权、超时、重试、限流。知识库存放历史工单、复盘报告、SOP文档提供向量检索能力。执行通道调用自动化脚本或运维平台接口但必须经过审批和审计。模块化最大的好处是模型可以随时替换。今天用一个通用大模型明天发现某个垂直场景需要换更专业的小模型只要模型接入层的接口不变上层业务代码几乎不用改。我们内部甚至同时接了两套模型服务按场景分流简单分类用小模型复杂根因分析用大模型成本可控且切换无感。3.2 Prompt如何写才不容易翻车Prompt设计是落地中最容易被低估的环节。运维场景和日常聊天不一样要求输出可解析、可复核、可追溯。所以我们从一开始就要求模型输出JSON结构并规定字段。下面是一个告警摘要场景的核心Prompt框架我们在实际项目中就是这么用的效果比较稳定。import json import os import requests def call_llm(messages, temperature0.1, max_tokens500, timeout15): # 团队自建的模型接入层统一收口所有大模型调用 resp requests.post( os.getenv(LLM_GATEWAY_URL) /v1/chat/completions, json{ model: ops-llm, messages: messages, temperature: temperature, max_tokens: max_tokens, }, timeouttimeout, headers{Authorization: Bearer os.getenv(LLM_API_KEY)}, ) resp.raise_for_status() return resp.json()[choices][0][message][content]调用时组装消息模拟源码如下。alerts [ {level: P1, title: Redis连接池耗尽, host: cache-01, time: 02:10}, {level: P1, title: 订单接口超时, host: app-03, time: 02:11}, {level: P2, title: CPU使用率过高, host: app-03, time: 02:12}, ] prompt f你是运维值班助手。请阅读以下告警事件输出JSON格式的摘要。 字段要求 summary: 用三句话以内的自然语言概括告警整体状况 possible_cause: 列出最可能的根因最多三个 evidence: 每条根因必须附上支持的告警证据 suggested_actions: 给出两条以内的排查建议 如果信息不足以判断根因在possible_cause中明确写“未知”禁止编造。 告警事件 {json.dumps(alerts, ensure_asciiFalse)} messages [ {role: system, content: 你是一名严谨的SRE助手只能基于给定告警信息给出判断不能假设任何未被提及的系统状态。}, {role: user, content: prompt}, ] result call_llm(messages) print(result)关于参数选择temperature一定要设低我们用0.1。运维场景要求输出可复现随机性越高越难排查问题。max_tokens设上限防止模型在某次异常输入下生成长篇大论既浪费钱又拖慢响应。系统消息里的“禁止编造”不是摆设我们实测下来明确写清楚边界之后幻觉比例肉眼可见下降。3.3 知识库搭建从历史工单到向量检索知识库质量决定问答效果上限。最开始我们直接拿工单系统导出的原始数据建索引结果模型经常引用一些没结论的工单回答得含含糊糊。后来我们定了三条清洗规则。第一只入库有明确结论的工单至少要包含“最终原因”和“解决操作”。第二把复盘报告按字段切分保留时间、现象、原因、影响、操作步骤去掉那些情绪化的描述和无关讨论。第三设置更新机制每次故障复盘完成后自动触发索引更新而不是人工定期维护。切分策略也要分场景。历史工单我们按字段切一条工单变成多个片段并且用元数据记录所属工单编号方便回溯源。长文档和runbook按Markdown标题切分每段不超过五百字段与段之间保留一百字左右重叠避免语义在边界处被切断。检索时有一个容易忽略的细节top-k要适当取大一点比如先取50条候选再用重排序模型挑最相关的5到10条送入大模型。直接只取5条的话可能因为向量相似度排序不够准而漏掉关键信息。3.4 权限分级与安全护栏大模型接入运维系统权限设计要慎之又慎。我们的做法是操作分级管控所有动作分为三个级别。级别范围是否自动执行L1只读查询、状态检查、日志分析可直接执行L2执行常规运维脚本、重启非核心服务需人工确认L3删除数据、重启核心服务、批量变更、权限修改禁止模型执行必须走正式变更审批流程这个分级表需要在模型侧和执行侧各设一道闸。模型侧通过Prompt约束它不生成高危险动作但Prompt约束并不可靠所以执行侧必须再做白名单校验。凡是L3范围的命令即使模型生成了执行通道也要直接拦截并通知管理员。还要在大模型服务之前做敏感信息脱敏比如把主机IP、账号、手机号、长SQL替换成占位符防止企业内部数据越过边界。所有调用记录、输入输出、审批动作都要写审计日志这一点不是可选项而是长期运行的基本保障。3.5 用指标证明它确实有用任何新系统上线都要回答“它到底有没有用”。我们用了五个指标做评估。指标含义参考目标告警压缩比聚合后告警数除以原始告警数不低于10比1摘要采纳率值班人员采用模型建议的比例月均不低于50%RCA命中率模型推荐根因与最终定位一致的占比初期达到50%以上问答命中率知识库问答返回可参考方案的占比高于70%MTTR环比平均恢复时间与上线前比较逐步下降指标不能只看数字要配合人工抽检。我们每周抽一批模型输出把内容和实际故障复盘做比对错误案例专门存成bad case库再反过来优化Prompt和知识库。刚开始RCA命中率只有百分之三十几经过三轮迭代勉强过五十。这个过程没什么魔法就是要持续喂反馈把做错的地方一条条找出来改进。行动比追求完美方案更实在。4. 落地过程踩过的坑与排查实录4.1 幻觉它很自信但可能全错第一次把大模型接入告警分析时我们遇到的最头疼问题就是幻觉。有一次模型在摘要里写“可能是MySQL主从延迟导致”实际上当时告警组里根本没有数据库相关的线值班同学被带偏了方向对着数据库查了半小时。根源在于Prompt里没有明确要求“只能使用给定告警信息”模型习惯性地用训练知识补全了因果。后来我们在系统消息和各处Prompt里都加了同样一句话未知就写未知不要推测、不要编造、不要补充、不要假设未提及的系统状态。同时要求模型在输出结构里带上evidence字段每条根因判断后面必须附着对应的告警依据。没有证据支撑的判断宁可输出“未知”也不让它出现在值班通知里。这个改动之后误导读次数明显减少但依然存在所以最终防线还是人工复核。4.2 “全自动”是最危险的诱惑团队里有一位开发同学曾提议既然模型已经能理解告警不如直接让它自动执行重启、扩容、清理缓存这些动作实现真正的无人值守。我们当时试着放开了一个测试环境结果模型误判了一次磁盘问题把测试库的表清理流程执行了一遍。虽然没有严重事故但这个教训足够深刻。从此我们确定了铁律大模型可以做方案建议绝对不能做最终执行决策。即便只是重启一个非核心服务也必须有值班人员在群里点确认。人的价值不是操作本身而是承担风险判断。机器可以更快地提出方案但方案的后果要由人来买单。这个边界越早划清楚后面越少提心吊胆。4.3 延迟与成本的控制之道大模型单次接口调用延迟普遍在2到5秒这个速度无法扛住每一条告警直连。一开始我们没有做分级所有告警都走大模型摘要结果高峰期模型请求排队原始告警反而被堵住了。后来调整为三层流水线。第一层规则预筛把明显是监控抖动或测试触发的告警直接丢弃或降级。第二层用一个小参数分类模型判断告警组是否需要深度分析只有高危和疑似关联故障才进入大模型。第三层才对筛选后的告警组做摘要和根因推荐。这样大模型的调用量大约只有原先的十分之一成本也跟着降下来。同时我们把同类型告警的摘要做了缓存比如同一个服务反复出现同一类问题十分钟内直接返回上次摘要不再重复请求模型。4.4 敏感信息、权限与审计一个都不能少知识库问答刚上线时有人直接在群里问“某台数据库的账号是什么”系统虽然没有直接返回明文密码但模型会把相关文档中的连接串片段一起引用出来差点造成敏感信息外泄。之后我们做了三件事一是对履历到模型服务的文本统一做脱敏账号、密码、IP、密钥等用占位符替换二是知识库入库时就把敏感字段过滤掉不让它成为检索候选三是在审计日志里记录每一次查询和导出行为由安全团队复核。部署形态也需要结合数据合规来考虑。如果对延迟不敏感且数据量可控部署私有化模型更省心但需要有人持续维护模型服务。如果使用外部大模型服务则必须保证所有传输过程经过统一的加密通道并且在接入层明确记录数据流向。我们目前是混合部署内部知识问答走私有化小模型复杂推理走更大的模型服务但都用同一个接入层收口方便审计和切换。4.5 数据质量决定效果上限大模型本身不能凭空产生运维知识。最开始我们给知识库灌入了几百份历史工单结果很多工单是没有结论的有些写着“问题暂未处理后续观察”模型把这种内容当作标准方案引用答出来的自然不靠谱。后来我们宁愿知识库数量少一些也要保证每一条都有完整闭环。我后来养成了一个习惯每一次故障复盘结束强制要求补充“最终原因”和“实际解决操作”两个字段没有结论的工单不允许入库。知识库数据少一点没关系回答准确比丰富重要得多。随着时间积累数据质量稳定之后系统的平均恢复时间才真正开始下降前面阶段的提升更多来自降噪和问答那是靠模型能力后面才是靠数据复利。回顾整个落地过程如果要我给一个最重要的建议那就是不要一开始追求全自动先把“看懂告警”这件事做好。我们团队实际跑下来最受好评的不是自动处置脚本而是那个能三秒钟解释一个告警组、还能翻出历史同类故障摘要的问答机器人。它把值班人员的体验从面对一堆红色弹窗变成了有人帮你把线索排好队。大模型不会让AIOps从此一劳永逸也不应该被神化但它确实把过去多年积攒的、没有被利用起来的运维知识重新激活了。后面我们还在继续迭代这个方向最近的关注点已经转向多轮对话式的故障诊断以及更细粒度的操作权限控制。说到底技术和工具再新最终衡量它的标准还是一句话值班的人有没有真觉得好用故障恢复时间有没有真的变短。这两点满足方向就不算走错。
阅读完成 · 觉得有帮助？
