摘自公众号:大码侯 本文系作者授权计蒜客发布，如需转载请与作者本人联系。 上周轰动一时的 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 小时工作制度是否合理，但对于脑力劳动者，违背用脑规律甚至使之处于过载疲劳状态，都会显著降低脑部的能量转换效率，还是科学用脑最为可靠，把时间用在效率最高的地方。 对此希望决策者能够意识到这个问题，而不是一味加班赶进度。这种危害已经越来越得到更多从业人员的认同了。 参考文章: 《从 Gitlab 误删除数据库想到的》 《从 gitlab 删库事件浅谈线上系统可靠性的提升》 |
注册
登录
