这家软件届的爱马仕遭遇了成立 5 年来的最大故障(故障这家年来遭遇成立)

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

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

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

故障时间线

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

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

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

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

故障原因

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