记录关键时间点
事件从发现到结案，中间会经过一连串节点：第一条痕迹出现、监控告警、人工初判、实施遏制、系统恢复、正式结案。把这些节点的时刻按统一口径记录下来，一方面用于向管理层说明响应节奏，另一方面在复盘时能看出哪个环节消耗了最多时间，为改进提供依据。
口径一致才有可比性
不同案例、不同班次之间要能对比，前提是口径统一：时间统一用 UTC 并注明，判定标准写清楚（例如「初判」定义为完成影响范围初步确认的时刻），并注明每个时间点是谁记录的。事后凭记忆补录的时间点会明显失真，最好边处置边记。
基本信息
| 适用平台 | 跨平台，属于流程管理范畴 |
|---|---|
| 时间点 | 首条痕迹 / 告警 / 初判 / 遏制 / 恢复 / 结案 |
| 统一口径 | 全部使用 UTC，注明记录人与判定标准 |
| 记录时机 | 边处置边记，避免事后补录 |
| 用途 | 复盘改进、对外说明、多案例横向对比 |
典型使用场景
- 向管理层汇报：用一组时间点说明响应各阶段耗时
- 复盘会：找出耗时最长的环节作为改进重点
- 多案例对比：统一口径的指标用于评估整体响应能力
- 跨班次交接：时间点清单让接班者快速掌握进度
- 报告附录：以时间点表支撑处置经过的叙述
时间点记录
时间点记录
first_artifact: 2026-01-02T03:20Z 记录人：分析-张工
alert: 2026-01-02T09:05Z 记录人：监控平台（自动）
triage: 2026-01-02T09:40Z 记录人：值班-王工（判定标准：确认受影响主机范围）
contain: 2026-01-02T10:20Z 记录人：应急-李工（判定标准：主机出站被阻断并验证）
recover: 2026-01-03T02:00Z 记录人：系统-赵工（判定标准：业务功能恢复正常）
close: 2026-01-05T08:00Z 记录人：负责人-刘工（判定标准：报告交付并归档）时间点定义建议
| 时间点 | 判定标准 | 常见偏差 |
|---|---|---|
| 首条痕迹 | 最早可确认的异常活动时刻 | 只按告警时间填，低估了实际起点 |
| 告警 | 监控系统触发时刻 | 区别于人工发现时刻 |
| 初判 | 完成影响范围初步确认 | 把「看到告警」当作初判 |
| 遏制 | 阻断动作生效并验证 | 把「下达指令」当生效 |
| 恢复 | 业务功能验证正常 | 把「重启服务」当恢复 |
| 结案 | 报告交付并归档完成 | 把「处置完成」当结案 |
指标主要用于改进响应节奏，而不是评价个人：把记录与考核直接挂钩，会让时间点被美化，数据反而失去参考价值。
时间点清单要保留原始记录人信息与判定依据，复盘时若发现某个时间点存在争议，可以回到当时的记录判断是定义问题还是执行问题。