灾难恢复与事故管理
登录后可在不同设备间同步进度。在此之前，进度只保存在当前浏览器中。
为什么重要
每个系统迟早都会遇到糟糕的一天：服务商宕机、一次出错的迁移、数据库被删、密钥泄露。企业客户和监管机构不会问你会不会出事故。他们问的是：你多快能发现、怎么沟通、最多会丢多少数据、多快能恢复。
学习目标
- 为每个系统定义 RPO 和 RTO，并据此设计备份。
- 通过实际恢复来证明备份可用。
- 规划故障切换，并理解什么时候才值得做多区域。
- 以清晰的角色分工和沟通机制处理事故。
- 建立可持续的 on-call 值班机制。
- 写出能带来真正修复的无责复盘。
- 开展受控的混沌实验。
课程内容
13.1 RPO 与 RTO（83）
- RPO（Recovery Point Objective，恢复点目标）： 你最多能承受丢失多少数据（例如 5 分钟）。
- RTO（Recovery Time Objective，恢复时间目标）： 你最多能停机多久（例如 1 小时）。
- 和业务方一起为每个系统分别设定。账本需要接近零的 RPO；分析缓存则可以重建。
13.2 备份（84）
- 3-2-1 原则： 3 份副本，2 种不同的介质/服务，1 份异地（不同账号/不同服务商）。
- 主数据库开启时间点恢复（PITR）。
- 备份要不可篡改，并放在单独的账号里，这样即使管理员账号被攻破或 agent 失控，也删不掉它们。（agent 和攻击者连同生产数据一起把备份删掉，是反复出现的事故模式。）
- 备份的不只是数据库：对象存储、密钥/配置（通过 IaC）、你无法重新生成的第三方数据。
- 没恢复过的备份只是一种希望。 定期安排恢复演练；测量实际 RTO。
13.3 故障切换与多区域（85, 86）
- 故障切换（Failover，85）： 把备用节点（副本、备用区域、第二家服务商）提升为主。自动故障切换需要可靠的健康检测，避免来回抖动或脑裂。
- 多区域（86）： 能降低全球用户的延迟，扛住区域级故障，但代价是复杂度、数据一致性难题和钱。大多数初创公司需要的是单区域内的多可用区，再加跨区域备份，而不是 active-active 多区域。
- 在跨境复制个人数据之前，先考虑数据驻留要求。
- 单一服务商依赖（只有一家 LLM 厂商、只有一个短信网关）：规划一个备选。
13.4 事故响应（109）
严重等级（示例）：SEV1 服务中断或数据泄露 / 资金流转出错；SEV2 主要功能不可用；SEV3 服务降级，有临时绕行方案。 角色：Incident Commander（事故指挥，负责协调和决策）、Ops/Tech lead（负责修复）、Comms lead（负责状态页、客户和监管沟通）、Scribe（记录时间线）。在一人公司里，四个角色你一个人全包；提前写好检查清单，事发时就不用临场思考。 流程：发现 → 宣布事故 → 先止血（rollback、关闭 flag、故障切换）→ 尽早并定期沟通 → 解决 → 跟进。 发生数据泄露时，法定时限随即开始计算：例如新加坡 PDPA 要求在评估确认泄露属于须通报情形后的 3 个日历日内通知 PDPC（参见 14 · 合规、治理与审计）。
13.5 On-call 值班（110）
清晰的轮值表、升级路径、每条告警都有 runbook、定期评审告警质量、被呼叫后有补偿或补休。独立创始人版本：手机上装一个呼叫工具，找一个信得过的外包工程师做后备，并且对告警保持极度克制。
13.6 事故复盘（111）
无责复盘：关注系统为什么允许这次故障发生，而不是谁犯了错。模板：摘要、影响（用户、时长、金额）、时间线、根因和促成因素（5 个为什么）、做得好的、做得不好的、哪里是侥幸、带负责人和截止日期的行动项。跟踪行动项直至完成。
13.7 混沌工程（87）
提出假设（“如果 LLM 服务商挂了，用户会看到降级方案，其他功能都不受影响”），限制爆炸半径，先在 staging 运行，然后在 game day 期间谨慎地在生产环境运行，测量，修复。在注入真实故障之前，先从桌面推演开始。
实验 13：Game day 演练
- 为每个数据存储写下 RPO/RTO；配置 PITR 和跨账号的不可篡改备份。
- 恢复演练： 把生产备份恢复到一个全新环境；校验数据；记录实际 RTO。
- Game day：讲师在不打招呼的情况下弄坏系统（有问题的部署、泄露的密钥、服务商宕机、被删的表）。学员按角色分工处理事故，更新状态页并对外沟通。
- 在 48 小时内写好复盘报告。
完成标准（Definition of Done）
AI 提示词包
- “针对这个架构，写一份‘主数据库不可用’的事故 runbook，包括检测、止血、沟通和恢复步骤。”
- “把这份事故时间线整理成一份无责复盘，包含 5 个为什么分析和具体的行动项。”