打开网易新闻 查看精彩图片

2017年1月31日晚，GitLab的一位工程师在排查数据库同步延迟时，把rm -rf敲在了生产环境。300GB数据瞬间蒸发，包括用户代码仓库、issue记录、合并请求——相当于一家代码托管平台的全部家当。

按剧本走，这该是"从备份恢复，2小时上线，发个公告道歉"的标准流程。但GitLab的5层备份体系，层层失守。AWS的磁盘快照因为API权限问题停在了几天前；Azure的异地备份因配置错误从未真正运行过；而那位工程师试图同步数据时，恰恰覆盖了本应保命的第三份副本。

CTO Sid Sijbrandij事后复盘时说了句扎心的话：「我们以为备份是自动的，但没人验证过它们能不能用。」

最终恢复耗时18小时，期间6小时完全无法写入新数据。GitLab被迫直播整个修复过程，工程师在YouTube上一边敲命令一边解释进展——这种"公开处刑"式的危机公关，反而成了行业经典案例。

事后他们加了条铁律：每月随机抽一份备份做真实恢复演练。毕竟，备份存在的意义不是让人安心，而是真的能用。