文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

站点可靠性工程(SRE)的优秀实践

2024-12-14 00:26

关注

【51CTO.com快译】如果管理者计划在组织内部或项目中采用SRE文化,那么需要了解如何更好地培训其SRE团队并遵循优秀实践。

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

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

SRE团队承担IT运营团队完成的人工任务,并将其交给使用工具和自动化解决问题和管理生产系统的工程师或运营团队。

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

为什么SRE很重要?如何构建优秀的SRE团队?

SRE就像是沟通软件工程团队和IT运营团队之间的桥梁,填补了两者之间的空白。几乎在任何地方,SRE随时随地都在为生产系统中的故障做好准备时发挥作用。它确保组织的系统具有可扩展性、可靠性、可预测性和自动化。

SRE还设置了服务水平指标(SLI)、服务水平目标(SLO)、服务水平协议(SLA) ,其中定义了性能的真实数字、团队满足该协议必须达到的目标,以及系统对最终用户的可靠性要求。SRE的主要目标是提高性能和运营效率。

因此,SRE人员不仅仅是“编写代码的运营人员”,也应该是开发团队的成员,并且拥有不同的技能,尤其是在部署、配置管理、监控、指标等方面。SRE团队需要负责这些领域,正如开发工程师必须知道如何从数据存储中提取数据一样。而SRE团队需要通力合作,交付易于更新、管理和监控的产品。当企业正在实现DevOps项目,但意识到他们对开发人员的要求太高,并且需要专家来处理运营团队过去处理的事情时,就自然会产生对SRE人员的需求。

在了解SRE以及SRE团队如何与开发团队合作之前,需要了解SRE如何在DevOps模式中发挥作用。

SRE团队如何与DevOps团队协同工作?

从本质上来说,SRE是DevOps模式的实现。正如持续集成和持续交付是DevOps原则在软件发布中的应用程序一样,SRE是这些原则在软件可靠性中的应用。

定义DevOps的方法有很多种。尽管如此,传统模式是将开发(“Dev”)团队和运营(“Ops”)团队分开,这导致编写代码的团队在客户开始使用代码时不负责代码的工作方式,而会将这些代码直接交给运维团队安装和支持。

根据谷歌公司的方法,组织可以使用SRE在其内部更好地采用DevOps原则并衡量实施是否成功。

为了更好将这两者结合起来,需要考虑以下原则:

现在知道SRE很重要的原因,以下继续讨论在接受SRE文化时必须遵循的SRE优秀实践。

SRE的优秀实践

在实施SRE时,组织可能需要一些时间来完善其策略并定制实践以满足运营需求。为了帮助加快这一过程,需要考虑以下SRE原则和优秀实践。

(1)错误预算

简而言之,错误预算是在用户开始不满意之前,组织的服务在一段时间内可以累积的错误量。可以将其视为用户的痛苦容忍度,但适用于服务的可用性和延迟等特定维度。为了计算误差预算,必须使用SLI方程:

SLI=[良好事件/有效事件]×100

在这个公式中的百分比表示为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:

③服务水平协议(SLA):

如果服务未达到预期,则向客户提供某种形式的补偿的商业合同。简单来说,SLA 就是SLO+后果。

(3)监控错误和可用性

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

(4)高效规划能力

组织需要为业务的有机增长(可能是产品采用率的增加)和无机增长(由于功能发布、营销活动等导致需求的突然增长)等进行规划。这些活动将消耗更多资源(如黑色星期五导致的停机)。为准备这些活动,组织需要预测需求并规划采购时间。

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

(5)注重变革管理

在许多组织中,大多数停机都是由对活动系统的更改引起的,无论是新的二进制推送还是新的配置推送。每一个微小的变化都会影响业务。因此,需要分析每个变更所带来的风险,并且应该受到监督。组织需要通过查看大局来考虑长期变化的影响,而不仅仅是它们如何影响当今的系统。

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

(6)无责任的事后分析

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

假设事件中涉及的人员根据他们当时可用的信息做出最好的选择。将事件归咎于某人或某个团队会适得其反。因为这将会带来人们不敢冒险、不敢创新、不敢解决问题的氛围和环境。

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

(7)劳动管理

SRE的主要关注点之一是自动化。一些重复性劳动对于开发人员来说是一种时间的浪费,通过SRE创建框架、流程、内部工具/构建工具来消除这些重复性劳动,将会让工程师专注于技术创新。

结论

本文试图涵盖建立成功的SRE团队所需的基本概念和实践。如果管理者计划在项目和组织内部采用 SRE文化,需要培训团队、遵循优秀实践并信任该过程。虽然不可能达到 100% 的完美,但是会让事情变得更加精简并尽可能接近完美。

原文Site Reliability Engineering (SRE) Best Practices,作者:Rayan Das

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

 

来源:51CTO内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯