抢修反而错删！GitLab损失300GB正式环境资料，5千专案遭波及

全球最大开源程式码平台GitHub的竞争对手GitLab，昨日惊爆工程师team-member-1（GitLab匿名处理，简称甲工程师）误删近300GB的正式环境资料，GitLab也紧急启动修程序，除了利用Google Doc即时更新维修进度外，甚至也利用YouTube全程直播长达8小时的维修数据库过程。

在这次事件中，GitLab总共损失了6小时的资料，包含开发Issue、合并请求、专案留言等档案。GitLab表示，此次总有707名使用者遭受波及，5,037个开发专案受到影响。不过GitLab强调，由于Git储存库并未受到损害，站方仍然有能力重建在误删事件发生前，系统所储存的专案，“但是我们无法复原这些专案相关的Issue。”

GitLab也在官方部落格上，按照时间顺序，揭露此事件的来龙去脉，以及站方做出的相对应策略。根据GitLab，此事件总共可以分成3大阶段。

第一波事件：不当使用者试图瘫痪数据库

GitLab表示，在世界协调时间（UTC）1月31日晚上6点，站方发现不当使用者（spammer）大量建立程式码剪贴簿（Snippet），利用此手段攻击数据库，使其运作变得不稳定。此时GitLab已经开始介入，除了了解事件外，也要进行反击。到了晚上9点，由于GitLab数据库承受过多资料写入，写入程序中已经开始产生锁死（lockup）现象，导致站方系统发生无法进行存取的情况。

面对这群不当使用者的攻击，GitLab祭出大招，锁定其IP位置进行封锁外，也移除不当使用者的账号。GitLab表示，其中1名使用者，还利用GitLab储存库（Repository），假作为CDN服务，让4万7千个IP地址都使用单一账号登入，“导致数据库的工作流量相当大。”

第二波事件：数据库运作近乎停摆

GitLab表示，到了晚上10点，已经开始接获使用者通报，“因为数据库复制程序Lag的太严重，几乎可说是停止运作”，延迟写入的资料已经达4GB之多。

而GitLab也表示，数据库停止运作的原因在于，1号数据库的流量负载过高，“无法即时将资料写入至2号数据库。”

在第二阶段中，GitLab首先尝试修复2号数据库，但是它并无法连线至1号数据库，“因为系统预设参数max_wal_senders 中，待命服务器连线数目过低。”

根据PostgreSQL的官方文件的定义，开发者可以透过max_wal_senders，限制当前待命服务器数目的最大值。另外，此参数也不可以高于参数max_connections的设定，限定PostgreSQL数据库服务器连线数目的最大值。

但即便甲工程师试图已经将最大连线数，从2千调高至8千，但是2号数据库仍然无法开始执行复写程序。

第三波事件：误删数据库的惨剧发生

当晚时间11点，当时决定要下班走人的甲工程师认为，应该是肇因于PostgreSQL档案目录的问题，才无法使用备份指令pg_basebackup进行复原，甲工程师决定将该Directory移除。

但是在甲工程师下了清除指令后，才惊觉他并没有切换目录，而是直接在储存正式环境资料的1号数据库执行。虽然他终止了该命令，但是为时已完，300GB的资料，已经删掉绝大部分，只剩下4.5GB。

多方备援手段皆不管用

按照常理推论，即使发生如此惨剧，GitLab其他的备份管道也应起作用，不至于无法复原资料。但GitLab坦承，虽然站方拥有LVM快照、日常备份、Azure硬盘快照，以及AWS S3等多种备份机制，“但复写程序真是脆弱的不得了”，除了容易出错，相关文件归档机制也不佳。GitLab表示，即使拥有5个备援管道，“没有一个运作可靠。”

在误删的惨剧发生后，GitLab已经展开修复行动，试图从Staging数据库中寻找遗失的资料。在此次事件中，虽然Git储存库未受到影响，“遗失正式环境资料对我们是无法接受的。”GitLab也预计在数天后，公开宣布此事成因及未来的应变措施。

虽然GitLab犯下了相当严重的失误，但是站方不仅第一时间就坦承，同时还利用Google Doc公开维修进度，以及YouTube直播维修数据库过程。这次GitLab事件的处理，也获得外国社群的赞许，称赞其大方面对错误，更表示，意外难免发生，而GitLab应该以此次事件为借镜，继续往前走。