托马斯·里德（Thomas Reid）曾经写道：“整个一条链并不比链条中最薄弱的节点更强大。” 这对于任何具有相互依赖的链接的系统都是如此，无论是文字链还是软件应用程序中的依赖链。如果一个链接断开，负载就会崩溃。
对于SaaS，PaaS，IaaS和其他服务提供商，此概念可以成就或破坏业务。这些服务的客户希望提供商能够提供高水平的可用性和性能，因为任何问题都可能导致他们自己的服务失败。换句话说，他们服务客户并产生收入的能力直接取决于其服务提供商的能力。这给提供商带来了巨大的压力，要求提供商最大化其服务的可用性，否则就有可能将客户流失给更可靠的竞争对手。
为了避免这种情况，服务提供商需要主动为可用性设置高标准。我们将在此博客文章中说明操作方法。
什么是“可靠性标准”？
链条中的每个链接都有一定的故障点。如果增加了过多的重量，或者链节的形状不佳（生锈，铸件缺陷，焊接不良等），则会断裂。由于链接是直接相互连接的，因此如果其中一个失败，则会破坏整个链。
这也适用于软件。如果我们的客户依赖我们的服务，那么我们服务中的任何故障都将导致他们的失败。我们需要确保为所有客户提供始终如一的可靠和高性能的体验。这听起来似乎很明显，但是让我们考虑一下对客户产生重大影响的SaaS中断的真实示例。
Slack是超过75万家公司使用的数字通信平台。在最近的一次事件中，性能下降使团队很难聊天，共享文件和搜索消息，这是当今远程优先工作环境中的所有基本任务。Slack具有99.99％或更高可用性的可靠性标准，这意味着每季度15分钟或更短的停机时间。结果，像这样的事件通常很少发生并且很快得到解决。
如何保证可靠性标准？
保证可靠性标准是组织范围内的工作，其中包括：
- 培养可靠的文化。
- 设定可靠性目标。
- 确定我们服务中的潜在故障模式。
- 验证我们的事件响应和灾难恢复计划。
培育可靠性文化
可靠性不仅是工程团队的责任，而是整个组织的责任，并且需要成为执行人员级别的KPI。不可靠的产品或服务可能会对整个业务产生重大影响。因此，每个人都需要了解可靠性对业务成功的重要性。对业务很重要的指标包括：
- 跟踪对预算支出的可靠性改进。
- 发起人净得分（NPS）和客户体验的变化。
- 50％和90％的请求的最高百分比延迟。
- 正常运行时间和延迟。
考虑可靠性可能需要组织学习对工程速度和效率的不同思考。例如，一个常见的挑战是，领导层以可靠性为代价，优先处理其他任务（例如，构建新功能）的优先级。换句话说，牺牲了可靠性而有利于新功能特征的推出速度。这会产生摩擦，并可能导致可靠性测试被推迟到开发结束的情况，从而增加了影响客户的事件和中断的风险。归根结底，功能只有对客户可靠才有价值。我们希望在不满足可靠性标准的情况下最大化特征速度。
我们已经看到组织进行这种对话的一种方式是通过为应用程序创建仪表板来显示其可靠性和效率之间的关系。这使整个组织能够确定何时投资于可靠性方面的工作，以最大化业务成果，并使业务利益相关者与可靠性计划保持一致。
设定可靠性目标
接下来，我们需要一种方法来定义可靠性目标并衡量实现这些目标的进度。这有助于我们向客户证明我们正在达到所创建的标准。
许多服务提供商使用服务级别协议（SLA），该协议通过合同向客户承诺最低的服务质量。如果我们未能达到该水平，他们还向客户提供追索权。SLA通常将服务质量定义为正常运行时间：例如，一个SLA承诺99％的可用性意味着我们的服务每月只能停机7个小时左右。
如果我们的服务是客户体系中至关重要的组成部分，那么这意味着我们的客户只能像我们一样可靠。换句话说，他们可以向客户保证最多99％的可用性。要求高可靠性的客户可能会避开此类服务，而转向更可靠的提供商。这就是为什么像AWS，GCP和Azure这样的主要提供商倾向于提供99.99％或更高的SLA。为确保我们达到SLA，我们应将内部可靠性目标（我们的服务水平目标或SLO）设置为高于SLA。如果我们的SLA为99％，则我们的SLO应该至少为99.5％（每月停机3.65小时）。这不仅使我们超越了客户的期望，而且在发生重大故障时也提供了余地。
识别潜在的故障模式
现代应用程序很复杂，并且可能以无法预测的方式失败。随着工程团队越来越多地迁移到Kubernetes和OpenShift等分布式云原生系统，尤其如此。与传统的应用程序体系结构相比，这些系统具有明显的优势，但是它们还增加了未知变量和故障模式（在我们本已脆弱的依赖链中提供了更多链接）。为了减少停机的风险，我们需要在发现服务或客户面临风险之前，主动找到并解决故障模式。
这是Chaos Engineering提供帮助的地方。混沌工程是一门科学，它通过注入精确的和量度的伤害以对系统进行有目的的实验，以提高其弹性。通过观察系统如何应对这种危害，我们可以实施更改并针对这些类型的故障加强系统。我们还了解有关系统行为的更多信息，这在迁移到新平台或体系结构时特别有用。
混沌工程有助于发现我们的链接中的弱点，而这些弱点是我们无法通过传统测试发现的。像Gremlin这样的Chaos Engineering解决方案使我们能够以受控方式进行实验，并观察我们的系统如何反应。然后，我们的工程师可以解决这些弱点，加强供应链，让我们向客户承诺更高的可靠性标准。
创建和验证响应计划
无论我们的应用程序有多强的弹性，都会发生事件，链接会断开，但是要让负载下降，我们需要准备好快速修复链条。我们的第一步是制定事件响应计划（也称为剧本或操作手册），以指导工程师快速有效地解决事件。对于灾难（例如数据中心中断和洪水），我们使用灾难恢复计划在发生史无前例的事件后尽快恢复服务。制定响应计划可以防止大量停机，从而帮助我们恢复正常运行时间，并减少事件发生时对工程师的压力。
对事件进行计划的挑战是验证我们的计划是否有效。拥有未经测试的剧本与没有剧本一样糟糕，因为我们无法保证它会在现实世界的事件中正常工作。当然，没有人愿意等待事件只是发现我们的计划缺少关键的一步。相反，我们可以使用Chaos Engineering主动测试和验证我们的计划，而不必使我们的系统，客户或业务面临风险。