服务事件分级标准模板的核心是一张分级矩阵：先定义P1–P4或S1–S4等级，再为每个等级写明影响范围、业务影响、响应时限、恢复目标、升级路径和通知对象，最后附上判定规则与填写示例。本文提供三张可直接复制的空白表、逐字段填写口径、必填与选填清单，以及一次登录故障的完整填写示范，适用于需要统一事件受理与升级依据的服务团队。
要点总览（TL;DR）
- 模板主体由三张表构成：等级定义表、事件受理登记表、分级判定规则表，复制后先填等级定义再投入使用。
- 等级定义表的关键字段包括等级编号、影响范围、业务影响、响应时限、恢复目标、升级路径和通知对象，其中响应时限约束接手速度，恢复目标约束业务可用时间。
- 必填项按“缺了就无法分级或无法追责”划分：登记表缺事件编号、发生时间、初判等级或处置负责人时不予受理。
- 初判与复核等级不一致属于正常流程，需在登记表中记录调整依据，升级与通知动作随等级变化自动触发。
- 模板启用前由服务台、业务代表和运维负责人共同评审，修订时维护版本号，重复事件按触发条件转为问题单跟踪。
可复制空白模板：服务事件分级矩阵
以下三张表构成模板主体。第一张定义等级，第二张登记单次事件，第三张固化判定规则。复制到文档或表格工具后，先填等级定义表，再投入使用登记表，判定规则表随评审补充。
表一：等级定义表
| 等级编号 | 等级名称 | 影响范围 | 业务影响 | 典型示例 | 响应时限 | 恢复目标 | 升级路径 | 通知对象 | 判定负责人 |
|---|---|---|---|---|---|---|---|---|---|
| P1 | |||||||||
| P2 | |||||||||
| P3 | |||||||||
| P4 |
表二：事件受理登记表
| 事件编号 | 发生时间 | 上报人 | 影响系统 | 影响用户范围 | 初判等级 | 复核等级 | 处置负责人 | 状态 |
|---|---|---|---|---|---|---|---|---|
表三：分级判定规则表
| 判定条件 | 对应等级 | 判定依据 | 例外说明 |
|---|---|---|---|
字段说明：每个字段填什么、怎么判断
同一张表由不同人填写时，结果是否一致取决于字段口径是否写清楚。下表逐字段说明含义与填写方法，团队可将其作为填表说明附在模板之后。
| 字段 | 填写口径 | 判断方法 |
|---|---|---|
| 等级编号 | 采用固定前缀加数字，如P1–P4或S1–S4，数字越小等级越高 | 编号一经确定不再随意增删，新增等级排在末尾并注明启用日期 |
| 等级名称 | 用简短词语概括该等级的性质，如“重大故障”“一般事件” | 名称与编号一一对应，避免同一编号出现两种叫法 |
| 影响范围 | 描述受影响的系统、服务、区域或用户群体，写清范围边界 | 按“哪些系统、哪些用户、覆盖多大比例”回答，用可核对的事实描述 |
| 业务影响 | 描述业务中断造成的后果，如交易无法完成、对外服务不可用 | 从业务视角判断严重程度，与影响范围分开填写，范围大不等于影响重 |
| 响应时限 | 从事件上报到有人开始处置的时间上限 | 响应指开始处置，不要求此时业务已恢复 |
| 恢复目标 | 从事件发生或上报到业务恢复可用的时间目标 | 恢复指业务可用，与响应时限分别设定，二者不可混用 |
| 升级路径 | 写明升级到谁、通过什么方式、在什么时点触发 | 按“一线→二线→负责人”的顺序填写角色，而非具体人名 |
| 通知对象 | 列出该等级需要通知的角色或部门 | 与升级路径区分：通知是告知，升级是转移处置责任 |
| 判定负责人 | 填写有权确认等级的岗位 | 通常为值班负责人或服务台主管，复核角色单独设置 |
| 典型示例 | 写一到两个该等级的常见事件场景 | 示例用于帮助初判，不作为唯一判定依据 |
影响范围与业务影响是最容易混淆的两个字段。前者回答“坏了多大一片”，后者回答“坏了之后业务损失什么”。例如某报表系统不可用，影响范围可能只涉及财务部门，但恰逢月末结账，业务影响可判定为高。两个字段分开填写，分级时才能同时权衡。
响应时限与恢复目标的区别同样需要在模板中写明。响应时限约束的是“多久有人接手”，恢复目标约束的是“多久业务能用”。P1事件可以要求15分钟内响应、2小时内恢复，两个数字分别考核不同环节。判定负责人负责初判，复核角色在事件受理后确认或调整等级，两者分开设置可以降低单人误判的风险。
必填与选填：哪些字段不能空
字段全部必填会拖慢受理速度，全部选填又会导致关键信息缺失。建议按“缺了就无法分级或无法追责”的标准划分必填项。
| 所在表 | 必填字段 | 选填字段 |
|---|---|---|
| 等级定义表 | 等级编号、影响范围、响应时限、恢复目标、升级路径 | 典型示例、通知对象、判定负责人 |
| 事件受理登记表 | 事件编号、发生时间、影响范围、初判等级、处置负责人 | 复核等级、影响系统、关联问题单号 |
| 分级判定规则表 | 判定条件、对应等级 | 判定依据、例外说明 |
必填项缺失时的处理约定应写入模板说明：登记表缺少事件编号或发生时间，服务台不予受理，退回上报人补齐；初判等级缺失时，由值班负责人按判定规则表先行判定并记录，事后补录依据；等级定义表中响应时限或恢复目标为空，该等级视为未启用，不得在受理中使用。选填字段允许留空，但复核等级一旦填写，须与初判等级不同的原因一并记录。
填写示例：一次登录故障事件的完整分级
以下为演示情景，用于说明各字段如何落地，数值仅作示范，团队应按自身业务设定。
背景：某业务系统在上午出现登录失败，部分用户无法进入系统，已登录用户操作正常。服务台接到多个用户上报后登记事件。
| 字段 | 填写结果 |
|---|---|
| 事件编号 | INC-20240612-0031 |
| 发生时间 | 2024-06-12 09:20 |
| 上报人 | 客服组值班人员 |
| 影响系统 | 业务系统登录模块 |
| 影响用户范围 | 约三成外部用户无法登录，内部用户不受影响 |
| 初判等级 | P2 |
| 复核等级 | P1 |
| 处置负责人 | 应用运维组当班工程师 |
| 状态 | 处置中 |
初判为P2的依据是影响范围限于登录模块、已登录用户不受影响。复核时发现该时段为业务高峰，登录失败直接导致外部用户无法下单，业务影响上升，复核角色依据判定规则表将等级调整为P1，并在登记表备注调整原因。等级调整后，按P1的升级路径通知应用负责人与业务负责人，并按P1恢复目标跟踪处置进度。
这个示例说明两点：初判与复核不一致属于正常流程，关键是记录调整依据；升级与通知由等级触发，等级变化后动作随之变化，不需要另行审批。
调整与维护：让分级标准随业务变化更新
模板首次启用前，应由服务台、主要业务部门代表和运维负责人共同评审，重点确认等级数量、各等级的影响范围描述和时限是否与业务承受能力匹配。评审记录随模板一并归档，作为后续修订的起点。
出现以下情况时考虑调整：业务新增关键系统，原有影响范围描述覆盖不到；连续多个事件在初判与复核间反复调整，说明判定条件表述不清；响应时限或恢复目标长期无法达成或明显宽松。调整等级数量应谨慎，增删等级会影响历史数据可比性，优先修订判定条件和时限数值。
修订记录建议包含版本号、修订日期、修订内容、修订人和生效日期，模板文件按版本号命名保存，旧版本保留备查。每次修订后同步更新字段说明与填写示例，避免模板与说明脱节。
分级标准还需要与问题管理衔接：同一类事件在一定周期内重复发生，或单次事件虽已恢复但根因未明，应转为问题单跟踪。可在登记表中保留关联问题单号字段，作为事件与问题的连接点。触发条件建议写入判定规则表的例外说明，例如“同一系统同类事件30天内出现三次，转问题管理”。
当分级标准从文档落到日常受理流程时，工单系统承担字段承载与状态流转。ONES 的工单管理支持自定义字段与状态流转，可将等级、影响范围、处置负责人等字段配置为工单属性，按等级设置通知与升级规则，事件转问题时关联到问题单，使模板中的判定规则在系统中直接执行，减少人工对照表格的环节。
常见问题
服务事件分级用P1–P4还是S1–S4，等级数量定几级合适？
两种编号方式都常见，P前缀多用于事件优先级，S前缀多用于严重度，选一种并在模板中固定下来即可，关键是数字越小等级越高、编号与名称一一对应。等级数量建议从四级起步：多数团队的事件分布能落在“重大、较大、一般、轻微”四档内，再细分会让初判变慢、复核争议增多。如果业务线单一、事件量不大，三级也够用；等级增删会影响历史数据可比性，优先调整判定条件和时限数值。
初判等级和复核等级不一致时，以哪个为准，需要走审批吗？
以复核等级为准。初判由受理人按判定规则表快速给出，复核由单独设置的复核角色在受理后确认或调整，两者分开是为了降低单人误判风险。等级调整不需要另行审批，但要在登记表中记录调整原因，例如影响范围扩大或恰逢业务高峰导致业务影响上升。等级变化后，升级路径和通知对象按新等级执行，处置负责人按新等级的恢复目标跟踪进度。
响应时限和恢复目标能不能合并成一个字段？
不建议合并，两者考核不同环节。响应时限约束的是从事件上报到有人开始处置的时间上限，此时业务可能仍未恢复；恢复目标约束的是从事件发生或上报到业务恢复可用的时间。合并后无法区分“没人接手”和“接手了但没修好”两类问题，复盘时也缺少判断依据。填写时两个数值分别设定，例如P1可要求15分钟内响应、2小时内恢复。
模板填好后放在文档里，怎么保证日常受理时真的按等级执行？
文档模板解决的是标准定义问题，日常执行需要工单系统承载字段与流转。可以把等级、影响范围、处置负责人配置为工单属性，按等级设置通知与升级规则，事件转问题时关联问题单，让判定规则在系统中直接触发。ONES 的工单管理支持自定义字段与状态流转，可作为承载方式之一；选型时重点确认字段能否按等级配置通知规则、事件与问题能否关联。模板与系统字段保持一致，避免两套口径。
同一类事件反复出现，什么时候该从事件转为问题管理？
建议把触发条件写进判定规则表的例外说明，常见口径是同一系统同类事件在一定周期内重复出现，或单次事件已恢复但根因未明。例如“同一系统同类事件30天内出现三次，转问题管理”。登记表中保留关联问题单号字段作为连接点，转问题时把事件编号一并带入，便于后续追溯。周期和次数阈值按团队事件量设定，事件量大的团队可适当收紧。
