2017年1月31日，UTC时间23:25，一名疲惫的GitLab工程师敲下一行命令。6小时后，他会在YouTube上被3000万人围观"社死"现场。
这不是段子。这是DevOps史上最昂贵的手滑之一——约6小时的用户数据（问题、合并请求、评论、代码贡献）瞬间蒸发。
但GitLab接下来的操作，让这场事故变成了行业教科书。
那行命令是怎么敲错的
当晚的工程师正在处理数据库复制延迟问题。生产环境和测试环境的服务器命名几乎一致，终端窗口来回切换，肌肉记忆在凌晨的疲惫中背叛了他。
原本要删除测试库目录的rm -rf，落在了生产环境的PostgreSQL主库上。
GitLab后来复盘时坦承：五个备份机制，没有一个在关键时刻管用。 Azure磁盘快照因API版本问题失效，S3备份停在了2016年10月，数据库复制延迟导致流式备份不完整。那句灾难恢复领域的老话——"你没测试过恢复，就等于没备份"——在此刻显得尤为刺耳。
凌晨3点的决定：开直播
事故确认后，GitLab没有走常规路线——没有凌晨发声明然后装死，没有"技术故障正在排查"的官话。
凌晨3点，他们打开了YouTube直播。工程师Ypirca对着镜头解释发生了什么、正在尝试什么、为什么上一个方案失败了。弹幕里飘过同行的建议、用户的愤怒、也有" respect"的致敬。
与此同时，一篇标题为《GitLab.com数据库事故》的Google Doc开始实时更新，详细到每一分钟的操作日志。这份文档至今仍是DevOps社区的事故响应范本。
代价与遗产
最终，GitLab从6小时前的快照恢复了数据，丢失了那6小时内的用户操作。CEO Sid Sijbrandij在事后采访中表示：「透明不是选择，而是义务。我们的用户有权知道他们的数据发生了什么。」
这场事故的直接影响是GitLab强化了备份验证流程，间接影响更为深远——它证明了技术故障可以与人性化沟通共存。此后，"GitLab式透明"成为行业术语，指代那种不遮掩、不甩锅、把用户当作成年人的沟通方式。
七年后的今天，当某云服务再次"删库"却只发一条"部分用户受影响"的公告时，评论区总会有人贴出GitLab的YouTube直播链接。那个凌晨的社死现场，反而成了信任资产。
如果你的团队在凌晨3点搞砸了生产环境，你会打开摄像头，还是打开律师函模板？
热门跟贴