SRE 基础知识：在站点可靠性工程中可以期待什么

作者：来自 Elastic Elastic Observability Team

在过去的 20 年里，大多数领先企业已经采用云计算和分布式系统来开发它们的应用程序。一个意想不到的后果是：传统的 IT 运维（ IT operations - ITOps ）常常难以应对日益增长的工作负载和云技术的复杂性。

随着分布式系统的扩展，将运维和开发分开最终会导致停滞。开发人员可能希望发布新的应用程序或更新，而已经忙于维护现有基础设施的运维团队则可能会拒绝任何可能带来风险的变更。

站点可靠性工程（Site reliability engineering - SRE）是一门结合软件工程原则与运维实践的学科，旨在确保服务在大规模下的可靠性和最佳性能。担任这一角色的人称为站点可靠性工程师（site reliability engineers - SREs ），他们负责简化和自动化原本由运维团队手动执行的任务。减少在繁琐、重复工作上花费的时间，为创新和业务增长打开了大门。

站点可靠性工程已成为现代组织中不可或缺的一部分。其好处包括告别被动的故障处理，迎来可预测的性能、主动的系统设计、更强的可扩展性、更少的服务中断，以及更多的改进机会。

想进一步了解 SRE 的角色以及站点可靠性工程的世界吗？让我们从基础开始。

什么是站点可靠性工程？

站点可靠性工程（Site reliability engineering - SRE ）是一种将软件工程工具和原则融入 IT 运维的实践。SRE 负责创建并维护可靠、有弹性、高效且可扩展的基础设施和服务。他们提升可扩展系统的可靠性，构建具备先天弹性的系统，并利用软件和自动化手段管理不断扩展的基础设施，这种方式远比手动管理更可持续。

站点可靠性工程师是负责管理和自动化 IT 运维的人。他们利用软件工程的专长，确保系统保持弹性和可用性，并能自动修复问题。这个角色还负责新应用程序的交付和部署，防止潜在的中断和故障。

站点可靠性工程的历史

Google 工程副总裁 Benjamin Treynor Sloss 于 2003 年首次提出 "site reliability engineering - 站点可靠性工程" 这一术语，他说：" SRE 是当你让一个软件工程师去设计一个运维团队时发生的事情。" 而他正是这么做的。

他作为 Google 的新员工，负责为快速扩张的运维和庞大的分布式基础设施寻找工程解决方案。按当时 Google 基础设施的增长速度，手动管理新服务所需的工程师数量几乎不可能满足创新的节奏。因此，Treynor 的团队在系统可靠性和创新之间达成平衡，推动了持续学习和改进的文化。

不久后，Google 不断壮大的 SRE 团队开始专注于将新功能推向生产环境，同时保持系统的稳定性和可靠性。几年后，越来越多公司面临与 Google 相同的问题：他们需要在保持服务可用性和可靠性的同时，管理庞大的分布式基础设施。很快，站点可靠性工程的实践开始从 Google 扩展到更多企业，成为现代 IT 运维的关键。

SREs 在现代 IT 基础设施中的角色

在如今这个以数字优先的时代，各类企业都依赖高度可用、可扩展且具弹性的系统。一次宕机 ------ 无论是网站还是移动应用 ------ 都可能造成财务损失、客户体验受损以及运营效率下降。这就是为什么 SRE 是每家公司中不可或缺的角色。

SRE 能帮助你更轻松地跟上竞争对手的步伐。他们可以在几分钟内（而不是几天）解决可用性问题，并确保无论用户数量多少，页面加载速度始终很快。

在大型企业中，SRE 执行的任务规模更大。他们通过自动化提升系统可靠性、优化性能，并通过主动监控和事件管理防止系统故障。通过推动开发与运维团队之间的协作，SRE 构建了可靠而高效的系统。

站点可靠性工程的核心原则

站点可靠性工程的核心理念是用软件开发的方法来处理生产环境中的运维问题。其他核心原则包括拥抱风险、使用自动化，以及设定服务等级目标（service-level objectives - SLO ）和服务等级指标（service-level indicators - SLI ）。

拥抱风险

SRE 明白没有系统是完美的。故障和宕机是创新过程的一部分。SRE 的重点不是避免失败，而是理解什么程度的风险是可以接受的。

拥抱风险的本质是找到提高可靠性、部署新代码与影响用户体验之间的平衡点。为了提升服务可靠性所投入的时间、精力或其他资源，就是 "可接受的风险"。剩下的就是 "多余的风险"。但问题是：多少风险是可以接受的？用户体验在哪个阶段开始受到影响？

这个 SRE 核心原则基于以下四个因素：

用户可接受的可靠性水平（通过设定 SLO 和 SLI 来确定）
提高可靠性的成本（包括自动化和工具建设）
不改进带来的风险
成本与风险之间的权衡（通过错误预算来评估）

很多时候，拥抱风险的关键是文化视角。SRE 工作于非惩罚性的文化环境中，强调从失败中学习，并持续实施预防性措施，以提升系统可靠性和应用性能。

错误预算 - Error budgets

错误预算是理解和管理风险的明确指标。它定义了在特定时间段内，一个服务允许出现的宕机时间或错误次数。

系统允许的一定程度的不可靠性（即错误预算）有助于在创新与可靠性之间取得平衡。工程师被鼓励去冒一定风险，比如加快部署速度、发布新功能，因为他们有 "错误的额度"。一旦达到这个阈值，工程师就会暂停变更，专注于系统稳定性和可靠性的提升。

SRE 团队通过基于 SLO 来确定可接受的错误水平（或宕机时间），从而计算错误预算。换句话说，错误预算就是 SLO 所允许的误差空间。

建立服务等级目标（SLO）和服务等级指标（SLI）

服务等级目标（Service-level objectives - SLO）是在一定时间内对性能设定的目标值。这些目标需要工程团队和业务相关方共同理解，从而设定清晰的预期，指导决策过程。

服务等级指标（Service-level indicators - SLI）用于衡量服务性能。通常，SLI 代表用户关注的优先事项，例如服务延迟、可用性、吞吐量、错误率等。

SLO 和 SLI 都不是静态的。它们会随着时间推移不断发展，需要定期评审和优化。

开发自动化和工具

最后是自动化。SRE 力求将手动和重复性的任务通过自动化方式替代。减少繁重操作（toil）意味着提高系统可靠性，同时更快、更高效地推动创新。

一些 SRE 团队会花费多达一半的时间开发用于部署、故障响应和测试的自动化工具。随着时间的推移，高级的自动化能力可以在保证服务可靠性和最佳性能的前提下，降低系统扩展的成本。

现在观看

网站可靠性工程的关键实践

在运行服务时，SRE 团队会专注于日常的关键活动，例如监控与可观测性、事件管理、容量规划和变更管理。

监控与可观测性

系统监控与可观测性对 SRE 至关重要。它们能真正让团队看清服务是否正常运行、运行得如何、问题出在哪里等。

监控帮助网站可靠性工程师快速发现并处理问题。可观测性则提供了实时和历史的系统性能洞察，用于应对未知的问题。追踪（traces）、日志（logs）和指标（metrics）是可观测性的主要信号来源。

网站可靠性工程的四大黄金信号

网站可靠性工程的四大黄金信号（ four golden signals）是：延迟、流量、错误和饱和度。这些指标是应用可靠性的基础，也就是分布式系统中服务的健康状况与性能。

延迟（latency） 是系统响应请求所需的时间（无论是成功还是失败）。高延迟表示存在性能问题，需要 SRE 立即处理。
流量（traffic） 衡量系统的使用需求。根据不同系统，可能是每秒交易数、每秒 HTTP 请求数等。SRE 借助流量判断用户体验是否在下降。
错误（errors） 是失败请求的比例。错误可能是显式的（如 HTTP 500）、隐式的（如 HTTP 200 但内容有误），或是策略性失败（如请求超过 1 秒自动失败）。根据系统的不同，SRE 会优先处理某类错误，并解决重复出现的问题。
饱和度 （saturation）表示系统的整体容量或服务的 "满载" 程度。它可以通过多种方式测量，取决于最容易受限的资源，或者系统还能承载的负载。

四大黄金信号帮助 SRE 专注于容量规划、逐步提升系统可靠性、响应与管理故障事件，以及寻找问题根因（ root cause of a problem）。

不过，光靠四大黄金信号还不足以让复杂的分布式系统变得完全可靠。这时，分布式追踪（ distributed tracing**）**就派上用场了，它可以将所有性能数据放在上下文中理解。

事件管理

如前所述，在 SRE 实践中，故障和宕机是无法完全避免的。但每一次事件都需要响应。一个有效的事件响应计划应包含分诊流程、清晰的沟通协议和升级路径。

也许同样重要的是 事后分析。这是一种建设性实践，不是为了追责，而是作为一次学习机会。SRE 应记录每次事件，找出根本原因，并与开发团队合作修复代码，或（如果可能）构建工具以防止问题再次发生。

深入了解事件管理。

容量规划

容量规划确保了服务在当前和未来的可靠性，既能防止资源过度配置，也能避免资源不足。

SRE 团队通过分析历史使用模式并预测未来资源需求来预测系统负载。他们寻找低效之处，基于实时信息优化并重新分配资源，并根据不断变化的数据定期更新这些规划。

借助容量规划，网站可靠性工程师确保系统能够应对增长和需求高峰。

变更管理

变更通常会导致宕机，传统 ITOps 也深有体会。然而，SRE 并不害怕宕机，也不害怕变更，而是通过三项最佳实践来积极应对变更：

渐进式、可控的发布：最小化潜在问题的影响，并实现早期检测。
监控：确保 SRE 能在第一时间准确发现问题。
回滚计划：在出现问题时能安全快速地撤回变更。

这三项实践，如果可以的话，都应该实现自动化。

适用于 SRE 的全栈可观测性解决方案：Elasticsearch

Elastic Observability 提供一个统一的解决方案，用于收集、监控和分析来自你技术栈中的可观测性指标。通过 Elastic Observability，你可以从任意来源收集、存储并可视化可观测性指标，并借助 Elastic 的 Search AI Platform 加速问题的解决。

将对话式搜索与代理型 AI 结合进 Elastic Observability，可以提供具有上下文感知能力的聊天体验，扩展到你的专有数据和操作手册。Elastic AI Assistant 能帮助 SRE 解读日志消息和错误、优化代码、撰写报告，甚至识别并执行操作手册。加快问题解决速度，促进协作，释放知识潜力，赋能所有用户，确保系统可靠性。

了解更多关于 Elastic 可观测性的信息。