GitLab 数据库误删事故：为什么一家做代码托管的公司，会有五个备份却一个都用不上？
备份的价值不在于配置了几套，而在于最近一次恢复演练是什么时候
GitLab 数据库误删事故：巅峰期面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品；终局是工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘。
面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品
工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘
4,944 votes cast
1 plans · 1 insights
投稿会先进入待审，通过后才进入公开目录和站点地图。
Root Causes Consensus Poll
Vote for the primary fatal error that caused this enterprise to collapse.
生产环境缺少强制保护与二次确认
删除操作能在生产库上直接执行，没有审批或延迟机制
备份机制未经过实际恢复验证
五个备份中多数存在配置失效，从未被真正演练过
生产与备份环境的权限边界不清
操作与验证的分工不明，误操作缺少阻断
数据丢失后的恢复粒度不足
只能按小时级快照恢复，无法做到更细粒度的数据找回
Timeline: peak to collapse
误删生产数据
工程师在处理数据库复制问题时误在生产库执行删除操作，数据被大量删除
五个备份相继失效
检查备份时发现多个备份机制存在覆盖、版本不兼容或未启用等问题
从快照恢复
最终从约六小时前的磁盘快照恢复数据，丢失这段时间内的部分用户数据
流程整改
公司公开全程复盘并整改操作权限与备份验证流程
Four-Dimensional Retrospective Breakdown
Background & Golden Era
平台以开源方式获得大量用户，同时为企业客户提供自托管版本，在托管服务上持续扩充功能与数据规模，团队规模相对精简巅峰期的成绩单是：面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品。此时的它拥有渠道、品牌与资本的合力，看起来没有任何理由会输。
Fatal Turning Point Miscalculation
生产环境的操作缺少足够的保护与二次确认；五个备份机制中有的被覆盖、有的因版本不兼容失败、有的从未真正启用，而团队此前没有做过完整的恢复演练底层架构的缺陷被增长掩盖了很多年，真正爆发时表现为线上事故、体验崩塌与迭代停滞，修复成本远高于当年重做的代价。
Internal Culture & Bureaucratic Hubris
技术决策长期被短期交付目标绑架，「先上线，以后再改」变成永久状态，没人对架构健康度负责。
The Collapse & Aftermath
工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘。GitLab 数据库误删事故的结局不是某一次意外，而是上面这些判断在数年里不断叠加、又始终没有被纠正的必然结果。
Battle-Tested Actionable Survival Rules
Distilled practical DOs and DONTs forged from costly corporate catastrophes.
备份只在恢复演练成功过之后才算存在
配置了五套而没有一套验证过，等于零套。
- •定期做完整恢复演练并把结果纳入考核
- •对生产库的删除操作设强制二次确认与延迟
- •不要把备份数量当作安全程度
- •不要让同一批人对生产与备份都拥有无限制权限
Revival Simulation: If you were the CEO at the inflection point, how would you save it?
History cannot be rewritten, but executive decision-making can be honed. Propose decisive divestitures and strategic bets, and let entrepreneurs & VCs vote on feasibility.
先补操作保护，再把恢复演练变成常规制度
Critical intervention point：2017 年 1 月 31 日误删生产数据、备份检查发现多处失效时
- •立即限制生产库的直接操作权限
- •停止依赖未验证过的备份机制
- •停止由同一角色同时掌握操作与恢复权限
- •对生产库的删除与批量操作设二次确认与延迟执行
- •把恢复演练列为季度固定任务并公开结果
- •提高备份频率与恢复粒度，缩短可丢失窗口
备份与演练的资源投入列为固定项，恢复时间目标纳入平台可靠性指标。
误操作在下达时被确认环节拦截，即使发生也能在分钟级恢复，不会造成用户数据丢失。
Expert Post-Mortem Insights
Firsthand diagnostic analyses from entrepreneurs, VCs, alumni, and analysts.
这次事故的连锁反应几乎是一个教科书式的清单：先在错误的库上执行了删除，接着发现五个备份机制分别因为被覆盖、版本不兼容、从未启用而失效，最后只能从六小时前的整盘快照恢复，丢掉中间的数据。每一环单看都是常见的运维疏漏，但叠在一起就说明团队从没做过完整的恢复演练。
判断一个团队的备份水平，问一句「上次恢复演练是什么时候」就够了。
Business Post-Mortem Memo · GitLab 数据库误删事故
为什么一家做代码托管的公司，会有五个备份却一个都用不上？
# Business Post-Mortem Memo：GitLab 数据库误删事故 > 为什么一家做代码托管的公司，会有五个备份却一个都用不上？ > Period: 2017 - 2017 | Industry: Enterprise SaaS > Peak: 面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品 > Final: 工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘 ## Overview 备份的价值不在于配置了几套，而在于最近一次恢复演练是什么时候。巅峰期面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品；终局是工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘。 ## Top-voted root causes 1. [Product & Tech] 生产环境缺少强制保护与二次确认 (1,626 votes) 2. [Org & Culture] 备份机制未经过实际恢复验证 (1,366 votes) 3. [Org & Culture] 生产与备份环境的权限边界不清 (1,106 votes) ## Actionable lessons ### 备份只在恢复演练成功过之后才算存在 > 配置了五套而没有一套验证过，等于零套。 - ✅ DOs: - 定期做完整恢复演练并把结果纳入考核 - 对生产库的删除操作设强制二次确认与延迟 - ❌ DON'Ts: - 不要把备份数量当作安全程度 - 不要让同一批人对生产与备份都拥有无限制权限 ## Revival plans ### 先补操作保护，再把恢复演练变成常规制度 — 良略编辑部 Intervention: 2017 年 1 月 31 日误删生产数据、备份检查发现多处失效时 - Must cut: - 立即限制生产库的直接操作权限 - 停止依赖未验证过的备份机制 - 停止由同一角色同时掌握操作与恢复权限 - Breakthrough moves: - 对生产库的删除与批量操作设二次确认与延迟执行 - 把恢复演练列为季度固定任务并公开结果 - 提高备份频率与恢复粒度，缩短可丢失窗口 - Expected outcome: 误操作在下达时被确认环节拦截，即使发生也能在分钟级恢复，不会造成用户数据丢失。 ## Community insights ### 备份这件事，只有在你真的恢复过一次之后才成立。 — 良略编辑部 (工程师) 这次事故的连锁反应几乎是一个教科书式的清单：先在错误的库上执行了删除，接着发现五个备份机制分别因为被覆盖、版本不兼容、从未启用而失效，最后只能从六小时前的整盘快照恢复，丢掉中间的数据。每一环单看都是常见的运维疏漏，但叠在一起就说明团队从没做过完整的恢复演练。 - Alternative Move if Replayed 判断一个团队的备份水平，问一句「上次恢复演练是什么时候」就够了。 --- Source: 良略 · https://www.lianglue.com/c/gitlab-database-incident