2. 复盘启动条件与时机

复盘不是“出了事就开会”这么简单。启动过早，事实尚未收敛，会议容易变成猜测会；启动过晚，日志被覆盖、人员记忆模糊、临时加固措施已经改变了现场，复盘只能得到一份“事后合理化”的说明。因此，复盘启动的核心问题是三个：什么条件下必须启动、由谁判定事件等级、这次复盘要覆盖到哪里、要回答什么问题。

一、启动条件：三类触发信号

企业通常把复盘触发条件分为三类，只要命中任意一类，就应进入复盘流程，而不是等到“影响足够大”才启动。

• 结果类触发：已造成业务中断、数据泄露、资金损失、客户投诉、监管问询或对外声誉影响的事件。例如核心支付接口不可用超过 10 分钟，或确认有 1 条以上真实客户数据被非授权访问。
• 过程类触发：虽然最终未造成损失，但过程中出现了高危信号。例如检测到攻击者已获得主机命令执行权限、安全设备告警被人工关闭、应急响应中出现了绕过变更流程的临时操作。
• 机制类触发：同类事件在 90 天内重复发生两次及以上，或某个控制措施在两次检查中均未生效。这类触发针对的是“系统性缺陷”，而非单次事件本身。

需要强调的是，“已恢复”不等于“可不复盘”。很多团队在业务恢复后直接关闭工单，导致根因未被识别，同类问题在数月后以另一种形式重现。建议在应急响应流程中设置一个硬性卡点：事件状态从“已处置”转为“已关闭”之前，必须完成复盘启动判定，判定结论只有两种——启动复盘，或记录不启动的理由并由安全负责人确认。

二、事件等级判定：用可核对的维度代替感觉

等级判定决定了复盘的深度、参与范围和时限。若只凭“感觉严重”来定级，容易出现小事件过度复盘、大事件草草了事。实践中建议使用影响维度 + 可控维度的组合判定，每个维度给出可核对的取值。

把上述维度组合后，可映射为三个复盘等级：L1 快速复盘（单点问题、影响可控，24 小时内完成，输出简要根因与整改项）；L2 标准复盘（涉及核心业务或数据，5 个工作日内完成，需跨团队参与，输出完整时间线与整改计划）；L3 深度复盘（重大影响、涉及监管或重复发生，由安全负责人牵头，必要时引入外部视角，输出机制级改进与验证方案）。

三、复盘范围与目标：先划边界，再定问题

范围不清是复盘跑偏的主要原因。建议在启动时明确三件事：时间范围（从哪个时间点开始追溯，通常不早于首次异常信号出现前 24 小时）、系统范围（涉及哪些主机、账号、网络区域、第三方服务）、组织范围（哪些团队需要提供材料或参与访谈）。范围一旦确定，应在复盘记录中写明，后续如需扩大，需说明理由。

目标则要避免写成“查明原因、加强防护”这类无法验证的表述。可验证的复盘目标通常包含：还原一条可核对的时间线；识别至少一个直接原因和一个系统性原因；产出可分配责任人、可设定完成时间的整改项；明确哪些现有控制措施需要验证其有效性。目标数量不宜过多，L1 复盘聚焦 1–2 个问题，L3 复盘可扩展到机制层面，但仍应保持聚焦。

四、启动时机的实操判断

“何时启动”在实操中往往比“是否启动”更难。一个可用的判断原则是：当关键事实已经可以固定下来时启动，而不是等所有事实都清楚。具体来说，满足以下任一条件即可启动复盘：

1. 业务已恢复或已进入稳定缓解状态，现场不再持续变化；
2. 关键日志、告警、账号操作记录已完成保全，不会被轮转覆盖；
3. 主要当事人仍在岗且记忆清晰，可接受访谈；
4. 事件等级已初步判定，且不会因后续信息大幅改变复盘深度。

如果事件仍在持续处置中，可以先启动“复盘准备”：指定复盘负责人、保全证据、记录处置时间线，但暂不召开正式复盘会。这样既不干扰应急，又避免事后无据可查。对于 L3 事件，建议在处置阶段就安排一名不直接参与处置的人员担任记录者，专门负责时间线与决策记录，这一角色在后续复盘中价值极高。

五、一份可直接使用的启动判定记录

为了让启动判定可追溯，建议在事件工单中固定以下字段。以下为示例结构，实际使用时按企业工单系统字段命名调整即可。

复盘启动判定记录（示例）
事件编号：INC-2024-0317-002
事件标题：某对外API异常调用导致账号批量锁定
触发类型：过程类（检测到异常调用源IP，未造成数据泄露）
业务影响：局部（非核心交易，影响约 120 个账号）
数据影响：无
持续时间：约 35 分钟
攻击者位置：外部未进入
控制有效性：部分失效（限流生效，但账号锁定策略被误触发）
判定等级：L2 标准复盘
时间范围：首次异常调用前 24 小时
系统范围：API 网关、账号服务、日志平台
组织范围：安全运营、后端研发、账号服务负责人
复盘目标：还原调用链时间线；确认限流与锁定策略的交互缺陷；
          产出策略调整项与验证方式
复盘负责人：安全运营 张工
证据保全：网关访问日志、账号锁定日志、告警记录已归档
启动时间：2024-03-17 16:40