针对4月初发生的断线事件,atlassian上周发布事后说明,指受影响的客户来到775家。
这事后报告说明断线事件不是出于网络攻击或被黑,而出于维护团队沟通及系统设计问题。事由是jira service management及jira software共享的“insight–asset management”独立app去年集成到jira service management中,因而必须删掉旧版独立app。但在执行时发生2项错误。一是请求删除app的团队给成了删除整个云计算网站的site id,而非该app的id,但atlassian标准的同侪审查(peer-review)并未检查到给出的site id。第二项错误是,删除网站或app的api并未能在接到site id(或app id)时发出警告并确认,而径自删除了网站。
种种乌龙造成的结果是,在世界协调时间(utc)4月5日早上7:38到8:01分775家客户的883个网站立即被删除,占其20多万客户的0.04%。2周前atlassian说被删除的网站为将近400个。
atlassian表示,事件发生时他们不是茫然无知,而是一开始就知道有哪些网站受影响。他们也知道第一要务是和网站负责人取得联系,不幸一些客户的联系资料遭到删除,这使得atlassian无法立即联系上客户,客户也无法通过支持工单通报。
整个断线历时14天,在抢修后第一批客户于4月8日回复上线。atlassian于4月18日说明所有受影响的客户均已恢复服务。该公司强调没有一家客户损失的资料超过5分钟,在回复服务期间,99.6%的云计算服务客户运行均没有任何中断。
为了防范事件重演,atlassian也修正了管理作业。第一是所有系统将禁止全网站删除,或采用各种防护措施,包括阶段性部署,以及回复计划。未来全球各站点都会导入“软删除”(soft delete),避免删除客户资料及metadata。
其次他们会扩大实施灾难恢复(disaster recovery,dr),以便在多站点、多产品删除事件发生时自动启动回复,加速回复时间目标(recovery time objective,rto)。atlassian也将改进大规模事件发生的sop(standard operating procedure)并且强化多团队协同的人员训练及工具。最后他们也将创建多渠道通报,加速事件确认及创建客户联系,并期盼在1小时内发布公开说明。