什么是 SRE？它和 DevOps 是怎么关联的？
大型企业里 SRE 角色比较常见，不过小公司也需要 SRE。
虽然 站点可靠性工程师 （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 还专注于确保交付给客户的产品是可靠且安全的。
via: https://opensource.com/article/18/10/sre-startup
作者：Craig Sebenik 选题：lujun9972 译者：BeliteX 校对：wxy