判断一个服务事件是否属于重大事件，核心看它对业务的影响范围与严重程度、受影响用户与关键服务的规模、是否造成收入或合规损失、恢复是否超出常规处置时限，以及是否需要跨团队协同和对外沟通。把这些条件写成可勾选的分级标准，并规定谁在什么时点做判定、判定后触发哪些动作，就能把“凭感觉升级”变成可复核的机制。本文给出判定标准表、从发现到定级的流程分工、与普通事件和问题管理的边界，以及上线后的校准清单。
要点总览（TL;DR）
- 重大事件判定建议从业务影响、规模、时间、协同四个维度写条件，每条落到可勾选的阈值或明确对象，并区分“满足任一即升级”与“需同时满足”两类逻辑。
- 判定流程要明确一线受理人初筛、值班负责人或事件经理复核定级、技术负责人组织恢复、沟通角色对内对外通报，并规定首次响应后给出定级结论的时限。
- 普通服务事件按常规流程处理，重大事件进入专项协同与高频通报，事件恢复后的根因跟踪转入问题管理，软件缺陷修复归缺陷管理，三者分开记录。
- 阈值松紧靠案例校准：影响面小的请求频繁被升级说明条件太宽，核心链路故障曾被当作普通事件说明条件太模糊，定期回看误判与漏判案例再调整。
- 机制上线后按清单自检：维度是否齐全、角色是否清楚输入输出、定级依据能否回溯、整改项是否转入问题管理跟踪。
重大事件的判定标准怎么写
重大事件的标准要能回答“凭什么算重大”。写法上建议分四个维度展开，每个维度落到可勾选的条件，并标注该条件是单独触发升级，还是需要与其他条件同时满足。阈值必须写具体数字或明确对象，例如“受影响付费用户超过5000”或“核心交易链路不可用”，避免“影响较大”“比较严重”这类无法复核的表述。
四个维度的分工如下：影响维度判断业务受损的性质，规模维度判断波及面，时间维度判断是否突破服务承诺，协同维度判断处置是否超出单一团队能力。前三个维度通常单独触发升级，协同维度多作为辅助判断或与影响维度组合使用。
| 维度 | 可勾选条件 | 阈值示例 | 是否单独触发升级 |
|---|---|---|---|
| 业务影响 | 核心业务链路中断或关键服务不可用 | 下单、支付、登录等核心链路任一不可用 | 是 |
| 业务影响 | 存在数据丢失、资金差错或安全暴露风险 | 出现客户数据外泄迹象或账务金额不一致 | 是 |
| 业务影响 | 触及合规或监管报告义务 | 涉及需按监管要求限时上报的事件类型 | 是 |
| 规模 | 受影响用户数超过阈值 | 受影响用户超过5000人或超过付费客户的10% | 是 |
| 规模 | 涉及高等级客户或关键行业客户 | 涉及战略客户、SLA约定高赔付等级的客户 | 是 |
| 规模 | 波及多个区域或多个系统 | 影响2个以上区域或3个以上关联系统 | 否，与业务影响组合判断 |
| 时间 | 持续时长超过阈值 | 核心服务中断超过30分钟仍未恢复 | 是 |
| 时间 | 突破服务目标承诺的恢复时限 | 超过SLA约定的恢复时间点 | 是 |
| 协同 | 需要跨团队、跨供应商联合处置 | 需3个以上团队或外部供应商介入 | 否，与业务影响或规模组合判断 |
| 协同 | 需要对外公告或客户主动通知 | 需向客户发布故障说明或媒体回应 | 是 |
表中阈值是示例口径，落地时要按自身服务目录、客户结构和SLA条款替换。写标准时还要明确“满足任一即升级”的条件清单，以及“需同时满足”的组合条件，例如“波及多系统且已持续超过30分钟”才升级。两类逻辑分开列，值班人员初筛时才能快速判断。
从发现到定级：判定流程与角色分工
标准写好之后，需要规定谁在什么时点做判定。建议把流程拆成上报、复核定级、协同处置、通报、恢复确认五段，每段有明确输入、动作、输出和完成标志。定级结论必须在首次响应后的固定时限内给出，例如30分钟内完成初判并记录，影响面不明的先按重大事件预案响应，确认后再调整等级。
| 步骤 | 输入 | 动作 | 输出 | 负责人 | 完成标志 |
|---|---|---|---|---|---|
| 1. 受理上报 | 用户报障、监控告警 | 记录现象、时间、初步影响面，按标准初筛 | 事件记录与初判结论 | 一线受理人 | 事件已登记，初判结论已填写 |
| 2. 复核定级 | 事件记录、初判结论 | 对照判定标准复核，宣布是否定为重大事件及等级 | 定级结论与判定依据 | 值班负责人或事件经理 | 定级结论已记录，依据可追溯 |
| 3. 拉起协同 | 定级结论 | 通知相关团队与供应商，建立统一处置通道 | 协同名单与处置分工 | 事件经理 | 各团队确认接手，分工明确 |
| 4. 组织恢复 | 故障现象与日志 | 定位原因、执行恢复动作、同步进展 | 恢复方案与进展记录 | 技术负责人 | 服务恢复或降级方案生效 |
| 5. 对内对外通报 | 定级结论与进展 | 按口径对内通报，必要时对外公告 | 通报记录与公告稿 | 沟通角色 | 通报已发出，口径一致 |
| 6. 恢复确认与降级 | 监控数据与业务验证 | 确认影响消除，判断是否降级或关闭 | 关闭或降级记录 | 事件经理 | 业务方确认恢复，状态已更新 |
定级不是一次性的。处置过程中影响面扩大、出现数据风险或突破SLA时限时，事件经理应主动升级等级；影响面确认小于初判、有稳定绕行方案时，可以降级，但降级同样要记录依据。升级和降级都走同一套记录，避免事后无法还原判断过程。
事件定级后的记录、协同与状态流转，可以借助工单与工作项工具承载。ONES Desk 提供事件管理及问题管理能力，工单可直接关联到待办事项列表，打通服务团队和研发团队的跨部门协同；同时支持评估和定义工单优先级，优先解决紧急事件。把定级结论、判定依据和处置进展记录在工单上，各角色在同一处更新状态，复盘时能直接回溯当时的判断条件。
重大事件与普通事件、问题管理的边界
并非所有异常都要升级为重大事件。边界不清会导致两个后果：该升级的没升级，或者大量普通事件占用专项协同资源。区分的关键是看对象归属和触发条件，而不是看处理难度。
| 对象 | 触发条件 | 归属流程 | 产出 |
|---|---|---|---|
| 普通服务事件 | 影响可控，有既定处置路径和绕行方案 | 常规事件流程，按优先级排队处理 | 事件关闭记录 |
| 重大事件 | 满足判定标准中的任一单独触发条件或组合条件 | 专项协同流程，高频通报，事件经理统一指挥 | 定级记录、处置记录、对外通报 |
| 问题管理 | 事件恢复后需要跟踪根因与整改 | 问题管理流程，独立于事件本身 | 根因分析、整改项与验证结果 |
| 缺陷修复 | 确认由软件缺陷引起 | 缺陷管理流程 | 缺陷单与修复版本 |
几个容易混淆的点需要说明。事件恢复后的根因跟踪归入问题管理，与事件定级分开记录，重大事件的定级结论不因后续转入问题管理而改变。软件缺陷修复归缺陷管理，本文不展开具体修复流程。重大事件处置中的通报、复盘属于事件处理过程中的动作，复盘产出整改项后才转入问题管理跟踪，这些协同活动本身不改变事件定级。
事件与问题之间的衔接需要留痕。ONES Desk 支持工单一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成，也可一键关联到 ONES Wiki 页面记录并分析问题、沉淀服务经验。这样事件关闭后，根因整改和缺陷修复有独立载体，事件记录仍保留原始定级依据。
判定示例：三个事件如何定级
以下为演示情景，用于说明标准如何套用，阈值按前文示例口径。
示例一：核心支付接口短时不可用。监控告警显示支付接口返回错误率骤升，持续约20分钟。命中的标准：业务影响维度“核心业务链路中断”，单独触发升级；规模维度受影响用户数超过阈值，同样单独触发。由值班负责人在首次响应后10分钟内复核并宣布为重大事件，事件经理拉起支付、网关、数据库三个团队协同，沟通角色向客服同步口径并准备对外公告。服务恢复后确认影响消除，关闭事件，根因分析转入问题管理。
示例二：单个内部用户报表加载缓慢。一名内部用户反馈报表页面打开慢，其他用户正常，且有导出替代方式。逐条对照：未命中核心链路中断，受影响用户数远低于阈值，未突破SLA恢复时限，无需跨团队和对外沟通。一线受理人初判为普通事件，按常规流程处理，记录现象后由对应支持人员跟进。此例说明阈值要能挡住影响面小的请求，避免专项资源被占用。
示例三：某服务间歇性报错，影响面暂不明确。监控出现间歇性报错，尚无法判断影响用户范围和是否涉及核心链路。此时按重大事件预案响应：值班负责人先宣布进入重大事件响应状态，拉起相关团队排查，同时并行确认影响面。30分钟内确认仅影响非核心功能且已有绕行方案，事件经理依据记录将等级降为普通事件，保留已完成的协同动作记录。此例说明“先响应、后校准”的处理方式，以及降级同样需要依据和记录。
三个例子对照可以看出阈值松紧的校准方向：如果示例二这类事件频繁被升级，说明规模阈值或业务影响条件写得太宽；如果示例一这类事件曾被当作普通事件处理，说明核心链路的判定条件需要写得更明确。定期回看误判和漏判案例，比一次性把标准写完美更有效。
上线后的完成检查与校准
判定机制上线后，需要定期检查它是否真的可执行、可复核。以下清单可作为自检依据，建议每季度或每次重大事件复盘后过一遍。
- 判定标准是否覆盖业务影响、规模、时间、协同四类维度，每条条件是否有明确阈值或明确对象。
- “满足任一即升级”与“需同时满足”两类条件是否分开列明，值班人员能否在初筛时直接对照勾选。
- 一线受理人、值班负责人或事件经理、技术负责人、沟通角色是否清楚各自的输入、动作和完成标志。
- 定级结论是否有记录，判定依据能否回溯，升级和降级是否都留下记录。
- 是否定期复核误判与漏判案例，并据此调整阈值或补充条件。
- 复盘产出的整改项是否转入问题管理跟踪，并有责任人和完成时间。
检查中发现的问题要落到具体修改动作：阈值不合理就改数字，角色不清就补职责说明，记录缺失就在工单字段中增加必填项。ONES Desk 支持自定义工单属性与工单内容，可灵活调整工作流以适应不同企业的工作方式，便于把定级字段、判定依据和升级记录做成工单上的固定项；其管理者视角可汇总工单处理情况、了解处理进度，工单分析报表用于掌握团队表现，为定期校准提供数据参考。具体可配置项以实际产品为准。
机制运行一段时间后，还可以用数据反向检验标准：统计一段时间内被定为重大事件的数量、升级与降级的比例、从发现到定级的平均耗时。如果定级耗时明显超出规定时限，说明标准太复杂或角色授权不清；如果重大事件数量异常偏多或偏少，说明阈值需要重新校准。校准结果要更新到标准文档并通知所有相关角色，保持判定口径一致。
常见问题
影响面一时判断不清时，应该先定级还是先排查？
建议先按重大事件预案响应，再并行确认影响面。值班负责人可以先宣布进入重大事件响应状态，拉起相关团队排查，同时安排人确认受影响用户范围、是否涉及核心链路。在约定时限内（例如30分钟）给出影响面结论后，再依据记录决定维持等级还是降为普通事件。降级同样要写明依据，保留已完成的协同动作记录，这样既不会因等待确认而延误处置，也能避免事后无法还原判断过程。
重大事件恢复后，定级记录还需要保留吗？
需要保留。事件恢复后根因跟踪转入问题管理，但事件本身的定级结论、判定依据、升级与降级记录应继续留在事件记录中，不因转入问题管理而改变或删除。这样复盘时能对照当时的条件判断定级是否合理，也为后续校准阈值提供依据。整改项在问题管理中单独跟踪，与事件记录相互关联即可。
阈值应该定多严，定得太严或太松各有什么表现？
阈值没有统一标准，要看自身服务目录、客户结构和SLA条款。判断松紧可以观察两类信号：如果影响面小、有绕行方案的请求频繁被升级为重大事件，说明规模或业务影响条件写得太宽，专项协同资源被占用；如果核心链路中断这类事件曾被当作普通事件处理，说明关键服务的判定条件写得太模糊。定期统计重大事件数量、升级与降级比例、从发现到定级的平均耗时，结合误判漏判案例调整，比一次性把标准写完美更有效。
判定标准由谁维护，多久调整一次？
通常由事件经理或服务管理负责人牵头维护，技术负责人和沟通角色参与评审。调整时机可以固定在每季度，也可以在每次重大事件复盘后顺带检查。调整内容包括阈值数字、条件表述、角色职责和记录字段。修改后要更新标准文档并通知所有相关角色，保持判定口径一致；如果调整涉及工单字段，同步在工具中更新必填项，避免记录缺失。
用工具承载定级记录时，重点要配置哪些内容？
重点是把定级结论、判定依据、升级与降级记录做成工单上的固定字段，并让相关角色在同一处更新状态。ONES Desk 支持自定义工单属性与工单内容，可灵活调整工作流以适应不同企业的工作方式；工单可直接关联到待办事项列表，打通服务团队和研发团队的跨部门协同；事件关闭后还可一键关联到 ONES Project 的需求或缺陷工作项，或关联到 ONES Wiki 页面记录分析过程。具体可配置项以实际产品为准。
