1月31日晚上恐怕是知名程序源码代管服务网站GitLab最长的一夜，因为一位工程师的疏忽造成大量资料流失，而又发现所有备份方案都无效而崩溃。
更严重的是二号数据库连复制都有困难了，跟上线的一号数据库的同步已经严重延迟，甚至拒绝连线一号数据库。线上处理的工程师里，有一位工程师的时区位于荷兰，当时荷兰已是深夜，身心俱疲的他决定把不听话的二号数据库资料全部删除再重建。
他本意是要对二号数据库服务器特定目录下rm-rf（Unix系的指令，不经doublecheck就可以强制删除所在目录下的所有资料）指令，结果执行1秒或2秒后，猛然发现目标服务器弄错了，是正在线上服务中的一号服务器而不是有问题的二号！
这就好像空难电影里，双引擎客机要处理故障的右引擎时，却把维持飞机动力的左引擎给关掉了。
紧急取消指令后，300GB的资料被删到只剩下4.5GB。而最后一个潜在可用的备份是6小时前手动操作的，一时之间连网站都连不进去了。根据该公司Googledocs的维护纪录在最新的讯息提到：“这个事件影响了网站数据库（包括issue问题和mergerequests合并请求），但不影响gitrepos（git版本管控档案库和wiki服务）。”
看到这句以后，彷佛全世界所有人的脸都震惊地冻结好几秒，这有点像铁达尼号的沉没是连续好几个安全机制同时失常。该公司只能坦诚地总结了这些错误。
更糟糕的是，GitLab去年曾经公开发表一件事：该公司本来使用的云端已经超载不够用了，要构筑和运行自己的Ceph云端。GitLab的基础设施领导人PabloCarranza表示，决定采用自己的基础设施“将使GitLab更具备高效能、一致性、可靠性，因为我们将拥有更多整体基础设施的所有权。”
回顾完GitLab去年的决策，再看这次发生的意外灾难最新报告，实在很尴尬。在编写本文时，GitLab表示：
±6小时的资料遗失了
大致上，受到影响的有4,613个常规项目、74个项目分叉（fork）和350个导入（import），总共5,037个项目。由于Git储存库没有遗失，我们可以重建这些项目在意外发生前所有的用户／群组，但是我们无法恢复这些项目任何issue问题。
±4979（所以±5000）注解遗失了。
可能有707个用户不见了，很难从Kibana日志中确定。
GitLab成立于2014年，获得2,000万美元的风险投资，客户包含IBM、Macy’s、ING、NASA、VMWare等。在本周，这些投资者的内心恐怕比其用户更加忐忑不安。
GitLab这事件发生以后，突显了几个议题，除了网站资料备份机制的漏洞，可能还有工程师的超时工作（导致判断失常）以及工作纪律问题：sudorm-rf这样最高权限不经doublecheck就强制执行的指令，在使用时应该要有适当的sop或更好的权限防呆。这事件反映出，除软硬件设备外，人员的良善管理更为重要。
亡羊补牢为时不晚，GitLab展现诚意以YouTube直播与Twitter将讯息公诸于网络，但是看来GitLab必须非常努力，才能挽回客户与投资者对该公司的信心。对其他依赖资讯科技的公司而言，相信这也是很好的借镜。