【.com快言】如果管理者计划在其组织或项目中采用SRE文化，他们需要了解如何更好地培训SRE团队并遵循最佳实践。什么是站点可靠性工程(SRE)？站点可靠性工程（SRE）的概念起源于谷歌，SRE是一种与DevOps密切相关的IT运维方法论。SRE团队使用该软件来管理系统、解决问题和自动化操作任务。SRE团队将IT运维团队完成的人工任务交给使用工具和自动化来解决问题和管理生产系统的工程师或运维团队。在创建可扩展且高度可靠的软件系统时，这是一种更有价值的做法。SRE团队通过代码帮助组织管理庞大的基础设施，这对于管理大量机器的系统管理员来说更具可扩展性和可持续性。为什么SRE很重要？如何打造一支优秀的SRE团队？SRE就像沟通软件工程团队和IT运维团队之间的桥梁，填补了两者之间的空白。几乎在任何地方，SRE都在随时随地为生产系统的故障做准备。它确保组织的系统是可扩展的、可靠的、可预测的和自动化的。SRE还设置服务水平指标(SLI)、服务水平目标(SLO)、服务水平协议(SLA)，它们定义了性能的实际数字、团队为满足该协议必须达到的目标，以及系统对最终用户的可靠性要求。SRE的主要目标是提高性能和运营效率。所以，SRE人不仅仅是“写代码的ops人”，他们也应该是开发团队的成员，拥有不同的技能组合，尤其是在部署、配置管理、监控、指标等方面。SRE团队需要对这些负责领域，就像开发工程师必须知道如何从数据存储中提取数据一样。SRE团队需要通力合作，交付易于更新、管理和监控的产品。当企业在实施DevOps项目时，发现他们对开发人员的要求太多，需要专家来处理过去由运维团队处理的事情时，自然会产生对SRE人员的需求。在了解SRE以及SRE团队如何与开发团队合作之前，有必要了解SRE如何在DevOps模型中发挥作用。SRE团队如何与DevOps团队合作？本质上，SRE是DevOps模式的一种实现。正如持续集成和持续交付是DevOps原则在软件发布上的应用一样，SRE是这些原则在软件可靠性上的应用。定义DevOps的方法有很多种。尽管如此，分离开发(“Dev”)和运营(“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=[GoodEvents/ValidEvents]x100此公式中的百分比表示为SLI，一旦组织为每个SLI定义了目标，这就是它的服务级别目标(SLO)，误差预算是余数，最高可达100。例如，假设一个组织正在衡量网站主页的可用性。可用性是通过将响应错误的请求数除以主页收到的所有有效请求数来衡量的（以百分比表示）。如果您确定可用性目标为99.9%，则错误预算为0.1%。组织的错误率最高可达0.1%（最好略低于0.1%），用户会很乐意继续使用该服务。下表显示了百分比如何转化为发生错误的时间：乍一看，错误预算似乎并不那么重要。它们只是IT团队和DevOps团队需要跟踪以确保一切顺利运行的指标之一。这种说法是错误的。错误预算不仅仅是确保组织履行其合同承诺的便捷方式。如果团队用尽了一个季度的错误预算，新的预算通常会被冻结。它们也是开发团队创新和承担风险的机会。(2)像用户一样定义服务级别目标(SLO)。服务级别目标(SLO)用于衡量对最终用户很重要的可用性和性能。SLO是所有SRE的基础，如果没有SLO，组织就无法制定错误预算、确定开发工作的优先级或进行及时有效的事件管理。SLO应指定如何衡量它们以及它们有效的条件。①服务水平指标（SLI）：对所提供服务水平某些方面（例如吞吐量、延迟）的定量测??量。通过SLI：用户可以直接测量和观察。它可以代表用户的体验。简单的说，就是了解用户想要测量什么。②服务水平目标（SLO）：SLI衡量的服务水平的目标值或取值范围。通过SLO：定义服务应该如何从用户的角度执行（通过SLI测量）。简单来说，应该提供多好的服务，以及需要改进的门槛。是用户可能考虑打开支持票的时间点。受业务需求驱动，而不仅仅是当前性能。③服务水平协议（SLA）：如果服务没有达到预期，向客户提供某种形式的补偿的商业合同。简单来说，SLA就是SLO+Consequences。(3)监控错误和可用性为了识别性能错误和维护服务可用性，SRE团队需要了解他们的系统中发生了什么。需要监控来验证应用程序/系统是否按预期运行，这意味着服务、满足特定目标以及了解进行更改时会发生什么。并在客户之前知道这一点。(4)高效的规划能力组织需要针对业务的有机增长（可能是产品采用率的提高）和无机增长（由于功能发布、营销活动等导致的需求突然增加）进行规划。这些活动会消耗更多的资源（比如黑色星期五造成的宕机）。为了准备这些活动，组织需要预测需求并计划采购时间。容量规划的重要方面包括定期负载测试和资源供应。定期负载测试使组织能够了解系统在日常用户的平均压力下的表现。此外，以任何形式增加容量都可能成本高昂，因此组织了解哪里需要额外资源是关键。(5)关注变更管理在许多组织中，大多数中断都是由对实时系统的更改引起的，无论是新的二进制推送还是新的配置推送。每一个微小的变化都会影响业务。因此，需要分析并监控每个变更带来的风险。组织需要从大局着眼来考虑长期变化的影响，而不仅仅是它们如何影响当今的系统。为确保在变更期间不会发生意外，必须由执行推出阶段的工程师或最好由可证明可靠的监控系统进行监控。如果检测到意外行为，请先回滚，然后进行诊断以最大程度地减少平均恢复时间(MTTR)。(6)无问责事后分析无问责事后分析有助于在组织中建立更可靠的系统。事后分析应该无可非议，应该关注过程和技术，而不是人的责任。假定事件相关人员根据当时掌握的信息做出了最佳选择。将事件归咎于一个人或一个群体会适得其反。因为会带来一种不敢冒险、不敢创新、不敢解决问题的氛围和环境。失败总会发生，没有办法绕过它。但通过良好的事件解决和回顾性实践，经历失败也可能是有益的。它揭示了需要注意的领域以提高弹性。只要人们从事件中吸取教训，就会取得进步。(7)劳务管理SRE的主要关注点之一是自动化。一些重复性的劳动对开发者来说是浪费时间。通过SRE消除这些重复劳动来创建框架、流程和内部工具/构建工具，将使工程师专注于技术创新。结论本文试图涵盖构建成功的SRE团队所需的基本概念和实践。如果管理者计划在他们的项目和组织中采用SRE文化，他们需要培训他们的团队、遵循良好实践并信任该过程。虽然不可能100%完美，但它会让事情变得更精简，并尽可能接近完美。原标题：站点可靠性工程（SRE）最佳实践，作者：RayanDas
