你经历过哪些线上故障，有什么经验或者教训？

[nailcui]

故障复盘、分析等文档收集

[nailcui]

AWS 的 S3 故障回顾和思考 - coolshell

• 运维误操作，引起核心服务下线；核心服务启动耗时太久
• AWS 在很长很长一段时间内都没有重启过 S3 的核心服务，而过去这几年，S3 的数据对象存储级数级的成长，以至于系统启动花了很长时间

[nailcui]

GitLab 运维因疲劳误删数据导致宕机超24小时

• 运维误删数据
• 5 重备份策略全部失效
• 宕机超 24 小时，数据丢失超 6 小时
• 恢复期间 Gitlab 在 Youtube 上直播了整个数据恢复过程

[nailcui]

关于语雀 23 日故障的公告

• 14:07 定位到原因是存储在升级中因新的运维工具 bug 导致节点机器下线
• 15:00 确认存储系统使用的机器类别较老，无法直接操作上线
• 15:10 开始新建存储系统，从备份中开始恢复数据，由于语雀数据量庞大，此过程历时较长
• 19 点完成数据恢复
• 21 点存储系统通过完整性校验

看完故障复盘报告后，总感觉似曾相识，查询 《SRE：Google运维解密》找到了这个案例：

在一项常规自动化测试中，该测试针对同一个集群（马上即将退役的）发送了两个连续的下线请求（turndown）。在处理第二个下线请求时，自动化系统中的一个非常隐蔽的Bug将全球所有数据中心的所有机器加到了磁盘销毁（diskerase）的队列中，这导致硬盘数据被清空。细节请参看第7章的“自动化：允许大规模故障发生”材料。

本案例其实应该分两部分来看：

1、出现问题的原因

• 运维脚本中的 bug；所以在写影响较大的程序时，一定要保证健壮性，比如空值的处理、异常后的兜底措施等

2、后续恢复

• 本案例数据备份完整且可以恢复，还是不错的；但是恢复时间花费了很久
• 上面 GitLab 的案例中，多重备份措施全部失效
• 上面 AWS 的案例中，重启时也花了很长时间，和本案例也是有些相似
• 1：有备份；2：备份可用；3：备份恢复速度