1. 课程导入与全景认知
在生产系统中，异常从来不是稀缺事件。真正稀缺的是在异常发生后，能够快速、准确地把问题交到正确的人手里，并在承诺时间内完成闭环。很多团队并不缺监控、不缺工单系统、也不缺值班表，但故障仍然反复拖延：告警在群里刷屏却无人认领，工单在多个团队之间来回流转，SLA 到期前才被临时"关闭"，复盘时又发现根因和最初判断完全不同。这些现象背后，缺失的往往不是工具，而是一套责任路由与 SLA 治理的工程机制。
一、什么是生产异常责任路由
生产异常，指线上系统在运行过程中出现的、偏离预期服务水平的可观测事件，例如接口错误率突增、核心链路延迟升高、任务积压、数据不一致、容量逼近阈值等。责任路由，则是在异常被确认后，依据异常特征、影响范围、系统归属和当前值班状态，把处理责任精确指派到具体团队与具体人的过程。
它包含三个关键判断：
- 归属判断：这个异常属于哪个服务、哪个业务域、哪个基础设施层？
- 角色判断：应该由一线值班、二线专家，还是变更发起方来接手？
- 时效判断：这类异常对应什么响应等级，需要在多长时间内响应、多长时间内恢复？
责任路由不是简单的"派单"，而是把异常信号与组织责任结构做一次映射。映射错了，后续所有努力都会打折。
二、SLA 治理在其中的位置
SLA（Service Level Agreement）在这里不是一份对外合同，而是团队对异常处理时效的内部承诺。它通常由几个可量化指标构成：
| 指标 | 含义 | 示例值 |
|---|---|---|
| MTTA | 平均响应时间，从异常确认到有人接手 | P1 ≤ 5 分钟 |
| MTTR | 平均恢复时间，从接手到服务恢复 | P1 ≤ 30 分钟 |
| 认领率 | 异常被明确责任人认领的比例 | ≥ 98% |
| 误路由率 | 首次派单被退回或转派的比例 | ≤ 10% |
SLA 治理的核心动作，是让时效承诺可观测、可追责、可改进。没有 SLA，责任路由只是一次性动作；有了 SLA，它才成为可持续运行的工程闭环。
三、端到端视角：从异常发现到责任闭环
把视角拉长，一次生产异常的完整生命周期通常包含六个阶段：发现 → 确认 → 路由 → 处理 → 恢复 → 复盘。每个阶段都有明确的输入、输出和判断条件，任何一个环节断裂，闭环就无法形成。
下面这张图展示了从异常信号产生到责任闭环的端到端链路，以及责任路由与 SLA 治理在其中的作用位置：
这张图想强调三件事。第一，路由是承上启下的关键节点：确认阶段产出的定级和影响面，直接决定路由策略；路由结果又决定处理阶段由谁、以什么优先级介入。第二，SLA 不是某一个阶段的指标，而是横跨确认到恢复的约束带，它把分散的动作串成一条有时效承诺的链路。第三，复盘必须回流：如果复盘结论不能改进路由规则或 SLA 阈值，闭环就只是形式上的关闭。
四、为什么需要"工程化"而不是"管理化"
很多团队把责任路由当成管理问题，靠开会、靠强调、靠"大家要有责任心"来解决。但生产异常的特点是高频、并发、信息不完整、时间压力大，靠人的自觉无法稳定收敛。工程化的含义是：
- 规则可执行：路由规则写成可被系统读取的配置，而不是口头约定；
- 状态可观测：每个异常当前处于哪个阶段、由谁负责、剩余 SLA 时间，都能实时看到；
- 偏差可度量：误路由、超时、反复转派都能被统计，并驱动规则迭代；
- 改进可沉淀：每次复盘产出的规则调整、预案补充，都进入下一次异常的处理路径。
五、本课程要解决的问题
接下来的章节会围绕这条端到端链路展开，重点解决四类问题：
- 路由规则怎么设计：如何从服务拓扑、业务归属、变更记录中提取路由依据，避免"谁在线谁处理"；
- SLA 怎么定和怎么算：分级标准、时限设定、计时起点与暂停条件，以及如何避免"虚假达标"；
- 异常处理过程怎么治理：认领、升级、转派、协同的机制设计，减少责任真空和重复沟通；
- 闭环怎么验证和改进：用哪些指标判断治理有效，如何从复盘结论反推规则和阈值调整。
需要先建立一个基本认知：责任路由与 SLA 治理的目标不是"零异常"，而是"异常发生后，责任清晰、时效可控、闭环可查"。异常本身是系统复杂性的正常产物，治理的对象是异常发生后的处理过程，而不是异常的发生概率。把这一点想清楚，后续所有规则设计和指标设定才不会跑偏。