SRE的含义及与 DevOps 如何关联？

虽然站点可靠性工程师（site reliability engineer SRE）角色在近几年变得流行起来，可是不少人 —— 甚至是软件行业里的 —— 还不知道 SRE 是什么或者 SRE 都干些什么。为了搞清楚这些问题，这篇文章解释了 SRE 的含义，还有 SRE 怎样关联 DevOps，以及在工程师团队规模不大的组织里 SRE 该如何工做。

什么是站点可靠性工程？

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

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

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

在深刻探讨什么是 SRE 以及 SRE 如何和开发团队协做以前，咱们须要先了解一下 SRE 在 DevOps 范例中是怎么工做的。

SRE 和 DevOps

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

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

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

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

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

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

SRE 在初创公司怎么工做

若是大家公司有好几百位员工，那是很是好的（若是到了 Google 和 Facebook 的规模就更不用说了）。大公司的 SRE 团队分散在各个开发团队里。可是一个初创公司没有这种规模经济，工程师常常身兼数职。那么小公司该让谁作 SRE 呢？其中一种方案是彻底践行 DevOps，那些大公司里属于 SRE 的典型任务，在小公司就让开发者去负责。另外一种方案，则是聘请专家 —— 也就是 SRE。

让开发人员作 SRE 最显著的优势是，团队规模变大的时候也能很好的扩展。并且，开发人员将会全面地了解应用的特性。可是，许多初创公司的基础设施包含了各类各样的 SaaS 产品，这种多样性在基础设施上体现的最明显，由于连基础设施自己也是多种多样。而后大家在某个基础设施上引入指标系统、站点监控、日志分析、容器等等。这些技术解决了一部分问题，也增长了复杂度。开发人员除了要了解应用程序的核心技术（好比开发语言），还要了解上述全部技术和服务。最终，掌握全部的这些技术让人没法承受。

另外一种方案是聘请专家专职作 SRE。他们专一于发布部署、配置管理、监控和指标，能够节省开发人员的时间。这种方案的缺点是，SRE 的时间必须分配给多个不一样的应用（就是说 SRE 须要贯穿整个工程部门）。 这可能意味着 SRE 没时间对任何应用深刻学习，然而他们能够站在一个能看到服务全貌的高度，知道各个部分是怎么组合在一块儿的。 这个“三万英尺高的视角”能够帮助 SRE 从系统总体上考虑，哪些薄弱环节须要优先修复。

有一个关键信息我还没提到：其余的工程师。他们可能很渴望了解发布部署的原理，也很想尽全力学会使用指标系统。并且，雇一个 SRE 可不是一件简单的事儿。由于你要找的是一个既懂系统管理又懂软件工程的人。（我之因此明确地说软件工程而不是说“能写代码”，是由于除了写代码以外软件工程还包括不少东西，好比编写良好的测试或文档。）

所以，在某些状况下让开发人员作 SRE 可能更合理一些。若是这样作了，得同时关注代码和基础设施（购买 SaaS 或内部自建）的复杂程度。这两边的复杂性，有时候能促进专业化。

总结

在初创公司作 DevOps 实践最有效的方式是组建 SRE 小组。我见过一些不一样的方案，可是我相信初创公司（尽早）招聘专职 SRE 能够解放开发人员，让开发人员专一于特定的挑战。SRE 能够把精力放在改善工具（流程）上，以提升开发人员的生产力。不只如此，SRE 还专一于确保交付给客户的产品是可靠且安全的。