服务问题根因分析的依据要围绕四条线取证：问题记录、事件证据、变更与配置信息、复现与验证结果。先用问题单固定影响范围、时间线和受影响服务，再汇总关联事件单、监控告警、日志与用户反馈，接着核对变更记录、配置项和依赖关系，最后用复现或验证结果确认因果链。每类依据都写明来源、时间、责任人和结论，结论才能经得起评审。下文给出取证范围、依据清单、因果链整理步骤和完成检查表。
要点总览（TL;DR）
- 根因分析的依据按四条线归集：问题记录、事件证据、变更与配置信息、复现与验证结果，每类都要标注来源、时间、责任人和初步结论。
- 启动分析前先用问题单固定影响服务、影响范围、首次发生时间、发现渠道和恢复状态，并明确分析负责人、参与角色与取证截止时间。
- 整理因果链时按时间线排列证据，对每条候选原因逐条列出支持与反对证据，用复现、对照或回滚验证确认或排除。
- 完成判断看五点：依据可追溯、候选原因闭环、结论经评审、遗留风险明确、改进项已转跟踪；关键证据缺失时保留问题单并标注待验证。
根因分析前先固定问题单与取证范围
根因分析常见的失败是取证发散：参与的人各查一段，最后拼不出完整时间线。启动分析前，先把问题对象和边界定清楚，后续所有证据都挂在这张问题单上。
问题单至少填写以下字段，缺一项就补齐再进入分析：
- 影响服务：具体到服务名称与接口、功能模块，避免只写“系统慢”。
- 影响范围：受影响的用户群体、地区、业务量级，以及是否波及上下游系统。
- 首次发生时间：精确到分钟，并注明时区，作为时间线的起点。
- 发现渠道：监控告警、用户报障、巡检发现或内部反馈，不同渠道决定后续证据的侧重点。
- 当前恢复状态：已恢复、部分恢复、仍受影响，以及采取过的临时措施。
需要区分事件处置与问题治理两个阶段。事件阶段的目标是尽快恢复服务，可以采取重启、切换、限流等临时手段；问题阶段的目标是查清原因、防止复发。服务尚未恢复时，根因分析只能做证据保全，不能替代应急处置。恢复之后再正式进入分析，并把临时措施记录在问题单上，因为它们本身也是重要证据。
同时确定三项组织信息：分析负责人（对结论负责）、参与角色（服务台、运维、研发、业务方等）和取证截止时间。取证范围说明写清“本次分析覆盖哪些服务、哪些时间段、哪些变更”，范围之外的现象另行开单，避免一个问题单无限扩张。
本节交付物是一张填写完整的问题单和一份取证范围说明。在 ONES Desk 中，事件与问题可以以工单形式承载，工单支持评估和定义优先级，便于先处理紧急事件、再推进问题分析；问题单所需的字段可按团队实际流程配置。
四类核心依据：事件证据、变更记录、配置信息、复现结果
四类依据各自回答不同问题，缺一类，因果链就会断。下表给出分类、回答的问题、取证来源和通常提供者。
| 依据类别 | 回答什么问题 | 取证来源 | 通常提供者 |
|---|---|---|---|
| 事件证据 | 故障何时发生、表现如何、影响谁 | 关联事件单、告警记录、日志片段、用户反馈、时间线 | 服务台、运维 |
| 变更记录 | 故障前后系统发生了什么改变 | 发布记录、配置调整记录、权限变更、依赖升级记录 | 运维、研发 |
| 配置信息 | 受影响服务的运行状态和依赖关系是什么 | 配置项清单、依赖拓扑、版本状态、容量参数 | 运维、研发 |
| 复现与验证结果 | 候选原因能否被证实或排除 | 复现条件、对照实验、回滚或灰度验证记录 | 研发、测试 |
事件证据要保留原始片段而非转述。日志截取要带时间戳和请求标识，告警记录要保留触发与恢复时间，用户反馈尽量保留原文和报障时间。多条事件单如果指向同一现象，应合并到问题单下作为关联证据，并标注哪些是同一故障的重复报障。
变更记录的取证窗口通常从首次发生时间往前推一段合理时间，覆盖发布、配置调整、权限变更和依赖升级。每条变更记录要写明变更内容、执行时间、执行人和回滚方式。变更与故障时间接近只是线索，不能直接当作原因。
配置信息用于确认故障时刻的实际运行状态，包括版本号、关键参数、依赖服务的地址与超时设置、容量与限流阈值。配置要有取证时点的快照，事后补录的配置说明参考价值有限。
复现与验证结果是把推测变成结论的关键。记录复现的环境、数据条件、操作步骤和观察到的现象；无法复现时，记录尝试过的条件和失败原因，这同样是有效依据。
每类依据在清单中标注来源系统或人员、取得时间、责任人和初步结论。清单按四类归集，不按人归集，便于后续按因果链重新组织。
从依据到结论：因果链的整理与验证步骤
依据齐了不等于结论成立。整理因果链的目标是让每条推断都能追溯到具体证据，并让反对意见有地方安放。
- 按时间线排列证据。把事件证据、变更记录、配置快照按时间顺序排在一张时间线上，标出关键节点：首次异常、告警触发、变更执行、临时措施、服务恢复。节点之间的间隔本身也是信息。
- 提出候选原因。基于时间线列出所有合理解释，通常三到五条，包括“变更引发”“容量不足”“依赖服务异常”“配置错误”“外部流量突增”等。候选原因要具体到机制，不写“系统不稳定”这类无法验证的表述。
- 逐条列出支持与反对证据。为每个候选原因建一行，分别填写支持它的证据和与它矛盾的证据。证据要引用清单编号或原始记录，不写“根据经验判断”。
- 用验证手段确认或排除。优先选择成本低、影响可控的方式：在测试环境复现、对比故障时段与正常时段的指标、回滚可疑变更观察现象是否消失。回滚验证要在变更窗口内进行并记录结果；生产环境实验需评估影响后再做。
- 记录被排除的原因及排除依据。被排除的候选原因同样要留痕，写明用什么证据排除。这一步能防止后续复盘时重复排查，也能在结论受到质疑时提供支撑。
完成上述步骤后，输出候选原因表和因果链说明。因果链说明用一段话讲清“哪个变化、通过什么机制、在什么条件下、导致了什么现象”，每个环节都能指向具体证据。若证据不足以确认唯一原因，如实写明“最可能原因”和剩余不确定性，比强行下结论更有价值。
角色分工与各环节交付物
取证效率取决于分工是否清楚。按角色划分依据提供责任，避免所有人都去查日志、却没人核对变更记录。
| 角色 | 负责提供的依据 | 交付物 |
|---|---|---|
| 服务台/一线 | 事件单、用户反馈原文、报障时间线 | 关联事件单清单与用户影响描述 |
| 运维 | 告警记录、监控指标、变更记录、配置快照 | 时间线证据包与变更核对表 |
| 研发 | 日志片段、代码与版本信息、复现与验证结果 | 复现记录与验证结论 |
| 问题负责人 | 汇总全部依据，组织因果链讨论 | 候选原因表、因果链说明、根因结论 |
| 评审角色 | 审核结论与证据的对应关系 | 评审意见与遗留风险确认 |
问题负责人是结论的第一责任人，负责推动各角色在取证截止时间前交付，并对证据缺口做出判断：是继续补证，还是带着不确定性出结论。评审角色通常由服务负责人或技术负责人担任，重点核对结论是否有证据支撑、被排除原因是否记录、遗留风险是否明确。
在协作工具上，问题单与研发工作项的关联能减少证据散落。ONES Desk 的工单可直接关联到待办事项列表，打通服务团队与研发团队的协同；也可一键关联 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成。分析过程中的记录和结论可关联 ONES Wiki 页面沉淀，供后续类似问题参考。这些关联的前提是团队同时使用相应产品，具体配置方式以实际环境为准。
示例：一次接口超时问题的取证过程
以下为演示情景，用于说明取证顺序，不代表真实案例。
问题单记录。某订单查询接口在上午出现超时，影响下单页面的订单状态展示，受影响用户集中在某一地区，首次发生时间为 10:12，由监控告警发现，10:40 通过扩容临时恢复。问题负责人为服务台主管，取证截止时间为次日中午。
事件证据取证。关联到 14 张用户报障事件单，报障时间集中在 10:15 至 10:35；告警记录显示接口平均响应时间从 200 毫秒升至 3 秒以上，10:40 扩容后回落；日志片段显示超时请求集中在调用下游库存服务的环节，并带有连接等待特征；用户反馈原文记录“页面一直转圈”。
变更记录核对。时间线显示 09:50 有一次配置调整，将库存服务连接池上限从 100 下调至 40，执行人为运维值班人员，回滚方式为恢复原配置。该变更与首次异常时间接近，列为候选原因之一。
配置信息核对。取证时点的配置快照确认连接池参数为 40，库存服务版本未变化，依赖拓扑与上周一致，排除版本升级和依赖变更。
复现与验证。在测试环境将连接池设为 40 并施加与故障时段相近的并发量，复现出连接等待和超时；恢复为 100 后现象消失。结合日志中的连接等待特征，确认连接池下调是直接原因，并发量上升是触发条件。
结论表述。“09:50 连接池上限由 100 下调至 40，在上午并发量上升的条件下，库存服务调用出现连接等待，导致订单查询接口超时。已恢复原配置，建议将连接池参数纳入变更评审清单。”被排除的候选原因“库存服务版本升级”注明排除依据为版本未变化。
完成检查：依据是否足以支撑根因结论
关闭分析前逐项核对，任一项不满足就补证或说明理由。
- 依据可追溯：四类依据均有来源、取得时间和责任人，原始记录可查，不只有转述。
- 候选原因闭环：每个候选原因都有支持证据或排除依据，没有悬空未处理的原因。
- 结论经过评审：根因结论由评审角色确认，评审意见记录在问题单上。
- 遗留风险明确：证据不足或无法完全复现的部分，写明剩余不确定性和监控措施。
- 改进项已转跟踪：预防复发的配置调整、变更评审规则、监控补充等改进项，转为具体工作项并指定负责人和期限。
五项都满足，问题单可以从分析状态转为关闭或待改进验证。若结论依赖的关键证据缺失，宁可标注“原因待进一步验证”并保留问题单，也不要用推测填补空白。ONES Desk 可汇总工单处理情况并提供分析报表，便于团队按上述口径检查问题单的完成质量；报表口径需按团队实际配置确定。
常见问题
服务已经恢复，还需要继续做根因分析吗？
需要。事件阶段的目标是尽快恢复服务，重启、切换、限流等临时手段解决的是当下影响；问题阶段的目标是查清原因、防止复发。服务恢复后应把临时措施记录在问题单上，再正式进入根因分析。临时措施本身也是证据，能帮助判断故障的触发条件。
变更记录与故障时间接近，能否直接认定为根因？
不能直接认定。时间接近只是线索，还需要用配置快照、日志特征和复现结果把因果链补齐。可行的做法是把可疑变更列为候选原因，在测试环境复现或在变更窗口内回滚观察现象是否消失，并记录验证结果。若验证条件不具备，应写明剩余不确定性，而不是把时间关联当作结论。
故障无法复现时，根因分析还能完成吗？
可以完成，但结论的表述方式要调整。无法复现时，记录尝试过的环境、数据条件和失败原因，这些同样是有效依据；同时用故障时段与正常时段的指标对比、配置快照和变更记录支撑最可能原因。结论中写明剩余不确定性和后续监控措施，问题单可保留为待进一步验证状态。
取证范围应该划多大，范围外的现象怎么处理？
取证范围在启动时写清：覆盖哪些服务、哪个时间段、哪些变更。范围之外的现象另行开单，避免一个问题单无限扩张、时间线越拉越长。如果分析中发现范围外的现象与本次故障可能相关，先记录线索，再评估是否扩大范围或新开问题单，并同步调整取证截止时间。
用 ONES Desk 承载问题单和取证记录时，需要注意什么？
ONES Desk 支持事件管理及问题管理，工单可直接关联到待办事项列表，打通服务团队与研发团队的协同；工单支持评估和定义优先级，便于先处理紧急事件、再推进问题分析。分析中的记录和结论可关联 ONES Wiki 页面沉淀，涉及研发处理的事项可关联 ONES Project 的工作项持续跟踪。这些关联的前提是团队同时使用相应产品，问题单字段与报表口径需按团队实际流程配置。
