2. 服务级别管理定义与缩写

第2章 服务级别管理定义与缩写

为何这不是一个术语表

根据本章标题，我可以预料到你会期望看到一个术语表（也许甚至是按字母顺序排列的）定义和缩写。

虽然我也可以这样写，但我希望尝试一种不同的风格，从更合乎逻辑的角度来审视。定义和缩写很难解释，因为你有时并不真正理解它们的实际含义，除非你在正确的上下文中看到它们。因此，当我说“逻辑方法”时，我的逻辑基于SRE领域的人在成为SRE的旅程中以及SRE流程的流转中会遇到这些缩写的顺序。

风险评估

从上一章可以明确的是，SRE的核心在于可靠性，即系统或应用程序工作负载可接受的正常运行时间。我也简要提到，追求100%的可靠性意义不大，部分原因是它很难实现，维护成本极高，而且往往更像是一种乌托邦而非现实。此外，对于许多企业而言，用户不会注意到5分钟宕机和15分钟宕机之间的区别。但将宕机时间从15分钟减少到5分钟的过程和成本可能对企业来说是巨大的。

另一方面，不可靠的系统对你的组织形象不利。如果你是一家电商企业（或任何在线企业），你的网站停机时间比运行时间还长，客户怎么能相信你的组织最终会交付订购的商品？如果你不认真对待业务的运行时间，又怎么会认真对待实际的售后流程？

因此，首先需要考虑的定义之一是风险评估。作为SRE，你基本上一直在管理风险。你应该专注于优化应用程序的稳定性，还是专注于为应用程序工程化新功能？如果集成新功能有助于稳定性呢？接下来，你应该从可接受的风险开始。如果你的业务同意99.9%的可用性目标，即允许0.1%的停机偏差，那么为什么还要追求更多呢？

随时间变化的可用性

除了可接受风险的值（指标）之外，了解随时间变化的可用性也很重要。在1天（24小时）内达到99.9%的可用性目标与在1个月或1年内达到是不同的，因为可用性从来不是线性的。

表2-1. 可用性时间

时间	1天（24小时）	1个月（730小时）	1年（8,760小时）
99.9% 可用性	23.976 小时	729.27 小时	8,751.24 小时
不可用时间（分钟）	最长 1.44 分钟/天	最长 43.8 分钟/月	最长 525.6 分钟/年

在绝对数字上，这应该很清晰。但月度的43.8分钟可能确实是整个月一次大约45分钟的宕机，也可能反映多次仅持续几分钟的短暂宕机。年度可用性也是如此：525分钟大约相当于9.5小时，这可能是一次该时长的宕机，或者每月约45分钟，或介于两者之间。

可用性不是线性的原因是它与SRE的核心目标——优化可靠性——相冲突。如果你有一个系统持续每天、每几天或每周都面临宕机，你很可能会在第二次发生后开始深入排查，并试图避免第三次发生。

此外，这些数字本身意义不大，因为它们只反映静态值，代表工作负载的单个实例。但应该明确的是，你绝不应该运行工作负载的单个实例，因为那会立即让你无法实现任何可接受的可用性。

聚合可用性

观察组织如何使用云（不要忘记本书最终将涉及在Azure上实现SRE），资源通常部署在多个数据中心，以限制宕机风险。因此，单个系统在某个区域可能宕机，影响可用性，但将所有用户重定向到可用区域可能很容易，而不会真正影响到工作负载的运行。

因此，应该着眼于所有工作负载的聚合可用性，甚至可能更细粒度地，比如应用程序的哪个特定组件面临宕机。用户无法重置密码可能比用户无法为购物车中的商品付款更不关键。

风险容忍度

此外，风险管理还应涉及应用程序的具体使用方式。例如，如果你有仅周期性运行的工作负载，比如每月的发票批处理或归档作业，那么如果宕机发生在该工作负载的关键过程中，前面的数字就没有实际意义。坦率地说，如果你不使用该工作负载，为什么要在意宕机呢？就像你在度假时家里停电几个小时一样（除了可能担心冰箱里的食物或家庭警报器，整体影响不大）。

应用程序工作负载场景的关键性也是如此。任何可能危害其用例或用户安全的应用程序都应被视为高度关键。想到的例子包括电梯（以及相应的监控解决方案）和健康相关设备（医院应用程序、手术室设备等）。

这正是站点可靠性工程师应与业务和应用所有者合作的地方，以明确风险容忍度。不是从整体数据中心风险评估级别开始，而是审视每个单独的工作负载场景及其所有相关组件。

组织在风险评估期间定义了两个主要非功能性需求：

• 恢复时间目标（RTO）：事件发生后应用程序可接受的最大停机时间。
• 恢复点目标（RPO）：事件期间可接受的最大数据丢失时长。

以下是一些有助于整体风险评估的其他问题：

• 业务方接受的工作负载预期可用性是多少？
• 业务方接受的工作负载可实现可用性是多少？
• 用户/消费者接受的工作负载预期可用性是多少？
• 用户/消费者接受的工作负载可实现可用性是多少？
• 你能识别不同级别的宕机及其相应的风险吗？
• 除了可用性之外，还有哪些重要的服务指标？
• 优化可用性的可预见成本影响是什么？
• 解释额外成本的动机是什么？
• 某些组件是否比其他组件更容易宕机？
• 如何优化此工作负载的可用性？
• 宕机会立即影响公司（可见性、收入等）吗？
• 谁为服务消耗付费？
• 该业务垂直领域的可用性标准是什么？
• 该业务在哪个行业运营？

让我分享另一个我在现场看到的例子。几年前，我为一家活跃在航空业（实际上是制造飞机）的企业提供Azure研讨会时。他们希望迁移到云（确实是Azure）的其中一个参考工作负载是驾驶舱管理软件，用于洲际飞行。同样的软件也可用于飞行员训练模拟器。为了反映真实的飞机体验，客户的要求是在模拟器中实现与最终将在飞机中构建的版本100%匹配。

无需过多解释，风险评估（以及相应的可接受可用性）结果在模拟器和实际飞机之间差异巨大。我们谈论的是完全相同的软件，但业务案例略有不同。

你可以尝试根据我之前提供的示例问题，估算两个场景的可能答案及其影响。这实际上是一个有趣的练习。

SRE指标与开发人员指标

这并非严格捕捉某个特定定义或缩写，但花几分钟讨论仍然很重要。SRE指标是反映可靠性的所有值。简而言之，这意味着站点可靠性工程师通常会尽量避免对正在运行的工作负载进行太多更改，因为对运行系统的任何更改都可能导致宕机。另一方面，开发人员（或产品经理）倾向于尽可能频繁地发布更改。这可能包括新功能、错误修复或总体上的锦上添花。开发人员能够产生应用程序更新的频率越高、速度越快，开发速度就越高，但可靠性可能会越低。

这里的挑战在于，作为SRE，你负责应用程序的整体可靠性，这意味着你需要面对产品更新、补丁、错误修复和功能发布，这些通常是在你控制范围之外的。

第2章 服务级别管理定义与缩写

错误预算

错误预算是指给定系统或应用程序工作负载的“不可用性余量”。它通常基于服务级别目标（SLO）——我们将在本章后面讨论。要衡量错误预算，首先要设定一个客观指标，最好基于所有各方达成的一致意见，并基于监控解决方案中经过验证的数据，以使其尽可能准确。SLO通常由业务方定义，可视为预期的、可容忍的可用性数字（参见“风险评估”部分）。此SLO与来自监控解决方案的有效运行时间指标进行映射。两者之间的差值即为错误预算。

有效可用性 − 服务级别目标 = 可用错误预算

只要有效可用性（“真实”运行时间）大于服务级别目标，即表示还有错误预算剩余，那么接受并推送变更应该是可以接受的。

例如，一个 99.9% 运行时间的 SLO 在没有出现问题的情况下，会为团队提供每月 43.2 分钟的错误预算。

多年来，我合作过的多数企业业务都使用这种“错误预算”机制来决定软件或系统更新。如果还有相当多的预算剩余，则实施变更更容易被接受。另一方面，如果系统不太稳定，即错误预算所剩无几，则通常会避免实施（大量）变更，除非开发人员和产品经理能够保证这些变更会带来更好的运行时间。（谁愿意承担这个风险？）但我们已经在 SRE 领域内讨论过这一点，它本身就是一个挑战。另一方面，它也可以用作一种工具，以整合更多的测试、更好的质量保证，以及在推送发布之前进行一系列验证和审批——这可能不会对当前运行的工作负载产生立竿见影的效果，但可能对同一工作负载或任何其他工作负载的未来发布产生巨大影响。

在任何情况下，“错误预算”都应该是指导原则。假设一个系统的错误预算即将用尽（意味着已经发生过几次中断）。这应允许 SRE 团队完全阻止任何变更的发生，除非该变更旨在改善错误预算值（提高可靠性，而非针对客户的功能）。

理解可靠性

本书中会多次提到一个术语，它处于 SRE 角色的核心位置：可靠性。

但什么是可靠性？影响你运行中工作负载可靠性的因素有哪些？

理解可靠性以及我们解决方案中需要监控的方面有很多方法；让我们来看看其中一些：

• 可用性：简单来说，服务是“运行”还是“停止”？我们在讨论可靠性时主要关注这方面。
• 延迟：请求与响应之间的延迟。如今，技术已发展到让解决方案“可用”对最终用户来说已不足够。最终用户体验真正受你解决方案的流畅程度影响，当体验下降时，用户会转向竞争对手。
• 吞吐量：成功处理的数据量，不要与带宽（理论传输容量）混淆。
• 新鲜度：数据刷新的频率如何？展示信息的“时效性”如何？
• 正确性：应用程序处理的数据是否显示预期结果？基于输入，我们得到了多少正确输出？
• 质量：在不降低服务质量的情况下服务有效请求。有时，请求可能不会给用户完整的结果，但它仍然可以工作。这是衡量降级结果比率的一种方式。
• 覆盖率：预期处理的数据中有多少实际被处理了，重点放在输入上。例如，如果输入损坏，你会将其视为无效，以衡量你的系统“有多好”。

服务级别指标

服务级别协议（SLA） 可能是最熟悉的服务级别指标，但实际上它是所有指标中最不技术性的一个。本节介绍可用于衡量的不同指标（这些指标也将在后续章节中通过示例进行介绍）。

服务级别指标（SLI）

简单定义：什么是服务健康状况的指标？基于前面提到的可靠性方面，我们将定义衡量系统可靠性的“探测点”。它是用于计算 SLO 的指标。SLI 必须从客户的角度进行衡量。

还应该清楚的是，并非所有 SLI 都应以相同方式解释。当你询问最终用户他们在可靠应用程序中寻找什么时，他们通常会谈论性能、延迟和稳定性。因此，从 SRE 的角度看是可靠的系统（=……系统 100% 运行……）可能会给最终用户带来完全不同的印象（=……系统有一半时间很慢，或者系统在早上 8:30 到 9:30 所有用户进入办公室时很慢）。

接下来，在其最简单的架构中，任何应用程序都有一个服务器端（数据中心）和一个客户端（最终用户）。在大多数情况下，你只控制架构的一端。一个应用程序从服务器角度来看可能具有出色的运行时间，但从客户端角度来看可能很糟糕，这取决于其使用方式或使用位置（=……从企业网络使用效果很好，但从家里通过企业 VPN 连接时延迟很糟糕）。正如最后一个例子所示，你的服务器可能再次拥有出色的可用性运行时间。请记住，SLI 必须以客户为中心。

部署正确的监控解决方案，允许跨应用程序架构所有层面进行可观测性，对于识别和衡量 SLI 指标至关重要。

服务级别目标（SLO）

服务级别目标可以描述为客户或用户对给定系统或工作负载可靠性的期望（作为用户，我期望每小时对 API 的请求有 99.9% 成功）。它应设定为技术 SRE 团队在衡量的指标（SLI）上应达到的目标。

可以将其视为在业务方提出讨论或用户开始抱怨之前允许的最低指标。也可以激励 SRE 团队超额完成 SLO，这转化为提供更好的服务、更少的停机时间等。

SLO 应被视为 SRE 团队工作（应该？）的驱动力，因为它们直接反映了用户对健康运行应用的印象。

从本质上讲，SLO 代表了服务提供商对其用户的承诺，概述了他们可以预期的最低服务水平。它建立了一个明确的基准，服务应努力达到或超越该基准，从而为旨在提升服务质量的努力创造一个清晰的目标。

服务级别协议（SLA）

图 2-1. Azure SLA 网站

关于 SLA 的一个常见误解是它们指的是给定服务的实际“运行时间”，但事实绝非如此。如果 SLA 是 99.95%，这意味着服务提供商（在我们的案例中是 Microsoft）将在测量的可用性低于该指标时向你（服务的消费者）进行补偿，而实际上，测量的可用性可能略低，也可能低得多（尽管我怀疑后者，因为那意味着 SLA 定义可能是错误的）。

表 2-2. SLA 与停机时间

SLA	每周停机时间	每月停机时间	每年停机时间
99%	1.68 小时	7.2 小时	3.65 天
99.9%	10.1 分钟	43.2 分钟	8.76 小时
99.95%	5 分钟	21.6 分钟	4.38 小时
99.99%	1.01 分钟	4.32 分钟	52.56 分钟
99.999%	6 秒	25.9 秒	5.26 分钟

• SLI：关注指标，定义用于衡量服务可靠性方面的监控指标。例如，针对所提供的 API，成功完成的请求数量（状态码和/或响应时间）占总请求的比例。
• SLO：基于用户体验设定目标。例如，在 24 小时周期内，99.5% 的请求应成功（状态码 200–299 且响应时间低于 200ms）。
• SLA：与客户签订的合同协议。通常，它会小于内部定义的 SLO（留出一些余量），例如，一个 24 小时周期内 99% 请求成功的 SLA（给了你相对于 SLO 0.5% 的错误余量）。

图 2-2. SLI/SLO/SLA

复合 SLA

复合 SLA 是组合多个 SLA 的结果，通常基于将多个服务组件堆叠在一起。复合 SLA 可能导致更高或更低的运行时间量，具体取决于应用程序架构。

以 Azure 上运行的工作负载为例。

• Azure 应用服务: 99.95%
• Azure MySQL 服务: 99.99%
• 复合 SLA = 99.95% × 99.99% = 99.94%，这比每个单独组件的 SLA 都低；这是合理的，因为每个组件都增加了整体架构的复杂性，从而增添了更多故障点。

图 2-3. WebApp 和 MySQL

新的场景产生以下指标：

• Azure 应用服务 (WebApp): 99.95%
• Azure MySQL 服务: 99.99%
• Azure 存储队列: 99.9%

图 2-4. WebApp、MySQL 和队列

• MySQL 和存储队列同时宕机的概率为 (1 – (0.001 × 0.0001) = 99.99999%)。
• Web App SLA = 99.95%
• 复合 SLA = 99.95 × 99.99999 ≈ 99.95%

NOTE

我将在本书后续的 Azure IaaS 和 PaaS 相应章节中说明几种参考架构，强调根据所选架构对 SRE 的影响。

类似复杂性也出现在跨不同位置（数据中心或区域）部署相同工作负载时，其中涉及以下指标：

• N：单区域中复合应用程序工作负载的 SLA (99.95%)
• R：应用程序部署的区域数量 (2)
• X：区域负载均衡器服务的 SLA (99.99%)

如果我们基于负载均衡的两个区域来衡量上述解决方案：

• 两个区域组合后的 SLA (1 – (1 – 0.9995) ^ 2) = 99.999975%
• 地理负载均衡器可用性 (99.99%) × 区域可用性 (99.999975%) = 99.989975%（每月 729.92 小时）

第2章 服务级别管理定义与缩写

不可用性指标

作为DevOps和站点可靠性工程（SRE）团队，在（关键业务的）工作负载发生故障时，你们是首要联系人。SRE工程师的主要任务之一是确保业务应用持续运行。同时，当故障发生时，你的团队需要监控应用工作负载尽快恢复。

• MTBF，平均故障间隔时间
• MTTF，平均故障时间
• MTTR，平均恢复/修复时间

图2-5. MTTF、MTTR和MTBF

MTTF – 平均故障时间

MTTF代表平均故障时间，简单说就是反映某个东西出故障之前需要多长时间。但让我们看看更完整的定义，这可以在多个行业参考网站上找到，包括Google的SRE文档：

“MTTF是指一种事件管理指标，使企业能够衡量系统或应用首次（通常是唯一一次）发生故障所需的平均时间。这意味着MTTF的定义用于描述系统或工作负载组件中不可修复的故障或缺陷。 在DevOps和SRE实践中，该定义（以及缩写）通常用于衡量IT环境的可用性和可靠性。简而言之，应该使用该指标来衡量工作负载和平台服务的整体质量，而不是衡量管理这些系统的DevOps或SRE团队的质量。”

计算MTTF的公式如下：

运营总时间（直到故障）的 x 项 / 总项数

假设你运行一个应用工作负载，依赖于一个包含四个防火墙设备的集群。第一个设备在12,000小时后故障，第二个在14,300小时后，第三个和第四个分别在17,450小时后故障。每次故障都导致设备无法修复。

MTTF：12,000 + 14,300 + 17,450 + 17,450 = 61,200 小时
MTTF：61,200 / 4 = 15,300 小时

基于这个计算，可以假设每15,300小时就会有一个设备故障。然而，从例子中可以看出，并不能保证每个设备都恰好每15,300小时故障一次。因此，与其过度关注数学值，MTTF通常被用作预测下一次故障发生时间的指导。所以可以说它更多反映的是平均值，而非精确的故障时间指示。

稍后我将解释MTBF（平均故障间隔时间）。尽管与MTTF有不少相似之处，但一个关键区别是：对于MTBF，我们通常指的是导致故障的事件或中断，并且可以通过修复或更换组件来解决；而对于MTTF，解决故障的唯一方法是更换整个单元，因为无法修复。因此，MTTF常用于确定物理组件的寿命，例如磁盘、内存模块、CPU模块或完整的设备机箱。

让我用另一个计算来澄清这个例子。

假设一个硬件供应商对1,000个磁盘进行为期1个月（720小时）的寿命测试，发现3个磁盘故障，使用MTTF公式 (720 × 1000 / 3) = 240,000 小时。

这并不意味着任何一个磁盘会每240,000小时故障一次。更好地解释潜在磁盘故障的方式是：每333个磁盘中，每月会有1个磁盘故障，反映为每年0.3%或3.6%。使用同样的1,000个磁盘例子，大约每年会有36个磁盘故障，这与理论（但统计上计算正确）的100年寿命相比，意义完全不同。

因此，让我们深入探讨一些可能严重影响MTTF高低结果的原因和后果。

MTTF的原因与后果

总的来说，任何应用工作负载都运行在某个系统上，无论其架构（虚拟机、微服务容器等）或托管环境（本地、公有云）如何。任何系统在某个时候都需要维护。这就是业界所谓的计划内维护。然而，任何此类计划内维护都可能影响应用和服务交付、可靠性、收入、客户满意度和员工满意度。因此，准确表示MTTF将有助于优化服务可靠性。

面对不准确的MTTF测量可能导致一系列相关问题：

• 故障可能意外发生，导致停机和数据丢失。
• 客户因停机而不满，离开你的网站，收入下降。
• 员工士气低落，因为他们不断被召来处理本可预防的紧急情况。
• 你比必要频率更频繁地更换硬件，导致运营成本增加。

如果你希望每天可靠地用车送孩子上学并上班，可以考虑为汽车准备足够的备件，或者更好的是在车道上停一辆备用车。但这个解决方案似乎有点极端，不是吗？

你应该致力于制定计划性更换计划（例如，每月轮换更换数据中心的磁盘作为主动措施），或者优化硬件本身的冗余可能会是更好的方案。例如，采用冗余磁盘配置（RAID集、冗余卷等）、服务器中的多个网卡、冗余交换机、高可用性防火墙设备等，以避免或尽量减少因组件故障导致的停机。

作为MTTF的结束语，请允许我指出”mean”在”mean time to failure”中的错误含义。我更愿意将其表达为中位故障时间。我记得美国卡内基梅隆大学进行过一项研究，统计结果显示服务器磁盘故障的MTTF约为100年，而实际经验表明更准确的中位故障时间最多为10年。

MTTR – 平均修复时间

MTTR代表平均修复时间；虽然这个定义听起来不言自明，但让我们受Google SRE定义的启发，尝试提供更完整的含义定义：

“MTTR是指一种事件管理指标，使企业能够衡量排除故障并修复IT系统问题、将其恢复到健康稳定状态所需的平均时间。在DevOps和SRE实践中，该定义（以及缩写）通常用于衡量IT环境的可用性和可靠性，但由于其关注修复过程，它可能更指向DevOps和SRE团队的服务质量，而非IT系统本身。简而言之，可以使用该指标来衡量DevOps或SRE团队的整体质量，以及所用工作负载或平台服务的质量。”

计算MTTR使用以下公式：

非计划维护总时间 / 总修复次数

假设你运行一个应用工作负载100小时（运营时间——参见MTBF缩写），在此期间故障了三次。检测并修复这三个问题（=维护时间）所需的总时间为六小时。

在这个例子中，MTTR = 6 / 3 = 2 小时。

坦率地说，不同行业对同一缩写有不同的含义：

• MTTR：平均恢复时间（这个含义更确定，因为问题不仅被修复，而且得到了较长时间的解决）
• MTTR：平均响应时间（这是对问题做出反应所需的时间）

回到风险评估的话题，如果MTTR超过了RTO（恢复时间目标），则意味着系统故障将导致不可接受的业务中断。

让我们用一个更具体的IT行业例子来映射这些定义：

2005年卡特里娜飓风袭击美国墨西哥湾沿岸时，大多数电话固定线路基础设施由Axcent Networks拥有和运营，该公司刚刚完成两个大型网络基础设施的合并。合并后的数据并未完全录入系统。虽然在正常运营中这不会造成大问题，但在飓风期间以及随后的几个月里，这确实带来了巨大麻烦。由于常规路由无法使用，提供商进入了网络发现模式。这导致了整体响应时间变慢（MTTR – 平均响应时间），不仅使运营商因无法满足与合作伙伴和客户的系统正常运行时间SLA而增加了运营成本，还导致了将所有信息编入目录的巨大成本，以及飓风后最初几天内快速“修复”（MTTR – 平均修复时间）的巨额成本。最终，在飓风过后数月，这演变为更稳固的MTTR（平均恢复时间），Axcent在该地区提供了全新的固定线路布线基础设施。

更多信息请参见关于此案例的文章：作为更广泛故障恢复计划一部分的MTTR（来源：Axcent axcent_dataintegrity_final.pdf (http://wordpress.com)）。

MTTR的原因与后果

MTTR（平均修复时间）从检测到故障的时刻开始，到故障修复完毕、受影响工作负载恢复运行状态时结束。这段时间通常包括诊断、故障排除和提出（通常是临时的）解决方案所需的时间。

如何解读低或高MTTR的结果也很重要。低（快）MTTR（快速修复）可被视为积极信号，但可能只是快速修补，无法保证受影响的系统或工作负载在（快速）修复后会更加稳定。

其次，响应时间与恢复时间之间的关系也至关重要。快速的响应时间可能是积极信号，但如果响应者花费相当长的时间进行故障排除并制定修复策略，总体MTTR仍然会很低。

如果你的MTTR很短（意味着任何问题都能在短时间内修复），但故障频繁（低MTBF），那将对你的业务造成损害，因为你将被视为状态不佳。

第2章 服务级别管理定义与缩写

现有客户在抱怨，新客户对你的产品不感兴趣，并且很难说服他们改变想法。

如果MTTR很长，意味着修复问题需要相当长的时间，但同时MTBF也很长，意味着故障很少或极不频繁发生，客户可能会原谅。显然，还有其他因素需要考虑，比如卡特里娜飓风的例子，或者COVID-19大流行早期公共云的影响（https://news.microsoft.com/source/features/innovation/azure-covid-19/?msockid=23e87e5108016409179b6ac4092a65c4）。

MTBF – 平均故障间隔时间

MTBF是平均故障间隔时间（mean time between failure）的缩写，受Google SRE文档启发，可以描述如下：

“MTBF是一个事故管理指标，允许企业衡量系统或应用程序故障之间的平均时间。它主要指可修复故障发生之间的时间。在DevOps和SRE实践中，该定义（及缩写）通常用于衡量IT环境的可用性和可靠性。简而言之，可以使用该指标来衡量DevOps或SRE团队的整体质量，以及所使用工作负载或平台服务的质量。”

使用以下公式计算MTBF：

运营总时间 / 故障总次数

以此为例，应该有助于理解结果。

假设你运行一个应用工作负载100小时（运营时间）；实际上它只运行了90小时，有10小时停机时间，可能发生了三次（故障次数）。在这个例子中，MTBF是90/3 = 30小时。

虽然这是一个基本示例，但也能识别出一些可能的误解。

有人可能认为每30小时应用工作负载就会发生故障。然而，并不能保证恰好每30小时发生一次。但MTBF常被用作预测，以估计下一次故障何时发生，或平均时间可能是什么样子。

其次，这个示例也没有考虑修复时间（MTTR）。可能第一次停机后，恢复时间比第二次和第三次停机时长得多，假设停机根本原因相同。

最后，有人可能得出结论：MTBF越长越好。但这在某种程度上取决于“故障”的定义。如果一个完整可工作的系统（如复杂应用架构）宕机，那么是的，MTBF越长，架构和应用越稳固。然而，如果系统中的某个bug由于一行损坏的代码导致故障，MTBF可能相当短，这本身可能迫使DevOps或SRE团队更快、更频繁地提出修复方案（MTTR）。在这种情况下，短MTBF也可能是一个积极信号，尽管仅限于有限的时间段。

2-6

Cisco ASA防火墙有一个已知的事故案例，说明运行特定软件版本的任何Cisco设备在恰好231天12小时后会“崩溃”。这就是MTBF。解决方案是重启受影响的设备，并（最好）更新软件。

https://www.cisco.com/c/en/us/support/docs/field-notices/642/fn64291.html

现场通知：FN-64291 – ASA和FTD软件 – 安全设备在运行213天后可能无法通过流量 – 需要重启 – 建议升级软件 – Cisco

图 2-6. Cisco 现场通知

需要考虑的另一个重要因素是设备使用时的整体条件和环境，意味着MTBF在很大程度上取决于设备的使用方式或地点。一个有趣的例子是物理服务器。我记得看到过服务器硬件的MTBF数字（通常针对单个组件，如RAM内存、CPU等），尽管不适用于完整的物理服务器设备。

在供应商那里，MTBF计算很可能基于其工程部门的研究。然而，实际的MTBF很大程度上取决于使用条件。物理服务器在炎热、潮湿、位置不平衡的环境中运行（大约20年前，我的一位客户就是如此，他从事航运业，在大西洋和南美洲的船舶上运行服务器——相信我，你不会想成为那艘船上的服务器）时，MTBF要短得多，而在纽约某商业园区内温度控制和制冷法规完美平衡的服务器机房中（是的，我也有处于那种情况的客户），则安全得多。

MTBF的原因与后果

基于之前分享的例子，MTBF短的主要原因之一是设备运行或使用时的条件。因此，原因和后果可以归结为错误使用。将其映射到数据中心基础设施和运行的应用上，可以想到规模过小的服务器，这会给系统带来比保持健康运行更多的压力。

此外，为了更好地理解MTBF，还应该理解其与MTTR（平均修复时间）的关系，这在前面已经讨论过。如果你面临频繁停机，但不需要太多时间修复问题，可能会导致从不寻找更稳固、长期的解决方案。例如，在之前的Cisco ASA设备中，与其修复软件问题，简单的解决方案（无论是工作量还是时间）是重启——甚至可能将其安排为现有软件中的一个计划选项。然而，这很可能不会被使用Cisco ASA解决方案的合作伙伴和客户所接受。因此，更好的解决方案（Cisco应用的）是查找根本原因（有缺陷的软件）并尝试缓解问题（修复软件中的bug），从而延长MTBF并最小化（或消除）MTTR。

简而言之，只改进单一指标（缩短MTBF或MTTR）毫无帮助。如前所述，应该综合考虑所有三个指标，以获得足够的结果并做出正确决策。我尝试用几个例子解释相关性：

• 长MTBF配合短MTTR：意味着最小停机时间，因为故障不频繁，且发生时能快速解决。
• 短MTBF配合长MTTR：意味着最大停机时间，客户不满且SLA被违反。
• 仅长MTBF：并不意味着你的服务总是可靠的，但短MTTR和长MTBF结合，你确实拥有可靠的服务。
• 有时，这是一个判断问题；例如，如果你有一个微服务每天崩溃50次（MTBF非常低），但因为没有客户注意到，因为它能快速自我重启（MTTR非常低），修复它可能不是你的首要任务。

如何改进不可用性指标

最终，DevOps和SRE团队将寻求改进他们构建和支持的基础设施及应用的MTBF（以及相关的MTTR和MTTF）指标。

处理这一问题的最佳方式是依赖监控，甚至更好的是使用可观测性（observability）——我将在后面的章节中讨论。可观测性保证能够访问必要的数据，并清晰地看到发生的事件。从指标和日志开始，并将追踪集成到你的监控实践中。当设备或应用发生故障时，团队可以立即确定问题或事故的根本原因。

一旦确定了根本原因并有了解决方案，像DevOps流程和流水线这样的工作流自动化能力将有助于缩短解决时间。工作流过程自动化的优势在于，它不仅有助于响应，还能应对从检测事件、正确响应到最终解决的整个流程的复杂性。

事后复盘

接着MTTR、MTBF和MTTF的定义，它们核心关注问题检测、故障和修复，我认为也有必要谈谈事后处理，主要描述在问题严重性得到修复后应该做什么。问题缓解后，同等甚至更重要的步骤是进行事后复盘。这主要包括记录导致修复或长期解决方案的步骤，记录可能的根本原因，以及你采取的哪些步骤导致了更短的解决时间（MTTR）。确定是谁或哪个过程对停机负责，谁承担了解决的所有权，以及未来可以采取什么措施避免停机或故障重复发生。（我将在后面的章节中分享更多关于有效且无指责的事后复盘的细节，分享一些关于什么有效、什么无效的经验。）

辛劳

SRE语言中一个非常常见的词是“辛劳”（toil）。你可能还记得第一章：为了优化SRE团队的工作和责任，他们应该能够将大约50%的时间用于“工程”工作，50%用于“运维”工作。辛劳完美地适用于这两个类别，可能指任何远离工程工作的事情，通常反映一个站点可靠性工程师不喜欢做的任务，很可能因为它倾向于反映一个手动任务或一系列手动任务。

由于SRE不能没有一部分运维工作，Google工程团队决定给它起一个新名字：“辛劳”。

一个戏谑的误解是将所有“手动”工作定义为辛劳，这是不正确的。辛劳特别指任何可重复的任务，从反应性角度触发（通常是事后追赶），且没有明确的结果或优化。可以说它并没有真正增加业务价值，但不知何故仍然需要完成。“辛劳”任务可能具有以下一个或多个属性：手动的、重复的、可自动化的、反应性的、无附加价值的、随服务扩展的。

从站点可靠性工程师的角度来看，最终目标始终应该是尽量避免辛劳，或至少尽可能减少它，部分原因在于它占用了原本可以用于更相关的SRE职责的时间，部分原因在于它对个人、SRE团队乃至组织的成功没有贡献。

可靠性层次结构

2-7

Dickerson 的可靠性层次结构

图 2-7. Dickerson 的可靠性层次结构

• 监控：作为基础，了解实际发生的情况并充分理解架构的行为。它允许你基于客观数据做出决策。我们需要能够测量以改进。对DevOps和SRE都至关重要的方面如下：
  • DevOps 关注价值 → 监控将帮助你确认交付的价值。
  • SRE 关注可靠性 → 良好的监控实施对于定义SLI/SLO至关重要，这些将作为SRE实践的基础。
• 事件响应：组织需要定义他们如何处理所遇到的事件以及他们将遵循的标准化流程：对问题进行分流、获取资源并缓解问题。

第2章 服务级别管理定义与缩写

• 无指责事后分析：如前所述，事故应被视为学习机会（以避免再次犯同样的错误）。组织需要制定实践，以改进研究、审查和学习体验。
• 测试/发布流程：主要支柱聚焦于自动化，可细分为以下内容：
  • CI/CD DevOps 流程：变更如何持续构建、测试（功能测试、质量测试和安全测试）并部署到服务中，遵循正确的发布策略/模式。
  • 可靠性聚焦测试：实践如性能/负载测试，将解决方案置于“真实”场景下，或混沌工程，其中“生产”中的故障被实际注入用于测试/实验。
• 容量规划：投资于可扩展且有弹性的架构，使其能够在各种场景（如高负载或区域不可用）下扩展并满足需求。
• 开发与用户体验（或产品）：聚焦于开发过程和提供的用户体验，这至关重要，因为服务等级目标（SLO）应基于客户体验。通过客户的视角审视你的解决方案（他们在何地、何时以及如何访问你的产品）。

本书将解释Dickerson可靠性层次中提到的主题（Dev和UX除外），重点放在Azure工具/服务（以及Microsoft和GitHub相关服务）上。章节将不会按照金字塔定义的基础到高级顺序，而是按照以下顺序（从上到下）：

• 容量规划相关：第3章和第4章将解释在Azure中架构不同类型弹性解决方案（IaaS、PaaS、无服务器和微服务）的最佳实践。
• 测试/发布流程：
  • 第5章将解释自动化实践（使用GitHub和Azure DevOps）及部署策略。
  • 第8章将展示用于混沌工程的Azure Chaos Studio解决方案以及Azure负载测试服务，以审查应用程序性能和容量。
• 事故响应和无指责事后分析：如何高效使用Microsoft工具处理这些实践将在第6章中解释。
• 监控：第7章将概述可用的Azure监控工具，以获取关于运行环境的最佳洞察。将涵盖数据收集、分析和报告选项。

总结

在本章中，你了解了站点可靠性工程（SRE）语境中最常见的缩写和定义。尽管IT行业中最流行的缩写可能是SLA（尤其是在弹性和可靠性语境下），但应当清楚它实际上是最不具指示性的缩写之一。

SRE团队如果不能将业务需求与技术指标映射起来，就无法履行其职责。我划分了两大类指标：从服务级别指标（非技术性指标，如SLI、SLO和SLA）开始，再到可靠性指标（MTTR、MTTF和MTBF）。

接着，我补充了SRE词典中的其他关键定义：事后分析，使SRE团队能够记录其观察和发现，从而在未来更快地控制解决方案；以及解释了辛劳（toil）的含义。

希望这两章让你学到很多——我试图让你深入了解站点可靠性工程（团队）的世界、成为站点可靠性工程师（角色）所需的条件，以及如何开始与团队和组织内不同业务团队进行对话，使用清晰的缩写讲流利的共同语言。

从这里开始，后续章节将更加技术性，特别是关于Azure环境服务和架构的内容，详细说明构建和部署高可用、关键业务工作负载所需的一切，利用Azure能力，涉及基础架构和平台服务，以及优化微服务架构。

让我们开始吧。

图像上下文：

• [图像 169，第46页]
• [图像 177，第48页]
• [图像 182，第49页]
• [图像 184，第49页]
• [图像 195，第52页]
• [图像 221，第60页]