线上事故发生时的大模型排障引导交互设计
当生产环境突然爆发出大面积 5xx 错误、电话告警响个不停时，值班工程师（On-call）面临的最大敌人往往不是技术复杂度本身，而是严重的信息过载与极度紧张下的决策混乱。
传统的故障辅助工具要么是简单罗列海量指标与日志，让排障人员在各个监控面板之间反复横跳；要么是粗暴地接入大模型 Chat 窗口，输入一句“线上服务 CPU 100% 怎么办？”，模型吐出几百字涵盖“可能是死循环、GC 频繁、线程泄漏”等宽泛的通用建议。在分秒必争的故障止血黄金五分钟内，这类宽泛对话毫无实操价值。
设计一个真正面向线上事故场景的大模型排障引导系统，核心在于将自由对话重构为确定性的 SOP（标准作业程序）引导流，坚持“止血优先于根因排查”的交互哲学。
事故引导交互的四大核心设计原则
告警风暴触发 (Prometheus / PagerDuty) │ ▼ ┌─────────────────────────────────────────┐ │ 1. 自动上下文汇聚 (Metrics+Logs+Deploys) │ └─────────────────┬───────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ 2. 状态机排障引导：止血优先向导 (SOP) │ │ ┌─────────────────────────────────┐ │ │ │ [Actionable Card] 一键切流 / 扩容 │ │ │ └─────────────────────────────────┘ │ └─────────────────┬───────────────────────┘ │ 止血完成 (SLA 恢复) ▼ ┌─────────────────────────────────────────┐ │ 3. 根因深度溯源 (Trace / Dump / 代码定位) │ └─────────────────────────────────────────┘- 止血第一（Mitigation First）：引导界面首屏绝不展示长篇分析，而是直接根据当前上下文（如“10分钟前有新版本发布”、“下游数据库连接池打满”）输出最高可信度的止血动作卡片（如：版本回滚、切断弱依赖、限流扩容）。
- 结构化动作卡片（Actionable Cards）：大模型输出的内容必须包含可一键执行或复制的命令与确认按钮，严禁让值班人员在多套系统中复制粘贴参数。
- 确定性状态流转：排障流程遵循严格的状态机：
告警感知 -> 影响面定级 -> 止血建议 -> 效果确认 -> 根因下钻 -> 事故报告生成。 - 上下文全自动感知：系统在调起大模型 Agent 时，必须已自动挂载：最近发版记录、配置变更历史、核心 JVM 堆栈摘要与 Prometheus 异常指标，杜绝让用户手工提供上下文。
排障引导交互协议与数据模型
在大模型与排障前端之间，交互协议不能采用纯文本或 Markdown，而应采用结构化的 UI 协议（Schema-driven UI）：
{ "incidentId": "INC-20260923-01", "currentPhase": "MITIGATION", "urgencyLevel": "P0", "summary": "order-service 接口 504 超时激增，伴随 JVM Old Gen 飙升", "contextSummary": { "recentDeploy": "v2.14.0 (发布于 8 分钟前)", "affectedNodes": 12, "errorRate": "34.2%" }, "actionCards": [ { "id": "act-rollback", "type": "EXECUTE_PIPELINE", "title": "一键回滚至上一稳定版本 (v2.13.9)", "confidence": 0.92, "riskLevel": "LOW", "payload": { "pipelineId": "deploy-order-service", "targetVersion": "v2.13.9" } }, { "id": "act-degrade-rec", "type": "TOGGLE_SWITCH", "title": "紧急关闭推荐与积分弱依赖", "confidence": 0.85, "riskLevel": "ZERO", "payload": { "configKey": "order.dependency.recommend.enabled", "targetValue": false } } ], "followUpQuestions": [ "是否需要临时调大 Gateway 路由重试次数？", "是否需要提取当前故障节点的 jstack 线程快照？" ] }核心后端：引导状态机与提示词工程实现
在 Spring Boot 中构建事故排障交互调度器：
package com.example.incident.agent; import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.ai.chat.client.ChatClient; import org.springframework.stereotype.Service; import java.util.List; import java.util.Map; @Service public class IncidentGuideAgentService { private final ChatClient chatClient; private final ObjectMapper objectMapper; public IncidentGuideAgentService(ChatClient.Builder builder, ObjectMapper objectMapper) { this.chatClient = builder.build(); this.objectMapper = objectMapper; } private static final String SOP_SYSTEM_PROMPT = """ 你是一名资深生产环境排障指挥官。当前系统发生生产事故，你的目标是帮助值班工程师以最快速度止血。 【交互准则】 1. 必须优先推荐能立刻止血的运维操作（回滚、降级、限流、切流、重启），禁止首先进行耗时的大段代码调试分析。 2. 严格以 JSON 格式输出 ActionableCard 结构。 3. 每个操作必须评估风险等级（LOW, MEDIUM, HIGH）与置信度。 """; public IncidentGuideResponse generateGuideStep(IncidentContext context) { String userContextJson; try { userContextJson = objectMapper.writeValueAsString(context); } catch (Exception e) { userContextJson = "{}"; } String rawLlmResponse = chatClient.prompt() .system(SOP_SYSTEM_PROMPT) .user("当前事故上下文如下，请给出第一步止血决策建议：\n" + userContextJson) .call() .content(); return parseResponse(rawLlmResponse); } private IncidentGuideResponse parseResponse(String rawJson) { try { return objectMapper.readValue(rawJson, IncidentGuideResponse.class); } catch (Exception e) { // 异常兜底保护 return IncidentGuideResponse.fallback(); } } public record IncidentContext( String incidentId, String appName, List<String> activeAlerts, String lastDeploymentInfo, Map<String, Object> metricsSnapshot ) {} public record IncidentGuideResponse( String incidentId, String currentPhase, String summary, List<ActionCard> actionCards ) { public static IncidentGuideResponse fallback() { return new IncidentGuideResponse( "UNKNOWN", "MITIGATION", "正在分析系统上下文，建议先行检查发布系统并准备回滚操作", List.of() ); } } public record ActionCard( String id, String type, String title, double confidence, String riskLevel, Map<String, Object> payload ) {} }生产实战：从“慌乱查日志”到“30秒止血”
在实际落地该系统前，某次典型的线上事故处理流程如下：
- 监控告警群收到 500 告警，多位工程师在群内询问“谁发了版？”、“数据库有慢查吗？”。
- 开发登录跳板机查看日志，耗时 3~5 分钟。
- 发现是发布引入了连接泄漏，再通知运维走回滚流水线，整体 MTTR（平均恢复时间）长达 18 分钟。
引入大模型排障交互后：
- 告警触发同时，Agent 自动抓取 Git 提交记录与 Pod 异常指标，并在应急工作台生成排障向导。
- 首屏直接推送置信度为 95% 的“回滚版本 v2.14.0”操作卡片，同时附带影响范围和变更差异。
- 值班工程师点击确认，系统自动联动 CI/CD 完成金丝雀回滚，止血时间压缩至 45 秒内。
- 业务恢复后，Agent 自动切换至“根因诊断模式”，抓取当时的堆栈日志，精准定位到具体文件的连接未释放代码段，并自动起草事故复盘初稿。
这种以状态机 + 结构化指令卡片为核心的设计，真正发挥了大模型在信息整合与意图识别上的优势，避开了自由文本对话在极端高压场景下的低效与不确定性。
