站点可靠性工程师的变更管理指南

在我的上一篇文章中，我撰写了事件管理 (IM)，它是站点可靠性工程的重要组成部分。在本文中，我将重点关注变更管理 (CM)。为什么需要管理变更？为什么不简单地来一个自由放任，让任何人随时都可以进行变更呢？

有效 CM 有三个原则。这为您提供了 CM 策略的预测框架

• 渐进式发布变更： 渐进式发布（您分阶段部署变更）与一次性完成之间存在差异。您会发现，即使渐进式变更在纸面上看起来不错，也有一些需要避免的陷阱。
• 检测变更中的问题： 监控对于 CM 的有效运作至关重要。我将讨论并查看如何设置有效的监控的示例，以确保您可以检测到问题并尽可能快地进行变更。
• 回滚程序： 当事情出错时，您如何有效地回滚？

为什么要管理变更？

据估计，75% 的生产环境中断是由变更引起的。我们都执行的计划内和已批准的变更。这个数字令人震惊，只需要您掌握 CM，以确保在尝试变更之前一切就绪。这些惊人数字的主要原因是变更本身存在固有的问题。

基础设施和平台正在快速发展。不久前，基础设施还没有那么复杂，而且易于管理。例如，一个组织可能只有几台服务器，他们在这些服务器上运行应用程序服务器、Web 服务器和数据库服务器。但最近，基础设施和平台变得前所未有的复杂。

不可能在事后分析由众多子系统引起的每个互连和依赖关系。例如，应用程序所有者甚至可能不知道外部服务的依赖关系，直到它实际中断为止。即使应用程序团队意识到这种依赖关系，他们也可能不知道远程服务由于其变更而做出响应的所有复杂性和所有不同方式。

您不可能测试未知的场景。这可以追溯到当前基础设施和平台的复杂性。就您在实际应用变更之前花费的时间来测试每个场景而言，这将是成本过高的。每当您在现有生产环境中进行变更时，无论是配置变更还是代码变更，事实是，您都面临着创建中断的高风险。那么我们如何处理这个问题呢？让我们看一下有效 CM 系统的三个原则。

SRE 有效变更管理系统的 3 个原则

自动化是有效 CM 的基础方面。自动化贯穿 CM 的整个过程。这涉及以下几个方面

• 渐进式发布： 渐进式发布机制允许您分阶段实施变更，而不是进行一次大型变更，从而减少用户群在出现问题时受到的影响。如果您的用户群很大，例如 Web 规模的公司，则此属性至关重要。
• 监控： 您需要快速准确地检测到变更中的任何问题。您的监控系统应该能够毫无时间延迟地揭示您的应用程序和服务的当前状态。
• 安全回滚： CM 系统应在需要时快速安全地回滚。在没有万无一失的回滚计划的情况下，不要尝试对您的环境进行任何变更。

自动化的作用

你们中的许多人都知道自动化的概念，但是许多组织缺乏自动化。为了提高发布的velocity，velocity是运行敏捷组织的重要组成部分，必须消除手动操作。这可以通过使用持续集成和持续交付来实现，但这只有在大多数操作都完全自动化时才有效。这自然会消除因疲劳和粗心造成的人为错误。实际上，自动伸缩是基于云的应用程序的重要功能，不需要人工干预。此过程需要完全自动化。

SRE 的渐进式发布：逐步部署变更

对配置文件和二进制文件的更改会产生严重的后果，换句话说，当您对现有生产系统进行更改时，您将面临严重影响最终用户体验的风险。

因此，当您逐步部署变更而不是一次性部署时，您可以在出现问题时减少影响。如果我们需要回滚，那么以渐进方式完成变更时，工作量通常会较小。这里的想法是，您将从一小部分客户端开始您的变更。如果您发现变更存在问题，您可以立即回滚变更，因为此时影响范围很小。

渐进式发布有一个例外，如果它是紧急修复并且有必要这样做，您可以一次性全局发布变更。

渐进式发布的陷阱

发布和回滚可能会变得复杂，因为您正在处理发布的多个阶段。缺乏所需的流量可能会破坏发布的有效性。尤其是在初始阶段，您在发布中针对的是较小的客户端集时。危险在于，您可能会基于较小的客户端集过早地签署发布。它还发布了一个管道，您可以在其中运行一个包含多个阶段的脚本

与一次性（大型）变更相比，发布可能会变得更长。在一个真正分布在全球范围内的 Web 规模应用程序中，一项变更可能需要几天时间才能完全发布，这在某些情况下可能会成为问题。

文档非常重要。尤其是在一个阶段花费很长时间并且需要多个团队参与来管理变更时。必须详细记录所有内容，以防需要回滚或前滚。

由于这些陷阱，建议您深入了解组织变更发布策略。虽然渐进式发布是高效且推荐的，但如果您的应用程序足够小且不需要频繁变更，那么一次性变更是最佳选择。通过一次性完成，如果需要回滚，您将拥有一个干净的回滚方式。

渐进式发布的高级概述

一旦代码提交并合并，我们就启动“金丝雀发布”，“金丝雀”是测试对象。请记住，它们不能替代完整的自动化测试。“金丝雀”这个名字来源于早期的矿业，当时使用金丝雀鸟来检测矿井是否含有有毒气体，然后再让人进入。

测试完成后，使用一小部分客户端来发布我们的变更，并查看情况如何。一旦“金丝雀”通过，就进入下一个阶段，即“早期采用者发布”。这是一组稍大的客户端，您可以使用它们进行发布。最后，如果“早期采用者”通过，则转移到最大的一群：“所有用户”。

图片来源：

（Robert Kimani，CC BY-SA 4.0）

“爆炸半径”是指出现问题时的影响范围。当我们进行金丝雀发布时，它是最小的，而当我们向所有用户发布时，它实际上是最大的。

渐进式发布的选项

渐进式发布要么依赖于应用程序，要么依赖于组织。对于全球应用程序，基于地理位置的方法是一种选择。例如，您可以选择先发布到美洲，然后是欧洲和亚洲地区。当您的发布依赖于组织内的部门时，您可以使用经典的渐进式发布模型，许多 Web 规模的公司都在使用这种模型。例如，您可以从“金丝雀”、人力资源、市场营销开始，然后再到客户。

通常选择内部部门作为渐进式发布的首批客户，然后逐步转向外部用户。

您还可以选择基于规模的渐进式发布。假设您有一千台服务器运行您的应用程序。您可以从最初的 10% 开始，然后将发布量提高到 25%、50%、75%，最后达到 100%。这样，在您推进渐进式发布的过程中，您只会影响一小部分服务器。

在某些时期，应用程序必须同时运行 2 个不同的版本。这是您在渐进式发布情况下无法避免的事情。

二进制文件和配置包

系统有三个主要组成部分：二进制文件：（软件）、数据（例如，数据库）和配置（控制应用程序行为的参数）。

最好将二进制文件和配置文件彼此分开。您希望使用版本控制的配置。您的配置必须是“密封的”。在任何给定时间，当配置由应用程序派生时，无论配置何时何地派生，它都是相同的。这是通过将配置视为代码来实现的。

SRE 的监控

监控是 SRE 组织的基础能力。您需要知道您的应用程序是否存在影响最终用户体验的问题。此外，您的监控应帮助您确定根本原因。

监控的主要功能是

• 提供服务健康状况的可视性。
• 允许您基于自定义阈值创建警报。
• 分析趋势和计划容量。
• 提供对构成您的应用程序或服务的各种子系统的详细洞察。
• 提供代码级指标以了解行为。
• 使用可视化和报告。

监控的数据源

您可以监控环境的多个方面。这些包括

• 原始日志： 通常是从您的应用程序或服务器或网络设备生成的非结构化日志。
• 结构化事件日志： 易于使用的信息。例如 Windows 事件查看器日志。
• 指标： 组件的数值度量。
• 分布式跟踪： 跟踪事件通常由框架（例如 OpenTelemetry）自动创建，或使用您自己的代码手动创建。
• 事件自省： 帮助在运行时以详细级别检查属性。

在为您的 SRE 组织选择监控工具时，您必须考虑最重要的是什么。

速度

您可以多快地检索数据并将其发送到监控系统？

• 数据应该有多新鲜？数据越新鲜越好。您不希望查看 2 小时前的数据。您希望数据尽可能接近实时。
• 摄取数据和实时数据警报可能很昂贵。您可能必须投资像 Splunk 或 InfluxDB 或 ElasticSearch 这样的平台才能完全实现这一点。
• 考虑您的服务级别目标 (SLO) – 以确定监控系统应该有多快。例如，如果您的 SLO 是 2 小时，则您不必投资于实时处理机器数据的系统。
• 查询大量数据可能效率低下。如果您需要非常快速地检索数据，您可能必须投资于企业平台。

分辨率检查

监控数据的粒度是多少？

• 您真的需要每秒记录数据吗？推荐的方法是在任何可能的地方使用聚合。
• 如果对您的数据有意义，请使用采样。
• 指标适用于高分辨率监控，而不是原始日志文件。

警报

监控工具可以提供哪些警报功能？

确保监控系统可以与其他事件处理工具或第三方工具集成。例如，您的监控系统是否可以在紧急情况下呼叫某人？您的监控系统是否可以与票务系统集成？

您还应该使用不同的严重级别对警报进行分类。您可能希望为缓慢的应用程序选择严重级别 3，而不是为不可用的应用程序选择严重级别 1。确保可以轻松抑制警报以避免警报泛滥。电子邮件或页面泛滥可能会严重分散值班体验的注意力。必须有一种有效的方式来抑制警报。

[ 阅读下一篇： 7 个顶级的站点可靠性工程师 (SRE) 工作面试问题 ]

用户界面检查

它的通用性如何？

• 您的监控工具是否提供功能丰富的可视化工具？
• 它可以有效地显示时间序列数据以及自定义图表吗？
• 它可以轻松共享吗？这很重要，因为您可能不仅希望与其他团队成员共享您发现的内容，而且可能必须与领导层共享某些信息。
• 可以使用代码进行管理吗？您不希望成为一名全职监控管理员。您需要能够通过代码管理您的监控系统。

指标

指标可能无法有效地识别问题的根本原因。它可以告诉您系统中正在发生什么，但它无法告诉您为什么会发生。它们适用于低基数数据，当您的数据中没有数百万个唯一值时。

• 属性的数值度量。
• 带有属性的计数器。
• 易于摄取。
• 易于查询。
• 它可能无法有效地识别根本原因。指标可以告诉您系统中正在发生什么，但它无法告诉您为什么会发生。
• 适用于低基数数据 – 当您的数据中没有数百万个唯一值时。

日志

原始文本数据通常是填充了调试数据的任意文本。通常需要解析才能获取数据。数据检索和召回比使用指标慢。原始文本数据对于确定许多问题的根本原因很有用，并且对数据的基数没有严格的要求。

• 任意文本，通常填充了调试数据。
• 通常需要解析。
• 通常比指标慢，无论是摄取还是检索。
• 大多数时候您将需要原始日志来确定根本原因。
• 对数据的基数没有严格的要求。

您应该使用指标，因为与日志相比，可以快速地同化、索引和检索指标。使用指标和日志进行分析速度很快，因此您可以快速发出警报。相比之下，日志实际上是根本原因分析 (RCA) 所必需的。

要监控的 4 个信号

您可以监控很多内容，在某些时候您必须决定什么是重要的。

• 延迟： 最终用户在应用程序响应方面体验如何。
• 错误： 这可以是硬错误（例如 HTTP:500 内部服务器错误）或软错误，软错误可能指的是功能错误。它也可能意味着应用程序中特定组件的响应时间过慢。
• 流量： 指的是传入请求的总数。
• 饱和度： 通常发生在组件或资源无法再处理负载时。

监控资源

数据必须从某个地方派生。以下是构建监控系统时使用的常见资源

• CPU： 在某些情况下，CPU 使用率可能表明存在潜在问题。
• 内存： 应用程序和系统内存。应用程序内存可以是 Java 应用程序中的 Java 堆大小。
• 磁盘 I/O： 许多应用程序都严重依赖 I/O，因此监控磁盘性能非常重要。
• 磁盘卷： 监控所有文件系统的大小。
• 网络带宽： 监控应用程序使用的网络带宽至关重要。这可以深入了解如何消除性能瓶颈。

SRE 监控的 3 个最佳实践

最重要的是，请记住 SRE 组织中有效监控系统的三个最佳实践

1. 配置即代码： 使将监控部署到新环境变得容易。
2. 统一仪表板： 趋向于统一模式，从而可以重用仪表板。
3. 一致性： 无论您使用哪种监控工具，您在监控工具中创建的组件都应遵循一致的命名约定。

回滚变更

为了在变更未按预期进行时最大限度地减少用户影响，您应该争取时间来修复错误。通过细粒度的回滚，您能够仅回滚受影响的部分变更，从而最大限度地减少整体用户影响。

如果您的“金丝雀”发布期间情况不佳，您可能需要回滚您的变更。当与渐进式发布结合使用时，当您拥有可靠的回滚机制时，可以完全消除用户影响。

快速回滚并经常回滚。随着时间的推移，您的回滚过程将变得万无一失！

回滚的机制

自动化是关键。在您尝试回滚之前，您需要准备好脚本和流程。应用程序开发人员回滚变更的一种方法是简单地切换配置中的标志。可以基于简单地切换标志来打开和关闭应用程序中的新功能。

整个回滚可能是配置文件发布。一般来说，整个发布的回滚比部分回滚更受欢迎。使用带有版本号和标签的包管理系统，这些版本号和标签都已明确记录在案。

从技术上讲，回滚仍然是一种变更。您已经进行了变更，并且正在将其恢复。大多数情况都涉及以前未测试过的场景，因此您在回滚时必须谨慎。

前滚

通过前滚，您可以发布快速修复“热修复”，即包含修复程序的升级软件，而不是回滚您的变更。前滚并非总是可行。您可能必须在降级状态下运行系统，直到升级可用，以便“前滚完全完成”。在某些情况下，前滚可能比回滚更安全，尤其是在变更涉及多个子系统时。

变更是好事

自动化是关键。您的构建、测试和发布都应该自动化。

使用“金丝雀”来尽早发现问题，但请记住，“金丝雀”不能替代自动化测试。

监控的设计应满足您的服务级别目标。仔细选择您的监控工具。您可能必须部署多个监控系统。

最后，有效 CM 系统有三个原则

1. 渐进式发布： 努力以渐进方式进行变更。
2. 监控： SRE 团队的基础能力。
3. 安全快速的回滚： 通过流程和自动化来实现这一点，从而提高您 SRE 组织功能的信心。

在下一篇文章中，本系列的第三部分，我将介绍一些关于 SRE 最佳实践的重要技术主题。这些主题将包括断路器模式、自愈系统、分布式共识、有效负载均衡、自动伸缩和有效健康检查。