2. 异常与案例的基本概念
在异常知识库与案例复用工程中，“异常”和“案例”是两个最基础、也最容易被混用的概念。很多团队在建设知识库时，把告警、日志、工单、故障报告都笼统地称为“案例”，结果导致检索时命中率低、复用价值差。要建立可复用的知识资产，第一步必须把这两个概念的定义、边界和关系讲清楚。
一、异常的定义
异常（Anomaly / Exception）是指系统、设备、流程或业务在运行过程中，偏离了预期的正常状态、正常范围或正常行为模式的一种可观测现象。它强调的是“偏离”本身，而不是偏离造成的后果。
理解异常定义要抓住三个要点：
- 有基准：异常必须相对于某个“正常基线”才有意义。例如 CPU 使用率正常区间为 20%～60%，当持续 5 分钟超过 85% 时，才构成异常。
- 可观测：异常必须能被指标、日志、事件、人工反馈等信号捕捉到，否则只是潜在风险，不构成可管理的异常。
- 有边界：异常有开始时间、结束时间和影响范围，这为后续归类和案例化提供锚点。
例如，一条监控告警“订单服务 P99 响应时间从 320ms 升至 2100ms，持续 8 分钟”，这就是一个典型异常：它有基线（320ms）、有观测值（2100ms）、有时间边界（8 分钟）。
二、异常的分类
异常分类的目的不是学术上的完备，而是为了在知识库中建立可检索、可统计、可复用的标签体系。常见的分类维度有以下几种：
| 分类维度 | 典型类别 | 示例 |
|---|---|---|
| 来源 | 基础设施、应用、业务、安全 | 磁盘 IO 抖动、接口超时、支付失败率上升 |
| 严重程度 | 提示、警告、严重、致命 | P4 提示、P2 警告、P1 严重 |
| 持续时间 | 瞬时、短时、持续、周期性 | 秒级抖动、分钟级波动、每日高峰 |
| 可复现性 | 必现、偶现、环境相关 | 重启后必现、压测偶现、仅生产环境 |
| 影响面 | 单点、局部、全局 | 单实例、单机房、全站 |
分类维度可以组合使用。例如“应用层 + 严重 + 持续 + 偶现 + 局部”可以快速定位一类异常的特征画像，为后续案例匹配提供索引。
三、案例的定义
案例（Case）是对一次异常从发生、发现、分析、处置到恢复全过程的完整记录，并经过结构化整理，使其能够被他人理解、检索和复用。案例不是异常的简单复制，而是异常经过“加工”后的知识资产。
一个异常只有被完整记录并结构化，才可能成为案例。例如，同样是“数据库连接池耗尽”，如果只记录“连接池满了，重启解决”，那只是事件日志；如果记录了触发条件、排查路径、根因、修复动作和验证结果，才构成案例。
四、案例的要素
一个可复用的案例通常包含以下核心要素，这些要素也是知识库字段设计的依据：
- 标识信息：案例编号、标题、发生时间、所属系统、严重等级。
- 现象描述：异常的可观测表现，包括指标、日志、告警、用户反馈。
- 影响范围：受影响的用户、功能、地域、时间段。
- 排查过程：关键假设、验证动作、排除路径、使用的工具与命令。
- 根因分析：直接原因与根本原因，必要时区分触发因素与放大因素。
- 处置措施：临时止血、正式修复、回滚或扩容等具体动作。
- 验证结果：恢复判据，例如错误率回落至 0.1% 以下并稳定 10 分钟。
- 经验沉淀：可复用的检查项、预防措施、监控改进点。
五、异常与案例的关系
异常与案例的关系可以概括为：异常是案例的原料，案例是异常的知识化产物。一个异常可以对应零个、一个或多个案例；一个案例通常围绕一个主异常展开，也可能关联多个次生异常。
下图展示了从异常信号到可复用案例的转化关系，以及案例要素在其中的位置：
从图中可以看到，异常经过“识别—结构化—要素填充”后成为案例，而案例在复用过程中又会产生新的异常记录和新的案例，形成知识回流。这个闭环正是异常知识库持续增值的核心机制。
六、实践中的常见误区
在实际建设中，以下误区会直接削弱知识库的复用效果：
- 把告警当案例：告警只是异常信号，缺少根因和处置，无法直接复用。
- 案例要素残缺：只写“重启解决”，没有排查路径和验证判据，下次遇到仍要重新摸索。
- 分类标签随意：同一类异常在不同人手里打了不同标签，检索时无法聚合。
- 只记录不复用：案例写完就归档，没有在新异常发生时主动检索匹配。
总结来说，异常回答“发生了什么偏离”，案例回答“这次偏离是怎么被理解和解决的”。把两者区分清楚，并在知识库中用统一的分类标签和案例要素模板固化下来，后续的案例匹配、根因推荐和自动复用才有可靠的数据基础。