已知错误记录模板要解决的核心问题是把“现象、范围、临时处置、原因、状态”分开记录，避免把用户报错当成根因、把临时恢复手段当成最终修复。下面提供一张可直接复制的空白表，并逐字段说明症状、影响范围、临时措施、根因与状态的填写口径、必填要求、完整示例和维护方法，适用于服务台与研发团队共同维护已知错误的场景。
要点总览（TL;DR）
- 已知错误记录模板用一张表分开承载症状、影响范围、临时措施、根因和状态五类信息，避免把用户报错当根因、把临时恢复当最终修复。
- 症状只写用户可观察的现象、报错原文和复现路径；根因只写经日志、复现实验或变更记录确认的原因，推测单独标注为待验证假设。
- 影响范围按用户群体、服务/系统、版本、环境、时间窗五个维度记录；临时措施需写明恢复动作、生效条件、失效条件和回退方式。
- 必填字段随状态推进变化：待确认阶段至少具备标识字段、症状、影响范围和状态；进入已确认补根因；进入临时措施生效补临时措施四项内容。
- 模板需定期维护：字段增删看复盘是否反复出现且影响判断，状态调整先定映射再迁移历史记录，归档需满足根因修复验证、临时措施撤除、复盘结论记录三条。
可复制空白模板：已知错误记录表
下表可直接复制到文档工具或表格工具中使用。列名保持稳定，单元格按后文字段说明填写；一行对应一条已知错误记录。
| 字段 | 填写内容 |
|---|---|
| 记录编号 | KE-YYYY-NNN（团队自定义编号规则） |
| 标题 | 一句话概括“什么现象、影响什么” |
| 关联事件/问题 | 关联的事件单号、问题单号或工单链接 |
| 负责人 | 已知错误记录责任人（通常为问题经理或技术负责人） |
| 创建时间 | YYYY-MM-DD HH:MM |
| 更新时间 | YYYY-MM-DD HH:MM |
| 症状 | 用户可观察到的现象、报错原文、复现路径 |
| 影响范围 | 受影响用户群体、服务/系统、版本、环境、时间窗 |
| 临时措施 | 恢复动作、生效条件、失效条件、回退方式 |
| 根因 | 经证据确认的技术或流程原因；待验证假设单独标注 |
| 状态 | 待确认 / 已确认 / 临时措施生效 / 根因修复中 / 已解决 / 已归档 |
| 状态流转记录 | 每次流转的时间、操作人、流转依据 |
| 备注 | 补充说明、相关文档链接、复盘结论 |
基础标识字段（记录编号、标题、关联事件/问题、负责人、创建与更新时间）负责让记录可检索、可追溯；五类核心字段（症状、影响范围、临时措施、根因、状态）负责承载判断信息。复制时建议保留“状态流转记录”列，它让状态变化有据可查，而不只是一个当前值。
字段说明：每个字段该写什么、不该写什么
五类字段的边界是这张模板能否用好的关键。总体口径是：症状描述“看到什么”，影响范围描述“波及谁”，临时措施描述“先怎么恢复”，根因描述“为什么发生”，状态描述“现在走到哪一步”。
症状
写用户可观察到的现象、报错原文和复现路径。例如“登录页提交后提示 502，刷新三次仍复现，仅影响网页端”。症状字段不写原因判断，也不写解决方案。把“数据库连接池耗尽”写进症状，会让后续排查失去起点。
影响范围
按五个维度记录：受影响用户群体（如某区域客户、某租户）、服务或系统、版本、环境（生产/预发）、时间窗（起止时间与持续时长）。维度缺失会导致临时措施的覆盖面判断失真，例如只写“部分用户”无法判断是否需要全量回滚。
临时措施
写可执行、可回退的恢复动作，并配套三个条件：生效条件（在什么情况下该措施有效）、失效条件（什么情况下不再适用或需要升级）、回退方式（撤销该措施的操作步骤）。临时措施与根因修复计划分开跟踪，避免“重启服务”被误记为问题已解决。
根因
只写经证据确认的原因，证据可以是日志、复现实验、变更记录。尚未确认的推测单独标注为“待验证假设”，不写入根因字段。根因字段与症状字段的区分口径是：症状回答“用户看到什么”，根因回答“哪个组件、哪次变更、哪个流程环节导致了这一现象”。
状态
状态是记录在已知错误生命周期中的位置，建议取值与流转条件如下：
- 待确认：记录已建立，症状与影响范围初步填写，根因尚未验证。
- 已确认：根因有证据支撑，影响范围核实完毕。
- 临时措施生效：恢复动作已执行并验证有效，失效条件与回退方式已写明。
- 根因修复中：根治方案已排期或实施中。
- 已解决：根因修复完成并经验证，临时措施可撤除。
- 已归档：复盘完成，记录转入知识库长期保存。
每次状态变化都应在“状态流转记录”中写明时间、操作人和依据，例如“临时措施生效：2024-06-03 14:20，值班工程师，扩容后错误率回落至基线”。
必填与选填：哪些字段缺失就不能发布
必填划分的原则是：缺少该字段，其他团队无法据此判断或行动。下表给出对照，并说明随状态推进的必填变化。
| 字段 | 必填/选填 | 判定理由 |
|---|---|---|
| 记录编号、标题、负责人、创建时间 | 必填 | 保证记录可检索、可归属、可追溯 |
| 症状 | 必填 | 没有症状描述，记录无法被检索和匹配 |
| 影响范围 | 必填 | 决定临时措施覆盖面与优先级 |
| 状态 | 必填 | 标识记录所处阶段 |
| 关联事件/问题 | 选填（建议填写） | 有来源工单时填写，便于回溯上下文 |
| 临时措施 | 状态相关必填 | 进入“临时措施生效”状态前必须填写完整 |
| 根因 | 状态相关必填 | 进入“已确认”状态前必须有证据支撑的根因 |
| 状态流转记录 | 状态相关必填 | 每次状态变化时追加，不允许留空流转 |
| 备注 | 选填 | 用于补充文档链接与复盘结论 |
随状态推进的必填要求可以概括为：待确认阶段至少具备标识字段、症状、影响范围和状态；进入已确认阶段补全根因；进入临时措施生效阶段补全临时措施的四项内容；进入已解决阶段补全修复验证说明。缺失字段时的处理方式是保持当前状态不推进，并在备注中写明缺口与补齐责任人，而不是先推进状态再补填。
填写示例：一条已知错误的完整记录
以下为演示情景，用于说明五类字段如何分别填写并相互印证，不代表真实客户案例。
| 字段 | 示例内容 |
|---|---|
| 记录编号 | KE-2024-017 |
| 标题 | 网页端登录偶发 502，集中在高峰期 |
| 关联事件/问题 | 事件单 INC-2024-1032；问题单 PRB-2024-045 |
| 负责人 | 问题经理 A（服务台），技术负责人 B（后端团队） |
| 症状 | 用户提交登录表单后页面返回 502，刷新后多数可恢复；报错原文“502 Bad Gateway”；复现路径为高峰期连续登录请求，低峰期难以复现 |
| 影响范围 | 用户：华东区域约 8% 的网页端登录用户；服务：统一登录服务；版本：v3.4.1；环境：生产；时间窗：2024-06-03 09:10 至 10:05 |
| 临时措施 | 恢复动作：将登录服务实例临时扩容 2 个并重启网关；生效条件：高峰期并发超过阈值时执行；失效条件：扩容后错误率仍高于 1% 则升级为限流；回退方式：低峰期缩容回原实例数并核对监控基线 |
| 根因 | 网关连接池上限在 v3.4.1 变更中由 200 调整为 80，高峰期连接排队超时（依据：变更记录与网关日志） |
| 状态 | 根因修复中 |
| 状态流转记录 | 2024-06-03 10:30 已确认（根因经日志验证）；2024-06-03 11:00 临时措施生效（扩容后错误率回落）；2024-06-04 15:00 根因修复中（配置回滚排期） |
示例中症状只写用户看到的现象与报错原文，根因写的是经变更记录和日志确认的配置问题，两者不混写；临时措施写明了生效、失效与回退条件，其他人可照做也可撤销；状态与流转记录对应，能看出记录当前停在“根因修复中”。
调整与维护：模板如何随团队和复盘更新
模板上线后需要定期维护，否则字段会逐渐被填成形式。维护可以从四个方面入手。
字段增删的判断依据
当复盘发现某类信息反复出现在备注里、且影响判断时，考虑将其提升为独立字段；当某字段连续多个周期无人填写或填写内容与相邻字段重复时，考虑合并或删除。每次增删都记录变更原因和生效日期。
状态取值调整与历史记录处理
状态取值调整时，先明确旧值到新值的映射关系，再批量迁移历史记录，并在状态流转记录中保留原值说明，避免历史记录出现无法解释的状态。新增状态应同时定义进入条件和退出条件。
定期复核与关闭归档规则
建议按固定周期复核处于“临时措施生效”和“根因修复中”的记录，检查临时措施是否仍有效、修复是否已排期。满足“根因修复完成并验证、临时措施已撤除、复盘结论已记录”三条时，将记录置为已解决并归档，归档后保留只读。
模板版本与变更记录方式
模板本身应有版本号和变更记录，写明每次调整的字段、状态、生效时间和负责人。团队在服务台与研发之间共享这张表时，可借助工单与知识库的关联让记录和来源工单保持对应：ONES Desk 提供事件管理与问题管理能力，工单可关联到待办事项列表，打通服务团队与研发团队的协同；其工单属性与工作流支持自定义配置，便于按本模板设置字段和状态流转；工单还可一键关联到 ONES Wiki 页面，用于记录分析过程与复盘结论，ONES Wiki 适合管理操作说明、复盘记录等需要长期沉淀的知识。具体可配置范围以实际产品为准。
常见问题
症状字段里写了“数据库连接池耗尽”，为什么不对？
症状字段的填写口径是“用户看到什么”，应记录用户可观察到的现象、报错原文和复现路径。把“数据库连接池耗尽”写进症状，等于把排查结论前置，会让后续排查失去起点。正确做法是症状写“登录页提交后提示 502，刷新三次仍复现，仅影响网页端”，根因字段再写经日志和变更记录确认的连接池配置问题。
临时措施生效后，状态可以直接改为“已解决”吗？
不建议。临时措施的作用是恢复服务，根因修复计划需要单独跟踪。状态流转中，“临时措施生效”表示恢复动作已执行并验证有效，此时根因可能仍在修复中；只有根因修复完成并经验证、临时措施可撤除后，才进入“已解决”。如果临时措施生效后就改为已解决，后续根因修复容易被遗漏，同类问题可能再次发生。
影响范围只写“部分用户”为什么不够？
影响范围需要支撑临时措施的覆盖面判断和优先级排序。只写“部分用户”无法判断是否需要全量回滚、是否影响特定版本或环境。建议按五个维度记录：受影响用户群体（如某区域客户、某租户）、服务或系统、版本、环境（生产/预发）、时间窗（起止时间与持续时长）。维度缺失会导致临时措施的执行范围和升级判断失真。
状态流转记录必须每次状态变化都写吗？
是的。状态流转记录用于让状态变化有据可查，而不只是一个当前值。每次状态变化都应写明时间、操作人和流转依据，例如“临时措施生效：2024-06-03 14:20，值班工程师，扩容后错误率回落至基线”。缺少流转记录时，其他团队无法判断状态变化的依据，复盘时也难以还原处理过程。
模板字段增删应该依据什么判断？
当复盘发现某类信息反复出现在备注里、且影响判断时，可以考虑将其提升为独立字段；当某字段连续多个周期无人填写，或填写内容与相邻字段重复时，可以考虑合并或删除。每次增删都应记录变更原因和生效日期，并同步更新模板版本号和变更记录，避免不同团队使用不同版本的模板。
