GitLab 数据库误删事故：为什么一家做代码托管的公司，会有五个备份却一个都用不上？

# 商业复盘备忘录：GitLab 数据库误删事故

> 为什么一家做代码托管的公司，会有五个备份却一个都用不上？
> 周期: 2017 - 2017 | 行业: 企服与SaaS
> 巅峰: 面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品
> 终局: 工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘

## 核心概览
备份的价值不在于配置了几套，而在于最近一次恢复演练是什么时候。巅峰期面向开发者的代码托管与协作平台，以开源与自托管方案在企业市场快速扩张，是同类服务中增长较快的产品；终局是工程师误在生产数据库执行删除操作，五个备份机制同时失效，最终只能从数小时前的快照恢复，丢失部分用户数据，公司全程公开直播了事故复盘。

## 社区公投头号死因
1. [产品技术] 生产环境缺少强制保护与二次确认 (1,626 票)
2. [组织管理] 备份机制未经过实际恢复验证 (1,366 票)
3. [组织管理] 生产与备份环境的权限边界不清 (1,106 票)

## 可执行教训
### 备份只在恢复演练成功过之后才算存在
> 配置了五套而没有一套验证过，等于零套。

- ✅ 推荐做 (DOs):
  - 定期做完整恢复演练并把结果纳入考核
  - 对生产库的删除操作设强制二次确认与延迟
- ❌ 绝不能做 (DON'Ts):
  - 不要把备份数量当作安全程度
  - 不要让同一批人对生产与备份都拥有无限制权限

## 救亡方案
### 先补操作保护，再把恢复演练变成常规制度 — 良略编辑部
干预时点: 2017 年 1 月 31 日误删生产数据、备份检查发现多处失效时
- 必须断腕:
  - 立即限制生产库的直接操作权限
  - 停止依赖未验证过的备份机制
  - 停止由同一角色同时掌握操作与恢复权限
- 破局动作:
  - 对生产库的删除与批量操作设二次确认与延迟执行
  - 把恢复演练列为季度固定任务并公开结果
  - 提高备份频率与恢复粒度，缩短可丢失窗口
- 预期结果: 误操作在下达时被确认环节拦截，即使发生也能在分钟级恢复，不会造成用户数据丢失。

## 社区见解
### 备份这件事，只有在你真的恢复过一次之后才成立。 — 良略编辑部 (工程师)
这次事故的连锁反应几乎是一个教科书式的清单：先在错误的库上执行了删除，接着发现五个备份机制分别因为被覆盖、版本不兼容、从未启用而失效，最后只能从六小时前的整盘快照恢复，丢掉中间的数据。每一环单看都是常见的运维疏漏，但叠在一起就说明团队从没做过完整的恢复演练。
- 如果重来一次的纠偏招式 判断一个团队的备份水平，问一句「上次恢复演练是什么时候」就够了。

---
来源: 良略 · https://www.lianglue.com/c/gitlab-database-incident