[](https://res.cloudinary.com/practicaldev/image/fetch/s--BBpk52Gd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/uploads/articles/jie5qtei8pjafbfvpuxd.png)

什么是站点可靠性工程 (SRE)?

站点可靠性工程 (SRE) 概念起源于 Google。这个想法与 DevOps 的原则密切相关。这是一种 IT 运营方法。 SRE 团队使用该软件来管理系统、解决问题和自动化操作任务。

SRE 团队将 IT 运营团队通常手动完成的任务交给工程师或运营团队,他们使用工具和自动化来解决问题和管理生产系统。

在创建可扩展且高度可靠的软件系统时,这是一种有价值的实践。它帮助组织通过代码管理大规模基础设施,这对于管理数十万台机器的系统管理员来说更具可扩展性和可持续性。

为什么 SRE 很重要?是什么造就了一个好的 SRE 团队?

SRE 就像软件工程和 IT 运营之间的桥梁,填补了它们之间的空白。在为生产系统中的故障做准备时,SRE 几乎无处不在。它确保组织的系统是可扩展的、可靠的、可预测的和自动化的。

SRE 还设置了服务水平指标 (SLI)、服务水平目标 (SLO)、服务水平协议 (SLA),它定义了性能的真实数字、您的团队必须达到的目标才能满足该协议,以及系统需要的可靠性为最终用户。

SRE 的主要目标是提高性能和运营效率。

因此,SRE 不仅仅是“编码的运维人员”。相反,SRE 是开发团队的另一名成员,具有不同的技能,特别是在部署、配置管理、监控、指标等方面。就像为应用程序开发漂亮外观的工程师必须知道如何获取数据从数据存储中,SRE 不单独负责这些区域。整个团队共同努力,提供易于更新、管理和监控的产品。

当团队实施 DevOps 时,自然会产生对站点可靠性工程师的需求,但他们意识到他们对开发人员的要求太多,并且需要一名专家来处理运维团队过去处理的问题。

在深入研究 SRE 以及 SRE 如何与开发团队合作之前,我们需要了解站点可靠性工程如何在 DevOps 范式中发挥作用。

SRE 如何与 DevOps 协同工作?

从本质上讲,站点可靠性工程是 DevOps 范式的实现。正如持续集成和持续交付是将 DevOps 原则应用于软件发布一样,SRE 是将这些相同原则应用于软件可靠性。

定义 DevOps 的方法有很多种。尽管如此,传统模型仍然是开发(“devs”)和运营(“ops”)团队分开的地方,导致编写代码的团队不负责客户开始使用它时的工作方式。开发团队将“将代码扔到墙上”给运营团队进行安装和支持。

根据 Google 的方法,您可以使用 SRE 在组织中更好地采用 DevOps 原则并衡量您的实施是否成功。

为了更好地理解如何将两者结合起来,请考虑以下原则:

• 减少组织孤岛:SRE 通过在开发人员和运营团队之间共享所有权来提供帮助。这是 DevOps 哲学的主要原则之一。当 SRE 专注于改进问题检测和应用程序性能时,运营团队可以专注于管理基础设施,而开发人员可以专注于功能改进。

• 正常接受失败:与 DevOps 一样,SRE 不会将 IT 团队之间的故障和生产事件归咎于责任。无可指责的事后分析是一种 SRE 最佳实践,可确保将所有事件用作学习机会。当失败的可能性正常化时,团队可以承担更大的风险,从而可能导致更大的创新,而不必担心过多的挫折或停机时间。

• 实施渐进式变革:与 DevOps 一样,SRE 也鼓励通过变革进行持续改进。 SRE 要求更改小而频繁。因此,任何负面影响的影响都较小,并且可以轻松测试和实施低风险的增强功能。

• 利用工具和自动化:DevOps 鼓励自动化和技术采用,而 SRE 则专注于在 IT 团队中采用一致的技术和信息访问。这使得管理操作变得更容易,并减少了由技术不兼容造成的问题的可能性。这种标准化还有助于确保团队中的成员可以更好地协作,因为工具是统一的,并且不太可能需要某些成员缺乏的专业技能组合。

• 衡量一切:SRE 将指标与反馈循环相结合,以衡量运营并确定改进机会。它还根据需要为风险和手动操作建立松弛,使其通过测量更可预测。通过应用度量数据,团队可以设定适当的目标,同时保持对绩效的合理预期。

现在我们知道了 SRE 为何如此重要,让我们继续讨论在拥抱 SRE 文化时必须遵循的 SRE 最佳实践。

SRE 最佳实践

在实施 SRE 时,您可能需要一些时间来完善您的策略并定制实践以满足您的运营需求。为了帮助加快此过程,请考虑以下 SRE 原则和最佳实践。

1\。错误预算

简而言之,错误预算是在您的用户开始不满意之前,您的服务可以在一段时间内累积的错误量。您可以将其视为用户的痛苦容忍度,但适用于服务的特定维度:可用性、延迟等。

要计算误差预算,我们必须使用 SLI 方程:

SLI = [Good events / Valid events] x 100

进入全屏模式 退出全屏模式

现在,百分比表示为 SLI,一旦您为每个 SLI 定义了一个目标,即您的服务水平目标 (SLO),误差预算就是余数,最高为 100。

例如,假设您正在衡量主页的可用性。可用性是通过响应错误的请求数除以主页收到的所有有效请求数来衡量的,以百分比表示。如果您确定可用性的目标是 99.9%,则错误预算为 0.1%。您最多可以提供 0.1% 的错误(最好略低于 0.1%),用户会很高兴地继续使用该服务。

看看这张表,看看百分比如何转换为时间:

可靠性等级

每年

每季度

每 30 天

90%

36.5 天

9天

3天

95%

18.25 天

4.5天

1.5天

99%

3.65 天

21.6 小时

7.2 小时

99.5%

1.83 天

10.8 小时

3.6 小时

99.9%

8.76 小时

2.16 小时

43.2 分钟

99.95%

4.38 小时

1.08 小时

21.6 分钟

99.99%

52.6 分钟

12.96 分钟

4.32 分钟

99.999%

5.26 分钟

1.30 分钟

25.9 秒

乍一看,错误预算似乎并不那么重要。它们只是 IT 和 DevOps 需要跟踪以确保一切顺利运行的另一个指标,对吧?

幸运的是,答案是否定的。错误预算不仅仅是确保您履行合同承诺的便捷方式。如果团队用尽了特定季度的错误预算,新的更新通常会被冻结。它们也是开发团队创新和承担风险的机会。

2\。像用户一样定义 SLO

根据对最终用户而言重要的方面衡量可用性和性能。服务水平目标或 SLO 是所有站点可靠性工程的基础。没有它们,您就无法制定错误预算、确定开发工作的优先级或进行及时有效的事件管理。

SLO 应指定它们的测量方式以及它们的有效条件。在此处阅读有关服务水平目标的更多信息。

服务水平指标 (SLI):对所提供服务水平的某些方面(例如吞吐量、延迟)进行仔细定义的定量测量。它也是:

• 用户可直接测量和观察。

• 这可以代表用户的体验。

• 简而言之,这就是您要测量的具体内容。

服务水平目标 (SLO):由 SLI 衡量的服务水平的目标值或值范围。它也是:

• 从用户的角度定义服务应该如何执行(通过 SLI 测量)。简单来说,服务应该有多好?需要改进服务的阈值。

• 用户可以考虑打开支持票证的时间点。

• 受业务需求驱动,而不仅仅是当前性能。

服务水平协议 (SLA):SLA 是:

• 如果服务未达到预期,则向客户提供某种形式的补偿的商业合同。

• 简而言之,SLO + 后果。

3\。监控错误和可用性

为了识别性能错误并保持服务可用性,SRE 团队需要了解他们的系统中发生了什么。需要监控来验证应用程序/系统是否按预期运行。这意味着一项服务,满足特定目标,并了解进行更改时会发生什么。此外,我们想在客户之前知道。

4\。有效规划产能

组织需要计划诸如有机增长之类的事情,这可能是产品采用率的增加,无机增长,这来自于功能发布、营销活动等导致的需求突然增长。这将消耗更多资源(例如黑色星期五或网络中断周一)。要为这些事件做好准备,您需要预测需求并计划采购时间。

容量规划的重要方面包括定期负载测试和准确配置。定期负载测试可以让您了解您的系统在日常用户的平均压力下是如何运行的。此外,以任何形式增加容量都可能很昂贵,因此了解您需要额外资源的地方是关键。

5\。关注变革管理

在许多组织中,大多数中断都是由实时系统的更改引起的,无论是新的二进制推送还是新的配置推送。

每一个微小的变化都会影响业务。因此,分析每项变更所带来的风险。它应该受到监督。从大局考虑长期变化的影响,而不仅仅是它们如何影响今天的系统。

为确保在更改期间不会发生任何意外情况,必须由执行推出阶段的工程师进行监控,或者最好由一个可证明可靠的监控系统进行监控。如果检测到意外行为,请先回滚,然后再进行诊断,以最大限度地缩短平均恢复时间 (MTTR)。

6\。无可指责的验尸

真正无可指责的事后文化有助于在组织中建立更可靠的系统。事后分析应该无可指责,并专注于流程和技术,而不是人。

假设参与事件的人很聪明,出于善意,并且根据他们当时掌握的信息做出了他们可以做出的最佳选择。将事件固定在一个人或一群人身上会适得其反。它创造了一个人们害怕冒险、创新和解决问题的环境。

会发生故障。没有办法解决它。但是,通过良好的事件解决方案和追溯实践,失败可能是有益的。它揭示了提高弹性的重点领域。只要你从事件中吸取教训,你就取得了进步。

7\。劳力管理

SRE 的主要关注点之一是自动化。辛苦是浪费宝贵的工程时间,通过 SRE 创建框架、流程、内部工具/构建工具来消除它,工程师可以重新开始创新。

结论

这篇博文试图涵盖建立成功的 SRE 团队所需的基本概念和实践。如果您打算在您的项目/组织中采用 SRE 文化,请培训您的团队,遵循最佳实践并信任该过程。你不会达到 100% 的完美。这是一个神话。但是你会让事情变得更加精简,并尽可能接近完美。

希望这篇博文对您有所帮助。请在下面的评论中告诉我们您的想法。在Twitter和LinkedIn上开始对话

参考文献

• https://sre.google/sre-book/service-best-practices/

• https://opensource.com/article/18/10/sre-startup

• https://stackpulse.com/blog/site-reliability-engineering-sre-what-why-and-5-best-practices/

• https://www.usenix.org/blog/what-is-sre-how-does-it-relate-to-devops-lisa18

• https://www.bmc.com/blogs/sre-vs-devops/

• https://cloud.google.com/blog/products/management-tools/sre-error-budgets-and-maintenance-windows

• https://www.atlassian.com/incident-management/kpis/error-budget

• https://devopsinstitute.com/choosing-the-right-service-level-indicators/

• https://www.observability.splunk.com/en_us/infrastructure-monitoring/guide-to-sre-and-the-four-golden-signals-of-monitoring.html

• https://www.enov8.com/blog/site-reliability-engineering-sre-top-10-best-practice/

• https://www.blameless.com/blog/5-best-practices-nailing-postmortems