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

事件回顾

GitLab官方的事故报告（postmortem）：

恢复过程直播，有一些工程师的现场答疑：

OSChina的中文报道：

YCombinator的英文讨论：

目前来看最终会丢失一小部分线上数据（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 的创业公司来说，直接使用云服务商提供的数据库服务可能更为安全高效。

传说中有6种备份的 gitlab 怎么就爆炸了呢? 看他们的报告吧

1.LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage

这是唯一能用的备份,每24小时执行一次,上一次是6小时前.

2.Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size.

这个也是24小时一次的备份,不过首先找不到它在哪.等找到了发现备份是空的

3.Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.

Azure 的备份没给数据库服务器用

4.The synchronisation process removes webhooks once it has synchronised data to staging.

同步进程在一次同步完成后就把 webhooks 删了

5.The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented

这个备份是依赖一些混乱的脚本,很容易出错,而且没文档2333

6.Our backups to S3 apparently don’t work either: the bucket is empty

S3 备份是空的2333

看得我都要笑死了,备份从来没人管吧233.然后直播复制备份,速度只有6MiB/s.好在 gitlab 只有 310 GiB 的数据.

总之现在直播给出的 ETA 还有至少 5 小时吧.

欢迎围观史上第一次 YouTube 直播欢乐地恢复数据