软件企业对可靠运营大规模服务的需求在不断增长。这种需求可以通过不同的方式来满足。谷歌为此提出了一种方法，也就是所谓的站点可靠性工程（SRE），这是一门将软件工程技术应用在运营上的学科。SRE 让软件企业能够在不线性增加运营服务所需人数的情况下扩展运行中的服务数量。此外，SRE 帮助团队做出数据驱动决策，决定何时在服务的可靠性上投入，而不是去实现新特性。
近年来，SRE 在软件行业中已经变得相当流行。越来越多的软件企业采用了这个规程。Siemens Healthineers 的团队合作数字健康平台于 2019 年开始采用 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>
除了部署之外，还需要执行一系列日常任务，以保持基础设施是最新的。在部署过程中设置好的警报规则将对实时问题发出警报。错误预算的消耗反而会跨越更长的时间。由于可能存在大量的日志，建议对遥测日志进行聚合，并预先计算每个 SLO 每天的误差量消耗。我们使用脚本将这些 SLO 统计信息概要迁移到 Kusto 数据库中，并可能包含更多的属性，比如当天和端点的总请求数。一旦数据在 Azure top="3319">服务警报
警报是 SRE 的一个非常重要的方面。频率的警报和晚到的警报之间总是存在一个权衡。谷歌的 SRE 系列图书介绍了几种不同风格的警报策略，它们都有各自的优点和缺点。在团队协作中，我们会计算过去一个小时的消耗率，如果服务消耗的误差量超过计划的两倍，就会发送警报。在每个误差量周期（四个日历周）结束时，我们还为那些消耗了所有误差量的端点发送一个通知。
下图摘自“Establishing SRE Foundations”一书，说明基于 SLI 的警报优于常规警报。
可视化仪表盘可以帮助团队检查为服务定义的 SLO，查看 SLO 的误差量消耗，并根据时间上的误差量消耗来确定可靠性工作的优先级。仪表盘是一种交互式的 PowerBI 报告，用户可以根据需要对数据进行过滤，每 24 小时更新一次。
仪表盘提供的附加功能：
下面显示并详细解释了一些现有的仪表盘。
下面的仪表盘显示了可用性误差量随着时间的推移而发生的消耗。它在仪表盘顶部显示了“post /api/categoriesdistribution/getcategoriesdistributiondata”99%的可用性。
顶部下面的横线图显示了随着时间的推移，每个部署环境每天剩余的误差量的百分比。最大的误差量消耗显示为一条红褐色的线。第二大的误差量消耗显示为一条红线。最小的误差量消耗显示为一条黄线。
3 月、4 月、5 月的 prod_eu（绿线）清楚地显示了过早的误差量消耗（误差量周期中的误差量为负）。4 月份的 prod_jp（黄线）也出现了这个现象。这为团队指明了哪些地方需要进行可靠性投入。
下面的竖线图显示了每个部署环境在一段时间内每天的失败请求率。
除了这个，也有用于跟踪延迟 SLI 误差量消耗的仪表盘。
SRE 基础设施提供了两个可靠性优先级仪表盘：
对于选中的项，仪表盘左上角的饼图显示了所有适用的 SLO 与正在消耗误差量的 SLO 的概览。到目前为止，大约 70%的 SLO 在当前误差量周期的 13 天内没有误差量消耗。
仪表盘下方的表格显示了可选择的 SLO。左侧显示的是可用性 SLO，右侧显示的是延迟 SLO。在颜色方面，每个 SLO 的合规情况以一种引人注目的方式显示出来：
有了这个仪表盘，团队可以将注意力放在需要立即提升可靠性的地方。发布后的服务监控是仪表盘发挥重要作用的一个场景。在产品发布后的几天，评估部署变更对误差量消耗的影响是一件非常有趣的事。
长期可靠性优先级仪表盘如下所示。团队可以把它放大，查看过去三个月服务的误差量消耗情况。
有了这个仪表盘，团队可以将注意力放在需要立即提升可靠性的地方。基于仪表盘上的数据，团队通常会创建一些工作项，通过现有的优先级过程（例如看板或 Scrum）来确定需要高优先级的可靠性提升工作。
我们建议使用一种非常直观的颜色编码，如红色/黄色/绿色，来表示误差量消耗和其他指标。此外，用户应该能够根据不同的地理区域或技术服务上下文轻松地过滤数据，检测到问题所在，并将其限制在某个领域。
为了方便进行比较，可以对误差量消耗图进行规范化。这样可以将重点转移到客户体验上，因为 SLO 是基于客户满意度定义的，因此一个用例的 99.9%的 SLO 与另一个用例的 95%的 SLO 同等重要。
在警报方面，我们建议在警报消息体中加入详细的上下文信息，方便开发人员定位问题的根源。警报消息体本身也应该包含资源、Runbook 甚至数据库查询的链接。所有这些都有助于缩短事故后的恢复时间。
仪表盘的维护工作量非常小，因为每日刷新机制会自动收集最新的数据。只有当数据传播因发生了短暂的错误（例如源数据不可用）而失败时，才需要进行手动维护。在大多数情况下，这些错误通过再次刷新就可以修复。当然，仪表盘应该根据 SRE 的需要不断改进，包括可用性的改进，或者通过加入新的图表和从日志中抽取的附加信息进行扩展。每天的数据刷新就足够了，因为仪表盘不适合用于进行反应式的生产监控。这是通过警报机制来实现的。仪表盘应该被用于在开发周期中根据新特性的开发情况来确定可靠性优先级。此外，它应该提供关于已定义的 SLO 的概览，并且有助于可视化新部署的变更对可靠性的影响。这可以通过在发布之前、发布期间和发布之后比较服务的性能来实现。
要使用 SRE 基础设施，开发团队需要为之做好准备。团队需要了解通过 SRE 来运维服务的优势。为了让团队熟悉 SRE 的方法论、概念和基础设施，我们主要采用了团队指导的方法。
我们基于团队采用 SRE 基础设施，并认识到每个团队都是独特的，它们都有自己的成长过程。
我们根据经验将 SRE 嵌入到我们的持续改进计划中，使用了前面描述的指标框架，并系统性地在整个组织中推广开来。
SRE 基础设施的采用可以通过几个维度来衡量：
维度 1 到 7 只是输出，而不是结果。维度 8 到 10 可以被认为是结果。在我们采用 SRE 基础设施的 3 年时间里，上述部分维度的数据如下：
我们确实有可量化的证据表明，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 FoundationsDevOps方面的知识
原文链接
：
Establishing a Scalable SRE Infrastructure Using Standardization and Short Feedback Loops
可视化仪表盘
SLI 的误差量消耗仪表盘
可靠性优先级仪表盘
有助于提升生产力的用户体验
使用 SRE 基础设施
SRE 基础设施的采用
总结
鸣谢
