服务问题根因分析报告需要同时回答三个问题：发生了什么、为什么会发生、如何确保不再发生。一份可用的模板应包含报告基本信息、问题描述与影响范围、时间线与服务恢复过程、证据链与数据来源、根因分析过程、根因结论、纠正措施与预防措施、责任人与时间计划、验证与关闭标准、附录十个部分。其中证据链按“现象—数据—推断—结论”逐层对应，根因结论区分直接原因与系统性原因并标注置信度，纠正措施分为临时遏制、纠正、预防三层，各自写明责任人、完成时间和验证方式。下文先给出可直接复制的空白模板，再逐字段说明填法，并用一份完整示例演示。
要点总览（TL;DR）
- 模板包含十个部分：报告基本信息、问题描述与影响范围、时间线与服务恢复过程、证据链与数据来源、根因分析过程、根因结论、纠正与预防措施、责任人与时间计划、验证与关闭标准、附录。
- 证据链按“现象—数据—推断—结论”逐层对应，每条推断都能回溯到具体数据来源，评审时可直接核对。
- 根因结论分开写直接原因与系统性原因，并标注置信度；置信度为中或低时须列出待验证项。
- 纠正措施分临时遏制、纠正、预防三层，每层写明责任人、完成时间和验证方式，报告才能落到改进行动。
- 必填项保证报告可追溯、可评审、可关闭；P1、P2 级问题补齐选填字段，P3、P4 级可精简但保留现象、直接原因、纠正措施和关闭结论。
可复制空白模板：服务问题根因分析报告
以下模板按文档结构排列，方括号内为占位提示。复制到文档工具后，逐项替换占位内容即可使用。表格中的行可按证据条数增减。
一、报告基本信息
- 报告编号：[如 PRB-2025-001]
- 报告标题：[服务名称] + [故障现象] + [发生日期]
- 问题等级：[P1 / P2 / P3 / P4]
- 报告状态：[草稿 / 评审中 / 已关闭]
- 编制人 / 编制日期：[姓名] / [YYYY-MM-DD]
- 评审人 / 评审日期：[姓名] / [YYYY-MM-DD]
- 关联工单 / 事件编号：[工单号、事件单号]
- 涉及服务与系统：[服务名、模块、依赖组件]
二、问题描述与影响范围
- 问题现象：[用户或监控观察到的具体表现]
- 首次发现时间与发现方式：[时间] / [监控告警、用户报障、巡检]
- 影响用户范围：[全部用户 / 某区域 / 某租户 / 某版本用户，给出数量或比例]
- 影响业务功能：[具体功能点]
- 影响时长：[开始时间至恢复时间]
- 业务损失口径：[订单失败数、请求失败率、SLA 违约情况等可量化口径]
- 是否升级为问题单：[是 / 否，问题单号]
三、时间线与服务恢复过程
| 时间 | 事件节点 | 操作人/系统 | 动作与结果 |
|---|---|---|---|
| [HH:MM] | 故障发生 | [系统/人员] | [现象] |
| [HH:MM] | 告警触发/用户报障 | [监控/客服] | [响应动作] |
| [HH:MM] | 应急响应启动 | [值班人] | [拉起人员、分工] |
| [HH:MM] | 临时遏制措施生效 | [操作人] | [回滚、限流、切换等] |
| [HH:MM] | 服务恢复 | [操作人] | [恢复判据] |
| [HH:MM] | 影响消除确认 | [负责人] | [观察时长与结论] |
四、证据链与数据来源
| 编号 | 现象 | 数据与来源 | 推断 | 支撑的结论 |
|---|---|---|---|---|
| E1 | [观察到的现象] | [日志、监控曲线、变更记录、工单记录，注明时间范围与查询入口] | [由数据得出的判断] | [指向哪条根因或排除哪条假设] |
| E2 | [现象] | [数据来源] | [推断] | [结论] |
五、根因分析过程
- 分析假设列表：[假设1、假设2、假设3]
- 逐条验证方法与结果：[假设1：验证方式、数据、结论为成立/排除]
- 排除的假设及依据：[假设2 因何排除]
- 分析方法：[时间线比对、变更关联分析、依赖链路排查、复现验证等]
- 未验证项与待确认事项：[列出并说明后续验证计划]
六、根因结论
- 直接原因：[触发本次故障的具体条件或动作]
- 系统性原因：[流程、配置管理、容量规划、测试覆盖等层面的缺陷]
- 结论置信度：[高 / 中 / 低，附判断依据]
- 结论与证据对应关系：[结论1 对应 E1、E3；结论2 对应 E2]
- 待验证项：[如有，写明验证方式与期限]
七、纠正与预防措施
| 层级 | 措施内容 | 针对的根因 | 责任人 | 完成时间 | 验证方式 |
|---|---|---|---|---|---|
| 临时遏制 | [止血动作] | [直接原因] | [姓名] | [日期] | [验证判据] |
| 纠正 | [消除已发生问题的动作] | [直接原因] | [姓名] | [日期] | [验证判据] |
| 预防 | [防止同类问题再发生的动作] | [系统性原因] | [姓名] | [日期] | [验证判据] |
八、责任人与时间计划
- 措施总负责人：[姓名]
- 各措施责任人与协作人：[逐条列出]
- 里程碑：[措施启动、中期检查、全部完成的时间点]
- 延期处理规则：[延期申请方式与审批人]
九、验证与关闭标准
- 措施完成判据：[每条措施的完成标志]
- 效果验证方式：[观察周期、监控指标、回归测试、复现验证]
- 关闭条件：[措施全部完成且验证通过、观察期内无复发、报告评审通过]
- 关闭审批人 / 关闭日期：[姓名] / [YYYY-MM-DD]
十、附录
- 关键日志片段与截图：[附件清单]
- 监控曲线与报表：[附件清单]
- 变更记录与配置差异：[附件清单]
- 相关工单、问题单、复盘会议记录：[链接或编号]
字段说明：每个部分填什么、证据链怎么串
模板的价值取决于字段口径是否统一。同一团队多次填写时，如果“影响范围”有时写用户数、有时写功能名，后续统计和复盘就无法比较。下表逐字段说明填写含义，重点解释证据链、根因结论和措施分层的呈现方式。
| 部分 | 字段 | 填写含义与口径 |
|---|---|---|
| 基本信息 | 问题等级 | 按团队既定分级标准填写，等级决定后续字段的详略与评审层级 |
| 基本信息 | 关联工单/事件编号 | 填写原始事件单与问题单编号，保证报告可回溯到处理记录 |
| 影响范围 | 影响用户范围 | 统一用数量或比例表述，并注明统计时点；无法精确统计时写明估算方法与误差 |
| 影响范围 | 业务损失口径 | 选择可核验的指标，如失败请求数、失败率、SLA 违约时长，避免只写“影响较大” |
| 时间线 | 节点定义 | 至少覆盖故障发生、发现、响应启动、遏制生效、服务恢复、影响消除六个节点，每个节点写明判据 |
| 证据链 | 现象 | 只写观察到的客观表现，不掺入原因判断 |
| 证据链 | 数据与来源 | 写明数据种类、时间范围、查询入口，使他人可复核 |
| 证据链 | 推断 | 由数据直接得出的判断，一条数据对应一条推断，不跨层跳跃 |
| 证据链 | 支撑的结论 | 标明该证据支持或排除了哪条根因假设，形成“现象—数据—推断—结论”的闭环 |
| 根因结论 | 直接原因 | 触发本次故障的具体条件，回答“这次为什么发生” |
| 根因结论 | 系统性原因 | 使直接原因得以发生的流程或机制缺陷，回答“为什么允许它发生” |
| 根因结论 | 置信度 | 依据证据充分程度标注高、中、低；低置信度结论须列出待验证项 |
| 措施 | 临时遏制 | 恢复服务或限制影响的动作，可在根因未确认前执行 |
| 措施 | 纠正 | 针对直接原因消除已发生问题的动作，如修复配置、修正数据 |
| 措施 | 预防 | 针对系统性原因的动作，如补充检查项、调整变更流程、增加监控覆盖 |
| 验证关闭 | 验证方式 | 每条措施对应可观察的验证判据，并写明观察周期 |
证据链的串联方式是这份模板的核心。填写时先列现象，再为每个现象找到可复核的数据，由数据得出推断，最后把推断归入某条根因假设的成立或排除。这样写出的根因结论，每句话都能指回具体证据，评审时可以直接核对，而不是依赖撰写者的经验判断。
根因结论要站得住，需要把直接原因和系统性原因分开写。直接原因通常是一两个具体条件，系统性原因则指向流程、配置管理或容量规划层面的缺口。两者混写会导致措施失去针对性：只写直接原因，措施停留在修复个案；只写系统性原因，又无法解释本次故障的触发路径。标注置信度并列出待验证项，可以避免把相关性写成因果性。
必填与选填：哪些字段不能空
报告字段并非全部同等重要。必填项用于保证报告可追溯、可评审、可关闭；选填项用于补充说明，按问题等级和实际情况取舍。下表给出对照。
| 字段 | 必填/选填 | 理由与适用情形 |
|---|---|---|
| 报告编号、标题、问题等级、编制人、编制日期 | 必填 | 报告的身份信息，缺失则无法归档和检索 |
| 关联工单/事件编号 | 必填 | 保证报告与原始处理记录对应，便于复核 |
| 问题现象、首次发现时间、影响范围 | 必填 | 界定问题边界，是后续分析和定级的依据 |
| 时间线六个核心节点 | 必填 | 还原处理过程，评估响应时效 |
| 证据链至少一条完整记录 | 必填 | 根因结论的最低证据要求 |
| 直接原因、系统性原因、置信度 | 必填 | 报告的核心结论 |
| 至少一条纠正措施与一条预防措施 | 必填 | 确保报告落到改进行动 |
| 措施责任人、完成时间、验证方式 | 必填 | 措施可执行、可跟踪、可关闭 |
| 关闭条件与关闭审批人 | 必填 | 明确报告终止标准 |
| 业务损失口径 | 选填 | P1、P2 级问题建议填写；无法量化时注明原因 |
| 分析假设列表与排除过程 | 选填 | 复杂问题建议完整记录；简单问题可只写结论依据 |
| 待验证项 | 选填 | 置信度为中或低时必填 |
| 里程碑与延期规则 | 选填 | 措施跨团队、周期较长时填写 |
| 附录附件 | 选填 | 正文已引用关键数据时可只列清单 |
必填项缺失时，不应留空提交，而应走补充路径：先由编制人标注缺失原因和补齐期限，再由评审人确认是否允许带缺评审。影响范围和证据链两类字段缺失时，建议暂缓评审，因为这两项直接决定根因结论是否成立。
不同问题等级下的字段取舍可以这样处理：P1、P2 级问题填写全部必填项，并补齐业务损失口径、假设排除过程和附录；P3 级问题保留必填项，选填部分从简；P4 级问题可合并为简版报告，重点保留现象、直接原因、纠正措施和关闭结论。等级划分标准由团队自行定义，模板只规定各等级的最低字段要求。
填写示例：一次服务中断的完整报告
以下示例为演示情景，用于说明各字段的填写方式，数据均为虚构。
示例背景与影响范围
某订单服务在版本发布后出现接口超时，部分用户下单失败。影响范围为某区域约 12% 的下单请求，持续 47 分钟。业务损失口径为失败订单 860 笔，未触发 SLA 违约。
时间线与恢复过程
| 时间 | 事件节点 | 操作人/系统 | 动作与结果 |
|---|---|---|---|
| 14:02 | 故障发生 | 订单服务 | 接口响应时间上升至 3 秒以上 |
| 14:05 | 告警触发 | 监控系统 | 超时率告警推送至值班群 |
| 14:08 | 应急响应启动 | 值班工程师 | 拉起服务负责人，分工排查 |
| 14:21 | 临时遏制生效 | 运维工程师 | 回滚至上一版本，流量逐步恢复 |
| 14:49 | 服务恢复 | 监控系统 | 超时率回落至基线，持续观察 30 分钟无复发 |
证据链逐条对应
| 编号 | 现象 | 数据与来源 | 推断 | 支撑的结论 |
|---|---|---|---|---|
| E1 | 发布后接口超时 | 发布记录 13:55 上线；监控曲线 14:02 起超时率上升 | 超时与发布时间高度吻合 | 支持“本次发布引入问题”假设 |
| E2 | 数据库连接池等待队列增长 | 应用日志 14:03–14:20 连接获取等待记录 | 新版本查询未走索引，占用连接时间变长 | 支持“慢查询耗尽连接池”假设 |
| E3 | 回滚后超时消失 | 回滚记录 14:21；监控曲线 14:30 起回落 | 问题随版本回滚而消失 | 排除基础设施与网络因素 |
根因结论写法
直接原因：新版本中订单查询语句缺少索引条件，单次查询耗时从 20 毫秒升至 1.2 秒，连接池在高峰流量下被占满，导致接口超时。系统性原因：发布前的 SQL 审核清单未覆盖索引检查项，压测环境数据量与生产差异较大，未能暴露该问题。结论置信度：高，依据 E1、E2、E3 三条证据相互印证。
纠正与预防措施写法
| 层级 | 措施内容 | 针对的根因 | 责任人 | 完成时间 | 验证方式 |
|---|---|---|---|---|---|
| 临时遏制 | 回滚至上一稳定版本 | 直接原因 | 运维工程师 | 已完成 | 超时率回落至基线 |
| 纠正 | 为新查询补充索引并重新发布 | 直接原因 | 后端负责人 | 发布后 3 个工作日 | 压测环境查询耗时低于 50 毫秒 |
| 预防 | SQL 审核清单增加索引检查项，压测数据量对齐生产 | 系统性原因 | 研发经理 | 两周内 | 下一次发布按新清单执行并留存记录 |
验证与关闭填写
关闭条件：三条措施全部完成；新版本上线后观察 7 天，超时率维持在基线内；SQL 审核清单在最近一次发布中实际执行。关闭审批人为服务负责人，关闭日期为措施验证通过当日。
当报告需要进入团队协作流程时，证据、措施和验证记录需要与工单、问题单保持关联。ONES Desk 支持事件管理及问题管理，工单可直接关联到待办事项列表，打通服务团队和研发团队的协同；工单也可一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪至处理完成。报告中的措施条目可以据此落到具体工作项上，责任人、完成时间和验证结果随工作项状态更新，避免报告与执行脱节。报告本身及复盘记录可沉淀在 ONES Wiki 页面中，并与工单关联，便于后续同类问题检索。
调整与维护：按团队规模与问题等级裁剪模板
模板投入使用后，需要按团队分工和问题等级做裁剪，并建立版本维护机制，否则字段会逐渐流于形式或不断被临时增补。以下清单可作为落地操作参考。
- 按问题等级裁剪：为 P1 至 P4 分别定义最低字段集，等级越低字段越精简，但现象、直接原因、纠正措施和关闭结论始终保留。
- 按团队分工调整责任人字段：小型团队可由一人兼任编制与评审，但编制人和审批人分列两栏，保留职责区分；跨团队问题增加“协作团队接口人”字段。
- 建立模板版本与变更记录：在模板首页记录版本号、修订日期、修订内容和修订人，字段增删须经评审后统一发布。
- 与工单、问题记录关联：报告编号与工单号、问题单号互相引用，措施条目对应到具体工作项，验证结果回写到报告关闭栏。
- 定期复盘与更新：按季度汇总已关闭报告，检查哪些字段长期为空、哪些字段反复补充说明，据此合并或新增字段。
- 设置模板使用检查点：在问题评审会上核对报告字段完整性，把字段缺失情况纳入复盘议题。
裁剪的原则是保留可追溯性。字段可以精简，但每条根因结论仍应能指回证据，每条措施仍应有责任人和验证方式。团队规模较小时，可以把证据链和分析过程合并在一张表中填写；问题等级较低时，可以缩短观察周期，但关闭条件仍需事先写明。模板版本更新后，旧报告按原版本归档，新报告使用新版本，避免同一时期出现多种口径。
常见问题
报告里的证据链需要保留原始日志吗，还是写清查询入口即可？
两种做法都可以，取决于团队能否长期访问原始数据。正文模板要求证据链写明数据种类、时间范围和查询入口，使他人可复核；如果日志保留周期短于报告的归档周期，建议把关键片段作为附录附件保存。判断标准是：评审人或后续接手的人能否凭报告中的记录独立复核这条推断。查询入口会失效、日志会被轮转清理时，保留原始片段更稳妥。
根因暂时无法确认时，报告应该怎么提交？
可以提交，但要把结论状态写清楚。根因结论栏标注置信度为低，列出待验证项、验证方式和期限，措施栏先填临时遏制和已能确定的纠正动作。评审人据此判断是否允许带缺评审。正文必填项缺失的处理路径同样适用：编制人标注缺失原因和补齐期限，影响范围和证据链两类字段缺失时建议暂缓评审，因为这两项直接决定根因结论是否成立。
临时遏制措施和纠正措施在实际填写时容易混，怎么区分？
看措施针对的对象和时机。临时遏制用于恢复服务或限制影响，可以在根因未确认前执行，例如回滚版本、限流、切换流量；纠正针对已确认的直接原因，消除已经发生的问题，例如补充索引、修正配置、修复数据。同一次故障中两者可能都存在，填写时分别列行，各自写明针对的根因、责任人和验证方式，避免把止血动作当成问题已解决的证明。
报告关闭后，措施的执行进度还要继续跟踪吗？
要跟踪。关闭条件通常要求措施全部完成且验证通过，但预防类措施周期较长，可能在报告关闭时仍在执行。建议把每条措施对应到具体工作项，责任人、完成时间和验证结果随工作项状态更新。ONES Desk 支持工单关联到 ONES Project 的需求或缺陷工作项，可跟踪至处理完成；报告与复盘记录可沉淀在 ONES Wiki 页面并与工单关联，便于后续同类问题检索。
小团队人手少，模板字段能不能大幅删减？
可以精简，但要保留可追溯性。小型团队可由一人兼任编制与评审，编制人和审批人仍分列两栏保留职责区分；证据链和分析过程可合并在一张表中填写；P4 级问题可合并为简版报告。现象、直接原因、纠正措施和关闭结论这四项建议始终保留，它们是报告能够被复核和关闭的最低要求。字段删减后应在模板版本记录中注明，避免同一时期出现多种口径。
