3. 责任路由的核心原则与规则设计
责任路由不是“把异常丢给某个人”，而是在异常发生的那一刻，系统能够依据一组事先约定好的原则，自动推导出唯一且合理的责任归属。如果缺少原则约束，路由规则会迅速退化为一张充满特例的映射表，最终无人敢改、无人能懂。本节围绕四条核心原则——单一责任、就近路由、升级路由、兜底路由——说明它们各自解决什么问题，以及如何用可配置化的规则表达出来。
单一责任：任何异常在任一时刻只有一个责任主体
单一责任原则要求：一条异常在某个时刻必须且只能有一个“当前责任人”。这不是说异常只能由一个人处理，而是说在责任链上，同一时刻不能出现两个都“应该负责”的人。否则就会出现互相等待、互相推诿，或者两人重复处理同一问题。
实现单一责任的关键是引入“责任状态”概念。异常的责任主体随状态迁移而变化，但任一状态只对应一个责任角色。例如：
- 待分派：责任主体为路由引擎（系统），尚未落到人；
- 处理中：责任主体为当前处理人（唯一）；
- 待验证：责任主体为验证人（唯一）；
- 已关闭：无当前责任人，仅保留历史记录。
这样，任何时刻查询“这条异常现在归谁”，答案都是唯一的。规则设计上，应避免出现“同时通知A和B都来处理”的配置，而应表达为“先路由到A，A在超时未响应时再转移给B”。
就近路由：优先交给最接近异常现场的角色
就近路由的核心思想是：谁最了解现场、谁修复成本最低，就优先路由给谁。这里的“近”不是物理距离，而是信息距离和处理能力距离。通常按以下优先级排序：
- 异常发生的直接操作者或当班人员；
- 该设备/工序/服务的直接负责人（如线长、值班工程师）；
- 该领域的专业支持角色（如工艺工程师、SRE）；
- 跨领域协调角色（如生产主管、技术负责人）。
就近路由能显著缩短响应时间，但它有一个前提：异常必须携带足够的上下文，让“最近的人”能判断是否属于自己。因此路由规则通常需要结合异常来源、设备编号、工序代码、告警类型等字段进行匹配。例如，一条来自“注塑机A3”的“温度超限”异常，应优先路由给“注塑车间当班技术员”，而不是直接进入中央维修队列。
升级路由：超时或条件不满足时逐级上移
升级路由解决的是“就近路由失败”的问题。当责任人在规定时间内未响应、未处理完成，或异常满足特定严重度条件时，责任应自动上移到更高层级。升级不是惩罚，而是保证异常不会因为某个人不在、忙不过来或判断不了而停滞。
升级路由通常由两个要素驱动：时间阈值和升级路径。时间阈值定义“多久没动静就升级”，升级路径定义“升给谁”。例如：
| 异常等级 | 首次响应阈值 | 升级路径 |
|---|---|---|
| P3（一般） | 30分钟 | 当班技术员 → 线长 |
| P2（重要） | 15分钟 | 当班技术员 → 线长 → 生产主管 |
| P1（紧急） | 5分钟 | 当班技术员 → 线长 → 生产主管 → 厂长 |
升级路由的规则表达应支持“逐级升级”和“跳级升级”两种模式。逐级升级适合常规异常，跳级升级适合严重度极高或影响面极大的异常。配置时需明确每一级的触发条件、通知方式和责任转移时机，避免出现“已升级但原责任人仍以为自己在处理”的双责任状态。
兜底路由：确保异常永远不会无人认领
兜底路由是责任路由的最后一道防线。无论前面的规则因为字段缺失、匹配失败、角色空缺还是系统异常而未能命中，异常都必须有一个默认的接收方。兜底路由通常指向一个“异常池”或“值班调度岗”，由人工进行二次分派。
兜底路由的设计要点是：兜底对象必须是一个真实存在且有人值守的角色，不能是空值或已停用的账号。同时，兜底路由应记录“为什么走了兜底”，例如“设备编号为空”“未匹配到任何路由规则”“目标角色当前无人在岗”等，便于后续优化规则。
路由规则的可配置化表达
上述四条原则要落地，必须有一套可配置的规则表达方式。推荐采用“条件 + 动作”的结构，每条规则包含：规则名称、优先级、匹配条件、责任目标、升级策略、兜底标记。规则按优先级从高到低依次匹配，命中即停止。
下面是一个简化的规则配置示例，使用类 YAML 的伪代码表达：
rules:
- name: "注塑机温度异常-就近路由"
priority: 10
when:
source: "injection_machine"
alarm_type: "temperature_over"
machine_id: "A3"
assign_to: "role:injection_shift_technician"
escalate:
after_minutes: 15
to: "role:line_leader"
fallback: false
- name: "P1异常-跳级升级"
priority: 5
when:
severity: "P1"
assign_to: "role:shift_technician"
escalate:
after_minutes: 5
to: "role:production_manager"
skip_levels: true
fallback: false
- name: "默认兜底"
priority: 999
when: {}
assign_to: "role:exception_dispatch"
escalate:
after_minutes: 30
to: "role:production_supervisor"
fallback: true
这段配置体现了几个关键设计：优先级数字越小越先匹配；when 为空表示无条件命中，即兜底规则；escalate 中可指定升级时间和目标角色；fallback 标记用于区分兜底规则，便于统计和告警。
在实际系统中，规则引擎通常还需要支持条件组合（与/或/非）、字段存在性判断、角色解析（将角色映射到具体人员）以及规则版本管理。规则变更应经过测试和灰度发布，避免一条错误规则导致大量异常被错误路由。
从图中可以看出，异常从进入系统到确定责任人，经历“规则匹配—命中规则—确定责任—超时升级”的路径。四条原则分别在不同环节发挥作用：单一责任约束责任主体的唯一性，就近路由决定初始分配，升级路由处理超时和条件变化，兜底路由保证极端情况下仍有归属。规则的可配置化则让这些原则能够随组织、产线和异常类型灵活调整，而不需要每次修改代码。