主页 topics 什么是SRE (站点可靠性工程 )| IBM 什么是 SRE ( 站点可靠性工程 )?
深入了解 IBM 的 SRE 解决方案 订阅 AI 主题最新消息
拼贴齿轮、机械臂、手机象形图的插图
什么是 SRE?

站点可靠性工程 (SRE) 使用软件工程来自动执行 IT 运营任务,例如生产系统管理、变更管理、事件响应,甚至是本需要由系统管理员 (sysadmins) 手动执行的应急响应。

SRE 背后的原则是以软件代码自动监督大型软件系统是一种比手动干预更具可扩展性和可持续性的策略,尤其是当这些系统扩展或迁移到云时。

SRE 还可减少或消除开发团队与运营团队之间的很多自然摩擦,因为一些团队希望不断将新的或更新后的软件投入生产环境。然而,运营团队则不想发布任何类型的更新或新软件,除非完全确定它不会导致中断或其他运营问题。因此,虽然 DevOps 并未严格要求使用 SRE,但后者却与 DevOps 原则密切相关,并可在实现 DevOps 成功的过程中发挥重要作用。

SRE 的概念归功于 Google 工程副总裁 Ben Treynor Sloss,他曾写过一句名言:“当你要求软件工程师设计一个运营团队时,就会发生 SRE。”

IBM 机器人流程自动化的总体经济影响™

查看 IBM® Robotic Process Automation (RPA) 的成本和收益分析。

相关内容

阅读有关 IBM 人工智能驱动自动化解决方案的分析师报告

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

SRE (站点可靠性工程 ) 利用软件工程自动执行 IT 运营任务,例如,生产系统管理、变更管理、事件响应,甚至是应急响应。如果没有 SRE,这些任务则需要系统管理员手动执行。 

SRE 背后的原理是利用软件代码自动监督大型软件系统,与手动干预相比,这一策略具有更高的可扩展性和可持续性,当系统扩展或迁移到云端时尤为如此。

SRE 还可以减少或消除开发团队与运营团队之间的很多摩擦:开发团队希望不断将新的或更新的软件发布到生产环境,而运营团队则不希望发布任何类型的更新软件或新软件,除非能绝对保证不会造成停运或其他运营问题。 因此,虽然 DevOps 并未严格要求,SRE 仍严格遵守 DevOps 原则,且对于 DevOps 的成功有着举足轻重的作用。

SRE 的概念由 Google 工程部副总裁 Ben Treynor Sloss 提出,他有一句名言:“SRE 是你要求软件工程师设计运营团队时必然会发生的事”。

谁是 SRE 工程师,他们做些什么?

SRE 工程师是拥有 IT 运营经验的软件开发者,他了解如何编码,也知道如何保持大型 IT 环境持续运转。 

SRE 工程师将不超过一半的时间用于执行手动 IT 操作和系统管理任务,如分析日志、性能调整、应用补丁、测试生产环境、响应事件、进行后期检查,其余时间则用于开发代码来自动执行这些任务。 SRE 工程师的目标是缩短前者所花的时间,逐步将更多时间用于后者。

从更高层面来说,SRE 团队充当开发团队和运营团队之间沟通的桥梁,使开发团队能够尽快将新软件或新功能引入生产环境,同时确保协定的可接受 IT 运营性能和出错风险级别符合组织与客户达成的服务级别协议 (SLA) 。 SRE 团队会根据自己的经验和丰富的运营数据,帮助开发和运营团队建立:

  • 服务级别指标 (SLI):用于衡量系统所提供的服务级别,如可用性(正常运行时间)或等待时间等指标

  • 服务级别目标 (SLO):协定的服务级别指标评估方法

  • 错误预算:系统在不违反 SLA 合同条款的情况下发生故障或表现不佳的最长时间。 错误预算不仅仅是一个指标,还是站点可靠性工程团队用来自动协调公司创新速度与服务可靠性的一款工具。  
SRE 如何执行错误预算?

错误预算是 SRE 团队用来自动协调公司服务可靠性与其软件开发和创新速度的一款工具。 

假设某家公司的 SLA 承诺每年的正常运行时间达到 99.99%(通用可用性目标)。 这意味着每月的错误预算约为 4 分 23 秒,这是任何给定月份在不承担合同后果的情况下允许的停机时间总长。

现在假设开发团队希望推出一些新功能或对系统加以改进。 如果系统的运行不超出错误预算,那么团队可以交付新功能。 否则,团队无法交付新功能,除非他们与运营团队合作将这些错误或停机降低至可接受的级别。

通过 SRE 这种方式,错误预算可帮助开发团队和运营团队:

  • 提高服务的稳定性和绩效水平

  • 就部署新功能或应用制定数据驱动的决策

  • 通过让承担的风险在可接受限度内,最大程度开展创新
SRE 和 DevOps 开发运维

DevOps 是一种更快交付高质量应用的现代方式,该方式可自动执行软件交付生命周期,并让开发团队和运营团队共担更多责任,更多参与彼此的工作。 

与 SRE 一样,DevOps 适当地平衡了更快交付更多应用和变更的需求与避免“破坏”生产环境的需求,让业务更加敏捷。 不仅如此,DevOps 还与 SRE 一样,都旨在通过确定可接受的错误风险来实现这一平衡。 事实上,SRE 和 DevOps 非常相似,一些专家甚至认为 SRE 和 DevOps 二者完全等同,但大多数人认为 SRE 实践是实现 DevOps 原则的出色方法。 例如:

DevOps 原则:减少组织孤岛,利用工具和自动化

SRE 实践:使用开发人员开发和改进软件所用的同款工具自动执行并改进运营

DevOps 原则:将失败视为正常情况,逐步实施更改

SRE 实践:使用错误预算在可接受级别持续部署新功能部件和功能

DevOps 原则:评估一切内容

SRE 实践:根据 SLA 指标制定新软件发布决策

要了解有关 DevOps 的更多内容,请观看此视频 (5:58):

其他 SRE 优点

除了助力 DevOps 取得成功,SRE (站点可靠性工程)还可以帮助公司:

  • 通过跟踪组织中所有服务的指标、日志和追踪记录,并提供相关环境以找出事件发生的根本原因,提高服务运行状况的可见性。  

  • 通过帮助开发团队和运营团队了解违反 SLA 的成本,并帮助管理层量化系统可靠性对于生产、销售、营销、客户服务和其他业务部门的影响,量化停机时间引发的成本。 

  • 通过搭建高效的客服流程并简化警报工作流程,优化事件响应。 

  • 将对 IT 运营的深入了解与机器学习和自动化相结合,建立现代网络运营中心,直接向负责解决问题的人员发送警报。 
SRE、云和云原生开发

从传统 IT 和本地数据中心迁移混合云环境,是企业每年产生的运营数据平均增加两到三倍的主要原因之一。   SRE 的重要性逐步提高,随着 IT 环境愈加复杂,SRE 可利用此类数据自动执行系统管理、运营和事件响应,同时提高企业可靠性。

云原生开发方法,具体而言,即以微服务形式构建应用并将其部署到容器中,可以简化应用开发、部署和可扩展性。      但云原生开发也创造出一个日益分散的环境,让监管、运营和管理变得更加复杂。 SRE 团队可通过云原生方法支持快速创新,并保证或提高系统可靠性,同时不会给 DevOps 团队带来更多运营压力。

相关解决方案
IBM Turbonomic

可以在无需人工干预的情况下实时不断地自动执行关键操作,主动为堆栈每一层的应用程序提供最高效的计算、存储和网络资源。

探索 IBM Turbonomic
IBM Instana™ Observability

增强应用性能监视,提供更快解决事件所需的环境。

探索 IBM® Instana
平台工程服务

IBM® Consulting 平台工程服务通过支持开发人员实现基础架构自动化自助服务来提高软件交付团队的生产力。

深入了解咨询平台工程
SRE 资源 通往 AIOps 的 SRE 之旅

探索将 AI 和自动化技术应用于 IT 运营如何能帮助 SRE 确保企业应用程序的弹性和稳健性,并腾出宝贵的时间和人才来支持创新。

IBM® Cloud Professional Site Reliability Engineer (SRE) V2

通过 IBM 提供的专业级培训和认证提高 SRE 工作技能。获取有关 IBM Cloud 环境和工具的知识并在虚拟实验室中进行练习。

什么是 DevOps?

DevOps 通过将软件开发和 IT 运营团队的工作结合并实现自动化,加快交付更高质量的软件。

什么是云原生应用程序?

云原生应用程序由微服务组成,打包并部署在容器中,旨在在任何云环境中运行。

什么是 Kubernetes?

Kubernetes 是一款开源容器编排平台,可自动部署、管理和扩展应用程序。

采取后续步骤

借助 IBM Turbonomic,可通过经济高效的方式无缝、持续运行应用程序,帮助实现高效的应用程序性能,同时降低成本。

深入了解 Turbonomic 预订免费演示