一切都坏了，没关系

一切都破了。人的双手或头脑所创造的一切都不是完美的。您曾经骑过的每一辆车，您乘坐过的每部电梯，您曾经信任过的生活的每一个安全性至关重要的计算机程序都在某种程度上存在缺陷。花费多少钱都没关系-系统的正常运行时间始终以9秒为单位，即完成率的百分比

但是，许多不完美的事物仍然可以完美运行，包括人体和我们的许多系统。这个事实-不完美的事情仍然有效-是了解如何防止故障升级为灾难的不可或缺的一部分

故障是系统中断的一部分；灾难就是许多故障累积到无法恢复的程度。 1当灾难发生时，通常看起来非常安全的事情突然失败了。但是，当我们分析造成这种情况的原因时，我们发现根本不是突然发生的：警告信号出现了，早期出现了故障，但是我们没有预测它们如何结合

在过去的两个世纪中，我们控制计算机输入和输出的方式已经发生了根本性的变化。当发明家查尔斯·巴贝奇（Charles Babbage）在1800年代中期设计他的分析引擎并由数学家艾达·洛夫雷斯（Ada Lovelace）对其进行编程时，他们正在操纵物理对象。现在，我们处理软件和功能等数字对象，而不是打孔卡和读取器。从手动更改机器结构到使用计算机语言和抽象层的这一转变已经改变了我们对工作方式以及我们可以想象的控制方式的观念

但是，我们几十年来所做的任何改变都没有减少系统中发生的工作量。从芯片设计到开发人员工具，我们不会节省任何时间或精力，只是在重新分配劳力。开发人员现在可以例行重用并从概念上压缩其他人的工作。我们假设自己的工作-电气工程，制造精度，我们基于其构建的代码，我们用于制造新工具的工具-是既定的并且仅关注影响力范围内的任务

如果我们要构建稳定可靠的系统，我们必须承认有些部分我们不了解。否则，我们将继续假设我们使用的系统是固定的，不可变的或至少稳定的。我们假设过去的表现是未来表现的指标。但这并不一定是正确的，也不是在我们的控制范围之内-我们只是按照原样行事，这样我们才能完成工作。 2个

我们依赖他人未完成的工作的最明显例子之一是Spectre漏洞，该漏洞于2018年1月正式发布，该漏洞影响执行分支预测的微处理器。要减轻它，就需要改变我们的CPU功能-不能在实际命令之前工作-并导致全球执行速度下降。很少有开发人员认为他们的软件将运行在这些芯片上。他们为什么会呢？

我们知道复杂的系统可能会失败。但是使故障本身变得复杂的原因是我们并不总是知道何时会发生故障，原因或它将如何影响系统的其他部分

真正的问题是这种失败是否会成为灾难。举例来说，您乘坐过的每架飞机都有很多小问题。它们中的大多数都是已知的，并且会固定在某个点上，例如粘性的行李箱闩锁，座位破损或安全带磨损等。仅这些问题都不是使飞机接地的原因。但是，如果有足够多的小问题出现，则飞机可能不再满足旅客适航性的要求，航空公司会将其停飞。带有许多故障呼叫按钮的飞机也可能以其他方式维护不善，例如涡轮叶片微裂缝检查错误或起落架行为

一旦您接受了失败是不可避免的，并承诺避免造成灾难的失败串联起来，您和您的组织就需要决定什么样的风险以及如何确定风险的优先级。如果一切都是最重要的，那么什么都不是

我们所有人都希望相信我们的软件或服务对我们的用户起着至关重要的作用，但是某些行业承担着更大的风险。航空，医疗设备和核能等对生命至关重要的行业有自己的标准，而游戏，赌博或时尚等休闲型行业的标准更多是与失去市场份额有关，而不是即时的，限制生命的影响。评估错误的影响，例如受影响的人数或失败造成的金钱后果，可以帮助您做出合理的选择，以分配人力和财力来缓解

在设计软件时，降低风险和减轻危害的模式可以降低负面事件的发生频率和严重性。降低风险的目标是防止负面事件并使系统更难以破坏。疫苗，防抱死制动系统和平交道臂每天都是降低风险的例子。减轻危害的战略承认，负面事件仍然会发生，并设法使其影响尽可能小。安全带，抗病毒药物和防割手套是减轻伤害的实例

在软件开发中，降低风险的模式可能包括限制对系统的访问，用于管理更改的抽象，批准工作流，自动验收测试和结对编程。但是，任何使系统变硬以降低风险的策略也可能使其灵活性降低。完美优化的系统通常很脆弱，因为它没有内置的故障或冗余预期：如果出现问题，则几乎没有恢复空间。例如，如果地铁系统具有完全满足通勤高峰流量所需的容量，则一列停运的火车可能会导致整个系统的延误和拥挤。这就是减轻伤害的地方

软件开发中的危害缓解模式包括：断路器，用于移除有问题的过程或输入；隔离系统的可疑部分；具有许多控制点或断点（例如在微服务上）；以及快速回滚最近实施的更改的能力。虽然在系统中添加更多控制点也可能会引入更多潜在故障点，但通常能够进行权衡取舍，以便能够隔离和诊断系统的一个子集而不将其全部击倒

如O’Reilly的2018年SRE工作手册所述，我们通过错误预算来表示减轻危害的方法之一。系统可靠性工程接受并预期系统的某些部分可能会发生故障，并为这些故障制定预算。运行系统的团队故意使零件离线以测试响应，解决方法和恢复

Netflix及其2011年发布的Chaos Monkey工具广泛采用了这种“故意灾难”做法，但是组织使用灾难恢复做法的时间更长。如果这种做法是组织应变能力的常规组成部分，则有时被称为混乱工程。实时练习系统故障不仅教会团队如何应对已知的已知类型的故障（每个人都知道脱机的原因），而且还教会未知或无法预测的故障，因为团队已经学会了共同解决问题并进行了实践解决快速变化的情况

具有多层安全保护的灾难准备有时也被称为瑞士奶酪模型。每一层的准备，预防和缓解措施本身都是不够的-但是，当堆叠在一起时，它们可以为最坏的情况提供足够的保护。

该系统越复杂，它的某些部分就越有可能被破坏了。作为工程师，我们要花费数百万小时的设计和工程时间，以帮助我们和我们的用户，从找到手机到不断集成我们的代码，应有尽有。我们必须假设某些基础架构和我们的某些工作已损坏

如果我们接受这些不完善之处，那么我们可以朝着建立可以处理一点点静力并处理有缺陷的地基而不倒塌的弹性系统的方向努力。我们不会仅仅因为不可能而努力追求完美