运维想转 SRE？先了解这 7 个原则

站点可靠性工程，或 SRE，是一种将运维问题视为软件问题的方法。这一概念最初由 Google 工程师 Ben Treynor Sloss 在 2003 年提出并描述。作为一门学科，站点可靠性工程（SRE）旨在维持特定系统的可用性、性能和效率。

SRE 难以界定。它是一种方法或学科，而不是一套具体的指令性任务，其形式会根据特定组织的需求而有所不同。幸运的是，有七项 SRE 原则可以帮助指导 SRE 团队取得成功。

前言

软件开发的大部分工作理所当然地集中在创建上，包括 DevOps，这是一个相关但不同的领域，更关注产品的整个生命周期。但系统上线并不意味着工作就完成了。在 Google SRE 指南的前言中，作者指出，“系统总成本的 40%到 90%是在上线后产生的。”SRE 关注上线后的情况，旨在帮助确保产品尽可能保持可用。

SRE 最重要的元素是系统可靠性和运行时间。世界上最好的服务如果无法运行，对任何人也没有多大用处。因此，SRE 专注于最小化停机时间并创建可靠的系统。当然，SRE 也关注软件的发布变更、合规性和安全性、以及容量和资源效率。

SRE 的 7 项原则

SRE 的七项原则包括：

• Embracing risk 拥抱风险

• Service level objectives 服务水平目标 SLOs

• Eliminating toil 消除琐事

• Monitoring 监控

• Automation 自动化

• Release engineering 发布工程

• Simplicity 简洁性

SLO、Monitoring、Automation、Release engineering 都需要监控、可观测性体系工具的支撑，如果您想构建 一站式智能观测平台，欢迎联系我们免费交流产品技术：https://flashcat.cloud/contact/

1. 拥抱风险

虽然 SRE 非常关注管理和限制停机时间，但这并不意味着目标是让服务保持完美的 100%可用性。实际上，SRE 的一个关键原则是，100%的可靠性不仅不现实，甚至可能不是最优的结果。

在站点可靠性工程（SRE）中，风险被理解为一个连续体，随着可靠性接近 100%，降低风险的难度和成本呈指数级增长。从 99.99%的可靠性提升到 99.999%的可靠性，要比从 80%提升到 99%困难得多。为了无限接近 100%可靠性所需的资源，会削弱开发团队执行其他任务的能力，比如创新新功能和进行更新。相反，团队会有错误预算来表示可接受的故障量。

然而，尽管这一点似乎与直觉相反，完全的可靠性对客户来说通常也并不重要。超过某个阈值后，可靠性改进往往不会被客户注意到。这不仅代价高昂，而且几乎没有回报。理想情况下，设定一个目标并达到它，但不要过度追求。

相反，SRE 使用可用性指标来衡量停机时间风险的可接受性。在一个指标中，99.99% 的可靠年份将包括 52.6 分钟的停机时间。更复杂的指标会考虑某个位置或服务的一个元素发生停机的可能性，而其他部分仍然正常运行。

SRE 团队必须评估每个服务，并确定可接受的不可靠程度。允许多少停机时间？不同类型的故障，其根本原因不同，对用户体验会产生怎样的影响？超出这个限度会带来多大的成本（无论是人力还是财务方面）？平衡点在哪里？

2. 服务水平目标 SLOs

确定目标并衡量这些目标的实现程度及其原因对于 SRE 团队至关重要。服务水平目标（SLO）是一种具体且可衡量的目标，代表了 SRE 团队设定的质量标准。这些 SLO 可以以各种指标的形式出现，但可用性、查询速率、错误率和响应时间都是常见的指标。

这些目标通过使用服务级别指标（SLI）来衡量，SLI 是对性能的原始测量，例如延迟。在这种情况下，SLI 就是延迟指标，而 SLO 则是该指标保持在某个阈值以下。SLO 可以成为服务级别协议（SLA）的一部分，SLA 是服务提供商与用户之间的合同，其中列出了 SLO 以及未能达到这些指标的后果。

选择服务级别目标（SLO）可能会有些棘手。理想情况下，SLO 应该围绕用户最关心的内容来构建。例如，对于云游戏服务，SLO 可能会围绕低延迟来构建，但对于会计服务来说，延迟的重要性就没那么高了。

理想情况下，SRE 应该使用较少的 SLO 来专注于实现这些目标；最重要的是把主要任务做好。设定现实的目标也很重要；正如我们之前讨论的，完美既不现实也不被期望。

3. 消除琐事

SRE 的创造者们明确将“琐事”定义为一种劳动类别，这种劳动与工作有交集，但并不完全相同。琐事指的是那些按线性扩展的手动工作任务，通常是手动且重复的，往往可以通过自动化来完成。

重复性工作被称为苦力工作；理想情况下，一项任务只需进行一两次复审即可。如果一项工作没有使产品得到改进，那么这项工作也是苦力工作。“如果你完成一项任务后服务状态没有改变，那么这项任务很可能就是苦力工作，”Google 的 Vivek Rau 写道。修复错误、功能改进和优化都不是苦力工作，但手动下载指标就是苦力工作。包括工程师和运维团队之间大量协调的故障响应不是苦力工作，而且故障管理策略应在发布前就做好规划。

还有认知负担。你是否曾经使用过一个偶尔会用的基本食谱，但每次都要查原料和用量？这就是认知负担：反复重新学习某事会浪费时间和精力。相反，SRE 倡导创建更多的指南和标准，从而消除不断记忆或重新学习方法和任务的需要。

4. 监控

站点可靠性工程中最重要的一部分是监控：使用工具持续测量、分析和改进核心功能和系统性能。这些核心功能通常包括监控中所谓的“四个黄金信号（或称为指标）”：

• 延迟：最基础的来说，满足一个请求需要多长时间？请注意，这可能会根据请求是否成功而有所不同；有时错误消息的服务时间可能会显著更长。

• 流量：服务承受了多少负载或需求？具体的单位会有所不同；可能是页面浏览量，可能是交易量，也可能是 HTTP 请求。

• 错误：通常通过错误率来衡量，错误可能包括获取错误的数据、获取数据的速度比 SLA 中规定的要慢，或者根本无法获取数据。

• 饱和度：本质上，饱和度是衡量服务接近其容量的程度。理解饱和度很重要，因为当服务接近 100%饱和度时，一些服务可能会开始失效、变慢或产生更多的错误。

有许多监控工具可以收集数据、设定基准、调试和分析问题、提供有用的可观测性仪表盘，并在可能发生故障或其他问题时提醒 SRE。在事件解决后，提供 robust 的事后报告也很重要，报告应解释事件的背景、根本原因和触发因素、影响、解决方法以及未来吸取的教训。详细的、客观的事后报告对于避免再次犯同样的错误非常有价值。

5. 自动化

就像现代技术中的许多其他元素一样，将自动化引入工作流程的目的是为了使工程师免于处理那些不增加价值的重复性任务。有了新拓展的自由时间，工程师们就可以专注于自动化无法完成的任务：创作、创意、大规模指导以及其他更多工作。

自动化特别适用于以下目标：

• 一致性：重复的手动任务不仅会让人感到无聊并占用更有价值的时间。如果像用户账户创建这样的任务通过自动化工具完成，错误和不一致性可以几乎被消除。新员工可能会以不同于老员工的方式做事；用户可能会不小心在错误的字段中输入值。而自动化流程（通常情况下）不会出现这种情况。

• 可扩展性：自动化是可扩展性的一个主要长期优势。以我们之前的用户账户创建为例，如果账户创建量呈指数增长，那么负责账户设置的员工的工作量也会呈指数增长，从而将这名员工从其他可能更有价值的工作中抽离出来。而自动化系统则不会出现这个问题。

• 速度：某些任务，例如查找和修复代码中的错误，可能需要人工花费大量时间。自动化软件系统能够监控大量数据，并且往往能够通过高级模式识别和其他工具比人类更快地检测到错误。修复工作也可以同样快速地完成，通常不需要任何人工干预。

当然，任何自动化过程也伴随着风险。这些风险包括：

• 前期成本：自动化必须在部署前创建。这可能需要大量时间、努力甚至硬件成本。必须将自动化的价值视为创建它所付出的努力与上线后实际节省的资源之间的平衡。

• 维护：自动化任务似乎可以无限期运行，但实际上并非如此。自动化代码必须保持最新，并与其它代码和系统更新保持同步。如果新增了功能，自动化代码可能需要通过人工干预进行更新，以包含新的操作或防止错误。

• 人工智能为 SRE 带来了新的和令人兴奋的可能性，最明显的是在自动化领域。理论上，通过新的 AI 模型可以调节前期成本和维护成本。不过，AI 也带来了新的潜在问题：幻觉、安全和隐私问题，尤为突出。

6. 发布工程

发布工程是软件工程的一个子领域，专门专注于发布软件所需的步骤。这些步骤包括版本控制、发布计划、持续构建或定期构建、选择和收集发布指标等。在 SRE 中，发布工程从一开始就嵌入其中，而不是事后考虑；目标是避免在最后一刻仓促分配发布工程任务。

作为一门学科，发布工程包括几个关键原则。这些原则包括：

• 自动化和自助服务：理想情况下，许多发布流程可以实现自动化，并且需要最少或无需工程师的交互。这确保了快速且稳定的发布。

• 速度：在发布工程中，更倾向于快速、频繁的发布。通过快速推出发布版本，甚至在发布前后每小时推出一次，版本之间的变化较少。这种速度使得测试和故障排除更加容易。

• 封闭构建：构建过程应完全独立于构建机器本身，使用最流行的编译器、库和工具。“如果两个人在同一版本号的源代码仓库中分别在不同的机器上尝试构建相同的产品，我们期望得到相同的结果，”Google 的 Dinah McNutt 写道。

• 标准和政策：出于安全原因，必须对某些任务进行检查，包括部署、源代码变更、新版本发布以及构建配置变更。

7. 简洁性

软件工程的许多方面都致力于简洁。正如 Google 的 Max Luebbe 所写，“软件本质上是动态和不稳定的。”鉴于此，简洁是减少潜在问题并试图控制这种固有不稳定性的重要手段。

为此，软件可靠性工程推广各种任务，以简化和澄清项目。

1. 精心选择要包含的功能是有帮助的，但直接删除那些对产品实用性贡献不大的功能也同样有益。更多的功能意味着更多的复杂性。

2. 更小、更频繁的发布可以更容易地进行调试和故障排除。一个包含数十个新功能的新发布可能会引入难以追踪的错误。一个包含一个新功能的新发布呢？任何潜在的问题都只能来自一个地方。

3. 同样，通过使用多个端点、微服务等方式增加 API 的复杂性可能会很有诱惑力。但这应该避免。更简单的 API 设置更快，需要的文档更少，并能减少集成时间和成本。

原文地址：https://www.ibm.com/think/insights/sre-principlesSRETALK 关注 SRE、开源、可观测性相关领域的话题，分享业内最佳实践，欢迎大家投稿