你想成为 SRE 吗？理解 SRE 角色与核心原则-CSDN博客

本文链接：https://blog.csdn.net/weixin_42587823/article/details/148056318

你想成为 SRE 吗？理解 SRE 角色与核心原则

你好呀！如果你正在阅读这篇文章，那么你很可能对网站可靠性工程（Site Reliability Engineering, SRE）感到好奇，或者刚刚踏上 SRE 的学习之路。你可能听过像“SLO”、“错误预算”、“Toil”这样的术语，并且想知道它们是如何组合在一起运作的。这个博客系列正是为你——有志于成为或刚刚起步的初级 SRE 工程师——量身定制的，旨在帮助你扎实地理解将要日常接触的基础概念。

SRE 到底是什么？

SRE 这个术语最初由 Google 提出，其创造者 Ben Treynor Sloss 有一句经典概括：“SRE 就是让软件工程师来设计运维团队时会发生的事情。”

从本质上讲，SRE 是一门工程学科，专注于创建和维护高度可靠、可扩展且高效的软件系统。它通过将软件工程的原则——例如自动化、数据分析、系统化的问题解决方式——应用于基础设施和运维任务来实现这一目标。

它不同于传统的运维模式，后者可能更侧重于手动流程和对故障的被动响应。SRE 追求主动性，利用代码和自动化来预防故障，并规模化地管理系统。同时，SRE 与 DevOps 共享许多目标，例如强调协作、共同承担责任、打破开发与运维之间的壁垒，但 SRE 尤其关注将可靠性作为其衡量成功的首要标准。

核心原则 1：服务等级目标 (SLO) 与服务等级指标 (SLI)

如果你连“可靠”对于你的服务意味着什么都没有定义，那么你就无法实现可靠性。这就是 SLI 和 SLO 发挥作用的地方。

服务等级指标 (Service Level Indicator, SLI)：这是一个量化的指标，用于衡量服务性能或可靠性的某个方面。它必须是可测量的，并且能反映用户体验。
- 简单示例：
  - 成功的 HTTP 请求百分比（可用性 SLI）。
  - 95% 的登录请求完成所需的时间（延迟 SLI）。
  - 在10分钟内完成的数据处理作业比例（数据新鲜度 SLI）。
服务等级目标 (Service Level Objective, SLO)：这是一个针对 SLI 的目标值或范围，通常在一个特定的时间段内衡量（例如一个月，或滚动的 28 天）。它是对服务期望达到的可靠性水平的一种约定。
- 简单示例：
  - 在 30 天内，99.9% 的 HTTP 请求应该成功。
  - 在滚动的 7 天窗口内，95% 的登录请求应在 500 毫秒内完成。
  - 每天 99% 的数据处理作业应在 10 分钟内完成。

打个比方： 把 SLI 想象成你汽车的速度计读数（比如当前时速 60 公里）。而SLO就像是路边的限速牌（比如这条路限速 65 公里）。

SLO 至关重要。它们定义了可靠性目标，指导着工程决策，并构成了下一个核心原则——错误预算的基础。

核心原则 2：错误预算 (Error Budget)

追求100%的可靠性往往成本过高且不切实际。系统偶尔就是会出故障。错误预算为我们管理这一现实提供了一个框架。

定义：错误预算简单来说就是 100% 减去 SLO。它代表了在一个 SLO 周期内，服务可接受的最大不可靠程度。
- 示例： 如果你的可用性 SLO 是 99.9%，那么你的错误预算就是 0.1%。对于一个 30 天的月份（约 43200 分钟），这意味着你“预算”了大约 43 分钟的停机时间或等量的错误。
目的：错误预算是一个数据驱动的机制，用于在服务可靠性和功能开发/创新速度之间取得平衡。
- 如果服务运行良好，远未用尽错误预算（错误少，可靠性高），开发团队就有信心更频繁地发布新功能。
- 如果服务消耗了错误预算（错误太多，发生故障），这就发出了警报。后续的新功能发布可能会放缓甚至冻结，工程资源必须转向提升可靠性（修复 Bug、改进测试、增加冗余等），直到服务重新稳定运行在 SLO 之内。

打个比方： 你的服务的错误预算就像是它每个月根据其承诺的“出勤率”（SLO）所允许的“病假天数”。如果它月初就把病假都请完了，那它就得先专注于“养好身体”（提升可靠性），然后才能去进行新的“冒险活动”（发布新功能）。

核心原则 3：减少琐事 (Toil) 与拥抱自动化

SRE 是工程师，而不是整天手动点点点的操作员。一个关键的关注点是消除琐事 (Toil)。

定义：Google SRE 将 Toil 定义为具备以下特征的工作：
- 手动操作 (Manual)：需要人手工完成。
- 重复性 (Repetitive)：一遍又一遍地做同样的事情。
- 可自动化 (Automatable)：机器可以代劳。
- 战术性而非战略性 (Tactical)：被动响应、救火式的，缺乏长期的、持久的价值。
- 随服务规模线性增长 (Scales Linearly)：至少和管理的系统规模增长一样快（比如服务器越多，手动打补丁的工作量越大）。
- 示例： 手动重启宕掉的服务，给一大批服务器手动打安全补丁，手动生成每周报告，处理那些无需判断的低优先级告警。
为何要减少 Toil？ Toil 成本高昂、容易出错、枯燥乏味，并且阻碍 SRE 从事高价值的工程工作。SRE 减少 Toil 的主要手段就是自动化 (Automation)。通过编写软件、脚本和工具来自动化重复性任务，SRE 可以：
- 提高效率和速度。
- 减少人为错误。
- 实现运维工作的次线性扩展（管理 1000 台服务器不应该是管理 10 台服务器的 100 倍工作量）。
- 腾出时间进行主动性的工程工作：改进系统设计、构建更好的监控、开发新的自动化工具。