当时钟拨过一个不眠的故障夜业务恢复后最“扎心”的事往往不是修复过程而是还要坐在电脑前把零散的监控截图、告警消息、操作记录、会议纪要整理成一份逻辑通顺、时间线清晰、结论明确的故障复盘报告。手动整理一份复杂故障复盘短则四十分钟长则两三个小时其中大量时间花在“重新梳理事件顺序”和“组织语言”上而这部分工作恰恰是 AI 最擅长的。本文会从一个可以落地的角度出发讲清楚如何基于 LLM大语言模型能力把故障事件数据自动变成结构化复盘报告。我们会从核心概念讲起再逐步拆解提示词工程与 Agent 流程最后给出一套完整的 Python 实战代码。对 AI 应用开发、AI 工程实践感兴趣的开发者以及被复盘报告困扰的后端、运维、SRE 同学都可以直接参考这套思路。1. 背景与核心概念1.1 为什么故障复盘成了团队负担故障复盘也叫事后分析Postmortem、事故复盘是稳定性保障流程里不可或缺的一环。它的价值在于把一次故障的起因、经过、影响、恢复动作和后续改进项沉淀下来避免同一个坑踩第二次。但真正落地的过程中复盘报告的质量经常取决于整理者的表达能力和耐心。一个复杂故障可能跨越多个系统涉及应用、数据库、网关、消息队列、云服务等多个组件监控告警可能有几十条值班同学的排查动作也可能有十几次。把这些碎片信息拼成一个完整故事本身就是一个高强度的信息整理任务。手动整理报告时常见的问题时间线对不齐多个系统的时间戳格式不一致排序时容易错乱。信息遗漏故障跨度长中间有些不起眼的操作恰恰是恢复的关键节点。结论模糊只写了“某服务异常”没说清楚影响范围、恢复手段和后续改进。模板不统一每个人写出来的格式差异很大不利于事后检索和统计分析。AI 生成故障报告并不是要替代工程师做根因分析而是把“信息整理 结构化表达”这部分人力从繁重的手工劳动中解放出来让工程师把精力放在真正需要判断力的根因定位上。1.2 AI 生成故障报告它能做什么、不能做什么用 AI 辅助生成故障复盘报告通常包含下面几种能力事件时间线重排把不同来源的事件按时间排序形成秒级时间轴。影响范围归纳从告警和监控数据中提取受影响的业务、接口、地域和用户范围。关键动作抽取从操作记录中筛选出恢复动作、止损动作和验证动作。报告文本生成按团队模板生成背景、时间线、根因分析、恢复过程、改进措施等章节。根因参考建议基于历史故障库或知识库给出可能的根因方向和排查建议。需要注意的是AI 不能自动保证“事实正确”。如果喂给模型的事件数据本身有误AI 写出来的报告就会存在事实偏差这也是业内常说的“AI 幻觉”问题。所以在工程落地时不能把 AI 输出直接当成最终结论必须设计“人工审核”环节同时尽量让 AI 基于结构化数据推理而不是让模型凭空想象。1.3 适合谁来用用在什么场景这套方案适合以下几类人群后端开发工程师负责业务系统需要编写应用故障复盘。运维 / SRE需要处理大量监控告警和系统级故障。质量保障人员线上问题复盘中需要梳理测试遗漏和改进项。研发效能工程师希望把故障复盘流程集成到内部平台减少人工成本。典型使用场景包括每次故障恢复后自动生成初稿负责人只做修订和确认。周报 / 月报中自动汇总多次故障的关键信息和改进项。结合监控平台、告警平台、ChatOps 机器人在故障恢复后自动推送报告草稿。2. 环境准备与版本说明2.1 技术栈与运行环境本文示例以 Python 3 环境为基础核心依赖如下Python 3.9 及以上版本。openai或其他兼容 LLM API 的 SDK。pandas用于处理事件表格。jinja2用于格式化输出模板。一个可用的 LLM API 服务例如 OpenAI 兼容接口。需要说明的是大语言模型相关 SDK 的版本迭代比较快不同版本的参数名称和调用方式会有差异。本文重点讲清楚实现思路和代码逻辑你拿到项目里需要根据实际使用的模型服务做小幅调整。如果你还没有可用的模型 API也可以用本地方案比如通过 Ollama 部署开源大模型然后把调用地址改成http://localhost:11434即可。关键不在于用哪家模型而在于提示词结构、数据整理流程和人工审核机制。2.2 示例项目结构实战代码我们按下面结构组织ai_incident_review/ ├── data/ │ ├── events.json # 故障事件原始数据 │ └── incidents.json # 故障基础信息 ├── templates/ │ └── report_template.md # 复盘报告 Markdown 模板 ├── src/ │ ├── data_prepare.py # 数据清洗与特征提取 │ ├── prompt_builder.py # 提示词构建 │ ├── llm_client.py # LLM 调用封装 │ └── report_generator.py # 报告生成主流程 ├── output/ │ └── incident_report.md # 生成的复盘报告 └── requirements.txt这个结构把数据准备、提示词、模型调用、报告生成四层分开方便在真实项目中替换监控数据源和报告模板。3. 核心原理拆解3.1 事件数据的结构化提取要稳定生成高质量故障报告第一步不是写提示词而是把散乱的事件整理成结构化数据。常见的事件来源包括监控告警平台、日志平台、变更平台、值班操作记录、聊天群消息。事件数据通常需要包含以下字段字段名含义示例event_time事件发生时间2025-06-20 14:03:12event_type事件类型alarm / operation / deploymentsource事件来源监控平台 / 变更平台component组件或系统名order-servicemessage事件描述订单接口超时率超过 50%operator操作人可选zhangsanseverity严重程度P1 / P2 / P3清洗时要重点解决三类问题时间格式统一。所有事件时间必须统一成同一个时区和时间格式推荐使用YYYY-MM-DD HH:mm:ss。字段缺失补全。没有操作人的事件可以标记为system。去重。同一时间同一组件同一告警内容的重复事件要合并成一条。只有数据干净了AI 生成的时间线和影响范围才有意义。3.2 提示词工程让 AI 输出专业复盘提示词是 AI 输出质量的分水岭。很多新手直接把所有事件描述丢给模型说“帮我写个复盘报告”得到的结果往往像流水账。更稳妥的做法是给模型提供三个层次的信息角色和任务。结构化事件数据和基础信息。输出约束和模板要求。例如你是一名资深 SRE 工程师擅长编写故障复盘报告。 请根据以下故障基础信息和事件数据输出一份结构完整、结论清晰的复盘报告。 故障基础信息 {incident_basic} 事件数据 {events_table} 输出要求 1. 按照时间线顺序梳理事件经过。 2. 区分告警事件与操作事件标注关键恢复节点。 3. 根因分析部分要求基于事件数据不要编造数据。 4. 改进措施要求具体、可执行。 5. 使用 Markdown 格式输出。这里有一个经验不要急着让 AI 一次生成所有内容。建议拆分成“先按时间线梳理事件 → 再归纳影响范围 → 最后生成报告正文”三个步骤。这样每一轮生成的内容都基于上一轮结果逻辑更连贯也更容易检查错误。3.3 Agent 流程设计从数据到报告的流水线所谓的 AI Agent在这里并不神秘。它就是把大模型能力封装进一个有输入、有处理、有输出的流程中。我们可以把故障复盘生成流程拆成下面几步读取故障数据 ↓ 数据清洗与时间线排序 ↓ 调用 LLM 生成事件摘要 ↓ 调用 LLM 生成根因分析与改进建议 ↓ 组装 Markdown 报告 ↓ 输出草稿人工审核每一步都是独立函数中间用 JSON 传递数据。这样做的好处是单步失败可以重试不用重新跑完整流程。每一轮 LLM 的输入输出都可以留日志便于排查质量问题和审计。后续可以替换某一步的实现比如把“事件摘要”换成规则引擎。4. 完整实战案例下面我们来看一个可以直接运行的示例。为了便于理解我们使用简化的数据结构和代码重点展示流程思路。4.1 创建项目结构在本地执行mkdir -p ai_incident_review/{data,templates,src,output} cd ai_incident_review4.2 准备故障事件数据创建data/events.json[ { event_time: 2025-06-20 14:01:00, event_type: alarm, source: monitor, component: order-service, message: order-service 接口超时率超过 30%, severity: P1 }, { event_time: 2025-06-20 14:03:00, event_type: alarm, source: monitor, component: mysql-master, message: MySQL 主库 CPU 使用率达到 95%, severity: P1 }, { event_time: 2025-06-20 14:05:00, event_type: operation, source: ops, component: order-service, message: 运维紧急扩容 order-service 实例, operator: wangwu, severity: P1 }, { event_time: 2025-06-20 14:08:00, event_type: alarm, source: monitor, component: mysql-master, message: MySQL 主库 CPU 使用率下降至 60%, severity: P2 } ]创建data/incidents.json{ incident_id: INC-20250620-001, title: 订单服务接口超时率升高, start_time: 2025-06-20 14:01:00, end_time: 2025-06-20 14:30:00, level: P1, business_impact: 订单接口超时率升高部分用户无法正常提交订单 }4.3 编写核心代码4.3.1 数据清洗模块创建src/data_prepare.py# -*- coding: utf-8 -*- import json from datetime import datetime def load_json(file_path): with open(file_path, r, encodingutf-8) as f: return json.load(f) def normalize_events(events): 统一时间格式并按时间排序 for event in events: # 统一解析时间字符串转换后重新格式化 dt datetime.strptime(event[event_time], %Y-%m-%d %H:%M:%S) event[event_time] dt.strftime(%Y-%m-%d %H:%M:%S) events.sort(keylambda x: x[event_time]) return events def build_events_table(events): 把事件列表转成适合给 LLM 看的文本表格 header | 时间 | 类型 | 来源 | 组件 | 事件描述 | 严重级别 | separator | --- | --- | --- | --- | --- | --- | rows [] for e in events: row ( f| {e[event_time]} | {e[event_type]} | {e[source]} f| {e[component]} | {e[message]} | {e.get(severity, )} | ) rows.append(row) return \n.join([header, separator] rows)4.3.2 提示词构建模块创建src/prompt_builder.py# -*- coding: utf-8 -*- SYSTEM_PROMPT ( 你是一名资深 SRE 工程师擅长编写故障复盘报告。 你的任务是基于结构化事件数据生成逻辑清晰、内容准确的复盘报告。 你只能使用提供的数据进行推理不能编造任何未出现的事实。 ) def build_incident_prompt(incident_basic: dict, events_table: str) - str: user_prompt f 故障基础信息 {json.dumps(incident_basic, ensure_asciiFalse, indent2)} 按时间排序后的事件数据 {events_table} 请按照下面结构生成复盘报告 1. 故障概述 2. 故障时间线 3. 影响范围 4. 根因分析 5. 恢复过程 6. 改进措施 要求 - 时间线必须按照事件顺序展开并标注关键恢复节点。 - 根因分析必须引用事件数据不能编造。 - 改进措施要具体可落地。 - 使用 Markdown 格式输出。 return user_prompt注意json模块需要在这里导入。修改后# -*- coding: utf-8 -*- import json SYSTEM_PROMPT ( 你是一名资深 SRE 工程师擅长编写故障复盘报告。 你的任务是基于结构化事件数据生成逻辑清晰、内容准确的复盘报告。 你只能使用提供的数据进行推理不能编造任何未出现的事实。 ) def build_incident_prompt(incident_basic: dict, events_table: str) - str: user_prompt f 故障基础信息 {json.dumps(incident_basic, ensure_asciiFalse, indent2)} 按时间排序后的事件数据 {events_table} 请按照下面结构生成复盘报告 1. 故障概述 2. 故障时间线 3. 影响范围 4. 根因分析 5. 恢复过程 6. 改进措施 要求 - 时间线必须按照事件顺序展开并标注关键恢复节点。 - 根因分析必须引用事件数据不能编造。 - 改进措施要具体可落地。 - 使用 Markdown 格式输出。 return user_prompt4.3.3 LLM 调用封装创建src/llm_client.py# -*- coding: utf-8 -*- from openai import OpenAI def create_client(api_key: str, base_url: str) - OpenAI: 创建 LLM 客户端兼容 OpenAI 格式的接口 return OpenAI(api_keyapi_key, base_urlbase_url) def chat_completion(client: OpenAI, system_prompt: str, user_prompt: str, model: str) - str: 调用对话模型返回纯文本结果 response client.chat.completions.create( modelmodel, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature0.3, ) return response.choices[0].message.content.strip()4.3.4 报告生成主流程创建src/report_generator.py# -*- coding: utf-8 -*- import os from data_prepare import load_json, normalize_events, build_events_table from prompt_builder import SYSTEM_PROMPT, build_incident_prompt from llm_client import create_client, chat_completion def main(): # 读取数据 incidents load_json(data/incidents.json) events load_json(data/events.json) events normalize_events(events) events_table build_events_table(events) # 构建提示词 user_prompt build_incident_prompt(incidents, events_table) # 调用 LLM api_key os.getenv(LLM_API_KEY, your-api-key) base_url os.getenv(LLM_BASE_URL, https://api.openai.com/v1) model os.getenv(LLM_MODEL, gpt-4o-mini) client create_client(api_key, base_url) report_md chat_completion(client, SYSTEM_PROMPT, user_prompt, model) # 保存报告 os.makedirs(output, exist_okTrue) with open(output/incident_report.md, w, encodingutf-8) as f: f.write(report_md) print(报告已生成output/incident_report.md) if __name__ __main__: main()4.4 运行与验证安装依赖pip install openai pandas jinja2在项目根目录执行export LLM_API_KEY你的Key export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini python src/report_generator.py如果使用本地 Ollama 部署可以改成export LLM_BASE_URLhttp://localhost:11434/v1 export LLM_MODELqwen2.5:7b python src/report_generator.py4.5 结果说明运行成功后output/incident_report.md里会生成一份包含六个章节的 Markdown 报告。由于不同模型的输出略有差异这里不再贴一份“固定答案”你需要重点关注报告中的时间线是否与输入事件一致、根因分析是否引用了事件数据、改进措施是否具备可执行性。如果个别章节质量不满足要求可以考虑三种优化方向调整提示词中的输出约束。把单次生成拆成多轮生成先生成时间线再基于时间线生成根因分析。在事件数据中加入更多上下文比如变更记录、依赖关系、历史故障记录。5. 常见问题与排查思路在实际使用过程中比较容易遇到几个问题。问题现象常见原因解决思路报告时间线与原始数据不一致事件数据未按时间排序或模型自行重排了顺序在数据清洗阶段强制排序并在提示词中注明“严格按提供顺序输出”根因分析出现编造内容模型缺少足够上下文自动脑补了故障原因增加“只能引用事件数据”的约束引入知识库或历史故障库补充上下文输出的 Markdown 格式错乱模型输出中包含多余空格或特殊字符增加格式解析函数提取代码块中的内容在后处理阶段清洗一次调用超时或返回截断事件数据过长单次 token 超限拆分事件数据分多轮生成再合并或提高 max_tokens生成的改进措施太泛泛提示词约束不足在提示词中要求改进项必须对应具体事件并给出责任人和时间范围报告风格不符合团队规范提示词缺少模板输入把团队复盘模板放入提示词要求逐段填充排查这类问题的基本思路是先检查进入模型的数据是否干净再检查提示词是否准确表达了约束最后检查模型输出是否经过了合理的后处理。数据决定事实提示词决定结构后处理决定格式三者都要盯。6. 最佳实践与工程建议6.1 数据安全与最小权限故障数据往往包含业务敏感信息。在设计系统时需要注意调用 LLM 前先做数据脱敏把用户名、手机号、订单号等个人信息替换成占位符。尽量使用私有化部署或经过合规审批的外部服务避免敏感数据直接发送到未授权的第三方。API Key 必须通过环境变量或密钥管理系统注入禁止硬编码在代码仓库里。6.2 从“一次生成”走向“多轮 Agent 协作”单次生成适合快速出稿但在复杂故障场景中建议拆成多个子任务第一轮事件时间线与关键节点提取。第二轮影响范围与恢复动作归纳。第三轮根因分析与改进建议。第四轮按团队模板组装成完整报告。每一轮都是独立的 LLM 调用中间结果可以被人工检查也能在出错时单独重跑。6.3 引入人工审核与版本管理AI 生成的报告本质上是“草稿”不能直接发出去。最好设计一个审批流程AI 生成初稿 → 责任人修改确认 → 归档到知识库。有条件的话把报告纳入 Git 管理方便追溯每次修改。6.4 知识库注入减少幻觉想让 AI 的根因分析更专业可以维护一个“历史故障知识库”里面保存过去的故障原因、处理过程、改进方案。调用模型时把相似历史故障作为参考上下文注入提示词模型就能给出更贴合实际情况的分析而不是泛泛而谈。6.5 可观测性与成本控制每次 LLM 调用都要记录输入输出 token 数、响应耗时和报错信息。上线初期建议在测试环境用假数据验证再逐步接入真实故障数据。批量生成报告时要考虑限流和预算控制避免故障高发期产生高额调用费用。7. 总结与学习路线通过本文的梳理我们已经完成了从“手动整理故障复盘”到“AI 自动生成报告”的核心路径拆解。需要记住的关键点有四个第一事件数据的质量决定报告的天花板第二提示词决定了 AI 是否能按团队规范输出第三多轮小任务比一次性大任务更稳定可靠第四人工审核和知识库收集是故障复盘系统长期运行的基础设施。如果你准备在自己的团队落地这套能力建议按这个顺序推进先拿最近一次真实故障数据做验证写一份不含敏感信息的脱敏样本然后把报告模板放入提示词跑通最小闭环再逐步加入知识库、多轮生成和告警平台自动触发能力。AI 应用开发最忌讳一上来就追求“全自动、零人工”从辅助生成初稿开始让工程师切身体会到效率提升再继续迭代才是更稳妥的路径。如果这篇文章对你有帮助可以收藏备用。接下来可以继续研究 AI Agent 开发中的工具调用编排比如让 AI 自动查询监控系统、拉取日志、关联变更记录进一步把故障复盘从“半自动”推向“高度自动化”。