为何弹性系统设计对云可靠性至关重要

要点总结云的可靠性依赖于设计具有韧性的系统而非假设代码完美无缺因为软件漏洞不可避免。系统架构带来了额外的复杂性但也带来了显著的高级韧性机遇。弹性架构通过多种技术防止小型漏洞升级为重大故障如冗余、故障隔离、优雅降级、自动增量扩展和故障保护模式。结合多种韧性技术是创建高可用性服务的有效且高效的方法尽管保持每个层的高基线可靠性仍然至关重要。欢迎回到我们的可靠性系列课程。几个月前我们开始通过一系列博客文章深入探讨可靠性这一主题内容涵盖从软件和系统复杂性到组织可靠性文化、人为因素考量等多个方面。本系列文章的第一篇详细探讨了云服务对软件的依赖以及这些软件即使是高质量的软件不可避免地会出现错误。如果组成云服务的软件并不完美那么我们该如何构建高可靠性的云服务呢答案的第一部分在于工程师工作中最基本的一项任务设计弹性。在系列文章的第二篇博文中我们将探讨弹性系统设计为何对云端可靠性至关重要。设计弹性系统设计弹性是所有工程学科的关键组成部分而不仅仅是软件工程。例如土木工程师在建造桥梁时会让其承重能力超过设计载荷以应对可能导致桥梁倒塌的意外情况。同样机械工程师在设计电梯时安装了特殊的减速装置以防止电梯在主缆断裂的情况下坠落。航空航天工程师在航天器上安装了多台飞行控制计算机以防其中一台出现故障。这些案例的共同主题是工程师有责任了解哪些意外但相对常见的问题可能导致灾难性故障并设计出能够应对这种情况的弹性系统。在软件工程领域缺陷是需要考虑的最重要的问题之一。这部分是因为它们太常见了。作为一个行业我们已经认识到彻底消灭错误是不可能的。但这并不意味着我们不应该尝试。事实上我们必__须__努力让软件没有错误原因我们稍后会解释。但我们知道我们无法实现这一不可能的目标因此我们的系统必须在这种情况下继续有效运行。独立软件弹性在介绍云服务所采用的复杂弹性技术之前首先需要指出的是独立于云端的软件同样也采用了各种技术来防范错误。举一个简单的例子假设有一个程序包含一个非常复杂的数值计算并且该计算预期会产生一个具有特定属性例如大于零的数字。一种常见的防御技术是在将结果用于进一步计算之前验证结果是否为正数。如果返回值为负调用程序可以采取相应措施安全地停止运行并向用户发出警报。尽管这个例子非常简单但其背后的方法却非常有效验证必须为真的条件是否__为__真因为如果它们不为真则一定存在错误。这以及其他许多弹性技术都是软件工程的基础。从单一要素到系统要素当然现代软件尤其是云端软件大多并非由单一、独立的大型程序组成而是由多个独立软件模块实时协作完成任务。这可能发生在单台机器上其中多个进程可以协同工作或者是软件组件在机架内、数据中心内甚至全球范围内跨多台机器协同工作。当我们处理多个软件相互交互的问题时工程术语从讨论软件转向讨论系统。事实上当我在麻省理工学院学习计算机科学时时间是20世纪90年代后期这些课题是两门独立课程的重点——其中一门我们称之为6.170重点是软件工程另一门称之为6.033重点是系统工程。系统工程自成一类因为当多个独立软件相互交互时会给工程师带来一系列新的挑战包括当网络延迟较大时如何在多个实例之间同步数据如何确保一组独立参与决策的实例之间达成一致意见当部分实例之间的通信中断时会发生什么情况所幸的是系统并不只是带来新问题。它们也为增强韧性带来了新的机遇。再举一个简单的例子有一款运行在云端的软件它会在启动时加载大量数据集处理用户输入执行计算并把结果返回给用户。假设这个程序存在一个偶尔会导致程序崩溃的错误从而导致停机。自动重启程序以应对崩溃的机制通常是一种有效的故障恢复技术但由于该程序在重新加载数据集并恢复服务之前需要较长时间用户在重启过程中仍会面临服务中断的问题。系统可以拯救我们我们不妨同时运行两份软件而不是只运行一份。当主实例崩溃时备用实例它已经加载了必要的数据并处于待命状态会接管其工作。我们需要添加一些逻辑来快速将用户引导至辅助实例但这确实是一个有效的策略。现在我们再考虑一个问题如果导致程序崩溃的错误是由某个用户的输入引起的该用户在不知情的情况下导致主软件实例崩溃然后再次尝试请求但这又导致辅助实例崩溃该怎么办系统架构提供了隔离风险的有趣方法。例如如果您运行20个软件实例并且将每个用户仅分配到其中两个实例那么单个用户的错误输入最多只会破坏10%的服务而不会影响其他90%的服务。更先进的技术可以进一步优化这一过程。防微杜渐避免小问题变成大问题前文中的故障隔离是一个技术示例它体现了一个更广泛的弹性目标确保小问题不会变成大问题。电气工程师利用断路器来防止短路引发火灾。硬件工程师会在关键应用中使用的内存中额外添加奇偶校验位以防止偶然出现的宇宙射线破坏内存并导致控制系统故障。软件和系统工程师会采用冗余设计、故障隔离、优雅降级、自动化增量部署和故障安全模式等技术以防止小故障演变成重大故障。这些技术都得到了基础性方法的支撑例如提供遥测数据以快速检测和修复问题。这些技术的细节在麻省理工学院的6.033课程中有详细介绍。在接下来的系列文章中我们将深入探讨其中几个最重要的方面。系统可靠性建模除了个别技术之外还必须考虑它们如何整体地结合在一起这样我们才能了解这些技术为整个系统提供了何种程度的韧性。首先我们来考虑一个包含主要组件系统A和备用组件系统B的系统。例如如果系统A是一个数据库且发生故障那么系统B数据库可以接管并继续提供服务。系统B的存在增强了整个系统的稳定性。我们可以更广泛地推广这种B系统概念。如果我们担心某个组件在接收到错误的配置更新时出现故障那么解决方案可能不是添加一个新组件而是让系统A内部具备自动安全机制能够测试和/或自动拒绝错误的配置。通过这种方式可以利用针对各种故障模式的通用缓解措施来模拟系统的弹性。有多种数学方法可以描述这种“A和B”系统的整体可靠性。一种简单的方法是考虑一下在特定时间段内组件A出现故障的可能性。考虑在特定时间段内缓解措施B失效的可能性。将该时间段内发生双重故障的可能性建模为两个因素的乘积至少在A和B的可靠性完全相互独立这一简单情况下。如果我们将A和B的失败概率都降至极低水平那么两者同时失败的概率就是这两个极低概率的乘积因此会变得极低。这与我们的直觉相符即双重失败的可能性要小于单次失败。但即使是这个简单的模型也揭示了两个关键点将两个相对可靠的系统组合成一个高可靠性的配置通常比将单个组件提升到相同的整体可靠性水平要便宜得多。系统A和系统B都必须各自非常可靠这一点至关重要。由于整个系统的可靠性是每个部分可靠性的乘积因此每个组件可靠性的轻微下降会导致整体可靠性以平方倍数下降。这就是为什么尽管缺陷不可避免我们也构建了弹性来应对它们但我们仍然必须努力让软件没有缺陷。如果我们对单个组件的可靠性有所松懈那么发生双重故障的可能性就会大大增加。我们将在未来的文章中探讨组织动态如何导致这种情况。当然上述“A和B”系统模型过于简单化了原因有很多其中包括检测和修复某些故障需要两个以上的系统。但更重要的是人们现在发现这种模式在其他方面也存在问题。例如通常存在一些因素使得A或B发生故障的可能性相互关联而这种关联关系却难以被识别。此外概率计算通常无法准确评估低概率、高影响的潜在风险。因此尽管上述模型本身并不是确定系统可靠性的推荐实用方法但它对于说明一些基本原理仍然很有用。事故成因的瑞士奶酪模型弹性云软件依赖于多层弹性技术的纵深防御策略。软件组件经过全面测试采用稳健的软件工程技术进行设计部署环境遵循系统架构原则以保护其免受周围问题的影响并集成在更广泛的容错架构中实现实例化等等。这种策略通常被称为“瑞士奶酪”模型。任何一片瑞士奶酪上都有孔在这里这些孔就代表着可能导致失败的路径。但是一叠薄片每片上都有不同位置的孔期望能避免出现贯穿整个叠片的开口。这清晰地展示了多层防护如何提供深度防御不仅仅是A和B系统还有C、D等多个系统。以及E等等系统。然而这种模型对于实际应用来说也过于简单化了我们将在未来的文章中探讨这一问题。尽管如此它仍然说明了弹性分层防御的基本概念。