Atlassian是澳大利亚一名20岁的软件开发人员。旗下拥有知名企业项目管理平台吉拉、企业文档协作平台Confluence、看板协作工具Trello。许多大型企业采用吉拉来管理他们的敏捷开发项目，甚至Atllassian也为非技术团队推出了敏捷项目平台。许多企业习惯于敏捷管理业务、销售和业务分析团队。

根据Atlassian今年3月的财报数据，超过75%的世界500强企业是其企业用户，全球超过23万家企业采用吉拉服务管理服务管理企业内部大型系统开发项目的生命周期，有超过4万家企业，其中很多是大型企业，178家企业的年度授权订阅费超过百万美元这相当于几千人的授权订阅数，甚至是订阅数最多的超大型企业。 Atlassian每年仅来自订阅费的收入就超过13亿美元。

虽然Atlassian没有透露受此次事故影响的企业名单，只是披露受影响的企业家人数为775人，但其中有400家是活跃企业。根据外媒对受影响企业的采访结果，小的有150个牌照，大的有认购多达4000个牌照的企业。据非官方估计，在775家受影响的企业中，个人用户的累计影响超过5万。这件事也让Atlassian的市值大打折扣。从宕机到完全恢复的两周时间里，Atlassian的股价下跌了近20%，随后在5月下旬继续下跌。

(相关资料图)

Atlassian有十几年的SaaS服务运维经验，六年的SRE经验，云上常见的行业标准的容灾和恢复方案，这些都是事先找不到的。无法及时阻止4月份的大停电，无法在99.9%服务水平承诺(SLA)承诺的8.76小时内恢复。很多企业甚至等到14天才开放自己的敏捷项目数据。

为什么这个云服务提供商，SRE运维专家，不能避免这次大宕机？

大宕机事件的发生过程是一波三折，一个删除程序的误用导致灾难。

回到事发当天，4月5日上午，Team22第22届的前一天，Atlassian的年会，Atlassian会淘汰一些老app，4月5日删除这些老app。正是这个脚本程序删除了导致这次停机的旧AP。在实际删除之前，Atlassian测试了这个脚本没有问题，甚至在正规环境下尝试删除了30个客户使用的旧Ap也没有问题。

申请删除的业务团队提供了一份仍在使用这些旧AP的企业客户名单，作为脚本自动删除的目标名单。但关键的错误在于，他们提供的ID列表并没有直接提供要删除的AP的ID，而是给出了这些要删除的AP ID所在的网站ID列表，然后告诉执行删除指令的工程团队从这些网站ID中删除旧的AP。但双方沟通有隔阂，工程团队误以为这些网站id就是要删除的列表，直接应用到删除脚本中执行。4月5日，这个脚本删除的不是老AP，而是那些还在用老AP的企业的所有网站数据。

酝酿灾难的原因：想删除旧App，为什么反而删除客户的全站仪数据？

要了解误删的影响，首先要知道用APP ID删和用网站ID删有什么区别？这得从Atlassiant的技术架构说起。

Atlassiant的所有服务都部署在AWS上，采用高度分布式架构和微服务架构，在数据存储和服务架构上易于组合和复用。书架管理层和共享平台服务层设计在云基础设施上，也通过API串联了很多第三方厂商的应用。所有的微服务都部署在AWS的容器化服务上，提供一套PaaS服务，称为Micros，提供内部微服务的自动构建。公共服务部署、基础设施资源调度、数据存储管理和合规性控制都由该平台自动完成。

此外，Atlassian采用多租户架构，将域作为单个用户最基本的管理单位，也就是网站ID。企业应指定一个网站作为登录阿特拉斯服务的主要门户，并在该网站下注册其订阅的所有阿特拉斯服务。Atlassian也将这个URL称为网站容器，用于保存该企业的客户使用的所有数据、配置和应用程序。网站ID是用来标识企业网站容器的代号。

Atlassian的技术架构采用分布式架构，不仅在云基础设施上提高可用性，在应用系统层面也采用多租户微服务架构设计，兼顾灵活性和可用性。图片//大西洋

Atlassian的网站ID(企业客户网站URL)也是一个网站容器，它包含一个企业的所有数据、配置和使用。

Atlassian也用这个网站ID来作为识别一个企业用户帐号的代号，所有与这家企业有关的数据、表单、帐单，也都用这个网站ID来作为识别客户的索引，例如企业顾客提出支持工单时，这张工单就会用网站ID作为所属客户的代号。

当Atlassian业务单位提出了一份要删除老旧APP的网站ID，希望删除他们所用的老旧AP。但是负责执行的团队，误以为要删除这一批AP ID所在的网站ID。这就不只是删除了AP，而是删除了采用这些AP的企业所拥有的全部AP和数据。

4月5日7:38，开始执行旧版AP删除脚本，工程团队也没有接到任何通知，警告有企业顾客的网站遭删除，因为这是一只获得合法授权的删除。但是，不到10分钟，就有企业发现自己所用的Jira网站失联，提出第一张宕机支持工单。删除脚本在8点多执行完毕，事后调查，一口气删除了775家企业所拥有的883个网站。受影响的产品包括了Jira 产品系列、Confluence文件协作平台、Atlassian Access登入机制、Opsgenie 事件应变服务，甚至是网站状态查询页Statuspage。这些受影响企业，不只无法连线登入，甚至连要检视所用服务的运作状态页都打不开。

接连有不少顾客提出宕机工单，Atlassian决定在8:17启动重大事件管理流程，也组织了跨部门事件管理团队，找来工程部门、客户支持团队、项目管理团队和对外沟通部门，联手展开事故调查，每3小时开会一次，并在8:24将事件状态提升到「危急」状态。不到20分钟，工程团队就发现了事故的根本原因，是脚本误删数据而非黑客攻击，9:03时首度在服务状态网页中揭露发生宕机事故。

找出事故原因之后，下一步就是要尽快解决问题，恢复顾客所订阅的服务。Atlassian开始尝试建立一套标准化的复原方法，但却发现，要复原一个遭到删除的网站，得建立新网站、复原每个下游产品、服务及还原数据所需的资料，还须与各网站所用第三方生态系厂商重建连结，相关复原步骤高达70个。他们才发现，要复原这些网站的复杂性远超过他们的想像，所以在12:38时将这起事件的严重等级提升到「最高等级」，这时距离事故发生，已经超过了5小时。

Atlassian宕机后不久，越来越多顾客在Twitter上抱怨，因为Jira是许多企业用来管理敏捷开发项目的主要平台，无法使用，就等于无法进行敏捷项目的开发，连要打开项目工单来知道该处理哪些工作都没有办法。这股抱怨声浪越来越大，越来越多人发现，这起宕机事件持续时间越来越久，超过了8、9个小时，Atlassian所承诺的99.9%可用性承诺已经失守。

不少受影响的企业用户在Twitter上抱怨，他们连要向Atlassian通报宕机问题，或是申请支持工单都做不到，也有人是发出申请后，迟迟没有得到官方回应，仿佛Atlassian的服务窗口失联一样，无法通过原本的线上管道来接触。

直到事故发生后17个小时，Atlassian才发电子邮件通知受影响顾客，并开始打电话联系，对他们说明，而这时已经引起不少媒体的关注，开始大举报导这起大宕机事件。

直到事件发生后快2天，Atlassian才发布第一份宕机事件的官方公开声明。而Atlassian的合作伙伴，则还等到事故后第2天快结束时，才开始接到通知。因为宕机事故迟迟无法解决，Atlassian共同创办人也以个人名义发信，亲自向顾客说明复原进度缓慢的原因。

4月8日，也就是事件发生后的第四天，Atlassian终于成功复原了第一家受影响顾客的网站。可是，复原团队这才发现，采用第一版复原方法，需要48小时才能恢复一批网站，因为需要大量人工操作，只能分批复原，若要全面复原剩下的网站，还需要3周时间，所以，也开始改良复原程序。同一天，Atlassian也对所有工程部门实施代码冻结，禁止任何异动，来降低顾客数据不一致的变更风险

过了一天，4月9日开始启用第二套复原方法，将原本70道程序，大幅减少到只剩下30道程序。第二套做法重建顾客网站时，不是建立新的网站ID，而是直接沿用了顾客的旧网站ID，因此，大幅减少新旧ID比对的步骤，也不用再逐一与第三方程式供应商沟通，节省大量时间。这时有771个误删网站，可以改用第二套方法来复原。

不过，第二套方法还是需要大量手动操作，直到4月11日，Atlassian工程团队打造出自动化复原工具，来加速第二套方法的时间，才将复原时间缩短到12小时，这时候，Atlassian才在工单中向顾客承诺，可以在事故后2周内复原。

到了4月14日，采用第一版复原方法复原的网站达到112个网站，不再继续使用。Atlassian也打造出复原网站的完整验证脚本，不再需要人工验证，更加快了其他网站的复原速度，到了4月16日10:05 ，就完成所有网站的复原和自动验证，但还没经过顾客确认。隔天21:48，最后一位受影响顾客完成复原确认。Atlassian就在4月18日1:00宣布，受影响网站100%复原。这时，距离事故发生已经近14天，不过，宣布当时，仍有57个网站，因为复原资料的时间点过早，比原订「当机前5分钟」的复原时间点，还要更早，还需要追补后来异动的资料。

到了4月底，Atlassian发布了四月大宕机事件的完整事后分析报告。

关键词：