已知错误（Known Error）是IT服务管理中经过问题管理诊断、已定位根因或找到可接受临时处置办法、但尚未永久修复的故障成因记录。它把“为什么会出问题”和“修复前怎么让服务先恢复”固化成一条可复用记录，供事件管理在处理同类事件时直接调用。理解这个概念的关键在于：已知错误表示原因已查明、处置有据，永久修复仍作为后续任务跟踪，它并不等于问题已经解决。
要点总览（TL;DR）
- 已知错误是问题管理产出的成因记录：根因已诊断、永久修复未完成、有经过验证的临时处置，三者缺一不可。
- 它处于“原因已明、修复未完成”的中间状态，登记已知错误不等于问题已解决，永久修复仍需挂接任务跟踪。
- 典型流转链条是事件升级为问题、根因分析与处置验证、登记已知错误、事件侧调用临时处置、永久修复上线后退出。
- 与相邻概念的分工：事件管恢复速度，问题管根因根治，已知错误管修复前的处置依据，缺陷管代码层面的修复归属。
- 是否登记要看复发可能、影响程度和诊断结论，一次性偶发事件不必建已知错误，避免记录膨胀。
已知错误的准确定义
在ITIL等服务管理框架中，已知错误指一个已经完成诊断、根因或成因机制已经明确，但永久性修复尚未实施的问题成因。它通常由问题管理流程产出：问题经理或技术团队在完成根因分析后，把诊断结论、受影响的配置项、症状特征和临时处置办法整理成一条结构化记录，并赋予“已知错误”状态。这个状态的含义是“原因已知”，并不代表问题记录已经关闭。
可以把定义拆成三个必备要素：
- 已诊断的成因：有明确的根因分析结论，能说清故障在什么条件下、通过什么机制发生，而不只是“重启后恢复了”。
- 尚未永久修复：代码补丁、配置变更、架构调整等根治措施还没有上线，或已排期但未完成。
- 有临时处置：存在经过验证的绕行方案、限流策略、手动切换、参数调整等手段，能让服务在修复前恢复或维持可用。
三个要素缺一不可。只有根因没有处置办法，说明诊断尚未形成可操作的产出；只有临时方案没有根因，则更接近事件处理中的应急措施，还不足以称为已知错误。已知错误与问题记录的关系是：问题记录承载调查全过程，已知错误是问题在“原因查明、修复未完成”阶段的特定状态或关联记录。问题可以经历“新建—调查中—已知错误—已解决—已关闭”的状态变化，已知错误描述的是其中一段，而非终点。
边界：已知错误包括什么、不包括什么
划清边界有助于在记录时做出稳定判断。以下情形适合建立或归入已知错误：
- 重复发生且根因已定位的故障，例如某批设备在特定固件版本下定时断连，原因已确认，厂商补丁尚未发布。
- 已有经过验证的临时绕行方案的成因，例如数据库连接池在高峰耗尽，临时方案为调大池上限并增加排队重试。
- 影响范围、触发条件和症状特征都已记录清楚，事件处理人员可以据此快速匹配并执行处置的成因。
以下情形不属于本文所说的已知错误：
- 尚未诊断的普通事件。事件刚发生、只做了重启或切换等恢复动作，根因还不清楚，此时它是事件记录，需要评估是否升级为问题。
- 已经永久修复并关闭的问题。补丁上线、配置修正完成并验证有效后，该成因不再处于“已知错误”状态，应关闭问题或将经验转入知识库。
- 软件代码层面的缺陷修复归属。Bug 的提交、排期、修复和验证属于缺陷管理范畴，已知错误只在与缺陷关联时说明“这是某个缺陷引发的服务故障成因”，不展开缺陷修复流程。
- 硬件维修操作和网络攻击技术。前者是设备维护作业，后者属于安全攻防领域，均不在本文讨论范围。
需要说明的是，边界判断依赖组织自身的记录规范。同一成因在不同团队可能被放在问题记录、已知错误记录或知识条目中，关键是保证“症状—成因—临时处置—影响范围”这组信息可被事件处理人员检索到。
已知错误在事件与问题流程中如何产生和流转
已知错误通常沿“事件—问题—已知错误—永久修复”的链条产生。触发路径一般有两类：同一症状反复出现多个事件，服务台判断其具有共性；或者发生重大事件，服务中断影响较大，需要彻查根因。两类情况都会推动事件升级为问题，进入问题管理流程。
进入问题管理后，技术团队开展根因分析，定位故障机制，同时验证临时处置是否有效、适用条件是什么。诊断有结论后，将成因登记为已知错误，并把临时处置写清楚，供事件管理在下次同类事件发生时直接调用。此后，永久修复作为问题下的任务继续跟踪，修复上线并验证后，关闭问题或将处置经验沉淀为知识条目。整个链条可以概括为：
- 事件识别：服务台记录症状、影响范围和发生时间，完成服务恢复。
- 升级为问题：重复事件或重大事件触发问题创建，明确调查负责人。
- 根因分析与处置验证：技术团队定位成因，验证临时方案的有效性和副作用。
- 登记已知错误：填写症状、成因、临时处置、影响范围，关联相关事件和配置项。
- 事件侧调用：同类事件发生时，处理人员按已知错误记录执行临时处置，缩短恢复时间。
- 永久修复与退出：修复上线并验证后关闭问题，或将记录转为知识条目保留。
支撑这条链条的关键字段可以按下表组织：
| 字段 | 记录内容 | 作用 |
|---|---|---|
| 症状 | 用户可见的报错、超时、中断现象及触发条件 | 帮助事件处理人员快速匹配 |
| 成因 | 根因分析结论，涉及哪些组件、配置或版本 | 说明为什么发生，支撑修复方案 |
| 临时处置 | 绕行步骤、限流参数、切换操作及适用前提 | 修复前恢复服务，需注明风险 |
| 影响范围 | 受影响的业务、用户群、配置项和时间窗口 | 判断优先级与沟通范围 |
| 关联事件 | 触发调查的原始事件及后续同类事件 | 形成证据链，便于统计复发次数 |
| 永久修复任务 | 修复方案、负责人、计划完成时间 | 确保修复不被遗忘 |
当团队用工具承载这条流程时，记录之间的关联能力会影响流转效率。以 ONES Desk 为例，其事件管理及问题管理能力支持工单直接关联到待办事项列表，打通服务团队和研发团队的协同；工单可一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成；也可关联到 ONES Wiki 页面，记录并分析问题、沉淀服务经验。对于需要把已知错误中的永久修复任务交给研发排期的场景，这种关联可以让问题记录与修复工作项保持对应。具体到已知错误字段如何配置、状态如何流转，需结合组织实际流程在工具中设置。
已知错误与事件、问题、缺陷的区别
这四个概念经常被混用，用同一口径对照可以看清各自回答的问题。事件关注服务恢复的速度，问题关注根因和根治，已知错误关注原因已明情况下的处置依据，缺陷关注代码层面的修复归属。下表按回答的问题、主要目标和典型产出进行对照：
| 概念 | 回答的问题 | 主要目标 | 典型产出 |
|---|---|---|---|
| 事件 | 出了什么故障，如何尽快恢复服务 | 缩短中断时间，维持服务水平 | 事件记录、恢复动作、沟通记录 |
| 问题 | 为什么会发生，如何根治 | 消除根因，防止复发 | 问题记录、根因分析报告、修复方案 |
| 已知错误 | 原因已明，修复前如何处置 | 让同类事件有据可依地快速恢复 | 症状、成因、临时处置、影响范围 |
| 缺陷 | 软件代码哪里有问题，由谁修复 | 完成代码修复与验证 | 缺陷单、修复提交、验证结果 |
四者的衔接关系是：事件可以升级为问题，问题诊断后可能形成已知错误，已知错误指向的永久修复若落在软件代码上，则以缺陷形式进入研发流程。已知错误与缺陷的区别尤其需要注意：已知错误是服务管理视角的成因记录，缺陷是研发视角的修复单元，一条已知错误可能关联一个或多个缺陷，一个缺陷也可能引发多条已知错误。区分清楚，才能让服务团队和研发团队各司其职，避免把“已登记已知错误”误认为“研发已修复”。
一个具体例子与常见误解
以下为演示性示例，用于说明已知错误的实际用法。某企业内部订单接口在每日上午高峰期出现超时，服务台连续一周收到多起同类事件。由于复发频繁且影响下单，该事件被升级为问题。技术团队分析后发现，根因是接口在下游库存服务响应变慢时未设置合理的超时与重试上限，导致连接堆积。团队验证了临时处置：对调用方增加限流，并将重试次数限制为两次，验证后高峰期超时明显减少。随后登记已知错误，记录症状为“上午高峰订单接口超时”、成因为“下游响应变慢时连接堆积”、临时处置为“限流加两次重试”、影响范围为“下单业务及移动端用户”，并关联此前的事件记录。永久修复任务（调整超时配置与连接池策略）进入研发排期。此后同类事件发生时，服务台按已知错误记录直接执行临时处置，无需重新排查。
围绕这个例子，有三条常见误解需要澄清：
- 误解一：已知错误等于已解决。登记已知错误只说明原因查明、处置有据，服务仍可能在特定条件下受影响，永久修复尚未完成。把它当作已解决，容易放松跟踪，导致修复任务长期搁置。
- 误解二：有临时方案就不用再跟踪永久修复。临时处置通常有适用条件和副作用，例如限流会降低部分请求的成功率。已知错误必须挂接永久修复任务并明确负责人和时间，否则临时方案会变成长期将就。
- 误解三：所有事件都要建已知错误。一次性、偶发且已当场恢复的事件，没有重复风险时不必建立已知错误。是否登记应看复发可能、影响程度和诊断结论是否形成，避免记录膨胀稀释重点。
把握住“原因已明、修复未完成、处置有据”这三个特征，就能在服务恢复与问题治理之间找到已知错误的位置：它让事件处理有据可依，也让永久修复不被遗忘。
常见问题
根因已经查清但暂时没有可行的临时处置办法，还能登记为已知错误吗？
按定义的三要素，这种情况还不足以登记为已知错误。已知错误要求同时具备已诊断的成因和经过验证的临时处置，只有根因没有处置办法，说明诊断尚未形成可操作的产出。更稳妥的做法是让问题记录继续停留在调查状态，把根因结论先写入问题记录，同时把寻找临时处置作为一项任务推进；等绕行方案或限流、切换等手段验证有效后，再登记为已知错误。这样事件处理人员调用时拿到的是一条可直接执行的处置依据，而不是一句“原因已查明”。
临时处置长期有效，是否就可以不再推进永久修复？
不建议这样处理。临时处置通常带有适用条件和副作用，例如限流会降低部分请求的成功率，手动切换会增加人工负担。如果长期依赖临时方案，服务在条件变化时仍可能受影响，副作用也会持续累积。已知错误应当挂接永久修复任务，明确负责人和计划完成时间，并在修复上线验证后关闭问题或转为知识条目。临时处置的定位是修复前的过渡手段，它的价值在于争取修复时间，而非替代修复。
已知错误和缺陷单需要重复登记吗？两者如何对应？
两者视角不同，通常需要各自登记并建立关联。已知错误是服务管理视角的成因记录，说明故障在什么条件下发生、修复前如何处置；缺陷单是研发视角的修复单元，承载代码修改、提交和验证。一条已知错误可能关联一个或多个缺陷，一个缺陷也可能引发多条已知错误。实际操作中，可以在已知错误记录里关联对应的缺陷工作项，让服务团队看到处置依据，研发团队看到修复进度，避免把“已登记已知错误”误认为“研发已修复”。
已知错误在什么条件下应该退出，退出后信息如何保留？
退出条件是永久修复上线并验证有效。此时该成因不再处于“已知错误”状态，应关闭问题记录，或把症状、成因、处置经验和验证结论整理为知识条目保留，供后续类似场景参考。如果修复只覆盖了部分场景，剩余场景仍有复发风险，可以保留已知错误并更新影响范围与临时处置，而不是整体关闭。退出判断应以验证结果为依据，避免修复方案上线但未确认效果就提前关闭。
用工具管理已知错误时，需要关注哪些记录之间的关联？
重点看三组关联：已知错误与触发它的原始事件及后续同类事件之间的关联，用于统计复发次数和形成证据链；已知错误与永久修复任务之间的关联，确保修复进入研发排期并被跟踪；已知错误与知识条目之间的关联，便于修复完成后沉淀经验。以 ONES Desk 为例，其事件管理及问题管理能力支持工单直接关联到待办事项列表，工单可一键关联到 ONES Project 的需求或缺陷工作项，也可关联到 ONES Wiki 页面记录并分析问题、沉淀服务经验。具体字段与状态流转需结合组织流程在工具中配置。
