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

标签: gitlab 数据库 | 发表时间:2017-02-03 13:30 | 作者:Li Gong
出处:http://www.zhihu.com
事件回顾

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 个回答,查看全部。
延伸阅读:
不小心删除公司数据,会怎么样?
如何看待小米论坛被拖库?

相关 [gitlab 数据库] 推荐:

从Gitlab误删除数据库想到的

- - 酷 壳 – CoolShell
昨天,Gitlab.com发生了一个大事,某同学误删了数据库,这个事看似是个低级错误,不过,因为Gitlab把整个过程的细节都全部暴露出来了,所以,可以看到很多东西,而对于类似这样的事情,我自己以前也干过,而在最近的两公司中我也见过(Amazon中见过一次,阿里中见过至少四次),正好通过这个事来说说一下自己的一些感想和观点吧.

从Gitlab误删数据库事件,说一说IT审计的那些事儿

- - 钛媒体:网罗天下创新事
就在两天前,《Gitlab误删300GB数据,备份失效后直播抢救》、《Gitlab不小心删除了数据库导致网站下线》霸屏了科技新闻的头条. 整个事件的回顾,Gitlab 第一时间放到了 Google Doc 上,并在 Twitter 上对事件的处置状态进行实时更新,后来索性在 Youtube上 开了频道直播恢复进程,目前网站已经恢复了正常,不幸的是,Gitlab 还是丢掉了差不多6个小时的数据.

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

- - 知乎每日精选
GitLab官方的事故报告(postmortem):. 恢复过程直播,有一些工程师的现场答疑:. Gitlab.com 误删数据,备份恢复失败已宕机 10 小时. YCombinator的英文讨论:. 目前来看最终会丢失一小部分线上数据(6个小时的issues、comments、merge requests等,代码和wiki文档不受影响),或许不算是灾难级的事故,但教训仍然是深刻的.

GitHub 和 GitLab 的故事

- - 胡涂说
2005年,因为 Linux 社区被商业公司撤回了免费试用源码配置管理工具的权利,Linus Torvalds 一怒之下自己花了十天时间开发并发布了分布式源码配置管理工具Git, 虽然当时 Linus 只是想着给 Linux 社区小伙伴们开发个顺手的协作工具,但没想到这款工具将席卷全球,并改变了软件世界.

用 GitLab 做 CI/CD 是什么感觉,太强了

- - DockOne.io
GitLab CI/CD 是一个内置在 GitLab 中的工具,用于通过持续方法进行软件开发:. Continuous Integration(CI):持续集成. Continuous Delivery(CD):持续交付. Continuous Deployment(CD):持续部署. 持续集成的工作原理是将小的代码块推送到 Git 仓库中托管的应用程序代码库中,并且每次推送时,都要运行一系列脚本来构建、测试和验证代码更改,然后再将其合并到主分支中.

GitLab-CI:从零开始的前端自动化部署

- - DockOne.io
gitlab-ci&&自动化部署工具的运行机制. 1、通过在项目根目录下配置.gitlab-ci.yml文件,可以控制CI流程的不同阶段,例如install/检查/编译/部署服务器. GitLab平台会扫描.gitlab-ci.yml文件,并据此处理CI流程. 2、CI流程在每次团队成员push/merge后之后触发.

数据库sharding

- - 数据库 - ITeye博客
当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由. 另一个优势是不会受ORM框架的制约.

数据库索引

- - CSDN博客推荐文章
索引是由用户创建的、能够被修改和删除的、实际存储于数据库中的物理存在;创建索引的目的是使用户能够从整体内容直接查找到某个特定部分的内容. 一般来说,索引能够提高查询,但是会增加额外的空间消耗,并且降低删除、插入和修改速度. 1.聚集索引:表数据按照索引的顺序来存储的. 2.非聚集索引:表数据存储顺序与索引顺序无关.

数据库事务

- - 数据库 - ITeye博客
事务传播发生在类似以下情形:. 假设methodB的配置是:. 如果methodA在事务里,那么methodB也在这个事务中运行. 如果methodA不在事务里,那么methodB重新建立一个事务运行. 如果methodA在事务里,那么methodB也在这个事务中运行. 如果methodA不在是事务里,那么methodB在非事务中运行.