GP-02 · 故障 RCA 复盘报告初稿

① 场景引入

一、这件事现在是什么样

智算集群运维（GPU 与高速网络） · 真实业务触发

8 月 21 日凌晨 A12 区 GPU 降频、客户星澜科技训练任务变慢并在群里要书面说明。SLA 合同约定投诉受理后 24 小时内须提交第一份书面处理报告 —— 现在是第二天上午十点，时间线散落在监控截图、微信聊天、值班记录和厂商电话里。

二、痛点 · 每条都有来源

1. IDC 托管 SLA 协议明确约定投诉受理后 24 小时内提供第一份书面处理情况报告 —— 这是合同刚性，不是「有空再写」
   依据：IDC 托管 SLA 协议明确约定：受理投诉后 24 小时内向甲方提供第一份书面形式的投诉处理情况报告 ——故障后的文书压力是合同刚性的
2. 运维规范要求一级批量停机、重复频发故障 24 小时内完成 RCA 复盘，但「复盘流于形式、报告完成后不跟进」是行业公开的秘密
   依据：运维规范要求一级批量停机、重复频发故障必须 24 小时内完成RCA 复盘报告，但「复盘流于形式、报告完成后不跟进」是行业公开的秘密
3. 时间线靠翻聊天记录、监控截图、个人笔记拼 —— 每个环节的精确时间只有当事人在场才知道，「隐性降速不中断任务最难查」
   依据：大规模 GPU 集群运维实践：Xid 79 掉卡（需换卡）、Xid 48/63/94 不可纠正 ECC、Xid 31 多为客户代码问题；隐性降速（PCIe 降速、GPU降频）不中断任务最难查 —— 实测 PSU 问题导致 SM Clock 从 2GHz 掉到 500MHz、性能降至 1/4 而监控无感
4. 责任界定敏感：外包、设备厂商、自己人各说各话 —— 误拔电源查三天的教训就是「没有记录就没有追责」
   依据：U 位资产管理从业者自述：季度盘点账实不符比例接近 8%；误拔电源「查了三天才知道是外包运维人员干的，但人家说我也没记录啊」；审计突击「留给你的时间往往只有几十分钟」

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• IDC 托管 SLA 协议明确约定投诉受理后 24 小时内提供第一份书面处理情况报告 —— 这是合同刚性，不是「有空再写」
• 运维规范要求一级批量停机、重复频发故障 24 小时内完成 RCA 复盘，但「复盘流于形式、报告完成后不跟进」是行业公开的秘密
• 时间线靠翻聊天记录、监控截图、个人笔记拼 —— 每个环节的精确时间只有当事人在场才知道，「隐性降速不中断任务最难查」
• 责任界定敏感：外包、设备厂商、自己人各说各话 —— 误拔电源查三天的教训就是「没有记录就没有追责」

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 时间线重建 · 五源拼出完整事件链从 8 月 19 日巡检发现空调异常，到 8 月 21 日凌晨降频、客户投诉、临时处置，每个节点标来源与置信度 —— 含糊的标「待核实」
2. 根因分析 · 5Why 沿因果链下钻为什么降频（进风超温）→ 为什么超温（空调故障未修复）→ 为什么未修复（排期 8 月 22 日）→ 为什么排了 3 天（厂商人力）→ 为什么没有应急预案（高密区无备用制冷）—— 每层给证据
3. 影响范围 · 哪些客户哪些任务受累受影响节点、时长、任务类型逐项成表；与客户感知（iter time 变化）互证
4. SLA 影响测算 · 这件事按合同怎么算对照 SLA 条款逐项判定：计划内维护免责条款适用与否、降频是否构成「服务中断」、赔付金额的计算口径 —— 争议点单独列出
5. 成稿 · RCA 报告与整改跟踪清单标准 RCA 栏位（概述/时间线/根因/影响/整改项）+ 整改项跟踪清单，责任认定栏留空，签批栏齐备

要准备什么：DCGM 告警与 clock throttle 导出（故障时段）GPU 侧的权威时间线动环告警与巡检记录（8 月 19-21 日）环境侧的因果链起点客户与值班微信群聊天记录导出（txt）客户感知时间与承诺记录值班交接班记录（8 月 19-21 日）巡检发现与报修进度的中间证据空调厂商维修工单与通话记录报修时间与「8 月 22 日进场」约定的出处

为什么这个场景值得做

优先级评分：痛感 5 × AI 适配 5 ÷ 落地难度 3 = 8.3

最大差异点：与「工单系统自动生成故障报告」的区别：那些系统的数据止步于自己平台内。本场景的时间线从五处拼起来 —— DCGM 告警、动环告警、微信沟通、值班记录、厂商工单 —— 每个时间点标注来源与置信度。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：故障RCA复盘报告.xlsx 正式件 · 客户版与内部版 · 签批栏
• 可派发清单：整改项跟踪清单.xlsx 每条带责任部门/期限/验收标准
• 可派发清单：事件时间线.xlsx 五源拼合 · 每个节点标注出处

这套东西不承诺什么：不下最终责任认定（责任认定栏留空 —— RCA 是给责任认定会提供证据的，不是替它做结论）。不替客户决定赔偿方案。整改项只跟踪状态与期限，「已完成」的确认要责任部门签字。对外发送版需人工审定后发出。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：云枢智算数据服务有限公司（虚构 · 河北张家口 · 186 人）4 号楼，2026 年 8 月 21 日上午 10:00。8 月 21日凌晨 A12 区 4 节点因列间空调CRAC-A12-03 故障降频 5.2 小时，客户星澜科技 02:05 在群里反馈训练任务变慢并要书面说明 —— SLA 合同约定投诉受理后 24 小时内提交第一份书面处理报告，红线是 8 月 22 日 02:05。时间线散在

DCGM、动环、微信群、值班记录和厂商工单五处；本演示把五源拼成一份 RCA 初稿：客户版（事实 + 处置）与内部版（含赔付口径争议）分开出。

输入素材5 份（DCGM / 动环 / 微信 / 值班记录 / 厂商工单）时间线8/19 14:33 → 8/21 12:45 · 14 节点五源对齐赔付口径阶梯 9.8 万 / 性能 24.5 万 · 整改 18.6 万结论暂缓全文发出 · 事实通报版先行的两个方案

输入算力基础设施企业手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_DCGM告警与降频导出_8月21日.xlsx DCGM 导出（8/21 00:00-13:00）：4 节点 SM Clock 降频与恢复的完整记录 ——GPU 侧的权威时间线集群监控后台自动记录 · 值班工程师凌晨导出
• 02_动环告警与巡检记录_8月19至21日.xlsx 动环后台告警（8/19-8/21）—— 环境侧的因果链起点，与巡检日报 FA-01 同源动环后台自动采集 · 值班不常看的系统数据
• 03_客户与值班微信群记录.txt 星澜客户群与内部值班群的聊天记录（8/21 01:52-12:50），共 13 段 —— 客户感知时间与处置承诺的出处值班手机导出 · 凌晨的处置痕迹全在这里
• 04_值班交接班记录_8月19至21日.xlsx 值班交接班记录（8/19-8/21，5 次交接）—— 巡检发现与报修进度的中间证据交接班记录本拍照整理 · 每班一份
• 05_空调厂商维修工单与通话记录.xlsx 空调厂商维修工单 WA-0821（含 3 通通话记录）—— 报修时间与「8/22 进场」约定的唯一出处厂商工单系统截图 + 通话录音摘录 · 出了事才翻得出来的资料

注意标橙色那一份 —— 05_空调厂商维修工单与通话记

录.xlsx。它厂商工单系统截图 + 通话录音摘录 · 出了事才翻得出来的资料，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

昨天凌晨 A12 区 GPU 降频、星澜那边任务变慢的事，客户在要书面说明，合同规定 24 小时内要给第一份报告。 DCGM 导出、动环告警、巡检记录、微信聊天、厂商工单都在这里，帮我拼出完整时间线和根因。 哪些环节是拿不准的标出来。给客户的版本和内部版本分开。责任认定那栏留空，谁的责任不归我们定。

RCA 的标准栏位（时间线/5Why/影响/整改）与 SLA 判读口径已内置，客户只需把五处原始记录扔进来。

触发事情是这么来的

合同给你的 24 小时，不该用来翻聊天记录

凌晨的火场刚刚扑灭：01:47 降频、02:05 客户在群里要说法、02:10 起任务迁移、07:00 恢复、10:00 维修师傅提前进场、12:40 修复 —— 每个时间点散在不同系统和个人手机里。现在是 8 月 21 日上午 10:00，距 24 小时红线（8/22 02:05）还有 16 小时，RCA 初稿要从五处原始记录里拼出来。

第 1 步 · 时间线重建 · 五源拼出完整事件链

每个节点标来源与置信度，含糊的标待核实

这一步的看点 · 从历史里想起了公司踩过的坑去年 11 月 B 区供电模块事件，当时 RCA 写的是「设备偶发故障」，没有下钻到「同回路 6 张卡误换」那一层—— 三个月后才由检测报告翻案。这次 A12 事件的特征与 B 区高度相似（同位置聚集、换下的卡复检无损坏），换卡台账（GP-01）把两件事连了起来 —— 这条不靠当年经手人还在不在职。

第 2 步 · 根因分析 · 5Why 沿因果链下钻

每层给证据，落到可整改的物件上

这一步的看点 · 排除性结论「GPU 硬件故障可以排除 —— 4 节点 Xid 零记录、ECC 计数零、温度墙触发但源头在进风温度；当晚换下的 2 张卡复检 0 损坏（GP-01 台账），空调修复后零复发」。这一条直接保住了 4 张备件卡和一次 4 节点白拆，也是给客户解释「为什么不用停机换卡」的依据；客户代码问题同样可以排除 —— 同一任务迁 B 区后满频恢复（GP-03 三线交叉）。

第 3 步 · 影响范围 · 哪些客户哪些任务受累

节点级、任务级、客户可感知三个口径并列

这一步的看点 · 该拦的地方拦住了报告结论：「本 RCA 为内部初稿，不建议直接转发客户—— 8.21 事件中『降频是否构成服务中断』合同未定义，转发前须法务与商务确认口径」。按 SLA 要求的 24 小时第一份报告，先发事实通报版（时间线 + 处置措施），赔付口径另附 —— 两份东西不能混。

第 4 步 · SLA 影响测算 · 这件事按合同怎么算

双口径并列，争议点单独列出

这一步的看点 · 把技术动作翻译成钱整改投入 18.6 万（换机 16.4 + 备用制冷 2.2）低于一次性赔付风险 24.5 万 —— 这笔账写给总经理：整改不是花钱，是把下一次 24.5 万的风险一次性买断。对照只修不换的老路：CRAC-A12-03 三个月已经修了 4 次（FA-01 隐患台账），每次「再修修看」都在赌下一次不是 24.5 万。

第 5 步 · 成稿 · 客户版与内部版分开

标准 RCA 栏位 + 整改跟踪清单，责任认定栏留空

这一步的看点 · 排除性结论两份报告里都写明「GPU 硬件与客户代码可以排除」 ——客户侧不用自查代码、备件不用再拆，责任聚焦制冷排期与应急机制；但认定栏留空：RCA 是给责任认定会提供证据的，不是替它做结论。

这份 RCA 不能全文直接发客户内部初稿含双口径赔付测算（9.8 万 / 24.5 万）与责任链条，其中「降频是否构成服务中断」合同未定义 —— 转发前须法务与商务确认口径；但 24 小时红线（8/22 02:05）不等法务。方案一：今晚 20:00 前发事实通报版（时间线 + 处置措施 + 整改承诺，吴敏审定）—— 满足 24 小时条款；赔付测算 9.8-24.5 万留内部版，9 月5 日 SLA 月报（OP-01）按合同口径统一核算。方案二：事实通报版附「性能影响说明」—— 把缩水卡时 2.1 万的账主动摆上桌（与工单 1.4 万口径的差异写明）；风险是客户可能直接引用 24.5 万的性能口径，收益是透明换信任 —— 星澜年合同 2,340 万（195 万 × 12），续约谈判的先手牌在我们手里。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 第一份书面报告从「翻一天聊天记录」变成「核对一遍已拼好的时间线」—— 24 小时红线守得住
• ✓ 「降频是否构成服务中断」的合同缺口暴露出来了 —— 这是下次签 SLA 要补的条款，比这次赔付本身值钱
• ✓ B 区与 A12 两次事件的关联沉淀进台账 —— 第三次同类事件会在第一天就被顶出来
• ✓ 整改项从「会上说说」变成带期限和验收标准的跟踪清单

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 能不能直接把 RCA 报告发给客户？ 不能。内部初稿转客户前须经法务与商务确认口径 —— 我们已把客户版与内部版拆开，客户版只含事实时间线与处置措施。
• 根因就一定是空调吗？ 证据链指向空调（巡检-告警-降频三源互证），但报告保留了「待核实」标注的两处 —— 空调厂商的最终检测结论回来前，根因栏写的是「指向性结论」。
• 赔付金额你们说了算吗？ 不算。我们算的是「按合同阶梯的赔付区间与争议点」，确认口径和谈判是商务的事 —— 争议点列得越清楚，谈判越主动。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

故障 RCA 复盘报告初稿 —— 合同给你的 24 小时，不该用来翻聊天记录 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

incident-rca-draft.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是算力基础设施企业手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁GP-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

• 01_DCGM告警与降频导出_8月21日.xlsx DCGM 导出（8/21 00:00-13:00）：4 节点 SM Clock 降频与恢复的完整记录—— GPU 侧的权威时间线
• 02_动环告警与巡检记录_8月19至21日.xlsx 动环后台告警（8/19-8/21）—— 环境侧的因果链起点，与巡检日报 FA-01 同源
• 03_客户与值班微信群记录.txt 星澜客户群与内部值班群的聊天记录（8/21 01:52-12:50），共 13 段 —— 客户感知时间与处置承诺的出处
• 04_值班交接班记录_8月19至21日.xlsx 值班交接班记录（8/19-8/21，5 次交接）—— 巡检发现与报修进度的中间证据
• 05_空调厂商维修工单与通话记录.xlsx 空调厂商维修工单 WA-0821（含 3 通通话记录）—— 报修时间与「8/22 进场」约定的唯一出处

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

昨天凌晨 A12 区 GPU 降频、星澜那边任务变慢的事，客户在要书面说明，合同规定 24 小时内要给第一份报告。 DCGM 导出、动环告警、巡检记录、微信聊天、厂商工单都在这里，帮我拼出完整时间线和根因。 哪些环节是拿不准的标出来。给客户的版本和内部版本分开。责任认定那栏留空，谁的责任不归我们定。

为什么这么短就够了：RCA 的标准栏位（时间线/5Why/影响/整改）与 SLA 判读口径已内置，客户只需把五处原始记录扔进来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• GP-02_故障RCA复盘报告.xlsx 正式件 · 客户版与内部版 · 签批栏
• GP-02_整改项跟踪清单.xlsx 每条带责任部门/期限/验收标准
• GP-02_事件时间线.xlsx 五源拼合 · 每个节点标注出处

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：DCGM 告警与 clock throttle 导出（故障时段）GPU 侧的权威时间线动环告警与巡检记录（8 月 19-21 日）环境侧的因果链起点客户与值班微信群聊天记录导出（txt）客户感知时间与承诺记录值班交接班记录（8 月 19-21 日）巡检发现与报修进度的中间证据空调厂商维修工单与通话记录报修时间与「8 月 22 日进场」约定的出处

人工边界：不下最终责任认定（责任认定栏留空 —— RCA 是给责任认定会提供证据的，不是替它做结论）。不替客户决定赔偿方案。整改项只跟踪状态与期限，「已完成」的确认要责任部门签字。对外发送版需人工审定后发出。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

智算集群运维（GPU 与高速网络） · 产出即下一步输入

• GP-01 · GPU 故障换卡台账：换了 14 张卡，哪些真坏哪些误换，不该没有人说得清
• GP-03 · GPU 利用率日报：利用率 93% 的集群正在变慢，这种病监控看不出来

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。