事件分级响应机制由两部分组成：分级标准回答“这件事有多严重”，动作映射回答“这个级别要做什么”。制定时先确定影响范围、业务关键度、替代方案和对外承诺四个维度，把事件划为3–4级并写清判定条件；再为每级绑定响应时限、首问角色、通报对象、升级触发和恢复目标。两份内容成对发布，用历史事件回测校准后纳入值班执行。
要点总览（TL;DR）
- 分级标准固定影响范围、业务关键度、替代方案、对外承诺四个维度，设3–4级，多维度冲突时按就高不就低处理，判定存疑先按高一级响应。
- 响应动作按级别分档：每级写明响应时限、恢复目标、首问角色、通报对象与频率、升级触发条件，动作表与分级表成对发布。
- 通报解决信息同步，升级解决资源与决策权限；允许跨级处理和降级，但降级须记录依据，恢复确认仍按原级别完成。
- 角色矩阵把一线受理人、事件负责人、技术处理人、业务沟通人落实到岗位，并约定代班人和升级决定权。
- 上线前抽取至少20条历史事件回测，重点修正判定歧义和级别与时限不匹配的问题，上线后前三个月每月复查定级准确率与升级及时率。
分级标准怎么设计：四个维度定级别
分级标准的目标是让不同值班人员在看到同一事件时得出相同级别。做法是固定四个判定维度，每个维度给出可观察的判断依据，再按“就高不就低”的原则合并成最终级别。维度不宜过多，超过五个会让值班人员在压力下难以快速判断。
四个判定维度
| 维度 | 判断问题 | 判定依据示例 |
|---|---|---|
| 影响范围 | 受影响的是谁、多少人 | 单用户、单团队、多团队、全公司或全部外部客户 |
| 业务关键度 | 受阻的是哪类业务，是否影响对外服务承诺 | 核心交易、对外接口、SLA承诺中的服务、内部辅助工具 |
| 替代方案 | 是否存在可用的替代路径或降级手段 | 可切换备用通道、可手工绕过、完全无替代 |
| 对外承诺 | 是否已触发或即将触发对客户的承诺条款 | 合同SLA、公开服务公告、监管报送时限 |
四个维度中，影响范围和对外承诺通常权重最高。一个只影响单个团队但卡住对外交付的事件，级别应高于影响人数多但可用替代方案绕过的内部工具故障。
级别数量与判定优先级
建议设3–4级，命名为P1至P4或一级至四级，并在制度中写明级别越高越严重。级别太少无法区分动作强度，太多则值班人员记不住。判定规则写明：多个维度指向不同级别时，取其中最高级别；判定存疑时先按高一级响应，事后在复盘中修正。
每级判定条件的写法
判定条件要写成可核对的事实描述，避免“严重影响”“较大范围”这类无法验证的措辞。示例如下：
- P1：全公司或全部外部客户无法使用核心服务，且无替代方案；或已触发对外SLA违约条款。
- P2：多个团队的核心业务受阻，或单一对外服务不可用但存在临时降级手段；尚未触发承诺条款但预计在承诺时限内无法恢复。
- P3：单个团队业务受阻，存在可用替代方案；不影响对外承诺。
- P4：单个用户咨询或操作异常，业务可正常进行，按常规工单处理。
每条判定条件都应能对应到工单上的字段：影响范围、业务系统、替代方案说明、承诺关联。字段设计好后，定级就从主观讨论变成对照填写。
响应动作如何按级别区分：一张动作对照表
分级标准确定后，为每一级绑定一组动作，形成级别—动作对照表。动作表与分级表同时发布，值班人员按级别直接查表执行，不再临时商量。下表是一份可直接改用的模板，时限数值需结合自身服务承诺设定。
| 级别 | 响应时限 | 恢复目标 | 首问角色 | 通报对象与频率 | 升级触发条件 |
|---|---|---|---|---|---|
| P1 | 15分钟内响应 | 4小时内恢复或给出明确恢复计划 | 值班负责人直接担任事件负责人 | 立即通报服务负责人、业务负责人和高层；每30分钟更新一次 | 30分钟无进展、影响面扩大、出现数据风险时立即升级至应急小组 |
| P2 | 30分钟内响应 | 8小时内恢复 | 一线受理人首问，值班负责人介入 | 通报服务负责人和相关业务方；每1小时更新 | 2小时无有效进展或升级为多团队受阻时升为P1 |
| P3 | 2小时内响应 | 2个工作日内恢复 | 一线受理人首问，按需转技术处理人 | 通报受影响团队；每日更新 | 出现对外影响或替代方案失效时升级 |
| P4 | 1个工作日内响应 | 按常规工单排期 | 一线受理人 | 仅回复提交人 | 影响范围扩大时重新定级 |
时限与恢复目标的分档逻辑
响应时限指从事件登记到有人接手并给出初步判断的时间，恢复目标指从登记到服务恢复的时间。两者分开设定，避免把“有人看了”当成“已经处理”。P1、P2的恢复目标应留出升级和跨团队协同的余量，P3、P4可以按工作日计算。
通报与升级的区分
通报解决信息同步，升级解决资源和决策权限。通报对象按级别扩大：P1需要业务负责人知情以便对外沟通，P4只需回复提交人。升级触发条件写成可观察的事实，例如“超过约定时限无进展”“影响范围从单团队扩大到多团队”“出现数据丢失或合规风险”。升级路径写明下一站是谁：P2升P1由值班负责人决定并通知应急小组，P1内部无法控制时上报服务负责人决策。
跨级处理与降级条件
允许跨级处理：事件在调查中确认影响面更大，可直接跳到更高级别，不必逐级上升。降级同样要有条件，例如替代方案生效、受影响范围缩小到单团队，由事件负责人确认后降级，并在事件记录中写明降级依据和时间。降级不是关闭事件，恢复确认仍按原级别要求完成。
角色与交付物：谁在什么级别做什么
动作表规定了做什么，角色矩阵规定谁来做。服务事件响应通常涉及四类角色：一线受理人负责登记、初判和首问回复；事件负责人负责统筹处置节奏、决定升级和对外口径；技术处理人负责定位与恢复；业务沟通人负责向受影响业务方和客户同步进展。小团队可以一人兼多角，但每个级别下必须明确到具体岗位。
| 角色 | P1 | P2 | P3 | P4 |
|---|---|---|---|---|
| 一线受理人 | 登记并立即通知值班负责人 | 登记、初判、首问回复 | 登记、初判、按需转派 | 登记并直接答复 |
| 事件负责人 | 值班负责人担任，全程指挥 | 值班负责人介入并跟踪 | 由技术处理人兼任 | 不单独设置 |
| 技术处理人 | 按预案集结，分工定位 | 指定专人处理 | 按工单排期处理 | 按常规处理 |
| 业务沟通人 | 对外统一口径，按频率通报 | 向相关业务方通报 | 向受影响团队说明 | 回复提交人 |
各级别的交付物
- 事件记录：所有级别都必须有，包含现象、影响范围、定级依据、处理过程和恢复确认时间。
- 通报消息：P1、P2按约定频率发出，内容包含当前状态、影响范围、下一步动作和下次更新时间。
- 复盘报告：P1、P2在恢复后规定工作日内完成，P3视重复发生情况决定是否复盘，P4不单独复盘。
- 问题单：复盘确认存在根因且需长期治理的，转为问题跟踪，明确责任人和整改期限。
交接、代班与授权边界
值班交接要交接未关闭事件、当前级别、下一次通报时间和待办动作，交接记录随事件记录保存。代班安排写明谁在值班负责人缺席时行使升级决定权，避免P1事件因找不到人而停滞。授权边界要写清事件负责人可以调动哪些资源、可以决定多长时间的降级处理、哪些动作必须上报服务负责人，例如涉及数据恢复方案变更或对外公告发布。
当事件量增大、级别和状态需要在工单上稳定承载时，可以用ONES Desk承接这套机制：工单支持自定义属性，可把影响范围、业务系统、定级依据设为必填字段；支持评估和定义工单优先级，优先处理紧急事件；工作流可灵活调整，把定级、升级、恢复确认设为状态节点。跨团队处置时，工单可直接关联到待办事项列表，打通服务团队与研发团队协同；需要长期治理的，可一键关联到ONES Project的缺陷工作项持续跟踪，或将复盘结论沉淀到ONES Wiki页面。管理者可通过工单分析报表查看各级别处理进度和团队表现。
示例：一次P2事件的完整响应过程
以下为演示情景，用于说明从定级到复盘的连续执行，不代表真实客户案例。
事件现象与定级
上午9:05，客服团队反馈外部客户无法提交订单，提交页面持续报错。一线受理人登记工单，对照分级标准逐项判断：影响范围为全部外部下单客户，属多团队以上；业务关键度为对外核心交易；替代方案为客服可代客下单，属临时降级手段；对外承诺方面，若2小时内未恢复将接近SLA响应承诺。四项中影响范围和业务关键度指向P1，但存在代客下单的降级手段，综合判定为P2，并按“存疑从高”原则通知值班负责人介入。
按级别触发的动作与时间点
- 9:05 登记工单，标记P2，首问回复客户“已受理，30分钟内反馈进展”。
- 9:12 值班负责人介入，指定技术处理人，业务沟通人向客服团队发出首次通报。
- 9:40 技术处理人定位到支付回调配置异常，给出临时绕过方案，业务沟通人按每小时频率更新进展。
- 10:20 临时方案生效，下单恢复，事件负责人确认影响范围缩小，事件降为P3并记录降级依据。
通报与升级的实际发生
9:30 技术处理人反馈排查范围扩大到两个服务模块，事件负责人判断2小时内可能无法彻底恢复，按升级触发条件将事件升为P1，通知服务负责人和业务负责人，通报频率改为每30分钟一次。升级后资源投入增加，排查速度加快。这次升级说明触发条件要写成时间与事实，而非等待个人感觉。
恢复确认与复盘产出
11:00 根因修复完成，事件负责人确认监控指标恢复正常、客服侧无新增报错，记录恢复时间并关闭事件。次日完成复盘报告，结论为配置变更缺少校验环节，转为问题单，关联到研发侧工作项跟踪整改，复盘文档归档供后续值班查阅。
完成检查：机制上线前的核对项
机制写完后不要直接发布，先用检查清单逐项核对，再用历史事件回测。核对的目标是确认任何一名值班人员拿到事件都能独立完成定级和动作执行。
上线核对清单
- 分级标准覆盖近半年历史事件，抽取至少20条逐一试判，判定结果与当时实际处理级别一致或能解释差异。
- 每条判定条件都有对应的工单字段，字段为必填，定级不需要额外口头确认。
- 动作表每一级都写明了响应时限、恢复目标、首问角色、通报对象与频率、升级触发条件和升级路径，没有空白格。
- 角色落实到具体岗位和姓名，值班表覆盖全部时段，代班人和升级决定权已书面约定。
- 通报模板、复盘报告模板已准备好，模板字段与动作表要求一致。
- 降级和跨级处理的条件已写明，事件记录中有记录降级依据的位置。
- 复盘与问题治理的衔接方式明确：什么条件下转问题单、由谁负责、整改如何跟踪关闭。
回测与修正
回测时重点看两类问题：一是同一事件不同人判出不同级别，说明判定条件有歧义，需要补充可观察依据；二是级别与动作不匹配，例如P2的恢复目标短于实际跨团队协同所需时间，说明时限需要按真实处理链路调整。回测结论写成简短记录，列明修改了哪条判定条件或哪个时限，作为机制版本的一部分。上线后前三个月每月复查一次定级准确率和升级及时率，稳定后转为季度复查。
常见问题
分级标准写好了，但值班人员对同一事件仍判出不同级别，怎么处理？
先定位歧义来源。常见原因有两类：判定条件用了“严重影响”“较大范围”这类无法核对的措辞，或某个维度缺少对应的工单字段。处理办法是把判定条件改写成可观察的事实，例如把“影响较大”改成“全部外部客户无法下单”，并为影响范围、业务系统、替代方案说明、承诺关联设置必填字段，让定级变成对照填写。同时保留“判定存疑先按高一级响应、事后复盘修正”的规则，避免值班人员在压力下反复讨论。
P2事件处理到一半影响面扩大，应该逐级升到P1还是直接跨级？
直接跨级。跨级处理的条件是调查中确认影响面更大或出现新的风险事实，例如从单团队受阻扩大到多团队、出现数据丢失或合规风险。跨级时由事件负责人确认并通知对应级别的通报对象，在事件记录中写明跨级依据和时间，不必逐级上升。升级后通报频率、资源投入和决策权限同步切换到新级别的要求。
小团队人手有限，四个响应角色能否合并？
可以合并岗位，但每个级别下的职责要写清。常见做法是一线受理人兼任业务沟通人，技术处理人兼任事件负责人，P3、P4由一人完成登记、初判和答复。需要保留的是升级决定权和代班安排：写明谁在值班负责人缺席时行使升级决定权，哪些动作必须上报，例如数据恢复方案变更或对外公告发布。合并后仍要在角色矩阵中标注每个级别由谁承担，避免P1事件因找不到决策人而停滞。
响应时限和恢复目标应该按什么口径设定？
两者分开设定。响应时限指从事件登记到有人接手并给出初步判断的时间，恢复目标指从登记到服务恢复的时间，分开可以避免把“有人看了”当成“已经处理”。数值结合自身对外服务承诺和真实处理链路确定：P1、P2的恢复目标要留出升级和跨团队协同的余量，P3、P4可按工作日计算。回测时如果发现某级恢复目标短于实际跨团队协同所需时间，应按真实链路调整，而不是压缩处理步骤。
机制上线后，复盘和问题治理怎么衔接？
在动作表中写明转问题单的条件：复盘确认存在根因且需要长期治理的，转为问题跟踪，明确责任人和整改期限。P1、P2在恢复后规定工作日内完成复盘报告，P3视重复发生情况决定是否复盘，P4不单独复盘。问题单要能关联到研发侧工作项持续跟踪直至关闭，复盘文档归档供后续值班查阅。上线核对时确认这一衔接方式已写入制度，并有对应的记录位置。
