相关报道saas业界近年最大宕机事件追追追
在今年4月5日，atlassian发生大宕机事件，波及旗下jira产品系列、confluence文件协作平台、atlassian access登录机制、opsgenie事件应变服务，甚至是网站状态查询页statuspage，受影响企业家数达775家。造成四月大宕机事故的起因不复杂，atlassian也的确在事故发生后1个多小时，就厘清了根本原因，但是资料恢复成了他们最大的考验。
为了提供99.9%的可用性服务水准，这是云计算供应商常见的标准sla承诺，atlassian原本就有一套灾难恢复做法。但是，atlassian坦言，过去的dr计划主要聚焦在基础架构失败的恢复，或是从备份资料中恢复企业所用服务存储空间的做法，而少了一个关键环境，就是以顾客专属门户网站（网站id）视角的恢复计划。换句话说，atlassian的dr计划是以自己工程运维角度来思考，而少了从顾客视角，从企业所用专属网站的角度来设计恢复机制。
旧有dr计划有能力来应对基础架构层级的失效情况，如整个数据库失效、ap服务或aws可用区域遗失的恢复，也可以应对勒索软件事件、恶意程序、软件缺失，甚至是因人为操作错误而导致的服务存储资料损毁，都可以单独将资料恢复到30天内的任何时间点。换句话说，atlassian的dr计划涵盖了基础架构出错、资料损毁、单一服务活动或单一网站的删除。但是，在这起事故中，atlassian遭遇到多网站、多产品的自动恢复挑战。在atlassian的网站等级运维手册中，没有创建快速自动执行的脚本程序和程序，就得人工处理和协调跨所有产品和服务的恢复工作。
可是，atlassian的技术架构采取了分布式架构，不只在云计算基础架构采取分散架构来提高可用性，在应用系统层次，也采取了多租户微服架构设计来兼顾弹性和可用性。一位企业客户的网站，不只会部署到单一数据库或存储空间，也会部署到分布式基础架构中，可能涵盖了多个实体位置与逻辑位置，来存储中继资料、配置资料、产品资料、平台料或是其他有关相的网站资讯。这是为何需要一套高度自动化的paas部署和构建平台的缘故。不过，要恢复一整个网站，就得重建这个的高度自动化作业的过程，atlassian因为因为没有事先考虑到这个情况，就带来了庞大的人工验证的确认程序。
这正是为何在第一个恢复方法中，需要高达70个步骤，因为创建新的网站、授权、云计算id来激活正确的产品清单后，还得将网站资料转移到正确的aws区域中，并且要恢复和重新对应网站的核心中继资料和配置、网站的身份识别资料，然后才能复恢复网站的主要产品数据库，还要重新对应网站的相关媒体关联、附件，也要重新对应网站所有服务的资料。甚至要恢复和重新对应一个企业用户网站所用到的每一个第三方应用程序，告诉第三方应用的供应商，新的网站id与旧有网站id之间的关联，来取得合法串联授权。这中间有不少是因为新旧id转换而需要的确认和验证，而这些都没有事先完成的自动化脚本工具可用，得边做边人工处理。这正是为何第一个恢复方法花上48小时的缘故。
后来改良后的第二个恢复方法，放弃使用新网站id，而直接沿用企业用户遭删除的旧网站id，就少了许多需要验证的动作，尤其，第三方应用的串联，不需要再次确认就能继续使用，再加上后来完成了自动化恢复工具和验证工具，才把恢复时间缩短到12小时以内。
atlassian第一个恢复方法中，需要高达70个步骤，而且没有事先完成的自动化脚本工具可用，得边做边人工处理。这正是为何第一个恢复方法花上48小时的缘故。后来改良后的第二个恢复方法，放弃使用新网站id，而直接沿用企业用户遭删除的旧网站id，就少了许多需要验证的动作，来简化了一半验证程序，再加上后来完成了自动化恢复工具和验证工具，才把恢复时间缩短到12小时以内。图片来源／atlassian
为何顾客迟迟无法取得支持，从失败的顾客沟通学到教训
不只资料恢复时间延误，在这次宕机事件中，atlassian还遭遇了另一个问题，就是顾客抱怨无法取得官方的联系和说明。导致顾客沟通失利的关键，也是因为企业网站全站资料遭到删除的缘故。因为atlassian的核心系统（负责支持、授权和计费）下达了客户网站删除指令后，不只删除了企业网站id资讯，也会删除联系资讯，例如网站系统管理员的九游会官网真人游戏第一品牌的联系方式。因为，atlassian是利用网站id（网站url网址）和系统管理员联系清单，作为安全验证、优先级等用途的识别清单，因此，删除指令会一并删除这些资料，也让atlassian无法系统性的识别受到影响的企业顾客和顾客直接交互的能力。
再者，atlassian的线上联系表单或是工单申请，都要求要提供有效的网站url网址，但是受影响企业的网站id已经失效，就无法送出表单或申请工单，除非该企业有另一个可正常使用的网站id。当atlassian要开始联系顾客时，只能通过业务团队手上的联系名单，但其中不少联系资料已经异动失联，atlassian只能从其他可用资料，例如账单，历史工单等来源，重建完整的联系人清单，这就大大拖慢了atlassian对顾客的回应速度，也难怪有企业用户抱怨，好几天都没有得到任何联系或事故说明。
再加上，因为架构的复杂性，带来了这次事故恢复的挑战，atlassian迟迟无法确定影响范围和准确估算解决时间，atlassian采取了错误的做法，决定等到了解事故全貌后，才要告知顾客，这就让首席客户官时间处于资讯不明的不确定状态，而引发的大量抱怨。
atlassian坦言，失去联系清单而无法联系顾客，再加上采取了解全貌才说明的策略，让他们没有更早采取公开回应的做法。一直到事故发生一周后，才在首席技术官博客上公开恢复进度，而在这个过程中，失去联系资料的企业顾客，迟迟无法获得来自官方的私下说明。
atlassian从四月大宕机学到的4个教训
在这起事件事后，atlassian在报告中归纳出4个教训，第一项就是要在所有系统中普遍采用“软删除”的做法，也就是避免直接删除资料，而是先停用资料，经过一段保留期才真正删除。这起事件是来自合法的删除指令，因此工程团队没有收到任何事前警告，而在删除程序的事前测试中，也因为用对了正确的ap id而非后来实际提供的错误网站id，而没有发现删除目标的改变。
atlassian决定，必须彻底采取软删除，也要设计多层保护机制来避免错误或误删，并创建一套标准化的验证审查流程。
而第二个教训则来自这次辛苦恢复的过程，日后必须在灾难恢复计划中，创建一个大宗客户发生多网站、多产品删除事件的自动化修复机制。而他们也发现，过去靠多年累计的事件管理计划中，只会针对较小规模、短期影响的事件进行模拟演练，但这次事件中，动员了数百名工程师和客服支持人员，而且动员超过2周。日后需要在产品层级事件教战守则中，创建一个可让数百人协作的大规模事件流程来演练。最后一项教训是与顾客沟通渠道的改良，一方面既有事件沟通教战守则，没有通过多种渠道，尤其是社交媒体这种更公开、广泛的做法，来承认事件的发生，也与顾客沟通说明后续进展，另一方面，也要改进现有关键联系人的维护方式和顾客通报流程的盲点。atlassian也公开了这次大规模事件管理流程的运行示意图。
在sre实务中，事后分析报告（postmortem）是精进网站可用性的关键，现在也有越来越多云计算供应商，愿意公开自家大宕机事件的事后分析报告，来向外界说明。不只atlassian，过去也有多起重大宕机事件，企业都也披露事后分析报告。
尽管atlassian这份报告仍遭到批评，没有更完整地披露这次事件所影响的实际用户人数，而只公布了受影响的企业家数，但在报告中，atlassian对于事故发生原因，到如何应对复杂资料恢复的过程，都提供了种种细节和详细说明，仍是值得台湾企业参考的一次经典sre事后分析报告，也是saas服务运维团队必须了解的一起重大宕机事件。