Atlassian云服务宕机事故究竟给了我们什么启示？

287 2023-07-20

敏捷 Atlassian 事故 ID 停用

本文约3200字，阅读约需8分钟。

4月5日发生的Atlassian某些云服务宕机的事故在国内外引起了不小的波澜。本次宕机涉及Jira Work Management, Jira Service Management, Confluence, Jira Software, Atlassian Access和Opsgenie，据官方报告，影响的客户约400个，截止到本文发表时刻（4月15日20时37分），已经为其中55%的客户恢复了功能。

此次事故影响虽然有限，但因其解决时间长，没能满足其自身定义的SLA（Premium Cloud Products每月正常运行时间百分比99.9%，Enterprise Cloud Products每月正常运行时间百分比99.95%），并且最终用户的数据是否真正能够完好无损也成了大家讨论的焦点之一，信誉受到一定影响。

出现这样的事情，谁也不愿意看到。Atlassian能做的就是尽快解决问题，最大程度降低此事的影响，并且尽快让大家从这起突发事件的情绪中走出来。而我们能做的是，从整个事件的处理中，看到哪些是值得学习的，哪些是可以吸取教训的。

究竟发生了什么事？

根据官方解释，有一款用于Jira Service Management和Jira Software的插件叫做 "Insight – Asset Management"（参考资料1），已经被Atlassian作为原生功能完全集成到了产品中。从2023年2月3日以后，Jira Service Management 4.14或者Jira Software 8.14及以前的版本都无法以插件的形式安装Insight了。为此，Atlassian需要为客户停掉作为插件存在的Insight应用。Atlassian的工程团队计划使用一个现有的脚本来做这个停用的操作。于是麻烦就来了。

我们从事故的发生能学到什么？

事故之所以发生，官方提供的根本原因有两个（参考资料2）：

1. 沟通出现问题。请求停用的团队和运行停用的团队之间存在沟通问题。请求停用的团队没有提供想要停用的应用的ID，而是提供了想要停用的应用所在的整个云站点的ID。

这一沟通问题是非常典型的：

首先，这不是一个全功能团队，请求停用的团队和运行停用的团队是两个团队，这样就会导致团队间存在工作传递和交接，无论从效率上还是从准确度上，都为出现偏差留下了隐患。

其次，他们显然没有进行面对面的沟通，对于为什么要进行此次操作，执行方并没有透彻理解，只是机械照做，连ID也需要请求方提供。设想一下，如果请求方只是向执行方说明想要停用的应用名称以及停用的原因，其他一概都由执行方来自主进行（包括确定ID），是不是此事故发生的概率就会大大降低。

再次，看起来校验过程缺失或缺乏有效性。把应用的ID写成了整个云站点的ID也没有在请求方内部被发现，而执行方又只是机械执行，没有确认请求的原因并且再次对ID进行校验。

最后，管理的自动化程度有待提高。如果有非常好的配置管理，以及运维的后台保障，ID仅仅是后台的配置项之一，整个停用应用程序的过程应该是前台的一键操作，不需要请求方提供并传递应用的ID，也就不会出现错误。

2. 脚本的使用有问题。他们使用的脚本具有两种能力：“标记删除”能力，这种能力用于日常的操作（如需要还可以恢复）；同时还具有“永久删除”能力，这种能力用于因合规性要求而需要永久删除数据时。然而他们在执行脚本时，使用了错误的执行模式和错误的ID列表。结果导致大约400个客户的网站被不当删除。

这里虽然使用了脚本，但是显然在执行模式和ID列表方面出现失误。那么这里有两种可能性：

执行模式和ID列表是不是都是以数字或字母形式存在的，如果是这样，操作人员因为记忆的错误或者手误都有可能无意中导致事故。如果把这些都翻译成更友好的自然语言展示给操作员，而把晦涩易错的数字或字母通过配置管理藏在后台，是不是就可以更大程度减少事故的发生。

当然，校验过程的缺失或缺乏有效性，也会增加出问题的概率。

另外，在删除数据的时候是否有足够的警示性提示，让操作人员再次确认可能造成的影响，以及是否要继续执行删除操作。

是否考虑将脚本的功能分开，防止未来因为执行过程的混乱导致误用脚本的选项酿成大错。

我们从事故的恢复能学到什么？

对于数据恢复的速度问题，显然这次的时间是比较慢的，官方也给出了解释。Atlassian确实在多个AWS 可用性区域（AZ）中提供并维护一个同步备用副本。AZ故障切换是自动化的，通常需要60-120秒。他们还维护了安全的备份，这些备份能够帮助数据恢复到30天内的任意时间点。

然而Atlassian备份恢复的自动化程度不足，导致他们当前只能使用这些备份，定期回滚意外删除自己数据的单个客户或一小部分客户。而且，如果需要，他们也可以立即将全量客户恢复到新环境中。但他们没有能力在不影响任何其他客户的情况下，将一大部分客户恢复到现有正在使用的环境中，因为这需要非常强大的自动化恢复能力。

在Atlassian的云环境中，每个数据存储都包含来自多个客户的数据。由于此次事件中删除的数据只是其他客户继续使用的数据存储的一部分，Atlassian只能手动从备份中提取和恢复单个数据。每个客户站点恢复都是一个漫长而复杂的过程，需要在站点恢复时进行内部验证和最终客户验证。这就是为什么我们看到事情已经过去十天了，恢复工作仍在继续。

可见，自动化程度对于企业，特别是对于为诸多客户提供服务的企业来说有多么重要，时间就是金钱，时间就是企业的信誉甚至是生命。不知道Atlassian在这次事故发生前是否意识到了自身自动化程度的不足，不过我们看到就在事故发生以来的这段时间，Atlassian已经通过加强自动化手段提升了恢复的效率，赢得了很多的时间。对于其他企业来说，这个事故为我们敲响了警钟，我们要自查自身的灾难恢复水平，看是否可以在自动化方面更早更快地再上一个台阶。

总结与升华

总之，Atlassian的事故是值得大家反思的。企业都是为了满足用户的需要而存在的，能够连续不断地、安全地为用户提供服务，大多数时候比多提供几个新功能更加重要，而服务中断后恢复的速度，在用户的心中同样具有举足轻重的作用。

然而我们也发现，很多企业在这些方面的投入严重不足，无论是时间、人员还是资金。他们把大量的资源投入到开发新功能上，那些小概率事件常常被人忽视，甚至是给人一种不值得投入太多的错觉，导致在有些关键时刻错失良机。

同时，我们也看到，Atlassian事故的发生，有技术的因素，但更重要的是管理上出了问题。从上面的分析可以看出，无论是流程的合理性、完备性，还是未雨绸缪的计划性，以及各方面资源的投入都有非常大的提升空间。另外，在应对突发情况时，组织在各方面的响应能力，如技术资源和人力资源以及资金的调度能力，也体现了企业的柔性程度，即敏捷程度。

事故也许只是在单点位置发生，事故也许只是在少数的时间点发生，然而这背后，体现的是整个企业方方面面的能力，我们要相信偶然中往往暗藏着必然。我们常说业务敏捷，唯有以用户为中心，着力打造企业的柔性，为用户提供高质量和安全的服务的同时，不断快速响应用户、市场、以及可能的各种意外情况的发生，才能让我们的企业立于不败之地！

值得欣慰的是，Atlassian在事故发生的早期就在官网的状态更新页面（参考资料3）进行状态跟踪，及时通报进展。在胶着状态的时候，以2-3个小时的时间间隔更新，再后来事情趋于明了，时间间隔延长至6个小时，再后来时间间隔变成了1天。高频而透明的更新，有助于降低焦虑，管理利益相关者的期望，同时，也体现了Atlassian实事求是的态度，以及为客户投入人力和精力的专注。我们祝愿Atlassian能够早日将数据完全恢复，将用户和自身企业的损失降至最低，也希望整个行业能够吸取教训，共同为我们的用户提供更好的服务。

参考资料：

https://marketplace.atlassian.com/apps/1212137/insight-asset-management
https://www.atlassian.com/engineering/april-2022-outage-update
https://jira-software.status.atlassian.com/

推荐阅读

徐东伟敏捷教练公众号

本公众号由资深企业级敏捷教练和咨询顾问徐东伟主理，聚焦敏捷转型、业务敏捷和敏捷组织。每工作日更新，转载结合原创。希望为中国的敏捷事业尽自己的微薄之力！

敏捷转型包括：敏捷转型的策略/敏捷转型的避坑方法/敏捷转型的成功案例

业务敏捷包括：团队级敏捷运作/数字产品管理/数字化转型/创新创业

敏捷组织包括：敏捷战略/精益投资组合管理/敏捷人力/敏捷财务/敏捷治理/敏捷运营/敏捷组织架构/敏捷企业架构

原文链接： http://mp.weixin.qq.com/s?__biz=MzI4NjkwNzE4MA==&mid=2247484454&idx=1&sn=59d3db36329114ec5cc478f6f17afac5&chksm=ebd48a65dca30373b172b737582491beb4fee63706b28be6f207680007ec2e04f10f46969fc4#rd