从“事后救火”到“事前预判”，我们做对了什么？
大家好，我是某互联网大厂质量保障团队的技术负责人，负责微服务架构下的稳定性体系建设。
今天想分享一个我们最近做成的“实验”——用大模型学习历史故障数据，提前预测下一次P0级故障可能发生在哪个微服务。
先上结果：在最近一次大促压测前的演练中，模型提前47分钟预警了“优惠券服务”存在P0风险，我们紧急review后发现该服务近期有三次内存泄漏的Bug被标记为“已修复”但未做回归验证——实际线上验证时，内存确实在缓慢爬升。如果没有这个预警，大促当天大概率会炸。
这不是玄学。下面我把整个方案从头到尾拆一遍。
一、问题的起点：我们到底要预测什么？
很多团队一上来就想“预测所有故障”，结果模型准确率七八十却没人敢信——因为预测结果无法指导行动。
我们的目标很明确：预测下一个P0级故障会出现在哪个微服务上。
P0的定义大家都知道：系统崩溃、核心功能不可用、造成重大资损。在微服务架构下，一个P0故障往往是从某个服务的“慢性病”恶化而来的——内存泄漏、连接池耗尽、慢SQL积累、缓存穿透。
传统监控只能告诉你“现在出事了”，而我们要的是——在出事之前，告诉你是哪个服务最可能出事。
那怎么让模型学会这个？答案就藏在历史Bug里。
二、数据准备：你的JIRA就是一座金矿
任何AI项目第一步都是数据。我们的JIRA里沉淀了过去三年、两千多个微服务相关的Bug和故障报告。
但原始数据没法直接用。故障复盘报告里写的是这种话：
“凌晨2点15分，订单服务接口延迟从50ms飙升到3000ms。初步怀疑数据库问题，但指标正常。最终定位到v2.3.1版本引入的缓存层内存泄漏，嵌套JSON字段查询场景下GC失效。”
这段文字里有大量可学习的模式：渐进式劣化、误导性排查方向、版本变更关联、特定数据结构的触发条件。但模型看不懂自然语言，得结构化。
我们的数据清洗流程
第一步：提取因果链
用LLM辅助解析每一份故障报告，抽取出：
故障发生时间线（什么症状、什么时候出现）
初步假设（排查过程中考虑过哪些方向，对的错的都算）
真正根因（技术原因和组织原因）
故障前的前兆信号（故障发生前已经存在的异常迹象）
依赖关系（涉及哪些上下游服务）
这一步我们走了不少弯路。最开始人工标注，三个人干了两周才标了300条。后来改用大模型辅助抽取，效率提升了5倍，但需要人工复核——模型偶尔会“脑补”不存在的因果关系。
第二步：构建特征向量
清洗后的数据要转成模型能吃的格式。我们为每个故障构建了四类向量空间：
症状空间：故障发生时系统长什么样（指标异常、日志特征）
原因空间：根因是什么（代码缺陷、配置变更、资源耗尽）
修复空间：怎么修好的（回滚、扩容、Hotfix）
前兆空间：故障前哪些信号就已经存在了
第三步：打好标签
每条数据必须关联具体服务、版本号、变更记录、commit hash。没有这些关联信息，模型学到的就是“某服务某天出了个故障”，完全没法泛化。
踩过的坑：我们初期把ELK日志、监控指标、JIRA工单、Git提交记录一股脑全喂进去了，结果模型AUC高达0.92，上线后准确率暴跌到51%。后来发现是时间戳没对齐——日志是UTC时间，工单是北京时间，因果关系全错位了。花了两周重新梳理数据管道才解决。
三、模型选型与训练：不要一上来就搞微调
这个问题上我们做了三次迭代。
版本一：传统机器学习（练手阶段）
刚开始用的随机森林，特征主要是人工设计的——Bug标题里有没有“崩溃”“超时”“内存”等关键词、所属模块、报告者、修复代码行数等。
效果：P0预测准确率约65%，召回率不到50%。能用，但误报太多，没人当回事。
教训：人工特征覆盖面太窄，很多故障模式根本没法用几个关键词概括。
版本二：LLM + RAG（转折点）
我们换了个思路——不做微调，用RAG（检索增强生成） 。
流程是这样的：
系统实时采集各微服务的指标、日志、变更事件
当检测到异常信号（比如某服务内存缓慢爬升），自动检索历史故障库
大模型基于检索到的相似历史案例，判断当前状态的风险等级
RAG的好处是不需要重新训练模型，直接复用通用大模型的语义理解能力。我们用了内部部署的Qwen模型，结合自建的知识库做检索。
效果：P0预测准确率提升到82%，召回率65%。但有个新问题——检索到的历史案例如果不相关，模型会“幻觉”，给出错误判断。
版本三：微调 + RAG 混合（最终方案）
RAG的瓶颈在于检索质量。如果历史库里没有足够相似的案例，大模型再强也没用。
所以我们做了两件事：
第一，对基座模型做领域微调。用我们清洗好的两千多条结构化故障数据，对Qwen-7B做了LoRA微调。微调后的模型更懂我们的业务语境——知道“优惠券服务”和“订单服务”的故障模式有什么区别，知道“内存缓慢爬升”通常意味着什么。
第二，RAG做兜底。微调模型输出结果的同时，检索最相似的3个历史案例作为参考依据，附在预测报告里供人工复核。
最终效果：P0预测准确率91%，召回率78% 。
四、预测机制：到底怎么“算”出下一个P0？
模型不是算命的，它的逻辑其实很朴素——找出当前状态与历史上P0故障前状态的相似度。
具体来说，我们训练了一个故障前兆识别模型。它的核心能力是：给定一个微服务当前的状态（指标趋势、近期变更、近期Bug分布），预测它在未来1小时内发生P0级故障的概率。
模型关注的核心信号包括：
- 指标层面的“慢性病”
内存使用率在过去6小时持续上升（哪怕还没到告警阈值）
GC频率在缓慢增加
接口P99延迟在过去24小时内有三次超过基线20%
数据库连接池使用率持续高于75%
这些都是传统阈值告警不会触发但故障前普遍存在的信号。
- 变更层面的“定时炸弹”
该服务在过去7天内有≥3次上线变更
变更涉及核心模块（支付、优惠、库存等）
变更对应的测试覆盖率为“低”或“中”
变更关联的代码有圈复杂度>15的方法
- Bug层面的“预警信号”
该服务在过去30天内被标记为“已修复”的Bug数量突然增加
这些Bug中有多个涉及同一类问题（比如都是内存相关）
Bug的修复评论里有“临时方案”“先这样吧”等关键词
当以上三类信号叠加出现时，模型就会输出高风险预警。
一个真实的预测案例（脱敏版）：
某天下午2点，模型对“积分服务”输出P0风险评分87分（满分100），预警理由是：
内存使用率连续4小时从45%缓慢升至62%（未达阈值80%）
该服务前一天刚上线了一个版本，改动涉及缓存逻辑
该版本对应的测试用例只覆盖了正常流程，异常场景覆盖率不足30%
我们立刻拉上开发同学review，发现新版本确实引入了一个缓存Key设计缺陷——特定条件下会无限累积缓存对象。紧急hotfix后，内存曲线恢复正常。如果没有模型预警，这个Bug会在凌晨流量高峰触发OOM，妥妥的P0。
五、工程化落地：从模型到生产就绪
模型只是第一步，怎么把它变成团队真正能用的工具，我们踩了更多坑。
坑一：误报太多，没人看
刚开始模型每天输出20+条预警，准确率虽然80%多，但没人有精力处理20条预警。
解法：引入分级预警机制。
红色预警（P0风险≥85%）：直接推送到值班群，@所有人
橙色预警（P0风险60%-85%）：推送到TAPD，由SRE团队跟进
黄色预警（P0风险<60%）：仅记录，不做主动推送
现在每周红色预警平均2-3条，每条都有人跟进处理。
坑二：模型的判断依据不透明
开发同学最常问的一句话是：“凭什么说我的服务要炸？”
解法：每个预测结果必须附带推理链——模型不仅输出风险分数，还要输出“为什么”——具体是哪几个指标异常、匹配了哪个历史故障案例、相似度是多少。
我们做了一个小工具，点击预警可以看到完整的推理过程，类似这样：
风险来源：积分服务（风险评分87）
信号1：内存使用率持续上升（当前62%，4小时前45%），匹配历史案例#342（相似度92%）
信号2：昨日上线v3.2.1，涉及缓存模块变更，匹配历史案例#187（相似度78%）
信号3：该服务近30天内存类Bug共4个，高于平均水平（均值1.2）
综合判断：高风险，建议立即review缓存逻辑
有了这个，开发不再抵触预警，反而觉得“有点东西”。
坑三：数据漂移
模型上线三个月后，准确率开始下降。原因是系统架构在演进——新上了几个服务、老的依赖关系变了、故障模式也在变化。
解法：建立持续学习机制。每周自动用新产生的故障数据重新微调模型，同时人工review本周的误报和漏报案例，补充到训练集里。模型迭代周期从最初的2周缩短到了现在的2天。
六、效果数据总结
说几个硬数据：
指标
优化前
优化后
P0故障平均发现时间
已发生后才告警
平均提前35分钟预警
P0故障数量（季度）
5-8次
2-3次（预警拦截后未演变为P0）
预警准确率
不适用
91%
预警召回率
不适用
78%
误报率
不适用
从初期35%降至12%
SRE值班压力
高
降低约40%
最关键的变化：SRE团队从“天天救火”变成了“根据预警提前排查”。有一次值班同学开玩笑说：“现在凌晨被叫醒不是因为故障，而是因为模型说‘你两个小时以后可能会被叫醒’。”
七、给同行的一些建议
如果你也在做类似的尝试，我有几点掏心窝的话：
- 数据质量 > 模型复杂度
不要一上来就研究用什么大模型。先把历史故障数据清洗好、结构化好、打好标签。我们80%的时间花在数据上，模型选型和调优只占20%。数据不行，再强的模型也白搭。
- 从“根因分析”切入，别直接上“预测”
先做RCA（根因分析），再做预测。RCA是预测的基础——你得先让模型理解“这个故障是怎么发生的”，它才能学会“那个故障发生前是什么样”。我们第一阶段做的是故障根因自动定位，跑通了才上的预测。
- 接受“辅助决策”的定位
不要指望AI替你决策。我们的流程永远是：模型预警 → 人工复核 → 确认后采取行动。模型给出的是风险信号，不是执行命令。
- 持续迭代，别指望一次搞定
我们的模型从第一个版本到现在迭代了20多个版本。每一次迭代都伴随着误报率的下降和召回率的提升。这是个慢功夫，急不来。
最后说两句
AI不会取代SRE，但会用AI的SRE一定会取代不会用的。
我们这个方案没有用任何黑科技——微调了一个开源大模型、搭了一套RAG检索系统、接入了现有的监控和变更数据。技术门槛真不高，关键是想清楚自己要预测什么、数据从哪里来、预测结果怎么用。
如果你团队的历史故障数据已经攒了两年以上，我建议你可以试试。说不定下一个P0，你的模型比你更早看见。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
