服务事件分级矩阵用来把“这件事有多严重、该多快响应、该通知谁”从口头判断变成可复用规则。本文直接给出一张可复制填写的空白矩阵，并说明事件基本信息、影响与紧急度判定、等级与响应规则三类字段的含义，以及P1至P4四级的定义和一条完整填写示例，团队可据此调整等级数量与阈值。
要点总览（TL;DR）
- 服务事件分级矩阵模板通常包含三类字段：事件标识与基本信息、影响与紧急度判定、等级与响应规则，本文提供可直接复制填写的空白表格。
- 等级定义常用P1至P4四级（也可用S1至S4），按业务影响范围、受影响用户比例、业务中断程度、是否影响核心交易或数据安全、是否有替代方案综合判定。
- 决定分级结果的必填字段是影响与紧急度判定区字段；上报人、受影响用户比例、当前状态等用于记录追溯，可按团队规模取舍。
- 必填字段缺失时采用兜底规则：影响不明按取大取重暂定，涉及核心交易或数据安全无法判断时按“是”处理并通知业务负责人，确认后复核。
- 矩阵上线后按误分级复盘、服务目录变化等触发评审，记录版本并定期校准，同时与服务事件流程、问题管理衔接。
可复制空白分级矩阵模板
下表是空白模板，可整体粘贴到文档或表格工具中，按行填写。表格分为三块：左侧记录事件是谁、在哪、什么时候报的；中间记录影响与紧急度判定；右侧记录由此得出的等级和配套响应规则。填写时先完成中间判定区，再填右侧等级列，避免先定级后找理由。
| 事件编号 | 上报时间 | 上报人/渠道 | 服务对象 | 影响范围 | 受影响用户比例 | 业务中断程度 | 是否影响核心交易或数据安全 | 是否有可用替代方案 | 紧急度 | 事件等级 | 响应时限 | 升级路径 | 通知范围 | 当前状态 | 责任人 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队习惯先看影响再看紧急度，可以把“影响范围、受影响用户比例、业务中断程度、是否影响核心交易或数据安全”四列作为影响判定区，把“是否有可用替代方案、紧急度”作为紧急度判定区，两区交叉后落到“事件等级”列。等级确定后，响应时限、升级路径、通知范围三列按等级直接套用，不需要每次重新讨论。
模板中的“当前状态”和“责任人”用于记录事件在流转中的位置，便于交接和复盘。矩阵本身只负责定级，事件从受理到关闭的完整流转可以放在服务事件流程文档中管理。
字段说明：每个列位回答什么问题
字段之间是有判定顺序的：先确认事件身份和基本信息，再判断影响，再判断紧急度，最后得出等级并套用响应规则。下面逐列说明含义和取值方式，与上表列位一一对应。
| 字段 | 回答的问题 | 取值方式 |
|---|---|---|
| 事件编号 | 这是哪一条事件，如何追溯 | 按团队编号规则填写，如日期加流水号 |
| 上报时间 | 事件何时进入服务台 | 精确到分钟，作为响应时限起算点 |
| 上报人/渠道 | 谁通过什么方式报告 | 填写报告人或监控系统，以及电话、工单、群聊等渠道 |
| 服务对象 | 受影响的是哪个系统、服务或业务线 | 从服务目录中选择，避免自由填写造成口径不一 |
| 影响范围 | 波及单个用户、单个部门、多个部门还是全公司 | 按预设档位选择，如个人、团队、多部门、全组织 |
| 受影响用户比例 | 受影响人数占该服务使用者的比例 | 填写区间，如低于10%、10%至50%、超过50% |
| 业务中断程度 | 业务是完全不可用、部分功能受限还是仅体验下降 | 按档位选择：完全中断、主要功能受限、轻微影响 |
| 是否影响核心交易或数据安全 | 是否涉及下单支付、资金、客户数据泄露等敏感场景 | 是/否，并简要注明涉及的业务 |
| 是否有可用替代方案 | 用户能否通过其他方式继续完成业务 | 有替代、部分替代、无替代 |
| 紧急度 | 在影响之外，时间上是否等不起 | 高、中、低，结合是否有监管时限、是否持续扩大判断 |
| 事件等级 | 综合判定后属于哪一级 | P1至P4，按下一节映射规则得出 |
| 响应时限 | 多久内必须有人响应并给出初步反馈 | 按等级预设，如15分钟、30分钟、2小时、次日 |
| 升级路径 | 超时或无法解决时交给谁 | 填写一线、二线、值班经理、技术负责人等层级 |
| 通知范围 | 哪些角色需要被告知 | 按等级预设，如值班群、业务负责人、管理层 |
| 当前状态 | 事件处理到哪一步 | 待受理、处理中、待验证、已关闭等 |
| 责任人 | 当前由谁负责推进 | 填写具体人员或值班岗位 |
判定顺序上，影响范围和业务中断程度决定事件的“底子”，是否影响核心交易或数据安全具有一票提升作用，是否有可用替代方案和紧急度用于微调。把顺序固定下来，不同值班人员对同一事件的定级结果才会趋于一致。
必填与选填：哪些字段决定分级结果
决定等级的是影响与紧急度判定区的字段，这些字段缺失时无法得出可靠等级，应列为必填。其余字段用于记录和追溯，可按团队习惯取舍。
| 类别 | 字段 | 理由或适用场景 |
|---|---|---|
| 必填 | 事件编号、上报时间、服务对象 | 确定事件身份和响应起算点，缺失则无法追溯时限 |
| 必填 | 影响范围、业务中断程度、是否影响核心交易或数据安全 | 直接决定等级下限和是否触发最高级 |
| 必填 | 是否有可用替代方案、紧急度 | 用于在影响相近的事件之间区分先后 |
| 必填 | 事件等级 | 分级矩阵的输出结果，后续响应规则均依赖它 |
| 选填 | 上报人/渠道、受影响用户比例 | 比例难以快速估算时可先记录影响范围，复盘时补充 |
| 选填 | 当前状态、责任人 | 小团队可由工单系统状态自动体现，无需手工重复填写 |
| 选填 | 通知范围 | 已按等级写入流程文档时，矩阵中可省略 |
必填字段缺失时，采用兜底规则：影响范围或业务中断程度不明，先按“影响范围取大、中断程度取重”暂定，并在事件记录中标注“待确认”；涉及核心交易或数据安全无法判断时，按“是”处理并立即通知业务负责人。兜底定级应在确认信息后复核，避免长期停留在偏高的等级。
团队规模影响字段取舍。人数较少、值班人员彼此熟悉时，可保留核心判定字段和等级列，把通知范围写进流程说明；跨部门、多服务线的团队建议保留全部字段，尤其是服务对象和升级路径，减少交接时的口头确认。
等级定义与填写示例
常用做法是四级：P1至P4，也有团队用S1至S4，含义对应。等级由影响与紧急度组合得出，下表给出定义和判定条件。
| 等级 | 定义 | 判定条件 | 响应时限 | 升级路径 | 通知范围 |
|---|---|---|---|---|---|
| P1 | 重大事件，核心业务大面积不可用或存在数据安全风险 | 影响核心交易或数据安全，或全组织范围业务完全中断，且无替代方案 | 15分钟内响应 | 一线立即上报值班经理与技术负责人，30分钟未缓解升级至管理层 | 值班群、业务负责人、管理层 |
| P2 | 严重事件，主要功能受限或较多用户受影响 | 多部门受影响或主要功能不可用，有部分替代方案 | 30分钟内响应 | 一线转二线，2小时未解决升级至技术负责人 | 值班群、相关业务负责人 |
| P3 | 一般事件，局部功能异常，业务可继续 | 单个团队或少量用户受影响，有可用替代方案 | 2小时内响应 | 一线处理，当日未解决转二线 | 值班群 |
| P4 | 轻微事件，体验下降或咨询类问题 | 个人使用受影响，业务不受实质影响 | 次工作日响应 | 按常规排期处理 | 按需回复上报人 |
映射规则可以概括为：涉及核心交易或数据安全直接进入P1；无替代方案且影响多部门进入P1或P2；有替代方案、影响限于单个团队进入P3；仅影响个人体验进入P4。紧急度高时在同一影响档内上调一级，紧急度低时不单独降级，避免因主观判断压低等级。
以下是一条完整填写示例，演示从判定到定级的推导过程。
| 字段 | 填写内容 | 说明 |
|---|---|---|
| 事件编号 | INC-20250612-0031 | 按日期加流水号生成 |
| 上报时间 | 2025-06-12 09:12 | 响应时限从此起算 |
| 上报人/渠道 | 客服组，工单渠道 | 由客服代客户提交 |
| 服务对象 | 订单结算服务 | 来自服务目录 |
| 影响范围 | 多部门 | 销售、客服、仓储均无法结算 |
| 受影响用户比例 | 超过50% | 多数下单用户受影响 |
| 业务中断程度 | 主要功能受限 | 下单可提交，结算失败 |
| 是否影响核心交易或数据安全 | 是，影响支付结算 | 触发最高级判定 |
| 是否有可用替代方案 | 无替代 | 无其他结算通道 |
| 紧急度 | 高 | 影响持续扩大 |
| 事件等级 | P1 | 涉及核心交易，直接定P1 |
| 响应时限 | 15分钟内响应 | 按P1规则 |
| 升级路径 | 一线上报值班经理与技术负责人 | 30分钟未缓解升级管理层 |
| 通知范围 | 值班群、业务负责人、管理层 | 按P1规则 |
| 当前状态 | 处理中 | 已定位到结算接口异常 |
| 责任人 | 值班工程师甲 | 当前推进人 |
这条示例中，影响范围和中断程度本身指向P2，但“影响核心交易”具有提升作用，最终定为P1，响应时限和通知范围随之按P1执行。填写者可以对照这一推导检查自己的定级是否一致。
矩阵的调整与维护方法
矩阵上线后需要定期校准，否则会出现等级虚高、响应资源被挤占，或等级偏低、重要事件被延误。调整可以从触发条件、字段增减、版本记录和流程衔接四方面入手。
- 调整触发条件：出现误分级并在复盘中确认原因、服务目录新增或下线重要系统、业务高峰或大促期间影响口径变化时，启动矩阵评审。
- 字段增减：连续多次出现某字段无人填写，考虑删除或改为自动带出；复盘中发现定级分歧集中在某个维度，考虑拆分为更细的档位。
- 等级数量调整：事件量小、响应资源集中的团队可合并为三级；服务线多、监管要求高的团队可保留四级并细化P1、P2的判定条件。
- 版本记录：每次调整记录版本号、调整内容、生效日期和审批人，旧版本归档，便于回溯历史事件的定级依据。
- 评审节奏：建议按季度例行评审，重大事件复盘后即时评审，评审结论落到矩阵和流程文档两处，保持同步。
矩阵还需要与服务事件流程、问题管理衔接。事件关闭后，反复出现或根因未明的事件转入问题管理，问题记录中引用原事件编号和等级，便于判断该类问题的影响面。矩阵中的等级字段应作为流程分支的依据，而不是孤立的一张表。
在工具层面，分级字段需要有承载位置。ONES Desk 支持自定义工单属性，可把影响范围、紧急度、事件等级等字段配置到工单上，并按等级设置优先级以优先处理紧急事件；工作流可随团队处理方式调整。事件需要研发介入时，工单可关联到待办事项列表，或一键关联 ONES Project 的需求、缺陷工作项持续跟踪至处理完成。矩阵文档本身可放在 ONES Wiki 的页面模板库中，以制式化模板一键创建，保证各团队使用同一版本。工具承载的是字段和流转，等级阈值和判定规则仍由团队在矩阵中定义并定期维护。
常见问题
团队事件量不大，能不能只用三级而不是四级？
可以。等级数量取决于事件量和响应资源的分布，而非固定要求。事件量小、值班人员集中、响应资源有限的团队，可以把P3和P4合并为一级，保留“重大、严重、一般”三级，同时把原P4的响应时限并入合并后的等级说明。合并后需要同步检查两处：一是升级路径是否仍能覆盖原P3、P4的处理方式，二是通知范围是否因等级减少而遗漏业务负责人。服务线多、有监管时限要求的团队，建议保留四级并细化P1、P2的判定条件。
同一事件在不同值班人员手里定级不一致，怎么处理？
先看分歧集中在哪个字段。常见原因是影响范围、业务中断程度这类档位描述偏模糊，或“是否影响核心交易”缺少明确清单。处理方式有两条：一是把档位描述改写成可对照的具体情形，例如把“主要功能受限”细化为“下单可提交但结算失败”这类业务动作；二是在矩阵中固定判定顺序，先影响后紧急度，涉及核心交易或数据安全直接进入最高级，减少主观调整空间。复盘时把分歧案例记录下来，作为下一版矩阵的修订依据。
事件定级后，响应时限和升级路径需要每次人工确认吗？
不需要。响应时限、升级路径、通知范围应当按等级预先写死在矩阵或流程文档中，定级完成后直接套用。人工确认只保留在两种情形：一是使用了兜底规则暂定等级的事件，确认信息后需要复核等级并同步调整响应规则；二是事件在处理过程中影响面扩大，需要重新定级。把这三列做成按等级查表的固定规则，可以减少值班沟通成本，也便于事后检查是否按规则执行。
分级矩阵和问题管理之间怎么衔接？
事件关闭后，对反复出现或根因未明的事件转入问题管理，问题记录中引用原事件编号和等级，便于判断该类问题的影响面。矩阵中的等级字段应作为流程分支的依据：高等级事件转问题管理时优先安排根因分析，低等级事件可批量归并观察。这样分级结果不只是一张孤立的表，而是影响后续治理优先级的输入。
用工具承载分级字段时要注意什么？
关键是让字段可配置、可流转，而不是把矩阵停留在文档里。以ONES Desk为例，支持自定义工单属性，可把影响范围、紧急度、事件等级等字段配置到工单上，并按优先级优先处理紧急事件；工作流可随团队处理方式调整。事件需要研发介入时，工单可关联到待办事项列表，或一键关联ONES Project的需求、缺陷工作项持续跟踪。矩阵文档本身可放在ONES Wiki的页面模板库中，以制式化模板一键创建，保证各团队使用同一版本。等级阈值和判定规则仍由团队在矩阵中定义并定期维护。
