重大事件处置流程可以按“识别与上报—定级与启动—跨团队协同处置—恢复确认—复盘与问题治理”五个阶段组织，每个阶段都要写明触发条件、负责人、输入材料、输出记录和完成标志。核心角色包括事件上报人、一线值班、事件经理、技术负责人、业务或客服接口人、沟通负责人，重大事件还需指定决策人。本文围绕阶段、角色和记录字段给出可执行的设计方法，并在记录与协同环节说明ONES Desk能承载的管理动作。
要点总览（TL;DR）
- 重大事件处置按“识别与上报—定级与启动—跨团队协同处置—恢复确认—复盘与问题治理”五个阶段组织，前一阶段的输出记录就是后一阶段的输入。
- 核心角色包括事件上报人、一线值班、事件经理、技术负责人、业务或客服接口人、沟通负责人和决策人；事件经理与决策人分开设置，并各自安排替补。
- 记录字段固化在事件单模板中：基础信息、影响评估、处置时间线、升级与通知、恢复确认、关联问题单，处置记录采用追加式写法。
- 恢复确认需要业务侧验证与监控指标双确认；复盘产生的改进项逐条登记为问题单，指定责任人和期限。
- 流程落地检查重点看定级标准是否可判定、角色是否落实到人、记录字段是否固化、是否有演练与回顾机制。
重大事件处置的五个阶段与关键动作
流程设计的起点是把“先恢复服务、再治理复发风险”落到阶段划分上。五个阶段之间用明确的完成标志衔接：前一阶段的输出记录，就是后一阶段的输入。缺少完成标志，事件容易在口头沟通中推进，交接时无人能说清当前进展。
| 阶段 | 关键动作 | 输入 | 输出 | 完成标志 |
|---|---|---|---|---|
| 识别与上报 | 确认异常超出日常处理范围，通过值班渠道或事件入口上报，填写首条记录 | 监控告警、用户反馈、业务侧异常报告 | 事件单初稿：发现时间、现象、影响范围、上报人 | 事件单已创建并通知一线值班 |
| 定级与启动 | 按定级标准判定严重级别，达到启动条件后召集事件经理、技术负责人和决策人 | 事件单初稿、影响面信息、历史同类事件 | 定级结论、启动通知、处置群或会议、角色到位记录 | 事件经理确认接手，处置小组集合完毕 |
| 跨团队协同处置 | 按系统或业务模块分工排查，记录每次动作与结果，临时方案需走变更控制 | 定级结论、分工安排、监控与日志数据 | 处置时间线记录、临时方案及审批记录、升级记录 | 服务指标出现恢复迹象，临时方案生效 |
| 恢复确认 | 业务侧验证核心功能，监控侧确认指标回到基线，对外更新状态 | 处置记录、监控面板、业务验证清单 | 恢复确认记录：验证人、验证方式、恢复时间、对外通知版本 | 业务与监控双方确认恢复，对外口径已发布 |
| 复盘与问题治理 | 在约定时限内复盘，分析根因，把改进项登记为问题单并指定责任人与期限 | 完整处置记录、恢复确认记录、监控数据 | 复盘报告、根因结论、问题单及改进项清单 | 改进项全部有责任人和截止日期，问题单进入跟踪 |
识别与上报：把首条记录写完整
触发条件应写成可判断的描述，例如核心交易成功率低于约定阈值、关键页面连续多次探测失败、多个用户在同一时段报告同一故障。上报渠道保持单一入口，避免同时走群聊、电话和邮件导致记录分散。首条记录至少包含发现时间、现象描述、受影响的功能或区域、初步影响面、上报人和联系方式，这些信息直接决定后续定级是否准确。
定级与启动：定级依据要可判定
定级依据通常组合影响范围、业务损失程度和持续时间三个维度，并为每个级别写明启动条件，例如达到某级别必须召集哪些角色、在多长时间内响应。定级存在争议时，由决策人裁决并记录理由，避免在处置过程中反复讨论级别。事件经理到位后接管节奏，决策人负责资源调配和对外重大决策。
跨团队协同处置：记录与变更控制同步进行
处置小组按系统边界或业务链路分工，每个分支指定一名负责人，统一向事件经理回报。每次尝试都记录时间点、动作、执行人和结果，失败的尝试同样保留，它们是复盘时判断根因的重要线索。临时方案涉及配置修改、流量切换或数据修复时，按变更控制要求留下审批记录和回滚方案，防止处置动作本身引入新故障。
恢复确认：业务与监控双确认
监控指标回到基线只是必要条件，还需业务侧按验证清单确认核心功能可用，例如完成一笔真实交易、核对关键数据一致性。验证人、验证方式和恢复时间写入事件单。对外状态更新使用统一口径，说明当前恢复情况、仍受影响的范围和下一次更新时间。
复盘与问题治理：把复发风险交出去
复盘时点建议在恢复后约定工作日内完成，避免细节遗忘。复盘聚焦根因分析和改进项，改进项分为技术修复、监控补强、流程调整三类，逐条登记为问题单，指定责任人和期限。事件单在此阶段与问题单建立关联，形成从服务恢复到问题治理的完整链路。
各角色职责与交付物划分
角色设计的目的是让每个动作都有明确负责人，同时避免同一件事多人负责却无人交付记录。下表按角色列出职责边界、决策权限和必须留下的记录。
| 角色 | 职责边界 | 决策权限 | 交付物 |
|---|---|---|---|
| 事件上报人 | 发现异常并提交首条记录，配合补充现场信息 | 无 | 事件单初稿、现象截图或日志片段 |
| 一线值班 | 初步核实、过滤误报、按定级标准初判并通知相关角色 | 按标准初判级别 | 核实记录、初判级别、通知记录 |
| 事件经理 | 统筹处置节奏、组织分工、控制升级、维护处置记录 | 决定处置优先级与会议节奏 | 处置时间线、升级记录、复盘组织 |
| 技术负责人 | 判断技术方向、分配排查任务、审核临时方案 | 技术方案取舍 | 排查结论、临时方案及回滚方案 |
| 处置小组成员 | 执行具体排查与修复动作，回报结果 | 无 | 动作记录、执行结果 |
| 业务/客服接口人 | 提供业务影响信息、组织业务侧验证、反馈用户诉求 | 业务影响判断 | 影响面说明、业务验证结论 |
| 沟通负责人 | 统一对外口径、按节奏发布状态更新 | 对外表述版本 | 通知记录、口径版本 |
| 决策人 | 裁决定级争议、调配资源、决定重大取舍 | 升级裁决与资源调配 | 裁决记录、资源调配指令 |
事件经理与决策人应分开设置：事件经理负责推进流程和信息汇聚，决策人对争议和资源做最终判断。技术负责人专注技术判断，不承担对外沟通，避免注意力被分散。业务或客服接口人与沟通负责人可以由同一人兼任，但对外口径必须经过决策人确认后发布。
角色兼任与缺席安排需要在流程文件中提前写明。常见做法是为事件经理、技术负责人和决策人各设一名替补，替补名单随值班表更新；跨时区或节假日期间，明确由当班值班长代行事件经理职责，直到正式人员到位。替补人员同样需要具备相应权限，否则会出现“名义到位、无法操作”的情况。
重大事件记录与交接的字段设计
记录字段的价值在于让未参与处置的人也能读懂事件进展并接手。字段应固化在事件单模板中，而不是依赖个人在文档里自由书写。以下字段清单可作为事件单设计的基础。
| 字段类别 | 字段 | 填写要求 |
|---|---|---|
| 基础信息 | 事件编号、标题、发现时间、上报人、上报渠道 | 创建时自动生成或必填 |
| 影响评估 | 影响范围、受影响用户或业务量、严重级别、定级依据 | 定级时填写，级别变更需记录原因 |
| 状态 | 当前状态、当前负责人、下一次更新时间 | 状态变更即更新 |
| 处置记录 | 时间点、动作、执行人、结果、下一步 | 每次关键动作追加一条，不覆盖历史 |
| 升级与通知 | 通知对象、通知时间、口径版本、发布渠道 | 每次对外发布留痕 |
| 恢复确认 | 验证人、验证方式、恢复时间、遗留问题 | 业务与监控双方确认后填写 |
| 关联信息 | 关联问题单、关联变更单、关联复盘文档 | 复盘完成后补齐 |
处置记录采用追加式写法，每条记录包含时间点、动作、执行人、结果和下一步，交接时新负责人从最后一条记录即可判断当前进展。升级与通知记录保留口径版本，便于事后核对对外表述是否一致。恢复确认字段中的验证方式要写具体，例如“完成三笔真实支付并核对账务”，而不是只写“已恢复”。
当组织使用工单系统承载事件记录时，字段设计需要与系统配置对应。ONES Desk 支持自定义工单属性与工作流，可按上述字段类别配置事件单模板，并通过优先级设置区分紧急事件；工单可关联到 ONES Project 的工作项，便于把复盘产生的改进项交给研发团队持续跟踪，也可关联 ONES Wiki 页面沉淀复盘结论与服务经验。具体字段配置范围和版本能力以实际环境为准。
示例：一次支付中断事件的处置过程
以下为演示情景，用于说明阶段、角色与输入输出如何衔接，不代表真实案例。
| 时间 | 阶段 | 角色与动作 | 输入与输出 |
|---|---|---|---|
| 10:02 | 识别与上报 | 监控告警显示支付成功率下降，一线值班核实后创建事件单 | 输入：告警与用户反馈；输出：事件单初稿，含发现时间、影响功能、初步影响面 |
| 10:08 | 定级与启动 | 一线值班按标准初判为最高级别，通知事件经理、技术负责人、决策人；事件经理确认接手并组建处置群 | 输入：事件单初稿；输出：定级结论、启动通知、角色到位记录 |
| 10:15 | 协同处置 | 技术负责人按支付网关、账务、下游渠道分工；处置小组分别排查，事件经理每十分钟汇总一次 | 输入：分工安排与监控数据；输出：处置时间线，记录各分支动作与结果 |
| 10:40 | 协同处置 | 定位为下游渠道超时，技术负责人提出切换备用通道的临时方案，经决策人批准后执行 | 输入：排查结论；输出：临时方案、审批记录、回滚方案 |
| 10:52 | 恢复确认 | 业务接口人完成真实支付验证，监控确认成功率回到基线；沟通负责人发布恢复通知 | 输入：处置记录与监控面板；输出：恢复确认记录、对外通知版本 |
| 次日 | 复盘与问题治理 | 事件经理组织复盘，技术负责人给出根因结论，改进项登记为问题单并指定责任人 | 输入：完整处置记录；输出：复盘报告、问题单及改进项清单 |
这个示例中，每个交接点都有对应记录：一线值班交给事件经理的是定级结论和事件单，技术负责人交给决策人的是临时方案与回滚方案，业务接口人交给沟通负责人的是验证结论。复盘时，改进项包括下游渠道超时监控补强和备用通道切换演练，两项都进入问题单跟踪，事件单与问题单建立关联。
流程落地检查与常见缺口
流程文件写完不等于可运行。以下检查清单用于逐项核对，每项都应有明确的是否判断依据。
- 定级标准是否可判定：每个级别是否有具体的影响范围或指标阈值，定级争议是否有裁决人和裁决记录方式。
- 角色是否落实到人：事件经理、技术负责人、决策人是否对应到具体岗位或人员名单，是否设置替补并同步值班表。
- 记录字段是否固化：事件单模板是否包含基础信息、处置记录、通知记录、恢复确认和关联字段，字段是否必填。
- 恢复确认是否有业务侧参与：验证清单是否覆盖核心业务功能，验证人是否有权确认恢复。
- 复盘改进项是否有责任人和期限：问题单是否逐条登记，是否有跟踪机制和逾期提醒。
- 是否有演练与回顾机制：是否定期开展桌面演练或模拟事件，是否按季度回顾事件数据并修订流程。
常见缺口集中在三处：定级标准写成“影响较大”这类无法判断的表述；角色只写岗位名称，未落实到人，事件发生时临时找人；处置记录散落在群聊中，复盘时无法还原时间线。对应改进方式分别是把定级标准改为可量化条件、维护角色名单与替补表、把记录字段固化到事件单模板并规定追加式填写。流程上线后，建议用一次真实事件或演练检验上述检查项，再根据暴露的问题修订流程文件。
常见问题
重大事件定级出现争议时怎么处理？
在流程文件中预先指定决策人作为定级争议的裁决者，并规定裁决结果和理由要写入事件单。处置过程中先按初判级别启动，避免因反复讨论级别延误恢复；裁决后如需调整级别，记录变更原因和变更时间，后续复盘时据此检查定级标准是否需要修订。
事件经理临时缺席，流程如何继续？
为事件经理、技术负责人和决策人各设一名替补，替补名单随值班表更新，并确保替补人员具备相应权限。跨时区或节假日期间，可由当班值班长代行事件经理职责，直到正式人员到位。代行期间同样要维护处置时间线记录，交接时从最后一条记录说明当前进展。
临时处置方案需要走变更控制吗？
涉及配置修改、流量切换或数据修复的临时方案，建议按变更控制要求留下审批记录和回滚方案。这样既能防止处置动作本身引入新故障，也能在复盘时还原当时的判断依据。审批记录和回滚方案作为处置记录的组成部分，与事件单关联保存。
恢复确认由谁签字，监控指标恢复就够了吗？
监控指标回到基线是必要条件，还需要业务侧按验证清单确认核心功能可用，例如完成真实交易、核对关键数据一致性。验证人、验证方式和恢复时间写入事件单，验证人应具备确认恢复的权限。对外状态更新由沟通负责人使用经决策人确认的统一口径发布。
复盘改进项如何避免停留在文档里？
把改进项分为技术修复、监控补强、流程调整三类，逐条登记为问题单，指定责任人和截止日期，并与原事件单建立关联。跟踪机制中设置逾期提醒，按季度回顾事件数据和改进项完成情况，据此修订流程文件。使用 ONES Desk 时，工单可关联到 ONES Project 的工作项持续跟踪，也可关联 ONES Wiki 页面沉淀复盘结论。
