什么是SRE？

站点可靠性工程（SRE）使用软件工程来自动化IT操作任务，如生产系统管理、变更管理、事件响应，甚至应急响应，否则这些任务将由系统管理员手动执行。

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

SRE还可以减少或消除开发团队之间的许多自然摩擦，因为一些团队希望不断地将新的或更新的软件发布到生产中。然而，运营团队不想在不确定不会导致停机或其他运营问题的情况下发布任何类型的更新或新软件。因此，虽然SRE不是DevOps的严格要求，但它与DevOps原则紧密一致，可以在DevOps成功中发挥重要作用。

SRE的概念归功于谷歌工程副总裁Ben Treynor Sloss，他著名地写道：“SRE是当你要求软件工程师设计运营团队时会发生的事情。”

什么是现场可靠性工程？

站点可靠性工程（SRE）使用软件工程来自动化IT操作任务，例如生产系统管理、变更管理、事件响应，甚至应急响应，否则这些任务将由系统管理员手动执行。

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

SRE还可以减少或消除希望在生产中不断发布新软件或更新软件的开发团队与不希望在不绝对确定不会导致停机或其他运营问题的情况下发布任何类型的更新或新软件的运营团队之间的自然摩擦。因此，虽然SRE不是DevOps的严格要求，但它与DevOps原则紧密一致，可以在DevOps成功中发挥重要作用。

SRE的概念归功于谷歌工程副总裁Ben Treynor Sloss，他著名地写道：“SRE是当你要求软件工程师设计运营团队时会发生的事情。”

现场可靠性工程师做什么？

站点可靠性工程师是一名具有IT运营经验的软件开发人员，他知道如何编码，了解如何在大型IT环境中“保持照明”。

站点可靠性工程师将一半的时间用于执行手动IT操作和系统管理任务——分析日志、性能调整、应用补丁、测试生产环境、响应事件、进行事后检查。在剩下的时间里，他们开发自动化这些任务的代码。他们的目标是在前者上花更少的时间，在后者上花更多的时间。

在更高的层面上，SRE团队是开发团队和运营团队之间的桥梁，使开发团队能够尽快将新软件或新功能投入生产。他们做到这一点的同时，还确保根据组织与其客户签订的服务级别协议（SLA），在IT运营性能和错误风险方面达到商定的可接受水平。基于他们的经验和丰富的运营数据，SRE团队帮助开发和运营团队建立

• 服务级别指标（SLI）：衡量系统提供的服务级别的指标，如可用性（正常运行时间）或延迟。
• 服务水平目标：商定的衡量服务水平指标的方法。
• 错误预算：在不违反SLA合同条款的情况下，系统可能出现故障或表现不佳的最长时间。误差预算不仅仅是一个指标，它是现场可靠性工程团队用来自动协调公司创新速度与其服务可靠性的工具。
   

错误预算是如何工作的？

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

假设一家公司的SLA承诺每年99.99%的正常运行时间（一个常见的可用性目标）。这意味着每月的错误预算——任何给定月份在没有合同后果的情况下允许的总停机时间——大约为4分23秒。

现在，假设开发团队希望推出一些新功能或对系统进行改进。如果系统在错误预算下运行，团队可以提供新功能。否则，团队将无法提供新功能，除非他们与运营团队合作，将这些错误或停机降至可接受的水平。

通过这种方式，错误预算有助于开发团队和运营团队

• 提高服务的稳定性和性能。
• 就部署新功能或应用程序做出数据驱动的决策。
• 通过在可接受的限度内承担风险，最大限度地实现创新。

SRE和DevOps

DevOps是一种更快地交付更高质量应用程序的现代方式，它实现了软件交付生命周期的自动化，并赋予开发和运营团队更多的共同责任和对彼此工作的更多投入。

与SRE一样，DevOps通过平衡更快地交付更多应用程序和更改的需求与避免“破坏”生产环境的需求，使业务更加敏捷。与SRE一样，DevOps的目标是通过建立可接受的错误风险来实现这种平衡。事实上，SRE和DevOps看起来如此相似，以至于一些专家说它们是一样的——但大多数人认为SRE实践是实现DevOps原则的优秀方法。例如

• DevOps原则：减少组织孤岛，利用工具和自动化。
• SRE实践：使用与开发人员开发和改进软件相同的工具来自动化和改进操作。
• DevOps原则：正常接受失败，实施渐进式变革。
• SRE实践：使用错误预算在可接受的级别内不断部署新特性和功能。
• DevOps原则：衡量一切。
• SRE实践：基于SLA指标发布新软件的决策。

SRE的其他好处

除了支持DevOps的成功，站点可靠性工程还可以帮助公司

• 通过跟踪组织中所有服务的指标、日志和跟踪，以及在发生事故时提供识别根本原因的上下文，提高对服务运行状况的可见性。
• 通过帮助开发和运营团队了解违反SLA的成本，并帮助管理层量化系统可靠性对生产、销售、营销、客户服务和其他业务功能的影响，量化停机成本。
• 通过建立高效的随叫随到流程和简化警报工作流程来优化事件响应。
• 通过将对IT运营的深入了解与机器学习和自动化相结合，建立一个现代化的网络运营中心，直接向负责解决问题的人员发送警报。
   

SRE、云和云原生开发

从传统的IT和本地数据中心迁移到混合云环境是普通企业每年生成两到三倍多的运营数据的主要原因之一。SRE越来越被视为在IT环境变得更加复杂的情况下利用这些数据实现系统管理、操作和事件响应自动化，并提高企业可靠性的关键。

云原生开发方法——特别是将应用程序构建为微服务并将其部署在容器中——可以简化应用程序的开发、部署和可扩展性。但云原生开发也创造了一个日益分散的环境，使管理、运营和管理变得复杂。SRE团队可以支持云原生方法实现的快速创新，并确保或提高系统可靠性，而不会给DevOps团队带来更多的运营压力。