2021年12月

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

SRE 团队承担 IT 运营团队已完成的任务(通常是手动的),而是将其交给使用工具和自动化来解决问题和管理生产系统的工程师或运维团队。

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

为什么我们需要 SRE?重要吗?是什么造就了一支优秀的 SRE 团队?
SRE就像软件工程和IT运营之间的桥梁,填补了它们之间的空白。几乎在任何地方,SRE在为生产系统中的故障做准备时都发挥作用。它确保组织的系统具有可扩展性、可靠性、可预测性和自动化性。

SRE 还设置服务级别指标 (SLI)、服务级别目标 (SLO)、服务级别协议 (SLA),该协议定义了性能的实际数字、团队为满足该协议而必须达到的目标,以及系统对最终用户的可靠性。

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

因此,SRE不仅仅是"编码的运维人员"。相反,SRE 是开发团队中具有一组不同技能的另一个成员,尤其是在部署、配置管理、监视、指标等方面。正如为应用程序开发良好外观的工程师必须知道如何从数据存储中获取数据一样,SRE 不仅负责这些方面。整个团队共同努力,交付可以轻松更新、管理和监控的产品。当一个团队实施DevOps时,对站点可靠性工程师的需求自然而然地出现,但意识到他们对开发人员的要求太多,并且需要一个专家来处理运维团队过去处理的事情。

在深入探讨 SRE 以及 SRE 如何与开发团队合作之前,我们需要了解站点可靠性工程在 DevOps 范例中的运作方式。

SRE 与 DevOps 以及 SRE 如何与 DevOps 配合使用?
站点可靠性工程的核心是 DevOps 范式的实现。正如持续集成和持续交付 (CI/CD) 是 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需要跟踪的另一个指标,以确保一切顺利运行,对吧?幸运的是,答案是否定的。错误预算不仅仅是确保您履行合同承诺的便捷方式。如果团队用尽了特定季度的误差预算,则通常会冻结新的更新。它们也是开发团队创新和承担风险的机会。

  1. 像用户一样定义 SLO
    从对最终用户至关重要的角度衡量可用性和性能。服务级别目标或 SLO 是所有站点可靠性工程的基本基础。没有它们,您就无法制定错误预算,确定开发工作的优先级或进行及时有效的事件管理。SLO 应指定如何衡量它们以及它们在哪些条件下有效。阅读有关服务级别目标的更多信息。

服务级别指示器 (SLI):对所提供服务级别的某些方面(如吞吐量、延迟)的仔细定义的定量度量。它还:

用户直接可测量和观察。
这可以表示用户的体验。
简而言之,这谈到了您要测量的确切内容。
服务级别目标 (SLO):由 SLI 测量的服务级别的目标值或值范围。它还:

从用户的角度定义服务应如何执行(通过 SLI 测量)。简单来说,服务应该有多好?需要改进服务的阈值。
用户可以考虑打开支持票证的时间点。
由业务需求驱动,而不仅仅是当前性能。
服务级别协议 (SLA):SLA包括:

如果服务不符合预期,则为客户提供某种形式的补偿的商业合同。
简单来说,SLO +后果。

  1. 监控错误和可用性
    为了识别性能错误并保持服务可用性,SRE 团队需要了解其系统中发生的情况。需要监视以验证应用程序/系统的行为是否符合预期。这意味着服务,满足特定目标,并了解进行更改时会发生什么。此外,我们希望在客户之前知道。
  2. 高效规划容量
    组织需要为有机增长等事情做计划,这可能是增加产品采用率,无机增长,这来自功能发布,营销活动等原因导致的需求突然跃升。这将消耗更多资源(如黑色星期五或网络星期一的中断)。要为这些事件做准备,您需要预测需求并计划获取时间。

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

  1. 关注变革管理
    在许多组织中,大多数中断都是由对实时系统的更改引起的,无论是新的二进制推送还是新的配置推送。每一个小小的变化都会影响业务。因此,请分析每个更改所带来的风险。它应该受到监督。通过纵观全局来考虑长期变化的影响,而不仅仅是它们如何影响当今的系统。

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

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

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

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

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

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

希望这篇博文对您有所帮助。请让我知道你的想法。在Twitter上开始对话并LinkedIn。有关InfraCloud的定期云原生更新,请在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