站点可靠性工程(英语:Site reliability engineering,SRE)是一门将软件工程应用于基础设施以及运营的学科,该概念由Google于2003年提出。
站点可靠性工程主要目标是创建可扩展和高可用性的软件系统。
职责
站点可靠性工程师要花50%的时间来参与与软件运营相关的工作,如解决问题、随叫随到和人工干预。由于站点可靠性工程师所负责的软件系统需要高度自动化和自我修复,
所以站点可靠性工程师要将另外50%的时间用于开发工作,如增加新功能等工作
站点可靠性工程(SRE)是 IT 运维的软件工程方案。SRE 团队使用软件作为工具,来管理系统、解决问题并实现运维任务自动化。
SRE是"Site Reliability Engineering"(站点可靠性工程)的缩写,是一种将软件工程和系统运维结合起来的角色和方法论。SRE的主要目标是确保在线服务的稳定性、可靠性和性能,以提供高质量的用户体验。
SRE团队的成员通常是具备软件工程和系统运维技能的专业人士,他们的工作不仅仅是维护和管理系统,还包括编写自动化工具、设计监控系统、优化性能、处理故障和紧急情况等。SRE倡导以软件工程的方式来管理和运维基础设施,通过代码来实现自动化运维、监控和故障恢复,以降低人工操作带来的风险。
SRE的一些核心原则和实践包括:
SRE模式的引入,旨在解决传统运维与开发之间的鸿沟,以及保障在线服务的高可用性和稳定性。Google是最早倡导并实践SRE模式的公司之一,其经验和方法论在业界引起了广泛的关注和应用。随着云计算和大规模在线服务的发展,SRE作为一种新型的运维和工程角色,逐渐成为许多技术公司的常见职位和团队。
站点可靠性工程师是一个独特的岗位,要么必须具有系统管理员背景、或有运维经验的软件开发人员;要么必须是有软件开发技能的 IT 运维人员。
SRE 团队负责部署、配置和监控代码,以及生产服务的可用性、延迟、变更管理、应急响应和容量管理。
SRE 团队根据服务水平协议(SLA)确定新功能的推出,并利用服务水平指标(SLI)和服务水平目标(SLO)定义系统所需的可靠性。
SLI 测量所提供服务水平的特定方面。关键 SLI 包括请求延迟性、可用性、错误率和系统吞吐量。SLO 基于根据 SLI 而指定的服务水平的目标值或范围。
然后,根据确定可接受的停机时间,确定所需系统可靠性的 SLO。这个停机时间称为误差量,即出错和中断的最大允许阈值。
SRE 并不是要实现 100% 可靠性,而是针对故障做好计划并妥善应对。
一旦建立,开发团队就可以在发布新功能时允许出现这一定量的误差。利用 SLO 和误差量,团队随后可确定产品或服务是否能够在可用误差量的基础上启动。
如果某个服务在运行时处于误差量以内,则开发团队可在任何时间发布它,但是,如果系统当前有太多错误或停机时间超过误差量的允许范围,则必须使错误数减少至误差量以内后才能发布。
开发团队可执行自动化运维测试以验证可靠性。
站点可靠性工程师的时间要均衡分配给运维任务和项目工作。根据 Google 的 SRE 最佳实践,站点可靠性工程师最多只能将一半的时间花在运维上,所以应该监控确保不会超过这个时间。
他们剩余的时间应专注于开发任务上,比如创建新功能,扩展系统,以及实施自动化。
额外的运维工作和表现欠佳的服务应重新指定给开发团队,这样站点可靠性工程师就不用将太多时间花在应用或服务的运维上。
自动化是站点可靠性工程师的重要工作部分。如果他们一直在反复处理同一个问题,就会努力实现解决方案自动化。
保持运维和开发工作之间的平衡是 SRE 的重要组成部分。
DevOps 是指对企业文化、业务自动化和平台设计等方面进行全方位变革,从而实现迅捷、优质的服务交付,提升企业价值和响应能力。SRE 可视为 DevOps 的实施。
和 DevOps 一样,SRE 也与团队文化和关系密切相连。SRE 和 DevOps 都致力于搭建开发团队和运维团队之间的互通桥梁,以便加快交付服务。
DevOps 和 SRE 实践都可以实现更快的应用开发生命周期、改进的服务质量和可靠性,以及缩短的 IT 应用开发时间等优势。
然而,SRE 与 DevOps 有所不同,因为它依赖于开发团队中的站点可靠性工程师,这些工程师也要有解决通信和工作流程问题的运维背景。
站点可靠性工程师本身要求职责重叠,兼具开发团队和运维团队的技能。
DevOps 团队的开发人员常常疲于处理运维任务,需要拥有更专业运维技能,而 SRE 就能派上用场。
在编码和构建新功能时,DevOps 专注于有效通过开发流程,而 SRE 专注于通过创建新功能来平衡站点可靠性。
在这里,基于容器技术、Kubernetes 和微服务的现代化应用平台是落实 DevOps 实践的关键所在,可帮助企业交付安全的创新软件服务。
参考: