此外,随着微服务、持续部署和云计算的发展,网站可靠性工程(SRE)是为员工和面向客户的服务提供不间断服务的关键,特别是在数字时代。
SRE是一个由谷歌工程团队提出的概念,已经成为软件运营生命周期中一个强烈渴望的模式。更具体地说,它可以归功于Ben Treynor Sloss,他说:"SRE是当你要求一个软件工程师设计一个运营团队时发生的事情。""SRE是当你要求一个软件工程师设计一个运营团队时发生的事情。"
传统上,系统管理员手动执行确保系统可靠性的任务和流程。SRE的目标是通过软件自动化和持续改进来改造和优化这些流程。因此,公司可以从自动化和可重复的实践中受益,通过弥合开发和生产团队之间的差距,减少停机时间,促进DevOps方法的成功
在这篇文章中,你将了解什么是SRE,为什么它很重要,它与DevOps和事件管理的关系,以及SRE角色的职责是什么。
探讨SRE
顾名思义,SRE就是要确保软件产品的可靠性。然而,当涉及到软件发布周期时,软件开发人员和运营团队倾向于优先考虑可靠性概念的不同方面。
自然,软件开发人员希望加速发布新功能、重构或错误修复。运营团队关注的是发布流程,以确保终端用户拥有可靠的产品。然而,这些流程往往被视为 "拖累 "发布周期的障碍。SRE是这两个世界之间的桥梁,为了这两个目标,速度和质量,要通过自动化的软件程序来满足。
SRE团队设置了服务水平协议(SLA),规定了系统的可靠程度,以避免模棱两可或定义松散的可靠性概念。例如,一个每年99.5%的正常运行时间的SLA意味着有空间,或预算,在一年内有0.5%的错误。虽然SRE的目标是提高软件的可靠性,但应该设定和规划一个特定的误差幅度,而不是在SLA中设定100%的正常运行时间的目标。原因是,100%的正常运行时间的可用性被认为是不可能的,但接近100%是不可能的,但接近100%是不可能的。
为什么SRE很重要
开发团队和运营团队的目标是一致的,开发团队希望推出更多的功能,而运营团队则希望保持环境的稳定。由于两个团队都在努力实现SLA目标,并保持在预算的误差范围内,他们之间的传统鸿沟被缩小了,并且有一个更有凝聚力和协作的工作流程。
监测系统的可靠性
监测对于实现系统的可靠性和保持可用性至关重要。这是一个大的和多方面的概念,需要大量的自动化活动,如收集、处理和汇总你的系统的实时数据。SRE团队使用监控来识别不同类型的系统和性能错误监控来识别不同类型的系统和性能错误。
实现系统的可用性是一个持续的工程过程,需要对软件系统的基础设施的可视性;监控是通往这种可视性的门户,因为它提供了他们系统的鸟瞰图。监控包括反应性和主动性的事件,从这个意义上说,它可以通知SRE团队一些已经损坏或即将损坏的东西。
在实践中,与延迟、流量、错误和饱和度有关的指标突破等事件被用来触发警报。有些系统是自我修复的,如Kubernetes的声明系统,但在其他情况下,警报通知团队,他们反过来响应事件,以确定根本原因并补救问题。
SRE事件管理
如上所述,监控是SRE的一个关键步骤,因为它为事件管理的生命周期提供信息。在监控中,有四个黄金信号,这些信号会反馈给事件管理。当在。
-
延迟。服务一个请求所需的时间。
-
流量。系统需求的压力。
-
错误。请求失败的比率。
-
饱和度。服务的总体容量。
这些黄金规则是事件管理中成功的可操作项目的启动平台。
事件管理事件管理是指识别和纠正对组织的软件服务构成威胁或破坏的系统事件的过程。事故管理的生命周期是至关重要的,因为系统中断和停机会造成很大的损失,并对吸引新客户和保留现有客户产生负面影响。
SRE vs. DevOps
由于DevOps和SRE在哲学上或概念上的重叠,人们常常对它们的区别感到困惑。
DevOps是一种哲学、实践和工具的组合,它支持软件发布生命周期中的高速度、质量控制、基础设施管理和运营等总体目标。SRE也关注发布过程中软件的高速度和高质量,但更多的是维护服务的约定性能。
虽然DevOps在实现高速度和高质量方面高度关注管道方法和工作流程,但SRE更关注操作和可靠性问题,并使用软件来识别和补救系统事件,以保持商定的错误预算(根据SLA)。
简单地说,DevOps处理的是发布的效率,而SRE处理的是发布的可靠性DevOps处理的是发布的效率,而SRE处理的是发布的可靠性。两者通常是平行进行的(即DevOps从事工程,该组织将有SRE的团队)。
SRE技能和责任
基本的SRE工程师的技能和职责围绕着调查,分析和优化补救软件系统的调查,分析,和优化补救。在实践中,系统各不相同,因此,SRE工程师需要对特定系统的相关技术和工具有适当的了解,以帮助他们有效地调查、分析和补救问题。SRE应该承担的一些普遍角色和责任如下。
开发或构建软件以支持运营(即DevOps和IT Ops)。
SRE工程师应该对各种语言的编码和脚本感到满意,如Java,.NET,Golang,Scala,Node.js,和Python。在许多情况下,SRE来自于开发或运营背景,这可以作为一个很好的起点。SRE使用他们的编程技能,不断开发软件,帮助软件系统的操作程序自动化。
解决出现的系统支持问题
在支持和运营的生命周期中,系统错误和事故是一种预期的发生。SRE的很大一部分是为各自的团队待命,接收提示和警报,以便他们能够解决任何问题,即使是在凌晨2点。主动和被动的事件会触发监测警报,对SRE工程师来说,创建自动化和主动的工作流程很重要。SRE团队在修复工作中要有创新精神,将重复性的工作自动化,这样他们就可以拿出更多的时间来优化工作流程。
进行事故后审查
事件管理并不是在解决了系统退化问题后就结束了。SRE必须将审查事件的后续任务与解决事件的优先级放在同一直线上。在这些审查中,SRE可以与其他团队和利益相关者接触,以确定根本问题和原因,作为开发更好的程序和解决方案的第一步,以避免未来类似事件的发生。
记录和交流工作流程程序和架构设计
SRE团队与开发团队、DevOps工程师和商业利益相关者互动和接触。他们应该是跨部门的,因此,应该引领目标、流程、架构设计和工作流程的记录和知识共享,使所有相关方受益。SRE可以影响系统设计以确保生产中的性能。
最后的思考
在这篇文章中,你了解了什么是网站可靠性工程,它是如何产生的,它解决的问题,以及为什么它很重要。此外,这篇文章还探讨了监控如何在SRE工作流程中发挥重要作用,以及如何将其纳入事件管理生命周期中。最后,我们介绍了DevOps和SRE之间的重叠和差异,以及SRE工程师应该具备的主要职责和技能。
监控大型分布式系统是一项复杂的任务,需要各种工具来帮助SRE团队实现自动化、优化和简化流程。