GitLab 瘫痪了数小时：因更改配置失误

这次故障归咎于配置更改。

美国时间周五上午，一些用户无法正常使用 GitLab。

协调世界时（ UTC ） 16 点 34 分左右，这项代码托管服务开始向试图访问该网站的那些人返回 503 Service Unavailable （ 503 服务不可用）错误。

依赖这项服务的软件开发人员很快就开始庆祝这个突如其来的休息日。

他们还提到了盛传于系统管理员圈子当中的不在周五部署的迷信说法。

英国开发人员 Luke Warlow 打趣道：“GitLab 似乎是在周五部署配置更改的，结果搞砸了其网站。这确实很烦人，因为它阻止我在周五部署，还搞砸了我的网站。”

描述这次 IT 故障本身的问题页面在加载时返回一个错误横幅信息：“在获取事件状态时发生了错误。请重新加载页面。”

不过，用于解释故障原因而加载的页面目前被描述为“故障出在配置更改上”。

问题页面解释道：“服务目前正在恢复中，我们正在采取多项措施以便立即恢复服务，只待有针对性地解决故障的根本原因。”

影响被描述为是波及整个网站的故障，据说一些客户预计在“服务恢复后的一段时间内”无法正常使用其项目。

GitLab 的状态页面似乎归咎于谷歌云，特别指出受影响的位置是“谷歌计算引擎”。

在谷歌云上看到的唯一故障是谷歌 Kubernetes 引擎（ Google Kubernetes Engine ）在全球范围内造成的一些中断，但那只是“ GKE 集群日志中意外的额外消息 ”方面的问题，而不是系统不可用方面的问题。

GitLab 的状态页面列出以下 GitLab 服务遭到了中断：Git Operations、Container Registry（容器注册中心）、 GitLab Pages、CI/CD - GitLab SaaS Shared Runners、CI/CD - GitLab SaaS Private Runners、CI/CD - Windows Shared Runners（Beta测试版）、SAML SSO- GitLab SaaS、Background Processing（后台处理）和 Canary。

截至 UTC 时间 18 点 46 分，状态页面报告该问题仍在调查中：“我们已经实施了一个修复程序来缓解 Web/API 服务。其他服务的调查正在进行中。”

状态页面提供的最新消息显示，作为变更请求的一部分，一条旧的管道被触发，对生产环境运用了过时的Terraform计划/方案。

至少这次事件似乎没有 GitLab 在 2017 年发生的丢失生产数据那么严重，当时一名管理员在复制过程中误删除了一台服务器上的一个目录，结果导致 300 GB 的实时生产数据全部丢失。