网站可靠性工程要点:网站可靠性工程的期待内容

在过去的 20 年里,大多数领先的企业都采用了云计算和分布式系统来开发其应用程序。意想不到的后果是:传统 IT 运营 (ITOps) 往往难以应对工作负载和云技术增加所带来的复杂性。
随着分布式系统的扩展,将运营和开发分开最终会导致停滞。开发人员可能希望推出新的应用程序或更新,而运营团队由于已经疲于维护现有基础设施,可能会抵制对基础设施增加的风险。
网站可靠性工程 (SRE) 是一门学科,通过结合软件工程原理与运营实践,提供一种更加细致的方法,确保服务在大规模扩展下的可靠性和最佳性能。担任这一角色的工作人员是网站可靠性工程师 (SREs),他们简化并自动化运营团队需要手动执行的任务,减少花在繁琐重复工作上的时间,为创新和业务增长打开大门。
网站可靠性工程已成为现代组织的重要组成部分。其好处包括告别被动解决问题,迎接可预测的性能、主动的系统设计、改进的可扩展性、最大限度地减少服务中断以及发现新的改进机会。
想要了解更多有关 SRE 角色和网站可靠性工程领域的信息吗?我们从基础知识开始了解吧。
什么是网站可靠性工程?
站点可靠性工程是将软件工程工具和原则融入IT运营的实践。SRE 负责创建和维护可靠、弹性、高效且可扩展的基础架构和服务。SRE 提升可扩展性系统的可靠性。他们构建具有设计弹性的系统,并使用软件和自动化来管理不断增长的基础架构,这比手动管理更具可持续性。
站点可靠性工程师是负责管理和自动化 IT 运营的人员。凭借软件工程方面的专业知识,他们确保系统保持弹性和可用性,并自动修复任何问题。该角色负责监督新应用程序的交付和部署,防止潜在的故障和中断。
网站可靠性工程的历史
Google 工程副总裁 Benjamin Treynor Sloss 在 2003 年首次创造了“网站可靠性工程”一词,他说:“SRE 就是当你要求软件工程师设计一个运营团队时发生的事情。”他就是这样做的。1
作为 Google 的一名新员工,他的任务是为管理快速扩张的业务和庞大的分布式基础设施寻找工程解决方案。按照公司基础设施的增长速度,不可能在以同样的速度进行创新的同时,雇用必要数量的工程师来手动管理新服务。相反,Treynor 的团队在创新与系统可靠性之间取得了平衡,培养了一种不断学习和改进的文化。
很快,Google 不断壮大的 SRE 团队就专注于将新功能推向生产环境,同时维护其稳定性和可靠性。在短短几年内,越来越多的公司面临着与 Google 相同的问题。他们需要管理大规模的分布式基础架构,同时维护服务的可用性和可靠性。很快,站点可靠性工程的实践就扩展到了 Google 之外,并已成为现代 IT 运营的关键。
SRE 在现代 IT 基础设施中的角色
在当今数字优先的世界中,各种规模的企业都依赖于高可用性、可扩展性和弹性的系统。一次中断,无论是网站还是移动应用程序,都可能导致财务损失、糟糕的客户体验和运营效率低下。这就是为什么 SRE 在任何公司中都发挥着至关重要的作用。
SRE 让您更容易跟上竞争对手。他们可以在几分钟内(而不是几天)解决可用性问题,并确保页面加载速度快,无论用户数量多少。
在企业中,网站可靠性工程师在不同的扩展上执行相同的任务。他们通过主动监测和事件管理来自动化可靠性,优化性能并防止系统发生故障。通过促进开发和运营团队之间的合作,网站可靠性工程师可以创建可靠且高效的系统。
网站可靠性工程的核心原则
网站可靠性工程的核心是以软件开发方法处理生产中的运营问题。其他核心原则包括接受风险、使用自动化以及设定服务级别目标 (SLO) 和服务级别指标 (SLI)。
拥抱风险
SRE 认识到,任何系统都无法完美运行。故障和中断是创新过程的一部分,属于预期之中。SRE 不试图避免失败,而是专注于理解可接受的风险水平。
承担风险就是要找出提高可靠性、部署新代码与管理对用户潜在影响之间的临界点。提高服务可靠性所需的时间、精力或其他资源是可接受的风险。其余的就是多余的。但多少风险是可接受的?在过程中的哪个节点,用户体验会开始下降?
SRE 的核心原则基于四个因素:
用户可接受的可靠性级别(通过设置 SLO 和 SLI 确定)
可靠性改进成本(包括自动化和工具)
无法改善的风险
成本与风险(通过错误预算确定)
通常,接受风险的关键在于文化视角。网站可靠性工程师的工作文化是非惩罚性的。它要求从失败中吸取教训,并实施预防措施,以持续增强系统可靠性并提升应用程序性能。
错误预算
错误预算是了解和管理风险的一个明确指标。它指的是服务在一定时间内可能出现的中断(或错误数量)。
允许的系统不可靠性(又称错误预算)有助于平衡创新和可靠性。鼓励工程师承担风险,例如加快部署和发布新功能,因为他们有错误预算。一旦达到这个阈值,工程师就会稳定系统,提高可靠性。
网站可靠性工程团队根据 SLO 确定可接受的错误级别(或中断)来计算错误预算。换句话说,它是 SLO 允许的错误幅度。
设置服务级别目标 (SLO) 和指标 (SLI)
服务级别目标或 SLO 是一定时间内的性能目标值。根据设计,工程团队和业务利益相关者都必须了解这些目标,以设定明确的期望来指导决策。
服务级别指标(SLI)用于衡量服务性能。通常,SLI 代表用户优先级,例如服务延迟、可用性、吞吐量、错误率等。
SLO 和 SLI 都不是静态的。它们会随着时间的推移而发展,需要定期审查和改进。
开发自动化和工具
最后是自动化。网站可靠性工程师致力于用自动化取代手动和重复性任务。减少工作量意味着提高系统的可靠性,并更快、更高效地进行创新。
一些网站可靠性工程团队将多达一半的时间用于开发自动化工具,以用于部署、事件响应和测试。随着时间的推移,先进的自动化功能有助于降低扩展成本,同时确保服务的可靠性和最佳性能。
网站可靠性工程中的关键实践
在运行服务时,网站可靠性工程团队重点关注关键的日常活动,如监测和可观测性、事件管理、容量规划和变更管理。
监测与可观测性
监测和可观测性对网站可靠性工程师至关重要。它们提供了对服务是否在运行、运行状况如何、问题所在等方面的真实可见性。
监测有助于网站可靠性工程师快速发现并解决问题。可观测性可提供对系统性能的实时和历史见解,以解决未知的未知问题。 跟踪、日志和指标是主要的可观测性信号。
网站可靠性工程的 4 个黄金信号
网站可靠性工程的四个黄金信号是延迟、流量、错误和饱和度。这些指标是应用程序可靠性的基础,而应用程序可靠性指的是分布式系统中服务的健康状况和性能。
延迟是系统响应请求(无论成功还是错误)所需的时间。高延迟表明存在性能问题,需要 SRE 立即关注。
流量衡量的是系统的需求。根据系统的不同,它可能是每秒的事务数或每秒的 HTTP 请求数。网站可靠性工程师使用流量来判断用户体验是否下降。
错误是指请求失败的比率。它们可以是显式失败(如 HTTP 500)、隐式失败(如 HTTP 200 但有内容错误),也可以是策略失败(如任何请求失败时间超过一秒)。根据系统情况,网站可靠性工程可以优先处理一种类型的错误,然后再处理其他类型的错误,并解决重复出现的问题。
饱和度表示系统的整体容量或服务的“满载”程度。可以通过多种方式进行测量,具体取决于最受限制的资源或系统可以处理的剩余负载。
这四个黄金信号可帮助网站可靠性工程师专注于容量规划,逐步提高系统可靠性,应对和管理事件以及找到问题的根本原因。
不过,单靠这四个黄金信号并不能使复杂的分布式系统完全可靠。这就是分布式追踪的作用所在。它能将所有性能数字与上下文联系起来。
事件管理
正如我们之前提到的,涉及网站可靠性工程时,事件和中断是不可避免的。但是,每起事件仍然需要响应。有效的事件响应计划包括分流程序、明确的沟通协议和升级路径。
事后总结也许同样重要。事后总结是一种建设性的做法,它是一种学习经验,而不是指责的机会。网站可靠性工程师应跟踪每个事件,发现其根本原因,并与开发人员团队合作修复代码或构建工具(如果可能),以防止事件再次发生。
深入了解事件管理。
容量规划
容量规划确保的是当前和未来的服务可靠性。它可以防止过度配置和配置不足。
SRE 团队通过分析历史使用模式和预测未来资源需求来进行需求预测。他们根据实时信息查找低效环节,优化和重新分配资源,并根据不断变化的数据定期更新这些计划。
利用容量规划,网站可靠性工程师可以确保系统能够应对增长和需求高峰。
变更管理
变化常常导致中断,即使是传统的ITOps也能证明这一点。然而,SREs并不惧怕中断,因此也不惧怕变化,而是通过三项最佳实践来拥抱变化:
渐进式、受控的推出可以最大限度地减少潜在问题的影响,并允许早期检测。
监测确保网站可靠性工程师能够准确地实时检测问题。
回滚计划可确保在出现问题时以安全快速的方式回滚更改。
如果可能的话,这三种做法都应该实现自动化。
为网站可靠性工程师提供基于 Elasticsearch 的全栈可观测性解决方案
Elastic 可观测性提供了一个统一的解决方案,用于收集、监测和分析可观测性指标,覆盖您的整个技术栈。通过 Elastic 可观测性,您可以从任何来源收集、存储和可视化可观测性指标,并通过 Elastic 的搜索 AI 平台加快问题解决速度。
您可以将对话式搜索和代理 AI 与 Elastic 可观测性结合,获得上下文感知的聊天体验,使其扩展为包含您的专有数据和运行手册。Elastic AI 助手可以帮助网站可靠性工程师解释日志信息和错误,优化代码,编写报告,甚至识别和执行运行手册,从而加快问题解决速度,促进协作,解锁知识,赋能所有用户,并确保可靠性。
进一步了解 Elastic 可观测性。
资料来源1. Google,“Google SRE Book”,2017 年。
本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。