ReaderMX.
ITPUB

因为意外删库，这家软件届的爱马仕遭遇了成立 5 年来的最大故障

I天舟约 5 分钟

Image

软件里的爱马仕

Image

Image

Linear 是硅谷这两年涌现出的一家明星公司。它做的是类似于 Jira, Asana 的项目管理工具，但定位聚焦在软件研发的项目管理上。Linear 很早就实现盈利了，Vercel，Arc 浏览器，Mercury 这些当红公司也都是 Linear 的客户。

Image

因为创始人强大的设计背景，其在创办 Linear 前曾先后负责过 Coinbase 和 Airbnb 的设计团队。所以 Linear 的产品设计尤其突出，以致于在行业里掀起了 Linear style 的设计潮流。

Image

而就是这样一支全身散发着光环的顶级硅谷团队，也在前不久迎来了 5 年公司历史上最大的一次故障。而元凶依然是我们熟悉的桥段「删库跑路」

Image

故障时间线

Image

目前 Linear 团队已经在官网公开了完整的复盘报告。下面我们来详细梳理一下时间线：

1 月 24 日

  • 04:47: 全量备份完成 (事发前)。
  • 07:01: 造成数据丢失的变更合并入主干。
  • 07:20: 变更完成。
  • 07:52: 发现异常，开始自查。
  • 08:10: 启动严重事故预案，呼叫更多的工程师。
  • 08:36: 更新公开渠道, 包括 status page 和 X，提示正在调查数据访问问题。
  • 09:20: 进一步更新。
  • 09:56: Linear 进入维护模式，防止进一步的变更操作，并且开始从备份进行恢复。
  • 10:48: 数据库恢复到 4:47 的备份，Linear 重新开始可以访问。
  • 11:09: 更新 Status page 到观察状态。
  • 11:30: 开始恢复 4:47 到 9:56 之间的数据。
  • 13:50: 给 4:47 到 9:56 之间新建了 workspace 的用户发送了邮件，因为 Linear 无法重建这些 workspace。

  • 15:35: 给所有受到影响的用户和 workspace 管理员发送邮件，告知故障的信息和恢复方式。

1 月 25 日

  • 14:00: 通知管理员上线了专门的数据还原页面。
  • 14:25: 修复了数据还原页面的 bug，强制客户端刷新 (这又打挂了 API 导致了应用加载的问题).
  • 16:40: 数据恢复试运行启动。
  • 17:49: 正式的数据恢复开始。
  • 19:48: 恢复了 98% 受影响的 workspace。

  • 23:20: 恢复了 99% 受影响的 workspace。

1 月 26 日

  • 07:37: 除了一个 workspace 之外，所有的都恢复了。

  • 08:39: 完成了最后一个 workspace 的恢复。

Image

故障原因

Linear 使用的是 PostgreSQL 数据库，它官网上没有提。但在另一个生成 PG 测试数据的产品 snaplet.dev 的官网上，列了 Linear。
Image
导致删数据的是这条语句
Image
CASCADE 关键词会把所有有外健关联到 new_table 的表数据都清空掉。
Image
上面我们简单模拟了一下场景，可以看到当我们 TRUNCATE t CASCADE 后，会把 ref_t 的数据也都清空。我们看到通过命令行操作是有提示的，但是变更生产环境的流程通常不会采用命令行直连的方式。
Image
Linear 采用的是主干开发，要变更的 SQL 脚本是保存在代码仓库里的。每次变更时，先提交 SQL 语句进行审核，审核会进行一些 CI 的自动检查和人工审核，没有问题后，SQL 脚本合并入主干，然后触发变更。因为代码发布和数据库变更是分离的，为了保持代码能同时兼容新旧两个数据库版本，会使用 feature flag。
Linear 的 CI 自动检查没有捕捉到这个问题，因为 CI 里没有针对 TRUNCATE 的规则。而在本地测试和人工审核时也都没有发现这个问题，也是因为这个 TRUNCATE 的隐蔽性更强。Linear 这次是在开发一个新功能时从现有的生产数据库表里创建了一份测试数据库表。工程师在测试完成后，打算清理测试数据库表。但因为生产数据表也关联了测试数据表的外键。所以 TRUNCATE 测试数据表时，也把生产数据表跟端掉了。
Image

故障排查和恢复

因为 Linear 使用了好几层缓存，所以在误删了生产数据后，客户端因为缓存的关系，还没有直接报错，识别到问题的时间就靠后了些。不过 Linear 因为本身要实现同步的需要，把用户的每一次操作都以日志的形式记录了下来，这部分的数据是单独存放的，所以他们可以基于 4:47 的全量备份，回放所有的用户操作。但还是会有少部分操作，因为冲突的原因是无法自动回放的，这就还是需要用户手动介入。另外 Linear 的 PostgreSQL 数据库是开启了 Point-in-time recovery (PITR)，但因为团队之前没有测试过 PITR，所以在恢复时没有选择这个方案，不然的话，其实可以通过 PITR 恢复到 7:01 这个变更发生的时间点，然后再回放接下来的用户操作。这样可以缩小回放的数据量。
Image

故障影响面

所有用户都经历了 1 个小时的不可用，这段时间 Linear 在从备份中恢复数据。Linear 在 36 小时内恢复了 99% 的误删数据，剩下的因为冲突的原因没有办法自动解决。Linear 也说这是它 5 年历史上最严重的一次故障。
Image
从故障发生的 1.24 到发出复盘报告的 1.30，整个团队显然是在连轴转 (work around the clock)。
Image
Image

故障反思

Linear 自己列了如下的改进措施：
  • 剥夺所有用户在生产数据库上的 TRUNCATE 权限。
  • 改进如何创建和执行数据库的变更操作。其中包过通过 DBA 的审核实践，和代码审核分离，以及自动检查高危操作。
  • 改进预发环境的数据库变更测试流程。
  • 构建和演练使用 PITR 的数据恢复流程。
  • 改进内部事故处理的流程。
  • 改进数据完整性检查。

  • 给 Linear 添加只读模式。这样即使数据库不可写时，依然可以能让用户访问。

Linear 在意识到问题的第一时间就完全公开了所有情况，整个复盘报告也非常详细，对于其它研发团队也是一份很好的参考。所谓的 blameless postmortem（对事不对人的复盘）在这个报告中体现的淋漓尽致。

Image

KEEP THE THREAD GOING

更多来源文章