（转）为什么云会停止计算？从数以百计的服务中断中得来的教训

报告评论：为什么云会停止计算？从数以百计的服务中断中得来的教训

2016-11-13 云头条
这份报告对32家主流互联网服务的云中断进行了研究，分析了中断持续时间、根本原因、影响和修复程序。该报告出现在2016年度云计算研讨会上（SOCC 2016），作者为Gunawi、Hao、Suminto Laksono、Satria、Adityatama和Eliazar。

可用性显然对云服务非常重要。宕机会导致财务和声誉受损。随着我们对云服务的依赖程度不断增加，可用性损失会产生更为严重的问题。然而，云服务每年都会发生几次中断。该报告尝试回答了为什么即便冗余无处不在但仍会发生中断。

为了回答这个大的问题，报告先回答以下几个倍受关注的问题：

有多少服务没有达到99%（或99.9%）的可用性？
是成熟的服务还是新的服务发生中断的次数多？
困扰众多服务部署的共同根本原因是什么？
从各种中断中总结出来的共同教训是什么？

对于这些问题，你的答案是什么？请在进一步阅读报告摘要前记下它们。以下是我对这些问题的答案。　

99%的可用性容易实现，但99.9%的可用性对于许多服务来说仍然难以实现。
新的服务可能会比成熟的老服务发生更多的中断。
最具共性的根本原因可能为与配置和升级有关的问题。
“KISS原则：保持简单直白”可能为一个共同的教训。

报告所使用的方法

该报告调查了32个主流云服务发生的597起中断。哇，这令人印象深刻！人们可能会认为这些作者必定与行业团队有着非常好的关系才能进行如此广泛的调查。

原来他们只是使用了谷歌搜索。他们确定了32个流行的云服务（见表1），然后针对2009年1月至2006年12月的每个月搜索“service_name outage month year”。随后他们浏览了前30个搜索结果，收集了1247个描述597起中断的唯一链接。他们系统地研究了这些事后分析报告。这真是太聪明了！

报告称，这项调查可能要“感谢提供商信息透明的时代”。但是这种方法也存在一定的问题。只有提供商的信息透明度越高，结论才越全面。首先，数据集不完整。并非所有中断都会被公开。该报告将“服务中断”定义为，服务的全部或部分功能无法使用，影响到所有或是大量用户并导致中断被公开。其次，数据集中存在偏差。服务越受欢迎，其中断也就越受关注。再次，由于缺乏信息，中断的分类是不完备的。例如，只有40%的中断说明提示了根本原因，仅24%的中断透露了修复程序。（这些比率低的令人失望。）最后，根本原因经常在事后分析报告中被模糊化处理。“由于配置问题”既可指软件漏洞破坏配置，也可指操作员设置了错误的配置。在这种情况下，该报告根据所公布的信息选择标签，即使用CONFIG标签，而不是BUGS或HUMAN标签。

为了不损害任何服务的名声，该报告将这些云服务名称隐匿为后跟数字的分类。 （这为读者留下了一个有趣的练习，读者可以尝试着推测出这些服务的名称:-)

可用性

如果我们只考虑每个服务的最差年份，那么有10个服务（31%）没有达到99%的正常运行时间，有27个服务（84%）没有达到99.9%的正常运行时间。换句话说，5个9的正常运行时间（每年宕机时间为五分钟）仍然远未实现。

关于“服务成熟度是否有帮助？”这个问题，我的答案是错的。我猜测新的服务可能会比成熟的服务出现更多中断。但事实证明，新服务的中断次数相对较少。总体而言，调查显示，任务服务都会发生中断，这无关其成熟度。这是因为服务并不随着他们的成熟而保持不变。每年它们都会不断的发展和成长。它们会处理更多的用户，新添加的功能会增加复杂性。事实上，正如在根本原因部分所讨论的那样，每个根本原因几乎每年都会出现在大型流行服务中。随着服务的发展和成长，过去的类似问题可能会以新的形式重现。

根本原因

表3中的“Cnt”列显示355起中断（总数为597起）中有UNKNOWN（未知的）根本原因。在报告了根本原因的中断事件中，UPGRADE（升级）、NETWORK（网络）和BUGS（漏洞）是三个最常见的根本原因，其次是CONFIG（配置）和LOAD（负载）。我之前猜测最具共性的根本原因与配置和更新相关，这回我的答案是对的。

BUGS标签被用于那些明确提及“漏洞”或“软件错误”的报告。UPGRADE标签暗指硬件升级或软件更新。LOAD指意外的流量过载导致中断。CROSS指由其他服务中断引起的中断。POWER表示由于断电造成的故障，这类中断在研究中占6%。最后但同样重要的是，外部和自然灾害（NATDIS），如雷击、车辆撞到电线杆、切割两根光缆的政府建设工作、以及类似的水下光纤电缆切割导致的服务中断在该研究中占3%。

报告提到UPGRADE故障需要更多的研究关注。我认为Facebook的《配置器：整体配置管理》报告致力于解决UPGRADE和CONFIG故障。

单点故障（SPOF）？

虽然预料到会出现网络、存储、服务器、硬件和电源故障等组件故障，并因此设置了额外冗余予以保护，但是为什么这些故障仍会导致中断呢？是否有另一个“隐藏”的单点故障？

报告如是回答了这种矛盾：“我们发现No-SPOF原理不仅涉及冗余问题，而且还涉及故障恢复链的完善：完整的故障检测、完美的失效备援代码和工作备份组件。虽然这个恢复链听起来很简单，但是我们发现了大量由于其中某一部分的缺陷导致的中断。我们发现一些案例。如，缺失或不正确的故障检测不会激活失效备援机制，有缺陷的失效备援代码无法将控制权转移至备份系统，串联漏洞和巧合的多个故障会导致备份系统也出现故障。”

虽然报告没有提到它们，但我相信以下工作与解决No-SPOF问题关系密切。第一个是“只能崩溃的软件（crash-only software）”理念。我之前曾经评估认为：“只能崩溃的软件指那些仅以简单重启方式处理故障的计算机程序，而不尝试任何复杂的恢复。由于故障处理和正常启动使用相同的方法，这可以增加故障处理代码中漏洞被注意到的机会。” 第二个是恢复块和n版本软件。虽然这些都是老的理念，但它们仍然适用于现代云服务。特别是当前部署微服务的趋势，微重启（由crash-only软件提倡）和n版本冗余可以看到更多的应用程序。

图5将根本原因影响分为6类：完全中断（59%），基本操作失败（22%），性能故障（14%），数据丢失（2%），数据失效/不一致（1%）和安全攻击/违规（1%）。图5a显示了根据根本原因和暗示原因分类的中断次数。

只有24%的中断说明揭示了修复程序。图5.b将报告的修复程序分为8类：添加额外资源（10%）、修复硬件（22%）、修复软件（22%）、修复错误配置（7%）、重新启动受影响的组件（4%）、恢复数据（14%）、回滚软件（8%）和由于交叉依赖关系导致未修复（12%）。

结论

该报告中的关键信息为，软件是SPOF会导致发生中断。虽然这不是一个新的信息，但是该报告的贡献在于为云服务验证和重申了这一点。

就个人而言，我已经痴迷于“故障”。故障是分布式系统的调味品。如果没有它们，分布式系统将没有那么有趣和具有挑战性。例如，没有崩溃的节点，没有同步性丧失，没有丢失消息，一致性问题就微不足道的。另一方面，正如攻击将军和FLP不可能性结果证实的那样，出现了上述的任何一类故障，解决一致性问题就变成了不可能（如同时满足安全与活性规范）。

云头条编译｜未经授权谢绝转载

http://mp.weixin.qq.com/s?__biz=MjM5MzM3NjM4MA==&mid=2654679373&idx=1&sn=25e8a6cc746a7cd37242ed11db16c287&chksm=bd58605e8a2fe948a7f7cee1abefdcaf105fd9a0ba1652e295d0c02fca0cc2926edf2373576d&mpshare=1&scene=5&srcid=1119p21ltkoeSIEqAseZ9tAz#rd