什么是 SRE（站点可靠性工程）

what's site reliability engineer

站点可靠性工程（site reliability engineer SRE）是 IT 运维的软件工程方案。SRE 团队使用软件作为工具，来管理系统、解决问题并实现运维任务自动化。

SRE 执行的任务以前通常由运维团队手动执行，或者交给使用软件和自动化来解决问题和管理生产系统的工程师或运维团队执行。 

在创建可扩展和高度可靠的软件系统时，SRE 是宝贵的实践。它可帮助您通过代码管理大型系统，对于管理成千上万台机器的系统管理员（sysadmin）来说，代码更具可扩展性和可持续性。 

站点可靠性工程的概念由 Google 工程团队的 Ben Treynor Sloss 第一个提出。 

2003 年，Benjamin Treynor Sloss 加入了谷歌。他的首要任务之一，就是被要求管理一个由七名工程师组成的“生产环境团队（Production Team）”。

在此之前，他之前的工作经验是软件工程。因此，如果他担任 SRE ，他会按照自己希望的方式设计和管理团队。自那以后，这个团队已经发展成熟，成为谷歌现在的 SRE 团队，这一团队目前仍旧忠于这位终身软件工程师所设想的原始目的。

SRE 就是当你要求软件工程师设计一个运维团队时，所发生的事情

谷歌的几个工程师写的《SRE：谷歌运维解密》被认为是站点可靠性工程的权威书籍。谷歌的工程副总裁 Ben Treynor Sloss 在二十一世纪初创造了这个术语。他是这样定义的：“当你让软件工程师设计运维功能时，SRE 就产生了。”

虽然系统管理员从很久之前就在写代码，但是过去的很多时候系统管理团队是手动管理机器的。当时他们管理的机器可能有几十台或者上百台，不过当这个数字涨到了几千甚至几十万的时候，就不能简单的靠人去解决问题了。规模如此大的情况下，很明显应该用代码去管理机器（以及机器上运行的软件）。

另外，一直到近几年，运维团队和开发团队都还是完全独立的。两个岗位的技能要求也被认为是完全不同的。SRE 的角色想尝试把这两份工作结合起来。

SRE 可以帮助团队在发布新功能和确保用户可靠性之间找到平衡。

在这种背景下，标准化和自动化是 SRE 模型的两大重要部分。在这里，站点可靠性工程师寻求增强和自动化运维任务。

通过这些方式，SRE 有助于提高当今的系统可靠性，并且随着时间的推移不断提高。 

SRE 支持团队从传统 IT 运维方案迁移至云原生方案。

站点可靠性工程师的工作是什么？

站点可靠性工程师是一个独特的岗位：

• 具有系统管理员背景

• 运维经验的软件开发人员

• 有软件开发技能的 IT 运维人员

SRE 团队负责部署、配置和监控代码，以及生产服务的可用性、延迟、变更管理、应急响应和容量管理。

SRE 团队根据服务水平协议（SLA）确定新功能的推出，并利用服务水平指标（SLI）和服务水平目标（SLO）定义系统所需的可靠性。 

SLI 测量所提供服务水平的特定方面。关键 SLI 包括请求延迟性、可用性、错误率和系统吞吐量。SLO 基于根据 SLI 而指定的服务水平的目标值或范围。

然后，根据确定可接受的停机时间，确定所需系统可靠性的 SLO。这个停机时间称为误差量，即出错和中断的最大允许阈值。 

SRE 并不是要实现 100% 可靠性，而是针对故障做好计划并妥善应对。

一旦建立，开发团队就可以在发布新功能时允许出现这一定量的误差。利用 SLO 和误差量，团队随后可确定产品或服务是否能够在可用误差量的基础上启动。

如果某个服务在运行时处于误差量以内，则开发团队可在任何时间发布它，但是，如果系统当前有太多错误或停机时间超过误差量的允许范围，则必须使错误数减少至误差量以内后才能发布。   

开发团队可执行自动化运维测试以验证可靠性。 

站点可靠性工程师的时间要均衡分配给运维任务和项目工作。根据 Google 的 SRE 最佳实践，站点可靠性工程师最多只能将一半的时间花在运维上，所以应该监控确保不会超过这个时间。  

他们剩余的时间应专注于开发任务上，比如创建新功能，扩展系统，以及实施自动化。

额外的运维工作和表现欠佳的服务应重新指定给开发团队，这样站点可靠性工程师就不用将太多时间花在应用或服务的运维上。 

自动化是站点可靠性工程师的重要工作部分。如果他们一直在反复处理同一个问题，就会努力实现解决方案自动化。 

保持运维和开发工作之间的平衡是 SRE 的重要组成部分。 

SRE 团队的组成

谷歌服务管理方式的主要组成部分就由每个 SRE 团队的组成。总体而言，SRE 可分为两大类。

• 50-60 % 的人是谷歌软件工程师，他们是通过谷歌软件工程师的标准程序聘用的。

• 另外 40-50% 的应聘者也非常接近谷歌软件工程资格，同时拥有一套对 SRE 有用，但对大多数软件工程师来说很少用的技术技能。

到目前为止，UNIX 系统内部知识和网络专业知识是他们寻求的两种最常见的替代技术技能。

所有 SRE 的共同点是，他们都有通过开发软件系统，来解决复杂问题的信念和能力。

在 SRE 内部，他们密切跟踪了这两个群体的职业发展。到目前为止，他们还没有发现工程师在这两个领域的实际表现存在差异。事实上，SRE 团队有不同的背景，这通常会产生一些智能且高质量的系统，这显然是多种技能组合的产物。

谷歌为招聘 SRE 所用的方法，最终的结果就是，他们最终拥有这样一个团队：

• 会很快对使用手工方式完成任务感到厌倦

• 具备编写软件以取代以前手工工作所需的技能，即使解决方案很复杂，也是一样。

SRE 最终会与其他开发组织分享了学术和知识背景。因此，SRE 基本上是在做原来运维团队所做的工作，但其方式是启用具有软件专业知识的工程师，并基于这些工程师固有的使用软件设计和实施自动化的能力，来设计和实施自动化的能力。

SRE 和 DevOps

“DevOps” 这个术语在 2008 年末出现，其核心原则：

• IT 部门在系统设计和开发的每个阶段的参与

• 严重依赖自动化与人力投入

• 工程实践和工具在操作任务中的应用

与许多 SRE 的原则和实践一致。 人们可以将 DevOps 视为几种核心 SRE 原则向更广泛的组织，管理结构和人员的推广。 可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。

站点可靠性工程的核心，就是对 DevOps 范例的实践。DevOps 的定义有很多种方式。开发团队（“dev”）和运维（“ops”）团队相互分离的传统模式下，写代码的团队在将服务交付给用户使用之后就不再对服务状态负责了。开发团队“把代码扔到墙那边”让运维团队去部署和支持。

这种情况会导致大量失衡。开发和运维的目标总是不一致  ——  开发希望用户体验到“最新最棒”的代码，但是运维想要的是变更尽量少的稳定系统。运维是这样假定的，任何变更都可能引发不稳定，而不做任何变更的系统可以一直保持稳定。（减少软件的变更次数并不是避免故障的唯一因素，认识到这一点很重要。例如，虽然你的  web 应用保持不变，但是当用户数量涨到十倍时，服务可能就会以各种方式出问题。）

DevOps 理念认为通过合并这两个岗位就能够消灭争论。如果开发团队时刻都想把新代码部署上线，那么他们也必须对新代码引起的故障负责。就像亚马逊的 Werner Vogels 说的那样，“谁开发，谁运维”（生产环境）。但是开发人员已经有一大堆问题了。他们不断的被推动着去开发老板要的产品功能。再让他们去了解基础设施，包括如何部署、配置还有监控服务，这对他们的要求有点太多了。所以就需要 SRE 了。

开发一个  web  应用的时候经常是很多人一起参与。有用户界面设计师、图形设计师、前端工程师、后端工程师，还有许多其他工种（视技术选型的具体情况而定）。如何管理写好的代码也是需求之一（例如部署、配置、监控）——  这是 SRE 的专业领域。但是，就像前端工程师受益于后端领域的知识一样（例如从数据库获取数据的方法），SRE  理解部署系统的工作原理，知道如何满足特定的代码或者项目的具体需求。

所以 SRE 不仅仅是“写代码的运维工程师”。相反，SRE  是开发团队的成员，他们有着不同的技能，特别是在发布部署、配置管理、监控、指标等方面。但是，就像前端工程师必须知道如何从数据库中获取数据一样，SRE  也不是只负责这些领域。为了提供更容易升级、管理和监控的产品，整个团队共同努力。

当一个团队在做 DevOps 实践，但是他们意识到对开发的要求太多了，过去由运维团队做的事情，现在需要一个专家来专门处理。这个时候，对 SRE 的需求很自然地就出现了。

参考文章：

https://www.redhat.com/zh/topics/devops/what-is-sre

什么是 SRE？它和 DevOps 是怎么关联的？ https://cloud.tencent.com/developer/article/1881362

谷歌的 SRE 是怎么来的？ https://www.continuousdelivery20.com/blog/sre-how-google-come-up-with/