管理从发现到恢复的事件全过程

根据影响宣布事件

当某件事使服务中断、服务质量下降或面临威胁，且严重到需要协调响应时，就构成事件。组织定义严重等级和升级处理规则，再根据用户影响、受影响数据、持续时间和范围应用这些规则。

不要等到完整解释根因后才求助。清楚说明已观察到的影响，就足以启动协调。区分安全疑点与已确认结论。

发布前准备响应路径。在主要服务不可用时，也要能获取联系方式、访问流程、操作手册和沟通渠道。用虚构事件演练这条路径。

先分配职责，避免相互冲突的修改

事件协调负责确定优先级并管理决策。技术响应人员调查和缓解问题。沟通负责人让受影响人员持续了解情况。Google SRE 将这些职责描述为不同角色。小团队可以合并角色，但仍须完成相应工作。参见事件响应。

保留一份共享时间线。记录时间、观察、操作、操作者和结果。区分事实与假设。使用统一时区，并注明不可靠的时间戳。

分析一次虚构事件

以下时间均为 UTC。导出故障影响多个客户后，组织指定事件协调人。

有用的首次通报说明受影响功能、已知范围、缓解措施和下次更新时间。没有证据时，不承诺修复时间。不要在共享通报中包含客户记录。

09:10 时，事件性质发生变化。仅恢复成功导出已不够。团队需要评估可能的数据披露、控制访问、保全证据，并让适当的决策负责人参与。

缓解影响，同时保持控制

适用时使用经过测试的操作手册。回滚、故障转移或更改凭据前，检查前提条件。旧应用版本可能不理解当前数据库模式。区域故障转移也可能把同样的损坏数据一起转移过去。

让 AI 助手在获准边界内整理已移除敏感内容的证据，或比较假设。响应人员必须验证其结论。日志和工单是不可信输入，不是执行其中内容的授权。

紧急访问应具备获准目的、有限时长和审计记录。情况紧急，不代表智能体建议的命令正确。

分别完成恢复与后续工作

宣布服务恢复前，验证用户工作流、数据完整性、访问边界和监控数据的及时性。记录剩余限制。如果安全调查仍有未解问题，就保持调查开放。

之后，检查哪些条件使事件发生。为具体后续工作指定负责人和验证标准。无责复盘追求准确解释和有用改进，但不会免除完成这些改进的责任。参见复盘实践。

继续学习安全运营和闭合反馈循环。