从 10 次宕机中学到的 7 个教训

偶然机会，发现两个有意思的家伙（Tom and Jamie）在做的 Podcast，主题叫做 The Downtime Project（https://downtimeproject.com/)，专门复盘互联网上各类宕机事件。他们讨论的角度主要是从系统开发和运维。

最近的一期叫做 <7 Lessons From 10 Outages> （https://downtimeproject.com/podcast/7-lessons-from-10-outages/）。主要是从系统开发和部署角度的分析。摘取其中一条：

教训#3c。专注于恢复而不是备份，以及它们需要多长时间

• 备份未运行。。。那永远不可能啊，我在监控着！
• 备份到在S3中，运行正常。但是，备份文件是空的。或者它报错：Error: permission denied on directory /data。
• 备份表面上是正常的，但在上传时损坏了。
• 备份数据库完整的，但有坏块。
• 每个备份都包含正确、有效的数据库！但是，要通过 85ms 延迟的链路读取一个低端存储中数据，恢复需要 2 周。

• Gitlab 的 2017 Postgres 中断：备份脚本每天都在运行， 将数据放到 S3...直到做了软件更新，但没更新备份脚本。恢复从未真正被验证过。
• GitHub 的 43 秒网络分区：恢复需要很长时间（10h+），尤其是在网络高峰期，导致网站服务降级的时间很长。
  
  

宕机事件，当然不仅仅是备份与恢复的话题，这是要在系统规划设计阶段就要开始的工作，要考虑每一个系统层次的健壮性，以及部署架构的高可用。另外，用脚本来实现备份与恢复的弊端是显而易见的。