文档章节

Gitlab删库事件的借鉴意义

wier
 wier
发布于 2017/02/06 07:36
字数 2174
阅读 4750
收藏 67

 

上周轰动一时的Gitlab事件终于尘埃落定了,不可否认的是这次事故Gitlab官方公关的的很出色,及时公布事件细节并寻求帮助,这让本是一个失误引发的事故,演变为一个真诚面对问题并反思的正面教材。对此,网络上一片好评。

 

最新动态:

截止北京时间2017/02/02 02:14,GitLab.com已恢复正常。期间丢失了 6 小时的数据库数据(问题,合并请求,用户,评论,片段等)。Git / wiki 存储库和自托管安装不受影响。根据GitLab从日志里得出的结论,有707位用户丢失数据,5,037项目丢失,受事故影响的用户基数不到1%。

 

事件回顾:

 

起因是在 2017/01/31 18:00左右,Gitlab检测到垃圾邮件发送者通过创建片段来攻击数据库,使其不稳定,于是运维block攻击者的IP,并移除用户发送垃圾邮件。之后运维A发现db2.staging复制滞后生产库4GB的数据(据后期2nd Quadrant的CTO – Simon Riggs 建议,PostgreSQL有4GB的同步滞后是正常的),A开始尝试修复db2,但复制失败,A在尝试了多种方案之后依然如此。

在2017年1月31日23:00 左右A决定删除该db2数据库目录,令其重新复制。由于夜间开车时间很长,A错误的将db1.cluster.gitlab.com(生产库)的数据库删除,而不是db2的。虽然在一两秒之后意识到这个问题,终止了删除操作,但为时已晚。大约 300 GB 左右的数据只剩下约4.5 GB。

随后虽然有号称有五重备份机制(常规备份(24小时做一次)、自动同步、LVM快照(24小时做一次)、Azure备份(只对 NFS 启用,对数据库无效)、S3备份),没有一个可靠地运行或设置,最终只能基于LVM的备份(最近6小时以前),还原了6 小时前的备份。恢复期间Gitlab直播了这次恢复过程。

详细内容请查阅文档

 

借鉴意义

 

1、积极公开,寻求帮助

本次事件让我们大感震撼的是,Gitlab居然主动的公告了事件的细节,不但提交了详尽的事故报告到googleDoc上,还在网络上也积极的寻求帮助。这份真诚实在是令人敬佩。如果是一般的技术团队都是在向外界隐藏问题,然后自己闷头解决,最终时间耽误了,用户还不认可你,而你自己也有苦说不出。反而是Gitlab主动公布,不但获得了各方面的技术组织的鼎力帮助,还收获了用户的理解和支持,同时还让网络上也少了一份猜测和谣言。

除了积极的公开事件详细,GitLab的故障回顾中也说明了要对本次事故进行Ask 5 Whys。随后在直播的过程中,官方也主动说明了不会辞退运维A,而是会罚他看一个名为 "10 hours of nyancat" 的视频(http://www.nyan.cat/哈哈,很难看下去啊)。这个表明整个团队对本次事故的处理态度是,齐心合力解决问题,然后检讨流程,不归责于个人。这份处事态度也值得人钦佩,出现问题,首先不是追究责任,而是解决问题,然后发现后面的深层次问题,从而有效的避免下次再犯同样错误。

 

2、防止人肉运维

事故发生后,有人建议不要用rm命令,采用mv命令,其实这个只能解决暂时问题,你们保证用其他命令就不会出问题么。另外有人建议建立一个checkList流程,每次执行的时候check一遍流程,有文档做指示不会犯一些低级错误,如若每个命令都去check一下,工作是不会更复杂了。

另外还有一些建议双人操作,增加权限系统等等,我觉得对于一个规范流程来说,一些必要的提示和规范可以增加,但是运维要自动化,以机器来代替人工,而不是开倒车去采用更多的人工来避免错误。

 

3、高可用分布系统

本次的事故在恢复的时候,发现有5个备份系统基本都无用,最终导致了6个小时数据的丢失。基于备份系统的缺陷,有运维同学建议如下:

1、审核所有数据的备份方案,备份频率如何,备份数据放在哪里,保留多久。

2、对于云服务自带的镜像备份等服务,确认是否正确的打开和设置

3、对于自行搭建的备份方案,确认

4、定期做灾备演习,检验是否可以正确从备份中恢复,以及此过程需要多少时间和资源。

从备份流程和规范来说,这些建议很中肯。从另外一个角度来说,即便是你的备份系统已经做到了这些,而且操作人员零失误,但是丢失数据的问题也会发生,为何呐。

以下是采自左耳朵耗子《从Gitlab误删除数据库想到的》的文字。

备份通常来说都是周期性的,所以,如果你的数据丢失了,从你最近的备份恢复数据里,从备份时间到故障时间的数据都丢失了。

备份的数据会有版本不兼容的问题。比如,在你上次备份数据到故障期间,你对数据的scheme做了一次改动,或是你对数据做了一些调整,那么,你备份的数据就会和你线上的程序出现不兼容的情况。

有一些公司或是银行有灾备的数据中心,但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候,你就会发现,各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴,宁夏银行7月系统瘫痪最新解析》。

所以,在灾难来临的时候,你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作,但也会导致数据丢失,而且可能长期不用的备份系统很难恢复(比如应用、工具、数据的版本不兼容等问题)。

所以说,如果你要让你的备份系统随时都可以用,那么你就要让它随时都Live着,而随时都Live着的多结点系统,基本上就是一个分布式的高可用的系统。因为,数据丢失的原因有很多种,比如掉电、磁盘损坏、中病毒等等,而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作,都不管用,这个时候,你不得不用更好的技术去设计出一个高可用的系统!别无它法。

 

以上是每种架构的优缺点,我们可以看到Backups、Master/Slave、Master/Master架构下,Data都是会出现loss的情况的,而2PC和Paxos是不会的。

 

4、谨防夜间开车

夜黑风高,夜间长时间开车,必然会有车祸现场的时候。这次事故的运维A,工作到深夜,想必也是和疲劳驾驶有一定的关系。

我们不评论8小时工作制度是否合理,但对于脑力劳动者,违背用脑规律甚至使之处于过载疲劳状态,都会显著降低脑部的能量转换效率,还是科学用脑最为可靠,把时间用在效率最高的地方。对此希望决策者能够意识到这个问题,而不是一味加班赶进度。这种危害已经越来越得到更多从业人员的认同了。

 

了解更多请扫码关注公众号:

 

 

 

© 著作权归作者所有

wier
粉丝 780
博文 50
码字总数 134184
作品 0
东城
技术主管
私信 提问
加载中

评论(40)

wier
wier 博主

引用来自“TerryZ”的评论

发现一个老熟脸!
喔,啥意思
TerryZ
TerryZ
发现一个老熟脸!
八阿哥不在家
八阿哥不在家

引用来自“wier”的评论

引用来自“Outlooks”的评论

引用来自“wier”的评论

引用来自“Outlooks”的评论

经常用脑,没喝六个核桃啊😆

回复@Outlooks : 哈哈,找许姐姐帮忙

回复@wier : 许姐姐是谁?
许婷

回复@wier : 表示不懂是什么梗
wier
wier 博主

引用来自“Outlooks”的评论

引用来自“wier”的评论

引用来自“Outlooks”的评论

经常用脑,没喝六个核桃啊😆

回复@Outlooks : 哈哈,找许姐姐帮忙

回复@wier : 许姐姐是谁?
许婷
八阿哥不在家
八阿哥不在家

引用来自“wier”的评论

引用来自“Outlooks”的评论

经常用脑,没喝六个核桃啊😆

回复@Outlooks : 哈哈,找许姐姐帮忙

回复@wier : 许姐姐是谁?
wier
wier 博主

引用来自“Outlooks”的评论

经常用脑,没喝六个核桃啊😆

回复@Outlooks : 哈哈,找许姐姐帮忙
八阿哥不在家
八阿哥不在家
经常用脑,没喝六个核桃啊😆
xiaosanss
xiaosanss
有争议
xiaosanss
xiaosanss
xiaosanss
xiaosanss

引用来自“wier”的评论

引用来自“tinshen”的评论

关键是不开夜车。不然高风险操作在夜车下及其容易出问题。

引用来自“wier”的评论

做好自动化rollback,人工上线命令搞也是很危险的

引用来自“tinshen”的评论

你真以为自动化不会出风险的么。自动化运维也出过雷的。貌似比这次事情搞的还大。
那次的呐,看看学习下啥问题造成的

太,,
GitLab 称有 707 位用户超 5000 个项目丢失数据

GitLab 的一位系统管理员——官方博客称他是Team-member-1——本周早些时候删错了服务器上的 PostgreSQL数据库目录(他本想删除 db2.cluster.gitlab.com服务器上的目录,结果在db1.cluster.g...

凝小紫
2017/02/04
3.4K
15
CentOS7 配置 Gitlab

原文出处:枫子夜 公司在做技术选型的时候,我力排众议决定搭一套基于Git+Gitlab+Jenkins+Nginx+Tomcat+Redis的架构,无论是代码仓库管理还是自动部署对以后的项目迭代都有重大的意义。当然,...

枫子夜
2018/09/24
0
0
I-team 博客的 gitlab-runner 持续集成实践

做为一个略微看过nodejs语法,但又不懂nodejs的攻城狮,搭建hexo环境很是麻烦,要考虑到FQ、版本兼容等问题。于是乎,博主每换一个电脑,为了能继续发博客,都需要在新电脑上花一天时间重新搞...

haifeiWu
2018/07/24
0
0
382 名员工遍布 47 个国家如何炼成代码托管平台 GitLab?

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/csdnnews/article/details/84076578 对话 | 蒋 涛 撰写 | 卢鸫翔 出品 | CSDN(ID:CSDNNews) 提起“代码托管...

CSDN资讯
2018/11/14
0
0
docker入门到实战(7)使用docker快速搭建gitlab私服

下载镜像 docker pull gitlab/gitlab-ce 使用镜像 镜像中有三个目录用于保存gitlab的数据,出于安全考虑,应该使宿主机目录挂载这三个卷做持久化存储。如果出错保证数据不会丢失。 /etc/git...

编程老司机
2018/05/14
0
0

没有更多内容

加载失败,请刷新页面

加载更多

linux负载均衡总结性说明 四层负载和七层负载有什么区别

这篇文章主要为大家详细介绍了linux负载均衡的相关资料,什么是负载均衡?四层负载和七层负载有什么区别?具有一定的参考价值,感兴趣的小伙伴们可以参考一下 在常规运维工作中,经常会运用到...

天子剑毅
26分钟前
3
0
mysql in与or效率比较

在网上一直看到的是or和in的效率没啥区别,一直也感觉是这样,前几天刚好在看《mysql数据库开发的36条军规》的文章,里面提到了or和in的效率问题,文中提到or的效率为O(n),而in的效率为O(l...

whatwhowhy
27分钟前
4
0
使用docker 基于pxc镜像搭建mysql高可用集群

前置条件 docker已安装: 第一步:拉取镜像 docker pull percona/percona-xtradb-cluster:5.7.21 第二步:复制重命名镜像(可选) docker tag percona/percona-xtradb-cluster:5.7.21 pxc 第...

小海bug
32分钟前
6
0
windows安装nginx负载均衡

第一步:下载安装nginx 地址:http://nginx.org/en/docs/windows.html 下载完成,比如放在C盘根目录下: cd c:\ unzip nginx-1.15.3.zip //解压文件 cd nginx-1.15.3 //进入目录 start ngin...

你好夜故事
35分钟前
6
0
Jenkins CLI,助你轻松管理 Jenkins

本文首发于:Jenkins 中文社区 作者:Donghui Wang Jenkins CLI,简称 jcli,一个使用 Golang 开发的开源的 Jenkins 命令行工具。 它可以帮忙你轻松地管理 Jenkins。 无论你是 Jenkins 插件开...

Jenkins中文社区
37分钟前
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部