前情概要

GitLab公司简介

尽管GitHub的成功毋庸置疑，但是它还不够完美。

于是2011年，来自荷兰的程序员Dmitriy Zaporozhets开发了另一个代码管理工具——“GitLab”，起初这个工具只是他自己用来解决现有工具处理不了的问题。之后考虑到别人可能也有类似的问题，Zaporozhets便把GitLab的源代码免费发布到网上。

2013年，GitLab建立起了自己的免费软件交流社区，之后Zaporozhets与现任首席执行官Sytse “Sid” Sijbrandij一起把GitLab发展成为正式的公司。

时至今日，GitLab已经成为不少财富500强企业的首选代码存储库。加强的安全性和管理控制与迎合IT部门的软件环境为GitLab赢得了大批企业粉丝。

(via：网络)

GitLab项目简介

GitLab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。

它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。

(via：开源中国)

事件经过

一个叫做YP的小可爱在给公司线上db做负载均衡，做着做着碰到了DDoS攻击，等攻击完了发生了可怕的事，db2有差不多4G的数据没同步上生产库(以下称生产库为db1)，YP小可爱锤了10遍胸口也没使db2同步上那4个G的数据，于是他想到了一种横竖横的方法，删了db2的数据，重新从db1同步（类似修电脑常用的重装系统的方法，我常用😂）。

于是搞得快要昏古起的YP同学敲下了【rm -rf】命令，只不过他敲在了db1上，并完美的按下了回车去喝咖啡了。

等到发现并按下Ctrl+C的时候，300G数据已经删除的所剩无几了（还剩4.5G）。

那怎么办的，公司有五种备份机制，恢复就好了吧？

1
2
3
4
5
数据库的同步，没有同步Webhook
硬盘快照，没做数据库的快照
pg_dump的备份，用9.2的版本去dump 9.6的数据，导致没有dump出数据
S3的备份，完全没有备份上
人肉备份，可能是因为懒。。。

(Webhook科普)

最后他们发现有个6个小时前的备份，勉强用吧。。。

丢失的数据

  • 粗略估计，有4613 的项目， 74 forks, 和 350 imports 丢失了；但是，因为Git仓库还在，所以，可以从Git仓库反向推导数据库中的数据，但是，项目中的issues等就完全丢失了。
  • 大约有±4979 提交记录丢失了（陈皓注：估计也可以用git仓库中反向恢复）。
  • 可能有 707 用户丢失了，这个数据来自Kibana的日志。
  • 在1月31日17:20 后的Webhooks 丢失了。

（via：酷壳）

值得赞扬的地方

事件发生后公开处理：

  1. 整个事件经过，第一时间放在了 Google Docs 上
  2. Twitter 同步更新恢复进度
  3. YouTube 直播恢复过程，直播聊天很欢快（我在B站看的搬运）

透明处理获得了许多外部的帮助

公司决定不会开除YP小可爱 （但惩罚是听10个小时的Nyan Cat，祝安好😊）

想办法通过日志等恢复丢失的6个小时内的数据

一些个人想法及反思

【从删库到跑路教程】最近发生的很多，比如前不久网易就发生了，导致《炉石传说》游戏回档到前一天，这些都让大伙不得不开始重视此类事件。（听说阿里内部也经常发生🤔）

为何会发生

会发现，这样的事件都是人为不慎的误操作导致的。

如何避免

他人的建议：

  1. 一个人操作，另一个人在旁看，有问题提醒

增加了人力成本，时间成本，效率成本，并且依旧会出事，两个人也会因为疲惫等问题出错。

  1. 使用mv代替rm

规范需要有学习成本，并且依旧是人在实施，可能在某些情况依旧会使用rm导致出错。

  1. 增加权限

有权限的人依旧会出事啊，现在出错的人不都是有权限的人吗？

  1. 系统中碰到rm这种命令增加二次确认

二次确认也挡不住我不听使唤的双手啊！！！

个人意见

  1. 依旧做好备份工作
  2. 做好相关的文档工作
  3. 定期检查备份是否正常
  4. 经常live下，实践下看灾备系统是否能正常
  5. 备份要多节点，多种方式，防止各种问题
  6. 既然人工误操作问题不能完美解决，就让灾备系统完美运行吧

Ask 5 Whys

1
2
3
4
5
6
7
8
9
10
11
12
13
14
你需要找到正确的团队来完成这个故障反思。
使用纸或白板而不是电脑。
写下整个问题的过程，确保每个人都能看懂。
区别原因和症状。
特别注意因果关系。
说明Root Cause以及相关的证据。
5个为什么的答案需要是精确的。
寻找问题根源的步骤，而不是直接跳到结论。
要基础客观的事实、数据和知识。
评估过程而不是人。
千万不要把“人为失误”或是“工作不注意”当成问题的根源。
培养信任和真诚的气氛和文化。
不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。
当你给出“为什么”的答案时，你应该从用户的角度来回答。

（via：Wikipedia）

趣闻

微软核毁灭恢复演练
微软核毁灭恢复演练

佩服这种核弹毁灭了，第二天依旧勤奋工作的小可爱。

今天立春了，祝大家春暖花开！

最后送大家一本书，以便及时应对不时之需：

mysql从删库到跑路
mysql从删库到跑路