SRE 原则指南

站点可靠性工程 (SRE) 是一门构建自动化软件系统来管理产品或服务的开发运营 (DevOps) 的学科。换句话说，SRE 通过软件系统自动化运营团队的功能。

SRE 的主要目的是鼓励大规模系统的部署和正确维护。特别是，站点可靠性工程师负责确保给定系统的行为始终满足性能和可用性的业务要求。

此外，虽然传统的运营团队和开发团队往往有相反的激励措施，但站点可靠性工程师能够调整激励措施，从而同时促进功能开发和可靠性。

本文介绍了 SRE 的关键原则，提供了这些关键原则的一些示例，并包括相关细节和插图来阐明这些示例。

• 假设 10 个不同的用户向您的网站提供相同的 HTTP 请求，并且它们都得到了正确的处理。
• 返回时间的监控和记录如下：1 ms、3 ms、3 ms、4 ms、1 ms、1 ms、1 ms、5 ms、3 ms 和 2 ms。
• 平均响应时间或延迟为 24 毫秒 10 个返回 = 2.4 毫秒。

假设开发团队计划在本季度发布 10 个新功能，并且发生以下情况：

• 第一个功能不会导致任何停机。
• 第二个功能会导致 10 个小时的停机时间直至修复。
• 第三和第四个功能均会导致 6 小时的停机时间直至修复。
• 此时，已经超出了该季度的错误预算（10 + 6 + 6 = 22 > 21.9），因此第五个功能无法发布。

通过这种方式，错误预算确保了可接受的功能发布速度，同时不会影响可靠性或降低用户体验。

设定绩效预期的最佳方法是针对不同的系统风险设定具体的目标。这些目标称为服务级别目标或 SLO。下表列出了基于不同风险衡量的 SLO 示例。

建立 SLO 的主要目的之一是跟踪可靠性如何影响收入。重新审视上一节中的示例错误预算，假设该季度的预计服务收入为 500,000 美元。这可用于将 SLO 和错误预算转换为实际金额。因此，SLO 也是衡量与系统性能间接相关的目标的一种方法。

使用 SLO 跟踪间接指标（例如收入）可以评估改进服务的成本。在这种情况下，花费 10,000 美元将 SLO 从 95% 提高到 99% 是一个值得的商业决策。另一方面，花费 10,000 美元将 SLO 从 99% 提高到 99.9% 则不然。

SRE 与传统 DevOps 的区别之一是能够在不降低服务成本的情况下扩大服务范围。这称为次线性增长，这是通过自动化实现的。

在传统的开发-运营分离中，开发团队推出新功能，而运营团队将 100% 的时间用于维护。因此，一个纯粹的运营团队需要按照其所维护的服务的规模和范围以 1:1 的比例增长：如果需要 O(10) 系统工程师来服务 1000 个用户，那么需要 O(100) 工程师来服务 10K用户。

相比之下，根据最佳实践运营的 SRE 团队将投入至少 50% 的时间来开发系统，以消除运营工作负载中的基本工作要素。以下是一些例子：

• 一项服务，用于检测大型机群中的哪些机器需要软件更新，并定期按批次安排软件重新启动。
• “push-on-green”模块提供自动工作流程，用于测试新代码并将其发布到相关服务。
• 一个警报系统，可自动生成票证并通知事件响应团队。

为了保持可靠性，必须监控服务的相关分析并使用监控来检测 SLO 违规情况。如前所述，一些重要指标包括：

• 服务启动并运行的时间量（时间可用性）
• 成功完成的请求数（聚合可用性）
• 处理请求所需的时间（延迟）
• 提供预期结果的响应比例（正确性）
• 系统当前正在处理的请求量（吞吐量）
• 消耗的可用资源的百分比（饱和度）

有时也会测量耐久性，即数据准确存储的时间长度。

实施监控的一个好方法是通过仪表板。有效的仪表板将显示 SLO，包括错误预算，并显示与 SLO 相关的不同风险指标。

实现监控的另一个好方法是通过日志。既可以及时搜索又可以根据请求分类的日志是最有效的。如果通过仪表板检测到 SLO 违规，则可以通过查看受影响时间范围内生成的日志来创建更详细的情况。

上面讨论的跟踪服务内部分析的监控类型称为白盒监控。有时，从“外部”监控系统的行为也很重要，这意味着从外部用户的角度测试服务的工作流程；这称为黑盒监控。黑盒监控可能会揭示访问权限或冗余的问题。

SRE 减少工作量的最佳方法之一是在监控警报和票务期间使用自动化。SRE 流程比传统运营流程高效得多。

传统的操作响应可能如下所示：

1. 网络开发人员推出了向用户投放广告的算法的新更新。
2. 开发人员注意到，由于未知原因，最新的推送正在减少网站流量，因此向网络运营团队手动提交了有关流量减少的票证。
3. Web 运营团队的系统工程师收到了有关流量减少问题的通知单。排除故障后，问题被诊断为缓存卡住导致的延迟问题。
4. Web 运营工程师联系数据库团队的成员寻求帮助。数据库团队研究代码库并确定缓存设置的修复程序，以便更快地刷新数据并减少延迟。
5. 数据库团队更新缓存刷新设置，将修复推送到生产环境，并关闭票证。

相反，SRE 操作响应可能如下所示：

1. 广告 SRE 团队创建了一个部署工具，用于监控三种不同的流量 SLO：可用性、延迟和吞吐量。
2. 一位 Web 开发人员准备向服务广告的算法推送新的更新，为此他使用了 SRE 部署工具。
3. 几分钟之内，部署工具就检测到网站流量减少。它可以识别延迟 SLO 违规并创建警报。
4. 值班站点可靠性工程师收到警报，其中包含更新缓存刷新设置的建议，以加快处理请求的速度。
5. 站点可靠性工程师接受建议的更改，将新设置推送到生产中，并关闭票证。

通过使用自动化系统来警告和建议对数据库进行更改，所需的通信、涉及的人员数量以及解决问题的时间都减少了。

以下代码块是延迟和吞吐量阈值以及检测到违规时触发的自动警报的通用语言实现。

# Define the latency SLO threshold in seconds and create a histogram to track
LATENCY_SLO_THRESHOLD = 0.1
REQUEST_LATENCY = Histogram('http_request_latency_seconds', 'Request latency in seconds', ['method', 'endpoint'])


# Define the throughput SLO threshold in requests per second and a counter to track
THROUGHPUT_SLO_THRESHOLD = 10000
REQUEST_COUNT = Counter('http_request_count', 'Request count', ['method', 'endpoint', 'http_status'])


# Check if the latency SLO is violated and send an alert if it is
def check_latency_slo():
    latency = REQUEST_LATENCY.observe(0.1).observe(0.2).observe(0.3).observe(0.4).observe(0.5).observe(0.6).observe(0.7).observe(0.8).observe(0.9).observe(1.0)
    quantiles = latency.quantiles(0.99)
    latency_99th_percentile = quantiles[0]
    if latency_99th_percentile > LATENCY_SLO_THRESHOLD:
        printf("Latency SLO violated! 99th percentile response time is {latency_99th_percentile} seconds.")


# Check if the throughput SLO is violated and send an alert if it is
def check_throughput_slo():
    request_count = REQUEST_COUNT.count()
    current_throughput = request_count  time.time()
    if current_throughput > THROUGHPUT_SLO_THRESHOLD:
        printf("Throughput SLO violated! Current throughput is {current_throughput} requests per second.")

确保系统保持可靠性的最佳方法是保持系统简单。SRE 团队应该对添加新代码犹豫不决，而宁愿在可能的情况下修改和删除代码。添加到生产软件中的每一个附加 API、库和功能都会以难以跟踪的方式增加依赖性，从而引入新的故障点。

站点可靠性工程师应该致力于保持代码模块化。也就是说，API 中的每个函数都应该只服务于一个目的，就像更大堆栈中的每个 API 一样。这种类型的组织使依赖关系更加透明，也使诊断错误变得更加容易。

作为事件管理的一部分，应公开编写和发布典型待命调查和解决方案的手册。针对特定场景的剧本应描述事件（以及可能的变化），列出相关的 SLO，引用适当的监控工具和代码库，提供建议的解决方案，并对以前的方法进行分类。

正如 SRE 代码库应该强调简单性一样，SRE 发布过程也应该强调简单性。通过以下几个原则鼓励简单性：

• 更小的尺寸和更高的速度：不是大规模、不频繁的发布，而是以更高的频率发布较小的版本。这使得团队能够逐步观察系统行为的变化，并减少发生大型系统故障的可能性。
• 自助服务：SRE 团队应该完全拥有其发布流程，并且该流程应该有效自动化。这既消除了工作量，又鼓励小规模、高速的推动。
• 密封构建：构建新版本的过程应该是密封的或独立的。也就是说，构建过程必须锁定到现有工具（例如编译器）的已知版本，并且不依赖于外部工具。

所有代码版本都应在版本控制系统内提交，以便在出现错误、冗余或无效代码时轻松恢复。

提交版本的过程应该伴随着清晰可见的代码审查过程。基本更改可能不需要批准，而更复杂或有影响力的更改将需要其他站点可靠性工程师或技术主管的批准。

SRE 的主要原则是接受风险、设置 SLO、通过自动化消除工作、监控系统、保持简单以及概述发布工程流程。

拥抱风险涉及明确定义失败并设定错误预算。做到这一点的最佳方法是创建和实施 SLO，它直接跟踪系统性能，还有助于确定系统改进的潜在成本。适当的 SLO 取决于风险的衡量方式和客户的需求。实施 SLO 需要进行监控，通常通过仪表板和日志进行监控。

除了开发运营之外，站点可靠性工程师还专注于项目工作，这使得服务能够扩大范围和规模，同时保持低成本。这称为次线性增长，是通过自动化重复任务来实现的。自动发出警报的监控创建了简化的操作流程，从而提高了可靠性。

站点可靠性工程师应通过减少编写的代码量、鼓励模块化开发以及发布具有标准操作程序的手册来保持系统简单。SRE 发布流程应该是密封的，并使用版本控制和代码审查来推动小的、频繁的更改。