什么是站点可靠性工程(SRE)?
站点可靠性工程(SRE)的概念起源于谷歌。这个想法与DevOps的原则密切相关。它是It运营的一种方法。SRE团队使用软件来管理系统、解决问题和自动化操作任务。
SRE团队将IT团队完成的任务(通常是手工完成的)交给工程师或运维团队，后者使用工具和自动化来解决问题和管理生产系统。
在创建可伸缩和高度可靠的软件系统时，这是一种有价值的实践。它通过代码帮助组织管理大量的基础设施，对于管理数十万台机器的系统管理员来说，代码具有更强的可伸缩性和可持续性。
为什么SRE很重要?好的SRE团队需要具备哪些条件?
SRE就像是软件工程和IT操作之间的桥梁，填补了它们之间的空白。在几乎所有地方，SRE都在为生产系统中的故障做准备时发挥作用。它确保组织的系统是可伸缩的、可靠的、可预测的和自动化的。
SRE还设置了服务水平指标(SLIs)、服务水平目标(slo)、服务水平协议(SLA)， SLA定义了性能的真实数字、团队必须达到的目标以满足该协议，以及系统对最终用户需要有多可靠。
SRE的主要目标是提高性能和运行效率。
所以，SRE不仅仅是负责编码的行动人员。另外，SRE是开发团队中拥有不同技能集的成员，特别是在部署、配置管理、监视、度量等方面。正如为应用程序开发漂亮外观的工程师必须知道如何从数据存储中获取数据一样，SRE并不仅仅负责这些领域。整个团队一起工作以交付易于更新、管理和监视的产品。当团队在实现DevOps时，对站点可靠性工程师的需求自然会出现，但他们意识到他们对开发人员要求太多，需要一个专家来处理ops团队过去处理的事情。
在我们深入挖掘SRE以及SREs如何与开发团队合作之前，我们需要了解站点可靠性工程在DevOps范式中是如何发挥作用的。
SRE如何与DevOps一起工作?
站点可靠性工程的核心是DevOps范例的实现。正如持续集成和持续交付是DevOps在软件发布中的应用一样，SRE也是这些原则在软件可靠性上的应用。
定义DevOps的方法有很多种。然而，在传统的模型中，开发(devs)和运维(ops)团队是分开的，导致编写代码的团队在客户开始使用代码时不负责代码的工作方式。开发团队将把代码扔到给运维团队安装和支持。
根据谷歌的方法，您可以使用SRE更好地在组织中采用DevOps原则，并衡量您的实现的程度。
为了更好地理解如何将两者结合起来，可以考虑以下原则:
-
减少组织之间的代沟:SRE通过在开发人员和运维团队之间共享所有信息来降低摩擦。这是DevOps哲学的主要原则之一。当SREs专注于改进问题检测和应用程序性能时，运维团队可以专注于管理基础设施，而开发人员可以专注于功能特性改进。
-
接受失败:像DevOps一样，SREs不会在IT团队之间推卸失败和生产事件的责任。不责备事后分析是SRE的最佳实践，可以确保所有事件都被用作学习机会。当失败的可能性被规范化时，团队可以承担更大的风险，潜在地产生更大的创新，而不必担心过度的挫折或停机。
-
实施渐进式变更:与DevOps一样，SRE也鼓励通过变更进行持续改进。SRE要求更小且频繁的变更。因此，任何负面影响的影响都较小，低风险的增强可以很容易地测试和实现。
-
利用工具和自动化:DevOps鼓励采用自动化技术，而SRE则专注于跨IT团队拥抱一致的技术和信息使用。这使得沟通更容易，并减少了技术不兼容造成问题的机会。这种标准化还有助于确保团队成员能够更好地协作，因为工具是统一的，而且不太可能需要某些成员的专门技能。
-
度量一切:SRE将度量与反馈循环相结合，以度量操作并识别改进的机会。它还根据需要为风险和手工操作构建度量标准，通过度量使其更具可预测性。通过应用度量数据，团队可以设置适当的目标，同时保持对性能的合理预期。
既然我们知道了为什么SRE很重要，那么让我们继续讨论在拥抱SRE文化时必须遵循的SRE最佳实践。
SRE最佳实践
在实现SRE时，您可能需要一些时间来改进您的策略和定制实践，以满足您的操作需求。为了帮助加快这个过程，请考虑以下SRE原则和最佳实践。
错误的预算
简而言之，错误预算是指你的服务在用户开始不开心之前的一段时间内积累的错误数量。您可以将其视为对用户的忍耐力，但应用于服务的特定维度:可用性、延迟等。为了计算误差预算，我们必须使用SLI方程:
SLI = [Good events / Valid events] x 100
现在百分比用SLI表示，一旦您为每个SLI定义了目标，误差预算是剩下的，那就是您的服务水平目标(SLO)，最多100。
例如，假设您正在度量主页的可用性。可用性由响应错误的请求数除以主页接收到的所有有效请求数(以百分比表示)来衡量。如果您确定可用性的目标是99.9%，那么错误预算就是0.1%。您最多可以提供0.1%的错误(最好略低于0.1%)，用户将愉快地继续使用该服务。
看看这个表格，看看百分比是如何转化为时间的:
乍一看，错误预算似乎没有那么重要。它们只是IT和DevOps需要跟踪的另一个指标，以确保一切顺利运行，对吗?幸运的是，答案是否定的。错误预算不仅仅是确保你满足合同承诺的方式。如果团队在特定季度耗尽了他们的错误预算，新的更新通常会被冻结。它们也是开发团队创新和承担风险的机会。
像用户一样定义SLOs
以对最终用户重要的术语衡量可用性和性能。服务水平目标是所有站点可靠性工程的基础。如果没有错误预算、开发工作的优先级或及时有效的事件管理，您就无法做到这一点。SLOs应该指定它们是如何度量的以及它们在哪些条件下是有效的。
服务水平指标(SLIs):对所提供的服务水平的某些方面仔细定义的定量度量，如吞吐量、延迟。它还包括:
-
用户可以直接测量和观察。 -
这可以代表用户的体验。 -
简单地说，讨论了您将要度量的具体内容。
服务水平目标:由SLI测量的服务水平的目标值或值的范围。它还包括:
-
从用户的角度定义服务应该如何执行(通过SLI度量)。简而言之，服务应该有多好?需要改进服务的阈值。 -
用户可能会考虑打开支持的功能点。 -
由业务需求驱动，而不仅仅是当前的性能。
服务水平协议(SLA):
-
如果服务没有达到预期，为客户提供某种形式的补偿的业务合同。 -
简单地说，就是迟缓+结果。
监视错误和可用性
为了识别性能错误并维护服务可用性，SRE团队需要查看他们的系统中发生了什么。需要监控来验证应用程序/系统是否按照预期运行。这意味着一个服务，满足特定的目标，并理解发生更改时会发生什么。另外，我们想在客户之前知道发生了什么。
有效地规划服务容量
组织需要为一些事情做计划，比如有机增长，这可能是产品采用的增加，无机增长，这是由于功能发布，市场活动等导致的需求突然增长。这将消耗更多的资源(比如黑色星期五或网络星期一的宕机)。为了准备这些活动，您需要预测需求并计划获取的时间。
容量规划的重要方面包括定期的负载测试和准确的配置。定期的负载测试允许您查看系统在日常用户的平均压力下是如何运行的。此外，添加任何形式的容量都可能是昂贵的，所以知道在哪里需要额外的资源是关键。
关注变更管理
在许多组织中，大多数宕机都是由变更引起的，无论是新的二进制推送还是新的配置推送。每一个微小的变化都会影响业务。因此，分析每个变更所带来的风险。它应该受到监督。纵观全局，考虑长期变化的影响，而不仅仅是它们如何影响目前的系统。
为了确保在变更过程中没有意外发生，必须由执行推出阶段的工程师进行监控，或者最好是一个可靠的监控系统。如果检测到意外行为，首先回滚，然后进行诊断，以最小化平均恢复时间(MTTR)。
无指责的事后分析
一个真正无可指责的事后分析文化有助于在组织中建立一个更可靠的系统。事后分析应该是无可指责的，应该关注过程和技术，而不是人。
假设卷入事件的人都很聪明，出发点是好的，并且根据他们当时掌握的信息做出了最好的选择。把一件事归咎于一个人或一群人会适得其反。它创造了一种人们不敢冒险、不敢创新、不敢解决问题的氛围。
失败一定会发生。没有别的办法。但是，通过良好的事件解决方案和适当的追溯实践，失败可以是有益的。它揭示了提高弹性的重点领域。只要你从事件中吸取教训，你就取得了进步。
自动化管理
SRE的主要关注点之一是自动化。人肉工作是宝贵工程时间的浪费，通过SREs创建框架、流程、内部工具/构建工具来消除它，工程师可以重新开始创新。
总结
这篇博文试图涵盖建立成功的SRE团队所需的基本概念和实践。如果您计划在您的项目/组织中采用SRE文化，请培训您的团队，遵循最佳实践，并信任该过程。你不可能做到100%的完美。这是一个神话。但你将使整个过程变得更加流畅，并尽可能地接近完美。
引用
-
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
推荐
Linkerd、Consul、Istio、Kuma、Traefik、AWS App服务网格全方位对比
从Ice到Kubernetes容器技术，微服务架构经历了什么？
随手关注或者”在看“，诚挚感谢！
本文分享自微信公众号 - 云原生技术爱好者社区（programmer_java）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。