1 月 31 日晚上恐怕是知名程式源码代管服务网站 GitLab 最长的一夜，因为一位工程师的疏忽造成大量资料流失，而又发现所有备份方案都无效而崩溃。
在太平洋时间的 31 日晚上，该公司陆续发布了如下一系列震惊大家的推特文：
We are performing emergency database maintenance, https://t.co/r11UmmDLDE will be taken offline
— GitLab.com Status (@gitlabstatus) 2017年1月31日
we are experiencing issues with our production database and are working to recover
— GitLab.com Status (@gitlabstatus) 2017年2月1日
We accidentally deleted production data and might have to restore from backup. Google Doc with live notes https://t.co/EVRbHzYlk8
— GitLab.com Status (@gitlabstatus) 2017年2月1日
幕后完整的故事是这样子的：当晚 GitLab 的工程师们已经花了很长时间对抗垃圾讯息的发送者（spammer），这些大量垃圾讯息已经严重影响到数据库的稳定性跟服务速度，甚至严重到锁死数据库的写入功能。更严重的是二号数据库连复制都有困难了，跟上线的一号数据库的同步已经严重延迟，甚至拒绝连线一号数据库。线上处理的工程师里，有一位工程师的时区位于荷兰，当时荷兰已是深夜，身心俱疲的他决定把不听话的二号数据库资料全部删除再重建。
他本意是要对二号数据库服务器特定目录下 rm -rf（Unix 系的指令，不经 double check 就可以强制删除所在目录下的所有资料）指令，结果执行 1 秒或 2 秒后，猛然发现目标服务器弄错了，是正在线上服务中的一号服务器而不是有问题的二号！
这就好像空难电影里，双引擎客机要处理故障的右引擎时，却把维持飞机动力的左引擎给关掉了。
事发后的紧急处理
紧急取消指令后，300GB 的资料被删到只剩下 4.5GB。而最后一个潜在可用的备份是 6 小时前手动操作的，一时之间连网站都连不进去了。根据该公司 Google docs 的维护纪录在最新的讯息提到：“这个事件影响了网站数据库（包括 issue 问题和 merge requests 合并请求），但不影响 git repos（git 版本管控档案库和 wiki 服务）。”
由于不是所有资料都遗失了，所以对用户来说还是稍感安慰，但是该文件在“遇到的问题”（Problems Encountered）小节里，最后总结：
“因此，换句话说，部署的 5 个不同备份／还原技术中，没有一个能可靠地工作或第一时间还原回来，我们只能从 6 小时前有效的备份还原。”
看到这句以后，仿佛全世界所有人的脸都震惊地冻结好几秒，这有点像泰坦尼克号的沉没是连续好几个安全机制同时失常。该公司只能坦诚地总结了这些错误（原文刊登）：
- LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage.
- Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size.
- SH: It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.
- Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
- The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
- The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented
- Our backups to S3 apparently don’t work either: the bucket is empty
更糟糕的是，GitLab 去年曾经公开发表一件事：该公司本来使用的云端已经超载不够用了，要构筑和运行自己的 Ceph 云端。GitLab 的基础设施领导人 Pablo Carranza 表示，决定采用自己的基础设施“将使 GitLab 更具备高效能、一致性、可靠性，因为我们将拥有更多整体基础设施的所有权。”
回顾完 GitLab 去年的决策，再看这次发生的意外灾难最新报告，实在很尴尬。在编写本文时，GitLab 表示：
- ±6 小时的资料遗失了
- 大致上，受到影响的有 4,613 个常规专案、74 个专案分叉（fork）和 350 个导入（import），总共 5,037 个项目。 由于 Git 储存库没有遗失，我们可以重建这些专案在意外发生前所有的用户／群组，但是我们无法恢复这些项目任何 issue 问题。
- ±4979（所以 ±5000）注解遗失了。
- 可能有 707 个用户不见了，很难从 Kibana 日志中确定。
- 1 月 31 日 17:20 之前创建的 Webhook 被复原了，但在此时间后创建的则遗失了。
应有妥善 sop 或防呆机制
GitLab 成立于 2014 年，获得 2,000 万美元的风险投资，客户包含 IBM、Macy’s、ING、NASA 、VMWare 等。在本周，这些投资者的内心恐怕比其用户更加忐忑不安。
GitLab 这事件发生以后，突显了几个议题，除了网站资料备份机制的漏洞，可能还有工程师的超时工作（导致判断失常）以及工作纪律问题：sudo rm -rf 这样最高权限不经 double check 就强制执行的指令，在使用时应该要有适当的 sop 或更好的权限防呆。这事件反映出，除软硬件设备外，人员的良善管理更为重要。
亡羊补牢为时不晚，GitLab 展现诚意以 YouTube 直播与 Twitter 将讯息公诸于网络，但是看来 GitLab 必须非常努力，才能挽回客户与投资者对该公司的信心。对其他仰赖资讯科技的公司而言，相信这也是很好的借镜。
- GitLab.com Database Incident
- GitLab.com melts down after wrong directory deleted, backups fail
- GitLab suffers major backup failure after data deletion incident
（首图来源：shutterstock）
