如何评价 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文档不受影响),或许不算是灾难级的事故,但教训仍然是深刻的.

数据库sharding

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

数据库索引

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

数据库事务

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

数据库优化

- - 数据库 - ITeye博客
程序运行效率,优化应用程序,在SP编写过程中应该注意以下几点: . a) SQL的使用规范: .   i.尽量避免大事务操作,慎用holdlock子句,提高系统并发能力.   ii.尽量避免反复访问同一张或几张表,尤其是数据量较大的表,可以考虑先根据条件提取数据到临时表中,然后再做连接.   iii.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该改写;如果使用了游标,就要尽量避免在游标循环中再进行表连接的操作.

数据库调优

- - 数据库 - ITeye博客
1、1、调整数据结构的设计. 这一部分在开发信息系统之前完成,程序员需要考虑是否使用ORACLE数据库的分区功能,对于经常访问的数据库表是否需要建立索引等. 这一部分也是在开发信息系统之前完成,程序员在这一步需要考虑应用程序使用什么样的体系结构,是使用传统的Client/Server两层体系结构,还是使用Browser/Web/Database的三层体系结构.

MySQL数据库的修复

- Xin - 博客园-首页原创精华区
找到mysql的安装目录的bin/myisamchk工具,在命令行中输入:. 然后myisamchk 工具会帮助你恢复数据表的索引. 好象也不用重新启动mysql,问题就解决了. 当你试图修复一个被破坏的表的问题时,有三种修复类型. 如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的.