我们正处于Atlassian有史以来最长的一次中断中。近400家公司和5万至80万用户无法访问JIRA、Confluence、OpsGenie、JIRA状态页面和其他Atlassian云服务。
这次中断已经是第9天了，从4月4日星期一开始。阿特拉斯公司估计许多受影响的客户将在两周内无法访问他们的服务。在写这篇文章的时候，45%的公司已经看到他们的访问恢复了。与我交谈过的受影响的公司有4000个座位，与我交谈过的受影响的最小的公司有150个座位。
在这次故障的大部分时间里，Atlassian在他们的主要渠道（如Twitter或社区论坛）的沟通中一直保持沉默。直到第9天，该公司的高管们才承认了这次故障。
在公司保持沉默的同时，故障消息开始在Hacker News和Reddit等小众社区流行起来。在这些论坛上，人们试图猜测故障的原因，想知道为什么电台完全沉默，许多人嘲笑该公司如何处理这种情况。
在这段时间里，Atlassian在与客户的沟通方面也没有做得更好。受影响的公司收到了模板化的电子邮件，没有回答他们的问题。在我在推特上介绍了这次故障后，一些阿特拉斯公司的客户转向我发泄情况，希望我能提供更多细节。客户声称，公司的声明使他们似乎得到了支持，但事实上他们并没有得到支持。一些客户希望我能够帮助引起公司的注意，因为该公司除了告诉他们要等待数周直到他们的数据恢复之外，没有给他们任何细节。
最后，我成功地得到了许多受影响的Atlassian客户所希望的关注。故障发生8天后，Atlassian发布了第一份高管声明。这份声明来自Atlassian首席技术官Sri Viswanath，也是作为对我分享客户投诉的一条推文的回应。
这里谈论：
- 发生了什么？事件的时间线。
- 停机的原因。到目前为止我们所知道的情况。
- Atlassian公司的客户在说什么。他们是如何观察到故障的？这对他们意味着什么业务影响？他们会不会继续成为Atlassian的客户？
- 故障对Atlassian业务的影响。这次故障发生在一个关键时刻，Atlassian开始退役其服务器产品--该产品对这次故障没有影响--转而让客户使用其云计算产品，该产品被宣传为提供更高的可靠性。在这次漫长的事件之后，客户会信任阿特拉斯云吗？哪些竞争对手从Atlassian的失误中受益，为什么？
- 从这次故障中吸取的教训。工程团队能从这次事件中得到什么？无论是作为Atlassian的客户，还是作为向客户提供云产品的团队。
....详细点击标题
停机的原因
在过去的一周里，每个人都在猜测停电的原因。来自The Stack 等多个来源的最常见怀疑是旧版 Insight Plug-In 插件是如何被淘汰的。一个脚本应该从该插件中删除所有客户数据，但意外删除了使用该插件的任何人的所有客户数据。在第 9 天，Atlassian 既不会证实也不会否认这些猜测。
在第 9 天，Atlassian 确认这确实是他们官方更新的主要原因。从这份报告中：
“我们使用的脚本既提供了用于正常日常操作（需要可恢复性）的“删除标记”功能，又提供了出于合规原因需要时永久删除数据所需的“永久删除”功能。该脚本以错误的执行模式和错误的 ID 列表执行。结果是大约 400 名客户的网站被不当删除。”
那么为什么备份需要数周时间呢？在他们的“ Atlassian How Resilience ”页面上，Atlassian 确认他们可以在几个小时内恢复删除的数据：
“Atlassian 每季度对备份进行恢复测试，从这些测试中发现的任何问题都会作为 Jira 票证提出，以确保跟踪任何问题直到得到补救。”
但是有一个问题：
- Atlassian 确实可以在几个小时内将所有数据恢复到检查点。
- 但是，如果他们这样做，虽然受影响的约 400 家公司将取回所有数据，但其他所有人都将丢失自那时以来提交的所有数据
- 所以现在每个客户的数据都需要选择性的恢复。Atlassian 没有工具可以批量执行此操作。
他们还确认这是更新中问题的根源：
“我们（尚未）自动化的是将大部分客户恢复到我们现有（和当前正在使用的）环境中，而不会影响我们的任何其他客户。”
在中断的前几天，他们通过手动步骤恢复了客户数据。他们现在正在自动化这个过程。但是，即使使用自动化，恢复也很小，只能小批量完成：
“目前，我们一次分批恢复最多 60 个租户的客户。端到端，将网站交还给客户需要 4 到 5 天。我们的团队现在已经开发出并行运行多个批次的能力，这有助于减少我们的整体恢复时间。”
从这次故障中吸取的教训
任何工程团队都可以从这次故障中得到许多启示。不要等待像这样的故障来打击你的团队：而是提前做好准备。
事故处理：
- 有一个灾难恢复和黑天鹅事件的运行手册。期待意外的发生，并计划你将如何应对、评估和沟通。
- 遵循你自己的灾难恢复运行手册。Atlassian发布了他们的Confluence灾难恢复运行手册，但是，并没有遵循这个运行手册。他们的运行手册指出，任何运行手册都有沟通和升级指南。要么该公司没有沟通准则，要么他们没有遵循这些准则。不管是哪种情况，都是不好的。
- 直接和透明地进行沟通。阿特拉斯公司在9天之前没有做这些事情。这种缺乏沟通的做法不仅削弱了受影响的客户的信任，也削弱了任何知道故障的人的信任。虽然Atlassian可能认为什么都不说是安全的：但这是最糟糕的选择。请注意GitLab或Cloudflare在故障期间的沟通是多么透明--它们都是上市公司，就像Atlassian。
- 说出你的客户的语言。Atlassian的状态更新是模糊的，缺乏所有的技术细节。然而，他们的客户并不是商业人士。他们是选择购买Atlassian产品的IT主管和CTO......现在却无法回答系统有什么问题。通过简化信息传递，Atlassian将他们最大的赞助者--技术人员--置于无法为公司辩护的境地。- 把他们最大的赞助商--技术人员置于一个无法为公司辩护的境地。如果公司出现了客户流失，我把它大大归因于这个错误。
- 一位高管公开对故障负责。直到第9天，才有一个C级人员承认这个故障。同样，在开发者信任的公司，这几乎是立即发生的。高管们不发表声明，说明问题太小，他们不关心这个问题。我曾写过，在亚马逊，高管加入故障电话是很常见的。
- 直接与客户联系，与他们交谈。在这次故障中，客户没有感觉到被倾听，也没有人和他们交谈。他们被留下了自动信息。在黑天鹅事件中，动员人们直接与客户交谈--你可以在不影响缓解工作的情况下这样做。
- 避免什么都不说的状态更新。事件页面上的大部分状态更新都是复制粘贴相同的更新。Atlassian这样做显然是为了每隔几个小时提供一次更新......但这些并不是更新。他们让人感觉到公司没有控制好故障的发生。
- 避免静默。到第九天为止，阿特拉斯公司一直保持着无线电静默。不惜一切代价避免这种做法。
避免事件的发生：
- 为所有的迁移和淘汰工作制定一个回滚计划。在Migrations Done Well问题上，我们介绍了迁移的做法。对弃用也采用同样的原则。
- 对迁移和弃用进行模拟运行。根据Migrations Done Well这个问题。
- 不要从生产中删除数据。相反，标记要删除的数据，或使用租约来避免数据丢失。