14天才恢复 业界近年最大SaaS宕机案件
发布时间：2022-06-19 16:26:12 所属栏目：云计算 来源：互联网
导读：如果你用来管理所有开发项目的平台，企业内部文件的共享知识库，还有业务、销售、和行政部门合作的项目平台，突然都宕机了，甚至厂商告诉你，要2周后才能修复，这段期间，所有数据无法存取，也没有备份版本可用，你会怎么办？这正是775家企业在Atlassian四
|
如果你用来管理所有开发项目的平台，企业内部文件的共享知识库，还有业务、销售、和行政部门合作的项目平台，突然都宕机了，甚至厂商告诉你，要2周后才能修复，这段期间，所有数据无法存取，也没有备份版本可用，你会怎么办？这正是775家企业在Atlassian四月大宕机事件，所遭遇的处境。 虽然Atlassian没有公开这次事故受影响的企业名单，只披露受影响企业家数是775家，但其中有400家是活跃使用的企业。根据国外媒体采访受影响企业的结果，小则有150个授权，大则有订阅多达4千个授权的企业。根据非官方估算，775家受影响企业下，累积受到冲击的个人使用者超过了5万人。这起事件也大大重挫了Atlassian市值，从宕机事件到完全复原这2周期间，Atlassian股价足足下滑了近2成，后续到5月下旬仍持续下滑中。 Atlassian拥有十多年SaaS服务的运维经验，6年SRE经验，以及云上业界标准常见的灾备和恢复计划，都无法事前发现，及时阻止4月大宕机，无法在99.9%服务水准承诺（SLA） 承诺的8.76小时内复原，甚至有不少企业迟迟等到14天后，才能打开自己的敏捷项目数据。 提出删除申请的业务团队，提供了一份目前还在使用这些旧版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服务的主要入口网站，也把他们所订阅的所有Atlassian服务，都登记到这个网址下。Atlassian也称这个网址是一个网站容器，用来容纳属于这个企业顾客的所有数据、配置和所用的APP。网站ID就是用来识别一家企业的网站容器的代号。 Atlassian的技术架构采取了分布式架构，不只在云端基础架构采取分布式架构来提高可用性，在应用系统层次，也采取了多租户微服架构设计来兼顾弹性和可用性。 （编辑：大连站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐