通过标准化和短反馈循环打造可伸缩的 SRE 基础设施

软件企业对可靠运营大规模服务的需求在不断增长。这种需求可以通过不同的方式来满足。谷歌为此提出了一种方法，也就是所谓的站点可靠性工程（SRE），这是一门将软件工程技术应用在运营上的学科。SRE 让软件企业能够在不线性增加运营服务所需人数的情况下扩展运行中的服务数量。此外，SRE 帮助团队做出数据驱动决策，决定何时在服务的可靠性上投入，而不是去实现新特性。

近年来，SRE 在软件行业中已经变得相当流行。越来越多的软件企业采用了这个规程。Siemens Healthineers 的团队合作数字健康平台于 2019 年开始采用 SRE。它帮助企业可靠地运营大规模的平台。

在我们的 SRE 实现中：

• 运营团队构建并运行 SRE 基础设施；

• 开发团队利用 SRE 基础设施构建和运行服务。

这是“你构建，你运行”的一种职责划分。我们之所以要实现“你构建，你运行”，主要原因是这个模型为开发团队在特性开发期间实现可靠性提供了最大的源动力。轮班待命的开发人员并不喜欢被呼叫。有了“你构建，你运行”这种模型，开发人员可以在将服务部署到生产环境之前实现足够的可靠性，从而可以避免被呼叫。

SRE 基础设施让开发人员能够以敏捷的方式运行他们的服务。我们采用了非常短的反馈循环和标准化，让基础设施在发挥作用的同时具备可伸缩性。短反馈循环支持可伸缩性，因为基础设施的开发采纳了来自开发人员的反馈，他们需要使用基础架构来实现他们的监控目标。随着时间的推移，基础设施就有了足够多的有用特性，就会有更多的团队想要使用它们。

在本文中，我们介绍了我们的 SRE 基础设施的架构和实现，以及如何使用它。

实现 SRE 基础设施

SRE 基础设施是一系列工具、算法和可视化仪表盘的组合，让团队能够以有效的方式可靠地运营大规模的服务。SRE 基础设施的实现、维护和运营需要一个专门的开发者团队。

敏捷交付

在构建 SRE 基础设施时，我们在运营团队和开发团队之间建立了非常紧密的工作模式。在特性实现方面，我们确保运营团队始终只领先开发团队一步，但不会领先太多。每个实现的特性都立即提供给开发团队使用，并根据反馈不断迭代。

架构

SRE 基础设施的架构需要实现多个几乎同等重要的目标。这些将在下面的内容中进行描述，其中还包括架构的外部和内部视图。

目标

我们选择将可伸缩性作为 SRE 基础设施最重要的架构目标，这样有限的基础设施开发人员就可以为大量的开发团队和他们的异类需求提供服务。一套标准化的监控工具对于减少 SRE 基础设施工程师的初始工作量来说至关重要。遥测日志需要被标准化，这样就在不同的日志表上执行相同的数据库查询。否则，每个服务都需要记录自己的格式，例如可用性日志，然后需要专门的查询来检查服务的可用性。在这种情况下，SRE 基础设施工程师需要构建和维护大量频繁过时的查询。因此，这不是一个可行的解决方案。

这与第二个目标（跨越时间和团队的一致性）有关。触发警报的原因应该对任何感兴趣的警报响应者立即可见。确保所有 SRE 相关日志都有一个通用的模式，这样就可以通过少量的逻辑模板（例如，为检查 SLO 漏洞而进行的日志数据查询）进行聚合和监控大量的遥测数据。团队可以在这些模板中填入团队和服务的依赖信息，从而实现团队的定制化需求。有了这样的基础，一致性和可伸缩性就不再是相互冲突的目标，它们之间是可以相互受益的。

第三个目标是基础设施的可用性。任何熟悉 SRE 相关术语的开发人员都应该能够自己调整、创建和移除他们服务的 SLO。为此，我们需要在工具的直观性方面进行大量思考。在最好的情况下，你希望将用于 SLO 定义的自定义工具集成到现有的服务部署管道中，让 SLO 从一开始就处于活动状态，并且在发布新产品之前就已经完成了定义这些工具的思考过程。配置文件本身可以非常简单，标准化的目标应该被自动附加到服务中，这样就不会因意外而遗漏了任何东西。当然，开发团队应该能够通过扩展配置显式地移除或覆盖默认的 SLO。

自定义视图

本节将从使用工具来跟踪服务的开发人员的角度描述 SRE 基础设施的视图。正如图中所示，开发人员无法访问基础设施本身，因此显示成一个黑盒子。你将在下一节中找到关于这一部分的细节。输入部分描述了每项服务需要提供的所有必要信息，通常包含了几个 SLO。

在团队协作中，对外暴露的端点的目标（SLA）与内部和外部使用的服务目标（SLO）是有区别的。SLA 是向外部合作伙伴承诺的 SLO，并且总是与内部 SLO 紧密相关。预期的服务行为和合同中约定的服务行为之间存在一定的差距，因此会在合同违约之前触发警报。延迟 SLI 的 SLO 定义包含误差量、阈值和目标服务端点清单。如果没有明确定义 SLO，最好是定义一个默认（回退）SLO，并自动分配给服务的所有端点。可用性的 SLO 定义包含了除了阈值之外的信息，而且定义了有效或无效的 HTTP 结果代码。此外还需要提供一个数据库标识符，以便在正确的地方检查违反行为的警报。警报信息定义了一个 Webhook 或一组邮件地址，在发生 SLO 违规时需要通过它们发送通知。为了完成闭环，警报通知被发送到指定的开发人员和 Webhook 地址。此外，我们还提供了一份交互式 PowerBi 报告，其中有过去三个月所有的 SLO、SLA 和误差量消耗情况。

内部视图

本节将介绍将 SRE 配置转换为警报和仪表盘所需的步骤。

首先，在部署服务时在已配置的 SLO 目标上安装或更新警报。在我们的场景中，这包括设置 Azure Monitor 警报规则，这些规则是经常被执行的带有警报条件的日志查询。它们将定义的 SLO 目标与实时数据进行比较，并对当前误差量消耗发出警报。然后在 PagerDuty 中配置一个 Webhook 条目，处理在发生 SLO 违规时发出的警报，并通知相关利益相关者和开发人员来解决正在发生的问题。

然后，SRE 配置被上传到 SLO 数据库。我们建议将所有定义和部署的 SLO 和服务放在同一个地方，这样就可以非常方便地查看它们。在团队协作中，一般使用 Azure Data Explorer 来保存这类信息，因为它可以很好地与 Power BI 集成，而且它的查询语言非常强大。

除了部署之外，还需要执行一系列日常任务，以保持基础设施是最新的。在部署过程中设置好的警报规则将对实时问题发出警报。错误预算的消耗反而会跨越更长的时间。由于可能存在大量的日志，建议对遥测日志进行聚合，并预先计算每个 SLO 每天的误差量消耗。我们使用脚本将这些 SLO 统计信息概要迁移到 Kusto 数据库中，并可能包含更多的属性，比如当天和端点的总请求数。一旦数据在 Azure data Explorer 中可用，PowerBI 就会自动拉取数据。

服务警报

警报是 SRE 的一个非常重要的方面。频率的警报和晚到的警报之间总是存在一个权衡。谷歌的 SRE 系列图书介绍了几种不同风格的警报策略，它们都有各自的优点和缺点。在团队协作中，我们会计算过去一个小时的消耗率，如果服务消耗的误差量超过计划的两倍，就会发送警报。在每个误差量周期（四个日历周）结束时，我们还为那些消耗了所有误差量的端点发送一个通知。

下图摘自“Establishing SRE Foundations”一书，说明基于 SLI 的警报优于常规警报。

可视化仪表盘

可视化仪表盘可以帮助团队检查为服务定义的 SLO，查看 SLO 的误差量消耗，并根据时间上的误差量消耗来确定可靠性工作的优先级。仪表盘是一种交互式的 PowerBI 报告，用户可以根据需要对数据进行过滤，每 24 小时更新一次。

以下是可用的仪表盘：

• SLO 定义仪表盘（分别用于可用性、延迟和间隔指标）；

• SLO 合规仪表盘（分别用于可用性、延迟和间隔指标；显示单个 SLO 在过去三个误差量周期的合规情况）；

• 可靠性优先级仪表盘（显示团队、服务或部署的所有 SLO 在过去三个误差量周期的合规情况，并按照上面显示的最大误差量消耗进行排序）；

• 当前概要仪表盘（显示当前误差量周期的 SLO 合规情况）。

仪表盘提供的附加功能：

• 重试建议（检测被错过的针对 HTTP 500 的重试）。

对未来仪表盘的想法：

• 分布式系统缺乏适用的稳定性模式（例如，检测缺失的断路器）；

• 位于服务层次结构上方的 SLO 比位于服务层次结构下方被依赖的 SLO 会更加紧密（尽管在某些情况下，可能可以在不太可靠的东西上构建更加可靠的东西。请参考 Steve McGhee 在 SLOconf 上的演讲：SLO Math）。

下面显示并详细解释了一些现有的仪表盘。

SLI 的误差量消耗仪表盘

下面的仪表盘显示了可用性误差量随着时间的推移而发生的消耗。它在仪表盘顶部显示了“post /api/categoriesdistribution/getcategoriesdistributiondata”99%的可用性。

仪表盘的顶部显示了 SLO、失败请求的定义、当前误差量周期的日期和当前错误率周期的剩余天数。

顶部下面的横线图显示了随着时间的推移，每个部署环境每天剩余的误差量的百分比。最大的误差量消耗显示为一条红褐色的线。第二大的误差量消耗显示为一条红线。最小的误差量消耗显示为一条黄线。

3 月、4 月、5 月的 prod_eu（绿线）清楚地显示了过早的误差量消耗（误差量周期中的误差量为负）。4 月份的 prod_jp（黄线）也出现了这个现象。这为团队指明了哪些地方需要进行可靠性投入。

下面的竖线图显示了每个部署环境在一段时间内每天的失败请求率。

除了这个，也有用于跟踪延迟 SLI 误差量消耗的仪表盘。

可靠性优先级仪表盘

SRE 基础设施提供了两个可靠性优先级仪表盘：

• 带有当前误差量周期概览的短周期仪表盘；

• 带有最近 3 个已完成的误差量周期概览的长周期仪表盘。

下面是短期可靠性优先级仪表盘。仪表盘上面部份的中间位置显示了当前误差量周期的日期，右下方显示了当前误差量周期的剩余天数：28 天已过去 13 天。

对于选中的项，仪表盘左上角的饼图显示了所有适用的 SLO 与正在消耗误差量的 SLO 的概览。到目前为止，大约 70%的 SLO 在当前误差量周期的 13 天内没有误差量消耗。

仪表盘下方的表格显示了可选择的 SLO。左侧显示的是可用性 SLO，右侧显示的是延迟 SLO。在颜色方面，每个 SLO 的合规情况以一种引人注目的方式显示出来：

• 红色的单元格表示最低 SLO 合规，也就是指在当前误差量周期过去的天数中最大的误差量消耗。剩余的误差量太小，在当前误差量周期结束前会提前耗尽。红色单元格显示在顶部，因为这是开发人员最需要注意的地方。

• 黄色单元格（示例中没有）表示当前误差量消耗相当高的情况下的 SLO 合规。如果继续维持当前的消耗率，很可能会导致当前周期的误差量过早耗尽。因此在当前误差量周期内很有必要调查一下导致这种误差量损耗的原因。

• 绿色单元格表示当前误差量周期的误差量消耗完全可以接受。即使消耗率保持不变，当前误差量周期最终也不会出现负值。

有了这个仪表盘，团队可以将注意力放在需要立即提升可靠性的地方。发布后的服务监控是仪表盘发挥重要作用的一个场景。在产品发布后的几天，评估部署变更对误差量消耗的影响是一件非常有趣的事。

长期可靠性优先级仪表盘如下所示。团队可以把它放大，查看过去三个月服务的误差量消耗情况。

经过数据过滤，仪表盘中间会显示一个过滤后的 SLO 列表。仪表盘的顶部显示了最近 3 个已完成的误差量周期的日期。在右边的彩色单元格中，每个误差量周期中的 SLO 合规情况以一种引人注目的方式显示处理：

• 红色单元格表示最小的 SLO 合规，在给定的误差量周期结束时，误差量为负值。括号内为实际完成百分比。红色单元格显示在最上面，因为这些是最需要提升可靠性的地方。

• 黄色单元格表示在给定的误差量周期内误差量几乎被耗尽。虽然还剩余一些误差量，但很有必要调查一下为什么消耗如此之快。

• 绿色单元格表示完全可接受的误差量消耗。

有了这个仪表盘，团队可以将注意力放在需要立即提升可靠性的地方。基于仪表盘上的数据，团队通常会创建一些工作项，通过现有的优先级过程（例如看板或 Scrum）来确定需要高优先级的可靠性提升工作。

有助于提升生产力的用户体验

我们建议使用一种非常直观的颜色编码，如红色/黄色/绿色，来表示误差量消耗和其他指标。此外，用户应该能够根据不同的地理区域或技术服务上下文轻松地过滤数据，检测到问题所在，并将其限制在某个领域。

为了方便进行比较，可以对误差量消耗图进行规范化。这样可以将重点转移到客户体验上，因为 SLO 是基于客户满意度定义的，因此一个用例的 99.9%的 SLO 与另一个用例的 95%的 SLO 同等重要。

在警报方面，我们建议在警报消息体中加入详细的上下文信息，方便开发人员定位问题的根源。警报消息体本身也应该包含资源、Runbook 甚至数据库查询的链接。所有这些都有助于缩短事故后的恢复时间。

仪表盘的维护工作量非常小，因为每日刷新机制会自动收集最新的数据。只有当数据传播因发生了短暂的错误（例如源数据不可用）而失败时，才需要进行手动维护。在大多数情况下，这些错误通过再次刷新就可以修复。当然，仪表盘应该根据 SRE 的需要不断改进，包括可用性的改进，或者通过加入新的图表和从日志中抽取的附加信息进行扩展。每天的数据刷新就足够了，因为仪表盘不适合用于进行反应式的生产监控。这是通过警报机制来实现的。仪表盘应该被用于在开发周期中根据新特性的开发情况来确定可靠性优先级。此外，它应该提供关于已定义的 SLO 的概览，并且有助于可视化新部署的变更对可靠性的影响。这可以通过在发布之前、发布期间和发布之后比较服务的性能来实现。

使用 SRE 基础设施

要使用 SRE 基础设施，开发团队需要为之做好准备。团队需要了解通过 SRE 来运维服务的优势。为了让团队熟悉 SRE 的方法论、概念和基础设施，我们主要采用了团队指导的方法。

我们逐个指导团队：

• 实现标准化的日志；

• 通过迭代定义 SLO；

• 培训团队成员使用随叫随到的轮岗方式来应对 SLO 违规；

• 演示如何使用误差量消耗来识别可靠性问题；

• 演示如何使用提供的仪表盘确定可靠性的优先级；

• 执行误差量策略。

我们基于团队采用 SRE 基础设施，并认识到每个团队都是独特的，它们都有自己的成长过程。

我们根据经验将 SRE 嵌入到我们的持续改进计划中，使用了前面描述的指标框架，并系统性地在整个组织中推广开来。

SRE 基础设施的采用

SRE 基础设施的采用可以通过几个维度来衡量：

1. 随着时间的推移，采用 SRE 基础设施的团队的数量；

2. 随着时间的推移，SRE 基础设施上的服务的数量；

3. 使用 SRE 基础设施监控的环境的数量；

4. 随着时间的推移，SLO 合规的服务的百分比；

5. 随着时间的推移，SLA 合规的服务的百分比；

6. 随着时间的推移，事故后诊断的数量；

7. 随着时间的推移，可视化仪表盘中视图的数量；

8. 随着时间的推移，中断发生的次数；

9. 随着时间的推移，客户问题升级的数量；

10. 随着时间的推移，报告故障的工单的数量。

维度 1 到 7 只是输出，而不是结果。维度 8 到 10 可以被认为是结果。在我们采用 SRE 基础设施的 3 年时间里，上述部分维度的数据如下：

1. 使用 SRE 基础设施的团队的数量：17 个；

2. SRE 基础设施上的服务数量：57 个；

3. 使用 SRE 基础设施监控的环境的数量：15 个；

4. 最近 180 天内 SLO 合规的服务的百分比：

5. 在过去 180 天内没有提前耗尽可用性误差量的可用性 SLO 百分比：99.72%；

6. 在过去 180 天内没有提前耗尽可用性误差量的延迟 SLO 百分比：95.89%。

7. 过去 180 天 SLA 合规的服务的百分比：

8. 在过去 180 天内没有提前耗尽可用性误差量的可用性 SLA 百分比：100%；

9. 在过去 180 天内没有提前耗尽可用性误差量的延迟 SLA 百分比：100%。

10. 过去 6 个月的事故后诊断数量：9 个；

11. 过去 3 个月可视化仪表盘的视图数量：559 个；

12. 过去 6 个月的主要中断次数：1 次；

13. 过去 6 个月升级的客户问题数量：2 个。

我们确实有可量化的证据表明，SRE 的应用显著减少了客户问题升级的数量，减少了外部向我们内部团队报告的中断次数。此外，我们确实也有可量化的证据表明，SRE 的应用提供了一个良好的结构用于定义、分割和实现开发团队中各个角色之间的运营责任，甚至更多。

但没有证据表明 SRE 的应用需要随着运行中的服务数量的增加而扩大运营服务的人数。此外，我们需要在衡量 SRE 基础设施的价值方面投入更多，以便能够轻松地看出价值趋势的变化。

最后，有证据表明，已经在现有服务中采用 SRE 的团队从一开始就默认也将其应用到新服务中，通过内建的可靠性对新服务进行初始化、原型化、实现和部署。这必将在未来的生产环境中带来更可靠的服务。

总结

在产品交付组织中实现全新的 SRE 是一项相当艰巨的任务。它需要由专门的人员构建 SRE 基础设施，并帮助开发团队采用这个基础设施。这个过程需要进行广泛的团队指导，推动团队对 SRE 的认识和理解，并将 SRE 概念应用到每个独特的团队环境中。在团队开发人员和 SRE 基础设施工程师之间还建立起紧密的反馈回路，以确保基础设施满足用户的需求。

有关我们工作的更多细节，可以在即将于 2022 年晚些时候出版的“Establishing SRE Foundations”一书中看到。

鸣谢

我们要感谢在 Siemens Healthineers 数字健康平台中担任各种角色的人员，他们为推动 SRE 的采用做出了贡献。

作者简介：

Philipp Gündisch 是一名运维工程师，曾在德国埃尔兰根-纽伦堡大学学习计算机科学。他对云产品很感兴趣，并加入 Siemens Healthineers，帮助运营数字健康平台。

Vladyslav Ukis 博士毕业于德国纽伦堡埃尔兰根大学计算机科学专业，后又在英国曼彻斯特大学拿到博士学位。他在毕业后加入 Siemens Healthineers，一直从事软件架构、企业架构、创新管理、私有和公共云计算、团队管理、工程管理、投资组合管理、合作伙伴管理和数字化转型等工作。他目前担任 Siemens Healthineers 数字健康平台的研发主管。他在计划于 2022 年晚些时候出版的新书“Establishing SRE Foundations”中分享了他在DevOps方面的知识。

原文链接：

Establishing a Scalable SRE Infrastructure Using Standardization and Short Feedback Loops