服务事件分级标准的设计顺序可以概括为四步：先确定分级维度，再按维度组合划分3–4个级别，然后为每个级别绑定响应时限、处置角色、通报范围与升级路径，最后用历史事件回放校准级别边界。分级标准要能在一线被快速判定，每个级别都必须有可核对的进入条件和明确的响应动作，避免出现只有名称、没有动作的空级别。
要点总览（TL;DR）
- 分级标准按四步设计：定维度、划级别、绑动作、用历史事件回放校准边界，级别数量控制在3–4级。
- 分级维度采用“影响范围+业务关键度”两个主维度，可用替代方案只做上下浮动一级的修正项，避免判定逻辑分叉。
- 每个级别必须绑定首次响应时限、处置启动时限、通报节奏与范围、牵头角色、升级触发条件和复盘要求，不留空白格。
- 一线受理人初判定级，值班负责人复核与升级，事件经理协调处置，问题管理角色承接重复或高影响事件的根因治理。
- 上线前用历史事件回放验证级别边界，并先在一个服务范围试运行，统计定级分布与级别变更次数再推广。
分级标准先定维度：影响范围与业务关键度怎么组合
分级维度决定级别判定的稳定性。维度选得太多，一线在事件压力下难以快速判断；维度太少，又容易把影响差异很大的事件压进同一级别。实践中建议采用“两个主维度加一个修正项”的结构：影响范围作为第一维度，业务关键度作为第二维度，可用替代方案作为修正项。
第一维度：影响范围
影响范围回答“有多少用户或业务单元受到影响”，通常划分为单用户、单团队、多团队、全公司四档。这一维度最容易在现场获得事实依据，例如报障人数、受影响的门店或系统数量、监控告警覆盖范围。把影响范围放在第一位，可以让受理人在信息不完整时先做出初步判断。
第二维度：业务关键度
业务关键度回答“受影响的对象在业务中处于什么位置”，可分为核心交易链路、对外服务、内部支撑三档。核心交易链路指直接产生收入或履行对外承诺的业务；对外服务指客户可感知但非交易类的服务；内部支撑指员工办公与内部协作类系统。同样的影响范围，落在核心交易链路上应上调级别。
修正项：可用替代方案
是否存在临时绕行手段会改变事件的实际紧迫程度。有可用替代方案时，可在矩阵判定结果基础上下调一级；无替代方案且业务完全中断时，应上调一级。修正项只做上下浮动，不单独决定级别，避免判定逻辑分叉。
维度组合成级别矩阵
把两个主维度做成矩阵，每个交叉格填入对应级别，再用修正项调整，就得到可执行的判定表。下表为框架示例，具体档位可按组织实际调整。
| 影响范围 | 核心交易链路 | 对外服务 | 内部支撑 |
|---|---|---|---|
| 全公司 | 一级 | 一级 | 二级 |
| 多团队 | 一级 | 二级 | 三级 |
| 单团队 | 二级 | 三级 | 三级 |
| 单用户 | 三级 | 四级 | 四级 |
矩阵落地时注意两点：一是级别数量控制在3–4级，级别过多会导致响应动作难以差异化；二是每个交叉格只对应一个级别，避免“视情况而定”的模糊表述。修正项的使用条件要写清楚，例如“有经确认的替代方案且业务可继续运行”才允许下调。
级别划分与各级响应动作对照
级别定义完成后，必须为每一级绑定四类动作：响应时限、处置角色与决策权限、通报范围与升级触发条件、复盘要求与是否转入问题管理。动作缺失的级别在实际执行中会被一线自行解释，导致同级事件响应不一致。
响应时限
响应时限至少包含三个节点：首次响应时间（受理人确认并回复报障方）、处置启动时间（技术角色开始介入）、通报节奏（向相关方更新进展的间隔）。级别越高，三个节点越短、通报越频繁。时限应写成可核对的分钟或小时数，并注明起算点，例如“自工单创建起算”。
处置角色与决策权限
每个级别要明确谁牵头处置、谁有权调用资源、谁有权决定降级或关闭。一级事件通常由值班负责人或事件经理牵头，可跨团队调度；三级、四级事件可由一线或所属团队自行处置。决策权限写清楚，能减少处置过程中的请示等待。
通报范围与升级触发条件
通报范围随级别扩大：低级别通报至报障方与所属团队，高级别通报至业务负责人和管理层。升级触发条件要写成可观察的事实，例如“30分钟内未定位原因”“影响范围扩大至多团队”“出现数据不一致”。触发条件与级别判定分开写，便于处置过程中动态调整。
级别—响应动作对照表
| 级别 | 首次响应 | 处置启动 | 通报节奏与范围 | 牵头角色 | 升级触发 | 复盘与问题管理 |
|---|---|---|---|---|---|---|
| 一级 | 15分钟内 | 30分钟内 | 每30分钟更新，通报至管理层与业务负责人 | 事件经理 | 1小时未恢复或影响扩大 | 48小时内完成复盘，必须转入问题管理 |
| 二级 | 30分钟内 | 1小时内 | 每2小时更新，通报至团队负责人 | 值班负责人 | 2小时未定位或升级为多团队影响 | 5个工作日内复盘，重复发生转入问题管理 |
| 三级 | 2小时内 | 4小时内 | 按需更新，通报至报障方与所属团队 | 所属团队技术负责人 | 影响范围扩大或出现核心链路关联 | 按周汇总复盘，同类事件累计触发转问题管理 |
| 四级 | 1个工作日内 | 2个工作日内 | 结果回复报障方 | 一线受理人 | 判定依据变化时重新定级 | 月度汇总，不单独复盘 |
表中的时限与节奏为示例口径，组织应结合自身服务窗口与人员配置确定。关键要求是每一格都有明确内容，不出现“视情况”或空白。
角色分工与交付物：谁定级、谁响应、谁复盘
分级标准能否执行，取决于定级、响应、复盘三个环节的角色是否清晰、交付物是否留痕。定级与响应脱节是常见问题：一线定了级，但没有对应角色按级别动作响应，级别就失去意义。
一线受理人：初判与定级
一线受理人负责收集报障信息、按矩阵做出初判、创建事件记录并标注级别。交付物是包含影响范围、业务对象、初判级别和判定依据的事件记录。初判信息不完整时，按已知信息定级并注明待确认项，避免因等待信息而延迟响应。
值班负责人：复核与升级
值班负责人对一级、二级事件的定级进行复核，确认响应角色已到位，并在处置过程中根据升级触发条件调整级别。交付物是级别变更记录与升级通报。复核不是重新定级，而是检查定级依据与响应动作是否匹配。
事件经理：处置协调
事件经理在高级别事件中负责协调跨团队资源、组织进展同步、维护处置时间线。交付物是处置时间线与阶段性通报记录。事件经理关注服务恢复，根因分析交由问题管理角色承接。
问题管理角色：根因治理
问题管理角色承接重复发生或高影响事件，建立问题记录、推动根因分析、跟踪改进措施关闭。交付物是问题记录与改进措施跟踪表。事件与问题的衔接条件应写进分级标准，例如一级事件必须转问题管理、同类三级事件月度累计达到阈值转问题管理。
角色职责与交付物清单
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 一线受理人 | 信息收集、初判定级、创建事件记录 | 事件记录（含判定依据） |
| 值班负责人 | 定级复核、升级判断、通报组织 | 级别变更记录、升级通报 |
| 事件经理 | 跨团队协调、进展同步、时间线维护 | 处置时间线、阶段通报 |
| 问题管理角色 | 根因分析、改进措施跟踪 | 问题记录、措施跟踪表 |
这些记录如果分散在聊天工具和表格中，级别变更与复盘依据容易丢失。ONES 提供工单与问题管理的工作项承载方式，可将事件记录、级别字段、处置状态和复盘结论放在同一工作项上流转，并在事件关闭后关联问题工作项继续跟踪根因治理，使定级、响应、复盘各环节的交付物可追溯。
示例：一次核心服务不可用事件的分级与响应走查
以下为演示情景，用于说明分级标准从定级到复盘的完整走查过程，不代表真实案例。
事件发生与初判
某工作日午间，多个业务团队反馈核心下单服务无法提交订单，监控显示错误率快速上升。一线受理人收集到的事实是：受影响范围为多个团队且涉及外部客户，业务对象属于核心交易链路，暂无可用替代方案。对照矩阵，多团队加核心交易链路判定为一级，无替代方案维持一级不上调。受理人在10分钟内创建事件记录并标注一级及判定依据。
按级别触发响应
值班负责人复核定级后，按一级动作启动响应：15分钟内完成首次响应并回复报障方，30分钟内召集事件经理与相关技术角色介入，向管理层与业务负责人发出首次通报，并约定每30分钟更新进展。事件经理建立处置时间线，记录每次判断与动作。
处置中的升级判断
处置进行到40分钟时，技术角色定位到问题与一项近期变更相关，但回滚需要业务方确认。事件经理依据决策权限协调业务负责人快速确认，同时因“1小时未恢复”的升级触发条件临近，提前通知管理层准备客户沟通口径。级别保持不变，通报范围临时扩大至客户服务团队。
关闭、复盘与转问题管理
服务在70分钟时恢复，事件经理确认监控指标回到正常区间后关闭事件，并在记录中标注恢复时间与影响时长。按一级要求，48小时内组织复盘，输出时间线回顾、直接原因、处置中的有效动作与待改进项。由于该服务近三个月出现同类事件两次，复盘结论同时创建问题记录，由问题管理角色推动变更管理与监控告警的改进措施，并跟踪至关闭。
这个走查可以迁移到其他级别：把初判依据换成对应维度事实，把响应动作换成该级别对照表中的内容，把复盘要求换成该级别的规定即可。
完成检查：分级标准上线前的核对项
分级标准发布前，用以下清单逐项核对。每一项都应有明确答案和对应文档位置，无法回答的项说明标准尚未达到可执行状态。
- 每个级别是否都有可判定的进入条件，条件是否写成可观察的事实而非主观描述。
- 每个级别是否绑定了首次响应时限、处置启动时限与通报节奏，时限起算点是否写明。
- 每个级别是否明确了牵头角色、决策权限与通报范围。
- 升级触发条件是否与级别判定分开表述，处置过程中能否据此动态调整级别。
- 级别边界是否用历史事件回放验证过，回放结果与当时实际处置是否一致，不一致的边界是否已修订。
- 定级争议的裁决路径是否明确，例如由值班负责人裁决、重大分歧提交服务管理负责人。
- 分级标准与问题管理流程的衔接是否清晰，哪些级别或哪些情形必须转入问题管理。
- 事件记录、级别变更、通报与复盘结论是否有统一的留存位置，能否支撑后续统计与校准。
- 修正项（可用替代方案）的使用条件是否写明，是否限定只做上下浮动一级。
- 标准是否经过一线受理人试运行，试运行中出现的判定困难是否已回写到矩阵或条件描述中。
核对通过后，建议先在一个服务范围内试运行一个周期，统计定级分布与级别变更次数。若某一级别长期没有事件落入，或级别变更频繁，说明边界需要重新校准，再推广到全部服务。
常见问题
分级标准里级别数量定几级比较合适？
常见做法是3–4级。级别太少，影响差异很大的事件会被压进同一档，响应动作无法差异化；级别太多，一线在事件压力下难以快速判定，响应动作也容易写得雷同。可以先用四级框架（如一级到四级），试运行一个周期后看定级分布：如果某一级长期没有事件落入，或级别变更频繁，说明边界需要合并或重新校准。
事件处置中途影响范围扩大了，级别要不要改？
要改，而且这正是升级触发条件的作用。级别判定与升级触发条件应分开表述：判定依据是事件发生时的维度事实，升级触发条件写成可观察的事实，例如“影响范围扩大至多团队”“30分钟内未定位原因”。处置过程中一旦触发，由值班负责人或事件经理按预设路径调整级别并补发通报，级别变更记录要留痕，便于复盘时核对。
一线受理人信息不全时怎么定级，会不会定错？
按已知信息先定级，并在事件记录中注明待确认项，避免因等待信息而延迟响应。影响范围这一维度通常最容易在现场获得事实依据，例如报障人数、受影响系统数量、监控告警范围，可以先据此初判。值班负责人复核时再根据补充信息调整。定级争议的裁决路径要提前写明，例如由值班负责人裁决，重大分歧提交服务管理负责人。
哪些事件必须转入问题管理？
转入条件应写进分级标准，与级别和发生频次挂钩。常见做法包括：一级事件关闭后必须转问题管理；二级事件重复发生转问题管理；同类三级事件按月累计达到阈值转问题管理。转入后由问题管理角色建立问题记录、推动根因分析并跟踪改进措施关闭。事件侧关注服务恢复，问题侧关注根因治理，两者用关联记录衔接。
分级标准发布后怎么判断它是否真的可用？
看三个信号：一是历史事件回放结果与当时实际处置是否一致，不一致的边界是否已修订；二是试运行期间的级别变更次数，频繁变更说明判定条件写得不够可观察；三是事件记录、级别变更、通报与复盘结论能否在统一位置留存并支撑统计。核对清单逐项有明确答案和文档位置，标准才算达到可执行状态。
