一份传错的 ID 列表，让 775 家公司的 Jira 和 Confluence 凭空消失
目录
配图：AI 生成的概念示意图，非论文原图、真实现场或实验数据。
TL;DR：2022 年 4 月，Atlassian 为清理一个旧插件运行了删除脚本，却被交了「站点 ID」而不是「插件 ID」，结果整站被删。官方复盘称这不是黑客攻击，也没有数据被未授权访问；受影响的有 775 家客户，部分客户最长停摆 14 天。官方说客户丢失的数据不超过 5 分钟，但恢复速度远低于其自身目标。
这是一起 2022 年 4 月的旧事故，并非近期新闻，以下内容依据 Atlassian 事后发布的官方复盘。
本该只删一个插件
2021 年，Atlassian 收购并整合了一款名为 Insight – Asset Management 的独立应用，其功能后来内置进 Jira Service Management。于是，客户站点上遗留的旧版应用需要清理。负责的团队用了一个现成的删除脚本，但需求方给出的是云站点 ID，而不是应用 ID。
删除接口两种 ID 都接受，也不会提示你传的是哪一种。代码评审关注的是接口怎么调用，没有检查 ID 的类型；预发布环境里这些 ID 根本不存在，测试也没能发现问题。
23 分钟，883 个站点
4 月 5 日 07:38（UTC），脚本开始在生产环境运行。第一轮只涉及 30 个站点，结果符合预期；第二轮对 883 个站点逐个执行，到 08:01 结束，约 23 分钟，对应 775 家客户。官方称，其余 99.6% 以上的客户没有受到影响。
连报警的门都被删了
麻烦在于，脚本连同站点 URL 和系统管理员联系方式一起删掉了。Atlassian 的支持表单要求填写有效的云站点地址，受害客户因此无法正常提交工单。
监控也没有报警，因为这些删除走的是标准流程。首张工单 07:46 就进来了，直到 08:53 团队才确认它与脚本运行有关。公开沟通同样滞后：官方的 Statuspage 首次更新在当天 09:03，广泛的公开说明在 4 月 7 日，CEO 的致歉邮件在 4 月 8 日。复盘自己也承认，应该更早、更广泛地沟通。
慢到离谱的恢复
数据库本身有备份，大多恢复到了删除前 5 分钟的状态。慢的是把站点重建回来。第一套方案要新建站点、约 70 个步骤，每批大约 48 小时，4 月 5 日至 14 日共恢复 112 个站点；第二套方案复用原站点标识，步骤减到 30 多个，每个站点约 12 小时，4 月 14 日至 17 日恢复了 771 个站点。官方估计，只用第一套方案全部恢复大约要三周。第一批站点 4 月 8 日回归，全部在 4 月 18 日完成。
另外，57 家较早恢复的客户，部分 Confluence 和 Insight 数据被恢复到了更早的时间点，官方是在事后审计中发现的，并表示会协助这些客户找回剩余数据。复盘也承认，一小时的数据恢复点目标达到了，恢复时间目标没有达到。
为什么值得记住
没有黑客，没有入侵，只是一次沟通错位加上一个「什么都肯收」的接口。Atlassian 的改进措施包括：删除客户数据必须先走软删除、暂时禁止批量删除站点、在产品之外备份客户联系信息，并建立面向大规模事故的响应预案。
最初的估计是约 400 家客户，最终确认为 775 家，因为新增部分多为不活跃、免费或小型账户。