重大事件跨团队协同处置最容易出问题的环节，往往在交接：上一段处置完了，下一段不知道要接什么、由谁确认、依据哪条记录开工。解决思路是把处置拆成识别定级、协同处置、恢复确认、问题治理四段，逐段定义输入字段、动作、输出交付物和责任人，让上一段的输出直接成为下一段的输入。本文给出可直接套用的字段清单、角色责任表和验收检查项，并说明这类交接记录可以怎样在 ONES 中承载。
要点总览（TL;DR）
- 把重大事件跨团队协同拆成识别定级、协同处置、恢复确认、问题治理四段，每段有明确的起点信号和终点交付物，交接点落在处置目标变化的位置。
- 输入输出按“够下一段用”的原则定义字段：事件单、处置记录与恢复证据、恢复确认单、问题单依次流转，上一段的输出即下一段的输入。
- 交接以字段和状态为准，每个交接点写明确认人、确认方式和状态变化，升级与代班须在事件单登记并签字，未登记的交接视为无效。
- 定义完成后用回填演练和检查清单验收：抽一个历史事件按四段回填，下一段无需补充询问即可开工，才算可用。
- ONES Desk 支持事件管理与问题管理，工单可关联待办事项、ONES Project 工作项与 ONES Wiki 页面，用于承载交接记录，具体字段与流程配置以实际产品配置项为准。
先定四段流程，再逐段定义输入输出
定义输入输出的前提是先划清阶段边界。重大事件从发生到闭环，通常经历四个阶段，每个阶段有明确的起点信号和终点交付物。阶段划分的依据是处置目标的变化：先判断事件有多严重，再集中力量恢复服务，然后确认恢复可信，最后消除复发原因。目标变了，责任角色和交付物随之变化，交接点就落在这两处变化之间。
四段的流转是单向的：上一段的输出物即下一段的输入物。识别定级的输出是事件单，协同处置拿到事件单才能分派任务；协同处置的输出是处置记录与恢复证据，恢复确认据此判断能否宣布恢复；恢复确认的输出是恢复确认单，问题治理据此立项。任何一段的输出字段缺失，下一段就无法直接开工，只能回头补信息，处置时间被拉长。
| 阶段 | 起点 | 终点（交接点） | 交接物 |
|---|---|---|---|
| 识别定级 | 监控告警、用户报障、值班巡检等触发信号出现 | 事件完成定级并指派处置负责人 | 事件单（含级别、影响范围、负责人） |
| 协同处置 | 事件单指派到技术负责人 | 服务指标恢复、处置记录完整 | 处置记录与恢复证据 |
| 恢复确认 | 技术侧提交恢复证据 | 业务侧验证通过并签署确认 | 恢复确认单 |
| 问题治理 | 恢复确认单归档 | 根因查明、改进项关闭 | 问题单及改进项清单 |
这张表是后续字段定义的基础。每个交接点都要回答三个问题：交接物包含哪些必填字段、由谁确认、确认后状态如何变化。三个问题答不清，交接就会退化成口头同步。
每段的关键动作、角色与输入输出字段
字段定义的原则是“够下一段用”：不必穷举所有信息，但下一段开工所需的判断依据必须齐全。下面按四段分别列出动作、角色、输入、输出和完成标志。
识别定级段
这一段的目标是在最短时间内把事件纳入管理并定级。输入是触发信号，包括监控告警、用户报障、值班巡检发现和内部上报；定级依据通常按影响范围（受影响用户数、业务线数量、是否涉及核心交易）和紧急程度（是否持续恶化、有无临时规避手段）两个维度判断。值班负责人负责接单、初判和指派，遇到边界模糊的级别，按“就高”原则先定级，后续可调整但需留痕。
- 输入：触发信号来源、首次发现时间、初步影响描述
- 输出：事件单，必填字段包括事件编号、级别、影响范围、当前状态、值班负责人、技术负责人、业务负责人、沟通协调人
- 完成标志：事件单状态为“已定级”，技术负责人已确认接单
协同处置段
技术负责人接手后，先形成处置方案（临时规避、回滚、扩容、切换等），再按团队拆分任务：每个子任务写明负责团队、预期完成时间、依赖关系。进展同步字段是这一段的核心，要求各团队在固定节奏下更新“已完成动作、当前结论、下一步、阻塞点”，而不是只报“还在处理”。
- 输入：事件单、处置方案、各团队任务分派记录
- 输出：处置记录（时间线、每步操作与结果）、恢复证据（指标曲线、日志片段、验证请求记录）
- 完成标志：服务指标回到正常区间，处置记录时间线完整，恢复证据已提交
恢复确认段
技术指标恢复不等于业务可用。服务负责人组织业务验证：核心交易能否走通、数据是否一致、有无积压需要消化。验证通过后签署恢复确认单，写明恢复时间、验证范围、验证人和遗留观察项。若验证不通过，事件退回协同处置段，状态回退也要记录。
- 输入：恢复证据、业务验证清单
- 输出：恢复确认单（恢复时间、验证结论、验证人、遗留观察项）
- 完成标志：恢复确认单签署，事件状态变为“已恢复”
问题治理段
恢复确认单归档后启动问题治理。输入是事件全过程记录，动作是根因分析（可借助时间线复盘、变更比对、同类事件归并），输出是问题单：根因描述、影响评估、改进项清单（每项含责任人、截止时间、验收方式）。改进项关闭并经复核后，问题单才能关闭。
- 输入：事件单、处置记录、恢复确认单
- 输出：问题单、改进项清单及关闭证据
- 完成标志：全部改进项验收通过，问题单关闭
| 阶段 | 关键动作 | 主责角色 | 输入 | 输出 | 完成标志 |
|---|---|---|---|---|---|
| 识别定级 | 接单、初判、定级、指派 | 值班负责人 | 触发信号、影响初判 | 事件单 | 状态“已定级”，技术负责人接单 |
| 协同处置 | 制定方案、分派任务、同步进展 | 技术负责人 | 事件单、处置方案 | 处置记录、恢复证据 | 指标恢复，证据提交 |
| 恢复确认 | 业务验证、签署确认 | 服务负责人 | 恢复证据、验证清单 | 恢复确认单 | 确认单签署，状态“已恢复” |
| 问题治理 | 根因分析、立项改进、验收关闭 | 问题负责人 | 全过程记录 | 问题单、改进项清单 | 改进项验收通过，问题单关闭 |
角色分工与交付物：谁在哪个节点签字
四段流程涉及五类角色，职责边界要按“决策、执行、验证、沟通”分开，避免一人既处置又验证。事件指挥对整体节奏和升级决策负责；技术负责人对处置方案和恢复证据负责；业务/服务负责人对业务可用性验证负责；沟通协调人对内外部信息发布口径负责；问题负责人对根因与改进闭环负责。
| 交接点 | 交付物 | 确认人 | 确认方式 |
|---|---|---|---|
| 定级完成 | 事件单 | 事件指挥（或授权值班负责人） | 事件单状态变更并留痕，技术负责人回执接单 |
| 处置完成 | 处置记录、恢复证据 | 技术负责人 | 提交恢复证据，记录时间线完整 |
| 恢复确认 | 恢复确认单 | 服务负责人 | 业务验证通过后签署，写明验证范围 |
| 问题立项 | 问题单 | 问题负责人 | 根因与改进项经评审后立项 |
| 问题关闭 | 改进项关闭证据 | 事件指挥或服务负责人 | 逐项验收，全部通过后关闭 |
升级与代班要写进职责定义：当事件级别上调或长时间未恢复时，由事件指挥决定升级，升级后原负责人移交处置记录和当前结论，接任者在事件单上签字确认；值班人员临时离岗时，代班人需在事件单中登记，未登记的交接视为无效。这样处理，责任链在人员变动时不会断。
这些交接记录需要落在同一处才能被追溯。ONES Desk 支持事件管理与问题管理，工单可直接关联到待办事项列表，服务团队与研发团队围绕同一张工单协同；工单优先级可评估和定义，用于区分紧急事件；工作流与工单属性支持自定义，便于把上述字段和状态配置进流程。恢复确认后的问题治理，可通过工单关联 ONES Wiki 页面记录分析过程，或在同时使用 ONES Project 时将工单关联到需求/缺陷工作项持续跟踪。具体字段与流程配置以实际产品配置项为准。
一个跨团队处置的填写示例
以下为演示情景，用于说明字段如何填写与流转，不代表真实案例。
识别定级。某日 09:20，监控告警显示订单提交接口错误率升至 18%，同时客服报障量上升。值班负责人在事件单中填写：事件编号 INC-20240612-001，影响范围为“订单提交，涉及全部线上渠道”，紧急程度为“持续恶化、无临时规避手段”，定级为一级，指派技术负责人为交易系统组负责人，业务负责人为订单业务负责人，沟通协调人为服务台主管。状态置为“已定级”。
协同处置。技术负责人判断与 08:50 的一次配置变更相关，处置方案为回滚配置并观察 15 分钟。任务分派：交易系统组执行回滚，中间件组核查连接池状态，客服团队收集用户影响样本。09:35 回滚完成，09:50 错误率降至 0.3%。处置记录按时间线登记每步操作与结果，恢复证据附上错误率曲线和回滚操作日志，状态置为“待恢复确认”。
恢复确认。服务负责人组织业务验证：抽样 50 笔订单全部成功，支付回调正常，无数据不一致。10:20 签署恢复确认单，写明恢复时间 09:50、验证范围、验证人和遗留观察项“关注次日同时段错误率”。事件状态变为“已恢复”。
问题治理。恢复确认单归档后，问题负责人在问题单中记录根因“配置变更缺少灰度校验”，改进项包括：变更流程增加灰度步骤（责任人：发布平台组，两周内完成）、配置项增加自动校验（责任人：交易系统组，一个月内完成）。两项验收通过后问题单关闭，事件全过程记录与问题单相互关联，便于后续同类事件检索。
完成检查：定义是否可用的验收项
定义写完不等于可用。用下面这份清单逐项核对，全部通过才说明这套输入输出可以支撑实际处置。
| 检查项 | 通过标准 | 证据 |
|---|---|---|
| 每段是否有明确输入、输出与完成标志 | 四段均有字段级清单，完成标志可观察（状态、签署、指标） | 字段清单表、流程配置截图 |
| 交接点是否有确认人和确认记录 | 每个交接点写明确认人角色与确认方式，记录可追溯 | 角色责任表、事件单状态变更记录 |
| 输出字段能否支撑下一段直接开工 | 抽取一个历史事件回填，下一段无需补充询问即可启动 | 回填演练记录 |
| 问题治理是否闭环到改进项 | 问题单含根因、改进项、责任人与验收方式，关闭有证据 | 问题单样例、改进项验收记录 |
| 升级与代班是否有承接规则 | 升级和代班均需在事件单登记并签字，未登记交接无效 | 升级记录、代班登记样例 |
| 字段是否可配置落地 | 事件单、问题单的字段与状态能在所用工具中配置并强制必填 | 工具配置说明或流程演示 |
建议在正式启用前做一次桌面演练：选一个近期事件，按四段流程回填全部字段，检查每段交接是否顺畅、有无字段缺失或职责空档。演练中暴露的问题直接修订定义，修订后再演练一轮，直到交接无需口头补充信息即可完成。
常见问题
事件级别定错了，后续流程怎么纠正？
定级允许调整，但调整必须留痕。级别上调时，由事件指挥决定升级，原负责人在事件单中记录上调依据，并把处置记录和当前结论移交给接任者，接任者签字确认。级别下调同样要在事件单中写明理由和依据，避免事后无法解释处置力度的变化。定级阶段遇到边界模糊的情况，按“就高”原则先定级，后续再依据实际影响修正。
技术指标已恢复，业务侧验证不通过怎么办？
恢复确认不通过时，事件退回协同处置段，状态回退也要记录在事件单中。退回时需写明未通过的具体项，例如某类交易仍失败、数据存在不一致或存在积压未消化，技术负责人据此重新组织处置。恢复确认单在验证通过前不签署，事件状态保持“待恢复确认”，避免出现技术侧已宣布恢复、业务侧仍在报障的口径冲突。
问题治理阶段一定要在事件恢复后立即启动吗？
问题治理的起点是恢复确认单归档，但立项时间可以按事件影响和资源情况安排。一级事件通常建议尽快立项，明确问题负责人和初步根因方向；影响较小的事件可以合并同类项后统一分析。无论何时立项，问题单都应包含根因描述、影响评估、改进项清单，每项写明责任人、截止时间和验收方式，全部改进项验收通过后问题单才能关闭。
跨团队任务分派后，进展同步要写到什么程度？
进展同步字段要求各团队更新四项内容：已完成动作、当前结论、下一步计划、阻塞点。只写“还在处理”无法支撑事件指挥判断节奏。同步节奏按事件级别确定，一级事件可缩短间隔，并在事件单时间线中连续记录。阻塞点要写明需要哪个团队或哪个决策支持，便于事件指挥当场协调，而不是等到下一次同步才暴露。
用工具承载这套输入输出，需要关注哪些配置点？
重点看三处：事件单与问题单的字段能否按上述清单配置并设为必填；状态流转能否对应“已定级、待恢复确认、已恢复、已关闭”等节点；交接记录能否与处置记录、恢复确认单、问题单相互关联以便追溯。ONES Desk 支持事件管理与问题管理，工单可关联待办事项列表，支持自定义工单属性与工作流，工单可关联 ONES Project 的需求/缺陷工作项或 ONES Wiki 页面。具体字段与流程配置以实际产品配置项为准。
