如何评价 2017 年 2 月 1 日 GitLab 数据库被误删？

事件回顾

GitLab官方的事故报告（postmortem）：
https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

恢复过程直播，有一些工程师的现场答疑：
https://www.youtube.com/watch?v=nc0hPGerSd4

OSChina的中文报道：
Gitlab.com 误删数据，备份恢复失败已宕机 10 小时

YCombinator的英文讨论：
GitLab Database Incident Progress Report

目前来看最终会丢失一小部分线上数据（6个小时的issues、comments、merge requests等，代码和wiki文档不受影响），或许不算是灾难级的事故，但教训仍然是深刻的。GitLab 去年曾经提出自建私有云服务的计划，这次事故对于他们的声誉也会是一个沉重打击。

如何面对事故

这次事故虽然暴露了 GitLab 内部的一些问题，但他们的应对方式和态度还是值得赞许和学习的：
- Don't panic，承担责任的人才有犯错的机会，"You're not one of the team until you've brought down the server."
- 信息透明，尽可能寻求帮助
- 首先齐心合力解决问题，然后检讨流程，不归责于个人
- 提交详尽的事故报告（postmortem），从错误中积累经验

GitLab 的教训

以下简单总结这次事故中 GitLab 犯的一系列错误。

1、在深夜做高风险操作
事件的起因是 GitLab 遭到攻击后，一位工程师加班到深夜维护线上环境。因为遇到了种种常规脚本没能解决的问题，不得不进行大量人工操作，于是在精力不济后出现致命失误，准备从 db1 同步到 db2 时错误的删除了 db1 的数据。

2、部分备份脚本/设置没有定期维护
GitLab 的 PostGreSQL 本地备份和 Amazon S3 备份都没有正常工作。
其中 PostGreSQL 本地备份设置在数据库版本升级后失效了，但没有人注意到。
其它备份脚本也处于散落各处，长期无人维护的状态。

3、部分备份方案没有覆盖到所有数据类型
Azure 提供了磁盘快照服务，但 GitLab 的 数据库服务器并没有使用，只在 NFS 服务器上使用了。

4、部分备份方案没有保留完整数据
GitLab 在 Staging 环境上有一份6小时以前的数据，但其中没有保留 Webhook（STG 环境不应产生真实的 Webhook 行为）。实际上 Staging 环境本就不应该承担备份的责任，但这是 GitLab 眼下能找到的最完整历史数据了。后来他们在其它的备份中补回了 Webhook 的数据。

5、备份流程没有 Monitoring 和 Alert
因为没有 Monitoring 和 Alert，以上这些安全隐患长期没有人发现和注意。

6、备份频率不足
GitLab 的各种备份方案都是每天运行一次，从这次事件来看，对于他们来说可能还是不够。

7、备份不能正确恢复/需要太长时间
GitLab 的 LVM 快照因为某些原因，没能正确恢复成功。
从 Staging 环境恢复到 Production 环境的过程中，因为跨数据中心的网速以及 Staging 环境的磁盘速度等原因，备份数据在10个小时后还只传了一半，大大拖延了恢复进程。

8、没有正确的设置维护 PostGreSQL
事故发生后一些第三方评论指出（参见官方事故报告附录），GitLab 没有正确的配置和使用 PostGreSQL，也是这次事故升级的部分原因。

如何做得更好

GitLab 在事故报告之后附上了内部总结的若干 TODO 事项，对于其它流程不够完备的中小型团队来说，可以考虑同样做一遍自查。以下是我个人的一些建议：

1、审核所有数据的备份方案，备份频率如何，备份数据放在哪里，保留多久。
2、对于云服务自带的镜像备份等服务，确认是否正确的打开和设置
3、对于自行搭建的备份方案，确认
- 是否覆盖了所有重要数据
- 是否还在正常工作，考虑设置相关 Monitoring 和 Alert
- 相关的 script 和 configuration 进入源码管理
- 最终备份文件考虑存储不止一份（本地、不同的云服务商），使用云服务时最好使用单独的文件存储服务，而非直接放置在VM镜像内
4、定期做灾备演习，检验是否可以正确从备份中恢复，以及此过程需要多少时间和资源。
5、将灾备流程文档化，日常服务器维护流程中的注意事项也写成 checklist（或脚本化）。
6、降低 Production 环境的误操作可能
- 提倡 IAC （Infrastructure as Code）的最佳实践
- 深夜等工作时间外服务器出现状况时，优先考虑基于 CI 的 rollback 等自动化操作，高风险的人工操作尽量放在工作时间，有其它同事可以监督或者支援
- 考虑在 Production 环境的 CLI 界面中增加更多防呆提示（比如设置不同颜色，对于 rm 命令使用 alias 增加保护性检查等）
7、今天数据库运维仍然是一项比想象中更困难的任务，即使对于 GitLab 这样的成熟团队也是如此。对于没有专职 DBA 的创业公司来说，直接使用云服务商提供的数据库服务可能更为安全高效。

来源：知乎 www.zhihu.com
作者： Li Gong

【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。 点击下载

此问题还有 63 个回答，查看全部。
延伸阅读：
不小心删除公司数据，会怎么样？
如何看待小米论坛被拖库？