一、项目背景

做过电商大促技术保障的人都懂那种场面：大促夜的值班群里告警刷屏，一分钟几十条，值班同学根本看不过来；某个接口错误率突然抬升，五六个人在群里同时排查，各查各的，信息在群消息里互相淹没；好不容易定位到是缓存节点问题，处置预案在某个文档平台的某篇文档里，找到文档时故障已经持续了二十分钟。我们这个项目的客户——一家中型电商平台——去年大促就经历了这样一晚：一次数据库连接池打满的故障，从告警到恢复用了 43 分钟，其中前 25 分钟耗在"确认到底是什么问题"上。

客户的诉求是把大促应急从"靠人肉在群里吼"升级为体系化处置。我们基于所采用的 AI 私有化部署底座的智能体编排能力（与 XpShop 电商系统的监控体系对接），搭建了一套多智能体协同的值班应急系统，赶在今年大促前两个月上线。

二、落地场景

系统由四个各司其职的 Agent 组成，人始终在回路里。

监控 Agent 负责告警收敛：对接现有监控体系的全部告警源，按服务拓扑和时间窗口做聚合降噪——同一故障引发的连锁告警（数据库慢引发上游接口超时引发前端错误率上升）收敛成一个事件，而不是三十条独立告警轰炸值班群。每个事件带影响面描述：哪些服务、什么症状、开始时间、当前趋势。

诊断 Agent 负责根因定位：事件生成后自动拉取相关服务的调用链、近期变更记录（发布、配置变更、扩缩容）、资源指标，用大模型做关联分析，输出根因假设排序——"数据库连接池耗尽，疑似与 21:40 的营销服务发布相关，该服务连接泄漏的历史相似案例两起"。假设附带证据链接，值班同学可以点开核实。

预案 Agent 负责匹配处置方案：预案库里的处置方案全部结构化（触发条件、执行步骤、影响说明、回滚方法），Agent 按根因假设匹配预案并给出执行建议。关键设计是预案分级：只读类操作（重启探测、日志采集）Agent 可直接执行；变更类操作（切流、扩容、降级开关）必须由值班人在工作台一键确认后才执行；高危操作（数据库主从切换）要求双人确认。

执行与复盘：确认后的预案由执行器按步骤自动执行，每步结果实时回显；事件全程——告警、诊断、决策、执行、恢复——自动生成时间线，复盘会直接用时间线还原现场，不再靠回忆和翻聊天记录。

三、关键技术挑战与解决思路

第一个挑战是告警收敛的度。收敛不够等于没做，收敛过头会把独立故障错误合并、漏报大事。我们的做法是收敛规则可解释加可回溯：聚合只按服务拓扑的显式依赖边进行（A 依赖 B，B 的故障期内 A 的告警归入同一事件），拓扑外的告警绝不合并；每个被收敛的原始告警在事件详情里可展开查看，值班人发现误收敛可以一键拆分。大促演练中我们特意注入了两个时间重叠的独立故障，验证系统没有把它们错并成一个事件。

第二个挑战是诊断假设的可信度管理。大模型给根因假设，最怕一本正经地胡说。我们的约束是：假设必须挂证据，没有证据支撑的推测明确标注为"低置信推测"；假设排序的依据（变更时间相关性、历史相似案例、指标异常程度）在界面上展示；诊断 Agent 的每次输出都记录，事后与真实根因比对形成命中率报表——这个报表既是给业务方的信任凭证，也是我们迭代提示词和检索策略的依据。上线初期命中率（真实根因在前三假设内）约七成，两轮迭代后到了八成五。

第三个挑战是预案的可执行化改造。客户原有的预案是几十篇自然语言文档，写着"必要时可考虑扩容"这类没法执行的话。我们花了三周和运维团队一起把预案改写成结构化格式：每步是一条确定的命令或开关操作，有前置检查、有预期结果、有失败分支。这个过程本身暴露了大量预案缺陷——有的步骤依赖的脚本早已失效，有的预案两年没人演练。结构化不是格式转换，是一次预案体检。改造后每个预案都在演练环境跑通过才入库，并规定预案每季度必须演练一次，演练失败自动打回修订。

案例片段（已脱敏）：预案分级执行的核心配置——yaml playbook_policy:  readonly:   { exec: auto,          examples: [collect_logs, probe_restart] }  mutating:   { exec: human_confirm, examples: [switch_traffic, scale_out, degrade_flag] }  high_risk:  { exec: dual_confirm,  examples: [db_failover] } alert_converge:  window_s: 120  merge_only_on: topology_edge      # 仅按显式依赖边收敛  split: one_click diagnosis:  evidence_required: true  rank_by: [change_correlation, similar_incidents, metric_anomaly]今年大促夜的一条真实时间线（已脱敏）：22:17 监控 Agent 将 41 条原始告警收敛为一个事件；22:18 诊断 Agent 给出首位假设"缓存集群某分片内存驱逐风暴，与 22:10 的活动页配置变更强相关"；22:19 值班人核实证据后一键执行"回滚配置+临时扩容分片"预案；22:24 指标恢复。全程 7 分钟，同类故障去年耗时 43 分钟。

四、效果数据

以今年大促与去年大促对比（脱敏示意值）：值班群告警消息量下降约 90%（收敛后仅推送事件级通知），告警降噪比约 15:1；故障平均定位时长从约 25 分钟缩短到 6 分钟，诊断假设前三命中率约 85%；预案执行成功率约 97%（演练淘汰了带病预案）；大促期间 P1 级故障的 MTTR 从去年的均值 40 分钟以上降到 12 分钟；值班人力从去年的每晚 8 人减到 5 人，且值班同学的主观压力反馈明显改善——"从盯屏幕捞告警变成了处理系统递过来的待办"。复盘效率的提升是意外收获：时间线自动生成后，单次故障复盘会从平均一个半小时压缩到半小时。

五、可复用经验总结

第一，应急体系的第一步是告警收敛，但收敛必须可解释、可拆分，宁可保守也不能错并独立故障。第二，诊断 Agent 的价值边界是"带证据的假设排序"，不是替人下结论，命中率报表要公开透明地攒信任。第三，预案结构化是整个项目里投入产出比最高的工作，它逼着组织把"写在纸上的应急能力"变成"跑得通的应急能力"。第四，执行权限必须分级，只读自动、变更确认、高危双签，人在回路不是效率的敌人而是这套系统能被接受的前提。第五，自动生成的事件时间线让复盘从记忆考古变成数据回放，组织学习的速度就是这样快起来的。