服务问题根因分析报告模板：应包含哪些部分

服务问题根因分析报告模板应覆盖九个部分：报告基本信息、问题描述与影响范围、时间线与服务恢复过程、证据链与调查方法、根因结论、纠正措施与预防措施、责任人与时间节点、验证与关闭条件、附录证据清单。其中证据链、根因结论和措施跟踪三段需要能相互追溯。下面给出一份可直接复制填写的空白表，并配套字段说明、必填标注、完整示例和模板维护方法。

要点总览（TL;DR）

• 模板覆盖九个部分：报告基本信息、问题描述与影响范围、时间线与服务恢复过程、证据链与调查方法、根因结论、纠正措施与预防措施、责任人与时间节点、验证与关闭条件、附录证据清单。
• 证据链按“证据编号—来源—采集时间—对应假设—支持或排除”逐条记录，根因结论中每个判断都能回溯到证据编号。
• 根因结论同时写直接原因和系统性原因：前者解释这次为何发生，后者解释为何现有流程或监控未能提前发现或拦截。
• 报告编号、问题现象、时间线关键节点、证据链、直接原因与系统性原因、措施责任人与截止日期为必填，缺失时报告退回补充，不进入评审。
• 模板可按严重级别和团队规模裁剪，证据链与根因结论两个区块建议保留完整，模板本身应有版本号与变更记录。

可复制空白模板：服务问题根因分析报告表

下表为空白模板，可整体复制到文档工具或表格工具中使用。表格按报告填写顺序排列，每个区块对应报告的一个组成部分。填写时保留区块标题，行数按实际证据和措施数量增减。

区块	字段	填写内容
一、报告基本信息	报告编号
	报告标题
	关联事件/工单编号
	报告人
	评审人
	创建日期
	最后更新日期
	报告状态	草稿 / 待评审 / 已评审 / 已关闭
二、问题描述与影响范围	问题现象
	受影响服务
	受影响用户或业务范围
	发生时间
	发现时间与发现方式
	严重级别
三、时间线与服务恢复过程	关键时间点
	处置动作
	操作人
	服务恢复时间
四、证据链与调查方法	证据编号
	证据来源
	采集时间与采集方式
	指向的假设
	支持或排除
五、根因结论	直接原因
	系统性原因
	排除的其他假设
	结论依据的证据编号
六、纠正措施与预防措施	措施描述
	措施类型	纠正 / 预防
	责任人
	截止日期
	状态	未开始 / 进行中 / 已完成 / 已验证
七、验证与关闭条件	验证方式
	验证结果
	关闭条件
	关闭日期与关闭人
八、附录证据清单	附件编号
	附件名称与存放位置
	对应证据编号

模板中的“责任人与时间节点”并入措施区块记录，每条措施单独一行，避免责任分散。报告状态字段用于控制流程：状态为“草稿”时允许补充证据，进入“待评审”后证据链与根因结论应已定稿。

字段说明：每个字段填什么、证据链怎么记

字段说明与空白模板逐项对应。填写口径统一后，不同报告人产出的报告才能横向比较和复用。

字段	填写口径
报告编号	按团队约定规则生成，建议包含年份与流水号，便于归档检索。
关联事件/工单编号	填写触发本次分析的事件单或问题单编号，一份报告对应一个主问题。
问题现象	描述用户可感知的异常，写清报错信息、不可用功能或性能表现，避免直接写推测原因。
受影响用户或业务范围	写明受影响的用户群体、业务线或区域，能量化时给出数量或比例。
严重级别	按团队既有分级标准填写，与事件单级别保持一致。
关键时间点	记录到分钟，包括问题发生、告警触发、首次响应、关键处置动作、服务恢复等节点。
处置动作与操作人	每个时间点对应一个具体动作和操作人，回滚、扩容、切换等动作写清对象。
证据编号	按 E01、E02 顺序编号，与附录附件编号建立对应关系。
证据来源	写明来源系统或位置，如监控平台、日志系统、变更记录、用户反馈截图。
采集时间与采集方式	记录证据获取的时间和方式，说明是自动导出还是人工截取。
指向的假设	每条证据对应调查中的一个假设，假设可用 H1、H2 编号，便于在根因结论中引用。
支持或排除	明确标注该证据支持还是排除了对应假设，并简述判断理由。
直接原因	解释问题为何在此刻发生，落到具体变更、配置、容量或依赖故障。
系统性原因	解释现有流程、监控、评审或预案为何未能提前发现或拦截，指向机制层面。
排除的其他假设	列出调查中排除的主要假设及排除依据的证据编号。
措施类型	纠正措施用于消除已发生问题的影响，预防措施用于降低同类问题复发概率。
验收标准	每条措施写明完成标志，如“变更评审增加容量检查项并试运行一个月”。
验证方式与关闭条件	验证方式说明如何确认措施生效，关闭条件说明满足哪些条件后报告可关闭。

证据链的记录要点是“一条证据对应一个假设”。同一假设可由多条证据支持，但每条证据都要单独编号并注明支持或排除。根因结论中引用的每个判断，都应能在证据链中找到对应编号，形成从结论回溯到证据的路径。

直接原因与系统性原因的区分写法可以这样把握：直接原因回答“这次为什么发生”，通常指向一次具体变更、一个配置项或一个依赖异常；系统性原因回答“为什么没有更早发现或拦住”，通常指向监控覆盖、变更评审、容量规划或应急预案中的缺口。两者都写，报告才具备改进价值。

必填与选填：哪些字段不能空

必填字段缺失时，报告不能进入评审，也不能关闭。下表标注各字段要求及缺失处理规则。

字段	要求	说明
报告编号、报告标题、关联事件/工单编号	必填	保证报告可检索、可关联
报告人、创建日期、报告状态	必填	明确责任人与流程位置
评审人	必填（评审阶段起）	草稿阶段可暂空
问题现象、受影响服务、发生时间、严重级别	必填	构成问题定义的基础
受影响用户或业务范围	必填	无法量化时写定性范围
发现时间与发现方式	必填	用于评估监控有效性
关键时间点、处置动作、恢复时间	必填	至少覆盖发生、响应、恢复三个节点
证据编号、来源、指向假设、支持或排除	必填	根因结论的依据
直接原因、系统性原因	必填	两者缺一不可
措施描述、类型、责任人、截止日期	必填	每条措施单独填写
验证方式、关闭条件	必填（关闭阶段）	评审阶段可先写计划
排除的其他假设	选填	重大问题时建议填写
采集时间与采集方式	选填	证据来源为自动采集时可简写
验收标准	选填	措施较复杂时建议补充
附录附件编号与存放位置	选填	存在外部附件时填写

不同严重级别下字段要求可以调整。重大服务中断通常要求证据链完整、排除假设写明、验证方式具体；一般级别问题允许合并部分时间线节点，但直接原因、系统性原因和措施责任人仍需填写。必填字段缺失时，报告退回报告人补充，评审人不在缺失状态下签字。

填写示例：一次服务中断的完整报告

以下示例为演示情景，用于说明字段之间的对应关系，不代表真实案例。

报告基本信息：报告编号 RCA-2024-017，标题“订单查询服务中断 42 分钟”，关联事件单 INC-2024-1032，报告人为服务运营岗，评审人为技术负责人，状态为已评审。

问题描述与影响范围：现象为订单查询接口返回超时，受影响服务为订单查询服务，影响约 3000 名用户的查询操作，发生时间为 10:02，10:05 由监控告警发现，严重级别为重大。

时间线与恢复过程：10:02 接口超时率上升；10:05 告警触发；10:08 值班工程师确认数据库连接池耗尽；10:15 执行连接池扩容并重启部分实例；10:44 服务恢复，超时率回落至正常水平。

证据链：E01 监控平台超时率曲线，支持假设 H1“数据库连接不足”；E02 数据库连接池监控，显示连接数达到上限，支持 H1；E03 当日变更记录，显示上午上线了新的批量查询任务，支持假设 H2“新增任务占用连接”；E04 应用日志，未发现网络层异常，排除假设 H3“网络故障”。

根因结论：直接原因是新上线的批量查询任务未限制并发连接数，占满连接池；系统性原因是变更评审未包含对数据库连接容量的评估，监控也未对连接池使用率设置预警。排除的其他假设为网络故障，依据为 E04。

纠正与预防措施：纠正措施为限制批量任务并发数并恢复服务，责任人为研发工程师，截止日期为当日，状态为已完成；预防措施为在变更评审清单中增加容量评估项、为连接池使用率增加预警阈值，责任人为技术负责人，截止日期为两周后，状态为进行中。

验证与关闭：验证方式为观察一周内连接池使用率峰值与预警触发记录，关闭条件为两项预防措施完成并试运行一周无同类告警，关闭人为技术负责人。

示例中的每个根因判断都能回溯到证据编号，每条措施都有责任人和截止日期，与前述字段说明保持一致。

调整与维护：按团队规模裁剪模板

模板需要随团队规模和服务级别调整，但证据链与根因结论两个区块建议保留完整，它们是报告可追溯的基础。

按严重级别裁剪时，重大问题的报告保留全部区块，证据链逐条编号；一般问题可合并时间线节点，将发现方式与发生时间合并记录；轻微问题可使用精简版，保留问题描述、直接原因、纠正措施和关闭条件。裁剪规则应写入模板说明，避免不同报告人自行取舍。

小团队可以采用精简版：报告基本信息合并为三行，时间线只记录发生、响应、恢复三个节点，证据链保留编号、来源和支持或排除三列。团队规模扩大、服务数量增加后，再启用完整版，补充采集方式、排除假设和验收标准等字段。取舍标准是报告能否支撑评审和后续复盘，而非字段数量多少。

模板本身应有版本号和变更记录。每次调整字段时记录变更日期、变更内容和影响范围，旧版本报告按原版本归档，不随模板升级改写。报告归档时与事件单、问题单建立关联，复盘时按问题类型检索历史报告，复用其中的措施和验证方式。

在工具层面，报告需要与工单、措施任务和知识沉淀保持关联。ONES Desk 支持事件管理及问题管理，工单可直接关联到待办事项列表，打通服务团队和研发团队协同；工单也可一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成。报告中的纠正与预防措施可以落到具体工作项上跟踪状态和截止日期，报告正文与证据材料可沉淀在 ONES Wiki 页面中，并与项目工作保持关联，便于后续复盘检索。具体配置与版本能力以实际产品为准。

常见问题

报告已经写完，但证据链里的部分日志已被轮转清理，报告还能进入评审吗？

可以评审，但需要在证据链中如实标注证据状态。建议在“采集时间与采集方式”字段注明原始日志已轮转，并补充当时导出的截图、监控曲线或工单记录作为替代证据，同时说明替代证据与原始证据的对应关系。如果关键假设缺少任何可查证据支撑，评审时应将该假设标为“证据不足”，根因结论只保留有证据支持的判断，避免用推测填补空缺。

同一个服务问题反复出现，每次都要单独写一份根因分析报告吗？

建议以问题单为主线合并管理。首次发生时按模板完整填写报告；同类问题再次发生时，可在原报告下追加新的时间线与证据条目，更新根因结论和措施状态，不必每次新建独立报告。如果复发原因与首次结论不同，则另建报告并在“关联事件/工单编号”中注明与原报告的关系。合并记录便于复盘时看清措施是否真正生效。

纠正措施和预防措施由不同团队负责时，报告如何跟踪到关闭？

每条措施单独一行，分别填写责任人、截止日期和状态，避免把多项措施合并成一条导致责任分散。措施跨团队时，责任人填写实际执行方，报告人负责定期核对状态并在“最后更新日期”中体现。验证阶段逐条确认措施完成情况，全部措施达到验收标准且观察期内无同类问题复发，才满足关闭条件。在工具层面，可将措施落到具体工作项上跟踪状态和截止日期，ONES Desk 支持工单关联待办事项列表，也可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪直至处理完成，报告正文与证据材料可沉淀在 ONES Wiki 页面中，便于后续复盘检索。

小团队人手有限，模板可以精简到什么程度？

精简版至少保留问题描述、时间线三个关键节点（发生、响应、恢复）、证据编号与来源、直接原因、纠正措施及责任人和关闭条件。证据链可以只保留编号、来源和支持或排除三列，系统性原因可用一段话概括。取舍标准是报告能否支撑评审和后续复盘，证据链与根因结论不建议省略。团队规模扩大或服务数量增加后，再启用完整版补充采集方式、排除假设和验收标准等字段。

报告关闭后，历史报告和证据材料放在哪里便于以后检索？

建议按报告编号归档，并与触发分析的事件单或问题单建立双向关联，附录证据清单中写明附件编号与存放位置。归档时保留报告当时的模板版本号，模板后续升级不改写旧报告。复盘时可按问题类型、受影响服务或严重级别检索历史报告，复用其中的措施和验证方式。ONES Wiki 可用于管理复盘记录及其他需要长期沉淀的知识，并可与项目、任务等研发管理场景结合使用，使文档和项目工作保持关联。