engineered是什么意思 engineer

文章插图

编译自： https://opensource.com/article/18/10/sre-startup
【engineered是什么意思 engineer】作者： Craig Sebenik
译者： BeliteX

大型企业里 SRE 角色比较常见，不过小公司也需要 SRE 。

虽然站点可靠性工程师(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 。

engineered是什么意思 engineer

秒懂生活扩展阅读