数字化灾难！2016年九大服务停机事故总结

【51CTO.com快译】2016年发生的一系列停机事故已经导致众多知名品牌遭受严重损失，其商业信誉与消费者信心亦因此受到重大打击。发生停机事故的主要原因之一在于计划外的系统配置变更，这通常是因为即时bug或者潜在系统安全漏洞修复意外引发了更为严重的问题。

 

为了避免发生计划外停机，我们将在这里回顾过去一年中出现的那些最为严重的服务停机事故，希望能够以此为鉴指导新一年中的业务连续性保障工作。

美国西南航空

去年10月，836条西南航空航线遭遇延误，而根源在于该公司航线技术系统中的问题。根据该公司介绍，技术人员不得不全力修复主要系统并利用备份规程以帮助客户及其托运行李正确到达目的地。

达美航空

达美航空公司证实，亚特兰大当地的一次电力中断影响到其凌晨时开始进行的系统更新，并最终导致计算机系统瘫痪以及大量航班延误。该公司同时警告称，当周一其被迫因此取消大量航班，且机场屏幕及其它飞行状态系统将无法正常显示航班相关信息。

根据统计，此次时长达5小时的停机共造成2000次航班取消，总体损失估计达1.5亿美元。

Salesforce

这家云应用厂商在其官方网站上指出，其NA14实例上的一套数据库出现文件完整性问题，并导致超过12个小时的服务停机事故。

根据统计，由此次停机造成的经济损失约为2000万美元。

苹果

去年6月，苹果公司放下的iCloud、App Store、iTunes以及Apple TV等一系列互联网服务发生长达9小时的停机事故。另外，去年12月初用户们亦发现其暂时无法登录自己的iCloud账户。

Slack

去年6月，高达300万用户在2小时内由于Web服务器过载而无法正常访问Slack。

该公司目前正在就如何避免再次发生类似问题而进行讨论。

身份是解决问题的关键

为了避免发生停机事故，IT运营团队应当对现有服务进行分层，同时将系统身份识别作为业务中的关键性因素。其中***应用应是那些与业务成败直接关联的重要应用，例如销售点、票务或者计费等功能相关的应用。

为***系统制定故障切换计划

高可用性水平不可能自然实现，我们必须为其做好规划及实施。具体而言，高可用性立足于系统架构中的各个方面。***系统需要切实配合故障切换计划，同时利用额外负载容量处理意外出现的负载峰值。

投资建立高水平监控堆栈

如果无法把握服务的当前运行状态，那么保证其运行状态也将成为痴人说梦。事实上，准确了解IT系统运行状态的惟一途径就是在堆栈中的各个层面上引入***监控工具(例如系统监控、应用监控、Web与用户监控、日志记录以及错误追踪等方案)。目前IT行业正积极利用这种分层式功能独立方案取代原有的整体式服务监控机制，从而适应持续提升的IT系统复杂性与动态水平。

在警报机制内区分有效信号与干扰信号

工具数量的增加同时意味着我们需要面对更多干扰信号。为了有效识别、分类并解决潜在问题，IT团队必须找到可行方式以正确进行有效信号与干扰信号分离。通过采用警报关联解决方案，IT团队将能够了解各监控工具的警报信息间存在哪些联系，从而快速过滤掉非关键性问题，最终集中精力处理最重要的风险因素。

原文标题：Tech outages of 2016 and how to prevent them in 2017

原文作者：Ryan Francis

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】