IT服务已知错误库（Known Error Database，KEDB）登记的是已经查明根本原因、但彻底修复尚未完成的错误，以及配套的临时规避办法。它解决的是缺陷修复完成之前，服务台如何按统一口径快速恢复服务、减少重复诊断的问题。本文说明它的定义、进库边界、条目流转机制，并用一个示例厘清常见误解。
要点总览（TL;DR）
- 已知错误库登记的是根本原因已查明、彻底修复尚未完成的错误，以及配套的临时规避办法，用来在修复窗口期内支撑服务台快速恢复服务。
- 入库需同时满足三个条件：根因已确认、修复未完成、存在可执行的规避办法或恢复路径；事件工单、变更记录、配置记录不进库，缺陷工作项作为修复跟踪去向。
- 条目状态通常为待确认、已确认、已规避、已关闭，关闭条件是修复上线并验证，归档保留而非删除。
- 事件、问题、已知错误、缺陷分别回答不同问题，问题在根因查明后转入已知错误条目，缺陷管修复，已知错误管修复前的服务恢复。
- 条目价值取决于被检索到并被正确使用，上线后需统计引用情况并据此优化描述与分类，避免库沦为无人查阅的文档堆积。
已知错误库的准确定义
已知错误库是问题管理过程中形成的记录集合。一条记录进入库中，需要同时满足两个条件：根本原因已经查明，彻底修复尚未完成。原因未查清的事件属于问题，原因已查清且修复已上线的条目则退出库。这个中间状态正是已知错误库存在的理由——在等待修复的窗口期内，一线人员不必重新排查，直接按既定办法恢复服务。
已知错误库通常由问题管理角色维护，服务台和一线支持人员是主要使用者。条目产生于问题管理流程的产出环节：事件经过诊断确认根因后，若修复需要排期或依赖外部条件，就转为已知错误条目登记入库。它与事件记录、问题记录之间保持关联，便于追溯某条规避办法对应哪些实际发生的事件。
一条完整的已知错误记录应包含以下要素：
| 记录要素 | 内容要求 | 作用 |
|---|---|---|
| 现象描述 | 用户可观察到的报错、异常表现与触发条件 | 供服务台快速匹配 |
| 影响范围 | 受影响的系统、用户群体、业务时段 | 判断优先级与通知范围 |
| 根本原因 | 已确认的技术或配置原因 | 支撑修复方案与规避办法设计 |
| 临时规避办法 | 可执行的操作步骤、适用前提、预期效果 | 在修复前恢复服务 |
| 关联事件与问题 | 触发本条目的工单编号、问题记录 | 追溯发生频次与影响 |
| 状态与责任人 | 当前状态、维护人、修复跟踪去向 | 保证条目有人负责、有始有终 |
边界：哪些内容进库，哪些不进
已知错误库容易变成“什么都往里放”的杂物间，根源在于没有区分记录的目的。事件工单记录的是“发生了什么、怎么处置的”，已知错误条目记录的是“为什么发生、在修复前怎么绕过去”。前者是过程流水，后者是可复用的恢复知识。只有后者才需要进库。
与缺陷管理的分工同样清晰：代码或配置中的待修复项归缺陷管理跟踪，已知错误库保留的是修复完成前的恢复手段。两者通过关联关系衔接——条目指向对应的缺陷工作项，缺陷修复上线并验证后，条目随之关闭。变更记录描述的是某次改动的实施内容与审批过程，配置记录描述的是配置项当前状态，二者都不承担“规避办法”的职能。
| 记录类型 | 核心内容 | 是否进已知错误库 |
|---|---|---|
| 事件工单 | 现象、影响、处置动作、恢复时间 | 不进；作为关联依据 |
| 问题记录 | 待查原因的事件集合、调查过程 | 原因查明前不进；查明后转为已知错误条目 |
| 缺陷工作项 | 代码或配置的修复任务与进度 | 不进；作为条目的修复跟踪去向 |
| 变更记录 | 改动内容、审批、实施结果 | 不进；修复上线时另行记录 |
| 配置记录 | 配置项属性与当前状态 | 不进；规避办法可能引用其中信息 |
判断一条内容是否该进库，可以依次问三个问题：根本原因是否已经确认？彻底修复是否尚未完成？是否存在可执行的临时规避办法或明确的恢复路径？三问都答“是”，才构成入库条件。原因仍在调查中的归问题管理，修复已完成的不再保留为活动条目，既无规避办法也无恢复路径的，应先补足诊断再决定。
已知错误库的组成与运作机制
已知错误条目的生命周期从事件开始。触发路径有两条：同类事件在设定周期内重复出现，或发生重大事件后转入问题管理。问题管理角色完成根因分析，确认修复需要排期、依赖供应商或涉及较大变更时，将结论整理为已知错误条目，状态置为“待确认”。经服务台负责人或问题经理复核，确认现象描述可匹配、规避办法可执行后，转为“已确认”，正式对一线开放检索。
条目状态通常包括待确认、已确认、已规避、已关闭四种。已确认表示条目可用；已规避表示规避办法已在真实事件中应用并验证有效，服务恢复路径得到确认；已关闭表示对应缺陷已修复上线并通过验证，条目归档保留供后续查阅。状态变化应记录时间和操作人，避免条目长期停留在中间状态无人推进。
临时规避办法的编写有三项要求：步骤可被一线人员独立执行，不依赖原诊断人员；写明适用前提与不适用情形，防止误用扩大影响；写明预期效果与验证方式，例如执行后哪些现象应消失。规避办法上线前应在测试环境或低风险场景验证，验证记录随条目保存。
条目在服务台的使用方式是检索与匹配。一线接到事件后，按报错信息、受影响系统、现象关键词检索已知错误库，命中后按规避办法处置，并在工单中标注所引用的条目编号。这一步让条目使用情况可统计：哪些条目被高频引用，说明影响面大、修复应优先排期；哪些条目长期零引用，可能需要检查描述是否便于检索。
关闭条件是修复上线并验证。缺陷修复经变更流程发布后，问题管理角色确认原现象不再复现，将条目状态改为已关闭并归档。归档不等于删除，历史条目在同类问题再次出现时仍有参考价值。
在工具承载层面，条目的检索、关联与状态流转需要与工单和知识文档联动。ONES Desk 提供事件管理及问题管理能力，工单可直接关联到待办事项列表，打通服务团队与研发团队的协同；工单还可一键关联 ONES Wiki 页面用于记录并分析问题、沉淀服务经验，或关联 ONES Project 的缺陷工作项持续跟踪至处理完成。按上述机制，团队可以用工单承接事件、用问题记录完成诊断、用 Wiki 页面承载条目正文与规避办法、用缺陷工作项跟踪修复进度，形成从事件到关闭的可追溯链路。是否设置独立条目对象，需结合团队现有工具配置确定。
一条端到端示例路径：某业务系统的登录失败事件一周内出现多次，服务台按现象检索未命中，转入问题管理；诊断确认是会话配置缺陷，修复需随下个版本发布；问题管理角色登记条目，写明现象、影响范围、根因、规避办法（重启相关服务或临时调整超时阈值）及适用前提，状态置为待确认；复核后转为已确认；后续同类事件按条目处置并标注引用，条目转为已规避；版本发布后验证现象消失，条目关闭归档。
相邻概念区别：已知错误、问题、事件与缺陷
四个术语常被混用，区别在于各自回答的问题不同：事件回答“服务出了什么状况”，问题回答“为什么会出状况”，已知错误回答“原因清楚但还没修好时怎么办”，缺陷回答“哪段代码或配置需要改”。用同一口径对照如下：
| 概念 | 关注对象 | 典型负责人 | 结束标志 |
|---|---|---|---|
| 事件 | 服务中断或质量下降的表现与恢复 | 服务台、一线支持 | 服务恢复，工单关闭 |
| 问题 | 尚未查明原因的事件集合或潜在原因 | 问题管理角色 | 根因查明，转为已知错误或直接修复 |
| 已知错误 | 已查明原因、修复未完成期间的恢复手段 | 问题管理角色维护，服务台使用 | 修复上线并验证，条目关闭归档 |
| 缺陷 | 产品代码或配置中的待修复项 | 研发或配置管理 | 修复完成并通过测试 |
需要留意的是，问题与已知错误之间是前后衔接关系而非并列关系：问题在根因查明的那一刻完成使命，若修复不能立即完成，其结论转入已知错误条目继续发挥作用。缺陷与已知错误则通过关联关系协作，前者管“改”，后者管“改好之前怎么撑住”。
具体例子与常见误解
以下为演示情景，用于说明条目写法，不代表任何真实案例。某内部系统频繁出现登录失败，用户反馈集中在上午高峰时段。问题管理诊断后确认：会话配置的超时阈值设置不合理，高并发时大量会话提前失效。修复需随版本发布，短期内无法上线。据此填写的条目大致如下：
- 现象：上午高峰时段登录提示会话失效，重新登录后短时可用
- 影响范围：使用该系统的全体内部用户，高峰时段影响最明显
- 根本原因：会话超时阈值配置偏低，高并发下会话提前过期
- 临时规避办法：引导用户重新登录；必要时由运维重启会话服务临时缓解；适用前提为版本发布前
- 关联记录：若干登录失败事件工单、对应问题记录、待发布的缺陷工作项
- 状态：已确认，修复跟踪中
围绕这个例子，四类误解值得纠正：
误解一：已知错误库等于缺陷清单。缺陷清单跟踪的是“要改什么、改到哪一步”，已知错误库保留的是“改好之前一线怎么恢复服务”。前者面向研发排期，后者面向服务台处置，内容与读者都不同。
误解二：原因查清就可以关闭条目。原因查清只是条目成立的起点。修复未上线期间条目仍需支撑服务恢复，提前关闭会让一线重新陷入重复诊断。关闭条件应是修复上线并验证。
误解三：规避办法不需要验证。未经验证的步骤可能无效，甚至扩大影响。规避办法应写明适用前提，并在低风险场景确认有效后再对一线开放。
误解四：库建好就自动生效。条目价值取决于被检索到、被正确使用。缺少检索入口、关键词设计和一线培训，库会沦为无人查阅的文档堆积。上线后应统计条目引用情况，据此优化描述与分类。
常见问题
根本原因查明后，什么时候该建已知错误条目，什么时候直接修复即可？
判断依据是修复能否立即完成。若修复可以马上实施、不需要排期或依赖外部条件，问题记录在根因查明后直接进入修复流程，不必单独建条目。若修复需要排期、依赖供应商版本或涉及较大变更，等待期内一线仍会重复遇到同类事件，此时才把结论整理为已知错误条目，让服务台有统一的恢复口径。条目建立的同时应关联对应的缺陷工作项，明确修复跟踪去向。
临时规避办法验证到什么程度才能对一线开放？
验证的目标是确认步骤可执行、效果可观察、影响可控。建议在测试环境或低风险场景按条目写明的步骤完整执行一遍，确认预期现象消失，并记录执行前提与可能带来的副作用。对于涉及重启服务、调整配置阈值的操作，还应写明不适用情形，防止一线在超出前提的场景中误用。验证记录随条目保存，条目状态从待确认转为已确认后再对一线开放检索。
条目长期没有事件引用，应该关闭还是保留？
零引用不等于条目无效，先排查原因再决定处置。常见原因有三类：现象描述与用户实际报错用词不一致导致检索不到；条目分类或关键词设置不合理；该问题确实已不再发生。前两类应优化描述与分类后继续保留，第三类需确认修复是否已上线，若已上线并验证则按正常流程关闭归档。归档条目保留可查，同类问题再次出现时仍有参考价值。
已知错误条目和缺陷工作项之间需要保持怎样的关联关系？
条目指向缺陷工作项，缺陷工作项承载修复任务与进度，两者是恢复手段与修复动作的分工。条目中记录关联的缺陷编号，便于服务台了解修复排期；缺陷修复经变更流程发布后，由问题管理角色确认原现象不再复现，再将条目关闭。关联关系让“改好之前怎么撑住”和“改到哪一步”两条信息可以互相追溯，避免条目与修复进度脱节。
团队规模较小、事件量不大时，是否值得单独建已知错误库？
可以先从轻量做法起步：在现有知识文档中开辟固定区域，按统一要素记录根因已查明但修复未完成的条目，并在工单中标注引用。判断是否值得独立建库的标准是重复诊断的成本——同类事件反复出现、一线多次从头排查，就说明需要沉淀；事件稀少且修复周期短，轻量记录即可满足。随着事件量和条目数增长，再考虑与工单、问题记录做结构化关联。
