2022 年 4 月 5 日，星期二，协调世界时 07:46，Atlassian 收到一张支持工单，来自一位站点刚刚被删掉的客户。Atlassian 自己的监控一声没吭。这些站点是走标准流程删掉的，在监控眼里，这就是日常操作。
八分钟前，07:38，一个脚本开始运行，照着一张清单，一个站点接一个站点地删。08:01 跑完时，它已经删掉 883 个站点，分属 775 家客户。这些客户的 Jira、Confluence 和其他 Atlassian 产品，一下子全打不开了。
这活本来只是例行清理。2021 年，Atlassian 收购了一个叫 Insight 的应用，把它的功能并进了 Jira Service Management，旧的独立版就得从还装着它的客户站点上删掉。一个团队请另一个团队用现成的脚本来删。话在两个团队之间传了一手，清单的意思就变了：交过去的不是每个站点上那个应用的 ID，而是整个站点的 ID。
系统没有任何警告。删除接口站点 ID 和应用 ID 都收，收到什么就当它是对的。这个脚本还有两种模式：一种只是标记删除，数据还能找回；一种是彻底删除。据 Atlassian 首席技术官 Sri Viswanath 说，脚本运行时「用错了执行模式，也用错了 ID 清单」。
检查不是没有。脚本经过了同事评审，可评审看的是它调用哪个接口、怎么调用，没看这些 ID 指向的是什么。它也在预发环境测过，可那里根本没有这些 ID。更早一次在正式环境的运行，在 30 个站点上成功删掉了旧应用，因为那批 ID 是在传话出错之前整理好的。
4 月 6 日凌晨，Atlassian 在工单里告诉受影响的客户：问题出在一个维护脚本上，预计数据损失很小。数据这一头，按它事后的说法，确实说对了：没有哪家客户丢的数据超过五分钟。Atlassian 的备份保留 30 天，平时也常帮误删了自己数据的客户恢复。哪怕要把所有客户一次性恢复到一个全新的环境，它也做得到。
难的是把数据放回去。它从没准备过的，是把几百家客户放回正在运行的系统里。那里的每个数据存储，同时还装着别的客户的数据，这些客户还在照常干活。工程师只能从备份里把每个站点的碎片一块块手工挑出来。
第一套办法，每个站点要走大约 70 步。4 月 8 日，第一批客户拿回了站点，可照这个速度，Atlassian 估计全部恢复要三周。4 月 9 日，团队提出一套更快的办法，在事故进行中改了道。最后一批站点在 4 月 18 日恢复。对有些客户来说，这次中断长达 14 天。
与此同时，大多数受影响的客户连常规的支持表单都提交不了。脚本删站点时，把他们的联系方式也一并删了，包括每个站点的管理员是谁。而那张表单要求填一个有效的站点地址，这些地址已经不存在了。Atlassian 几小时内就在状态页上发了消息，但它在复盘里称为第一条面向外界的广泛消息的，是一条推文，要到 4 月 7 日才发出，距脚本开跑已过去大约 41 小时。
Atlassian 起初估计，受影响的客户约 400 家。最终复盘数出来，是 775 家。