上个月，软件工具供应商Atlassian遭受了主要的网络停电，持续了两个星期，并影响了超过200,000多个客户中的400多个。停电销毁了他们的几种产品，包括Jira，Confluence，Atlassian Access，Opsgenie和SupationPage。
虽然只有少数客户在整整两个星期内受到影响，但就公司工程师发现的问题的深度以及他们不得不寻找并解决问题所需的时间而言，中断意义重大。
停电是由于Atlassian自己的员工的一系列不幸内部错误的结果，而不是网络攻击或恶意软件的结果。最后，没有任何客户损失超过几分钟的数据交易，绝大多数客户都没有看到任何停机时间。
整个Atlassian中断情况有趣的是，他们管理事件与客户的最初沟通方式，然后他们最终如何最终发表了一篇冗长的博客文章，详细介绍了关于情况。
很少有一个大规模和公共中断的供应商需要努力将发生的事情和原因拼凑在一起，并提供了其他人也可以从中学到的路线图。
在帖子中，他们仔细地描述了他们现有的IT基础架构，指出其灾难恢复计划中的缺陷，如何解决其缺点以防止未来的中断，并描述时间表，工作流程以及他们打算改善其流程的方式。
该文档是坦率的，事实的，并且充满了重要的启示，应要求任何工程和网络经理阅读。它应该用作任何依赖软件来定位和修复您可能犯的类似错误的企业的模板，并用作讨论框架，以诚实评估您自己的灾难恢复剧本。
从事件中学到的教训
当公司决定删除通过购买功能相似的软件来冗余的旧应用程序时，麻烦就开始了。但是，他们犯了一个错误，即分配两个不同但相关职责的不同团队。一支团队要求删除冗余应用程序，但另一个团队被指控弄清楚如何实际完成任务。那应该立即提出一些危险信号。
这两个团队没有使用相同的语言和参数，因此立即存在沟通问题。例如，一个团队使用应用程序ID来识别要删除的软件，但另一个团队认为他们正在谈论应用程序所在的整个云实例的ID。
第1课：改善内部和外部交流
请求网络变更的团队和实际实施他们的团队应该是相同的。如果没有，那么您需要使用可靠的通信工具来确保它们是同步，使用相同语言并具有精确度的过程。由于沟通不畅，Atlassian工程师几天没有意识到自己的错误程度。
但是跨队沟通只是问题的一部分。When Atlassian analyzed its communications between various managers and its customers, they discovered that they posted details about the outage within a day on their own monitoring systems, but they weren’t able to directly reach some of their customers because contact information was lost when the legacy sites were deleted, and other information was woefully outdated.
另外，已删除的数据包含客户填写有效的支持请求票所需的信息。解决这个问题需要一组开发人员建立和部署新的支持票务流程。该公司还承认，他们应该在中断时间表中早些时候伸出援手，直到他们对恢复过程的范围有完整的了解。
即使没有特定的时间范围，这也可以使客户更好地围绕事件进行计划。“我们应该承认我们在提供站点修复日期的不确定性，并使自己更早地进行面对面的讨论，以便我们的客户可以相应地制定计划。我们应该对我们对中断和不知道的知识保持透明。”
第2课：保护客户数据
谨慎处理您的客户数据，确保它是当前和准确的，并在多个独立的地方备份。确保您的客户数据可以在灾难中生存，并在任何剧本中包含特定的检查。
这提出了关于灾难恢复的另一点。在4月的停电期间，Atlassian错过了其恢复时间目标（显然，考虑到恢复系统所花费的几周），但设法实现了其恢复点目标，因为他们能够在实际停电前几分钟恢复数据。他们也无法选择一组客户站点并以任何自动化方式将所有相互关联的产品从备份恢复到前一刻。
他们在分析中写道：“我们四月份发生的我们的站点级删除没有可以快速自动化此事件的运行簿。”“我们有能力恢复一个站点，但是我们没有建立能够恢复大量站点的功能和流程。”
在博客的供词中，他们绘制了以前的大规模事件管理流程 - 您可以看到它具有很多活动部件，并且无法完成“处理四月事件的深度，膨胀和持续时间”的任务。
第3课：测试复杂灾难恢复方案
检查并重新检查您的灾难恢复程序，剧本和程序，以确保它们符合各种目标。确保测试各种客户基础架构的场景。这意味着要专门解决和预期更大规模的事件响应，并了解使用多个产品或依赖您应用程序的互锁系列和序列的客户的各种复杂关系。
如果您使用的是自动化，请确保您的API正常运行，并在没有时发送适当的警告信号。这是Atlassian在停电几天拖延几天时必须进行调试的问题之一。
第4课：保护配置数据
最后，存在有关如何删除数据的问题，这开始了整个中断。他们现在意识到不允许删除数据，尤其是整个网站的数据。Atlassian正在转向他们所谓的“软删除”，直到使用定义的系统回滚并通过许多保障措施，该数据才立即处理数据。
Atlassian正在建立所有系统中的“通用软删除”策略，并创建一系列标准和内部评论。软删除选项不仅仅是一个选项。在整个基础架构中对其进行测试之前，不要删除任何配置数据。