2. 生产异常分类与责任域建模

生产异常一旦发生，最先被问到的往往不是“怎么修”，而是“这该谁负责”。如果分类口径不统一、责任域边界模糊，就会出现告警在多个团队之间来回踢皮球，SLA 计时起点无法确定，复盘时也无法判断到底是哪一环失效。本节要解决的核心问题，是把“异常”从一句模糊的描述，转化为可分类、可定位、可归属的结构化对象，并建立责任域、责任主体与责任边界之间的映射模型。

一、三个正交的分类维度

生产异常的分类不能只按“严重程度”一刀切，因为严重程度只回答“多急”，不回答“在哪、为什么、归谁”。实践中更有效的方式是采用三个相互正交的维度：业务链路维度回答“影响谁”，系统层级维度回答“在哪一层”，故障模式维度回答“怎么坏的”。三者组合后，一个异常才能被精确定位。

业务链路维度按用户可感知的价值流划分，例如：下单链路、支付链路、库存扣减链路、履约发货链路、对账结算链路。它的作用是确定异常的业务影响面——同样是接口超时，发生在支付链路和发生在内部报表链路，优先级和责任主体完全不同。

系统层级维度按技术栈自下而上划分，典型分层为：基础设施层（主机、网络、存储）、数据层（数据库、缓存、消息队列）、应用服务层（微服务、API 网关）、接入层（CDN、负载均衡、DNS）、客户端层（App、小程序、Web）。这一维度决定异常的技术定位范围。

故障模式维度描述失效的形态，常见模式包括：可用性故障（服务不可达、5xx 激增）、性能故障（RT 升高、吞吐下降）、数据故障（数据不一致、丢失、重复）、容量故障（连接池耗尽、磁盘写满）、依赖故障（下游超时、第三方不可用）、变更故障（发布、配置、扩缩容引发的异常）。故障模式决定处置手段，也直接影响责任主体的判定。

二、责任域、责任主体与责任边界

分类完成后，需要把异常映射到责任结构上。这里要区分三个容易混淆的概念：

• 责任域：一组由同一责任主体负责、边界清晰的技术或业务资产的集合。例如“支付应用域”包含支付服务、支付数据库、支付相关配置。
• 责任主体：对责任域承担第一响应与修复义务的团队或角色，如支付研发组、DBA 组、SRE 平台组、网络运维组。
• 责任边界：责任域之间的交接面，通常表现为接口契约、SLA 承诺、数据归属或调用方向。边界不清是责任路由失败的首要原因。

映射模型的基本规则是：一个异常实例在某一时刻只能有一个第一责任主体，但可以存在多个协同方。第一责任主体由“异常落点所在的责任域”决定，而不是由“谁最后改过代码”决定。例如数据库连接池耗尽，落点在应用服务层，但根因可能在数据层慢查询，此时第一责任主体仍是应用服务域，数据层作为协同方介入，直到根因证据指向数据层后再做责任转移。

三、责任路由映射模型

把三个分类维度与责任结构组合，可以得到一张可执行的路由表。下面这张图展示了从异常发生到责任归属的完整映射关系：左侧是分类维度，中间是判定过程，右侧是责任域与责任主体的落点。

图中左侧三个维度共同输入判定过程，判定过程输出唯一的责任域落点，再由责任域映射到具体责任主体。右侧虚线标注的是责任边界——它既是技术交接面，也是 SLA 承诺的分界点。当异常跨越边界时，必须明确“谁先响应、谁主导修复、谁提供证据”。

四、责任边界的判定规则

边界判定最容易出错的地方，是把“调用方”和“被调用方”的责任混为一谈。建议采用以下三条规则：

1. 落点优先规则：异常首先在哪个责任域的监控或日志中暴露，该域即为第一响应方，无论根因是否在其内部。
2. 证据转移规则：第一响应方在约定时限内（例如 15 分钟）完成初步定位，若证据指向其他责任域，则发起责任转移，转移后由新责任方主导，原责任方转为协同。
3. 契约兜底规则：若无法在时限内定位根因，则按接口契约判定——谁对外承诺了 SLA，谁承担兜底责任。例如支付服务承诺 99.95% 可用性，即使根因在数据库，支付服务域仍需先对外兜底。

五、一个可落地的责任路由表样例

把上述模型固化为路由表，可以让值班人员在告警触发后快速完成归属。下表是一个示例结构，字段可根据实际组织调整：

这张表的价值在于：它把“分类”和“归属”之间的推理过程前置固化了。值班人员不需要每次重新争论，只需按落点匹配行，即可得到第一责任主体和协同方。随着异常样本积累，路由表可以持续修正——如果某类异常频繁发生责任转移，说明边界定义或契约设计需要调整，这正是责任域建模反哺架构治理的地方。

总结来说，生产异常分类与责任域建模的关键，不是画出一张漂亮的分类图，而是让每一个异常实例都能沿着“链路—层级—模式”三个维度快速收敛到唯一的责任域，再由责任域映射到明确的责任主体，并用责任边界规则处理跨域交接。分类是手段，路由才是目的；只有路由可执行，SLA 的计时、归因和治理才有稳定的起点。