mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-03 01:10:13 +08:00
Merge pull request #10967 from belitex/master
翻译完成 What is an SRE and how does it relate to DevOps
This commit is contained in:
Chang Liu
GitHub
commit
44efef3efa
@ -1,71 +0,0 @@
|
||||
translating by belitex
|
||||
|
||||
What is an SRE and how does it relate to DevOps?
|
||||
======
|
||||
The SRE role is common in large enterprises, but smaller businesses need it, too.
|
||||
|
||||
|
||||
|
||||
Even though the site reliability engineer (SRE) role has become prevalent in recent years, many people—even in the software industry—don't know what it is or does. This article aims to clear that up by explaining what an SRE is, how it relates to DevOps, and how an SRE works when your entire engineering organization can fit in a coffee shop.
|
||||
|
||||
### What is site reliability engineering?
|
||||
|
||||
[Site Reliability Engineering: How Google Runs Production Systems][1], written by a group of Google engineers, is considered the definitive book on site reliability engineering. Google vice president of engineering Ben Treynor Sloss [coined the term][2] back in the early 2000s. He defined it as: "It's what happens when you ask a software engineer to design an operations function."
|
||||
|
||||
Sysadmins have been writing code for a long time, but for many of those years, a team of sysadmins managed many machines manually. Back then, "many" may have been dozens or hundreds, but when you scale to thousands or hundreds of thousands of hosts, you simply can't continue to throw people at the problem. When the number of machines gets that large, the obvious solution is to use code to manage hosts (and the software that runs on them).
|
||||
|
||||
Also, until fairly recently, the operations team was completely separate from the developers. The skillsets for each job were considered completely different. The SRE role tries to bring both jobs together.
|
||||
|
||||
Before we dig deeper into what makes an SRE and how SREs work with the development team, we need to understand how site reliability engineering works within the DevOps paradigm.
|
||||
|
||||
### Site reliability engineering and DevOps
|
||||
|
||||
At its core, site reliability engineering is an implementation of the DevOps paradigm. There seems to be a wide array of ways to [define DevOps][3]. The traditional model, where the development ("devs") and operations ("ops") teams were separated, led to the team that writes the code not being responsible for how it works when customers start using it. The development team would "throw the code over the wall" to the operations team to install and support.
|
||||
|
||||
This situation can lead to a significant amount of dysfunction. The goals of the dev and ops teams are constantly at odds—a developer wants customers to use the "latest and greatest" piece of code, but the operations team wants a steady system with as little change as possible. Their premise is that any change can introduce instability, while a system with no changes should continue to behave in the same manner. (Noting that minimizing change on the software side is not the only factor in preventing instability is important. For example, if your web application stays exactly the same, but the number of customers grows by 10x, your application may break in many different ways.)
|
||||
|
||||
The premise of DevOps is that by merging these two distinct jobs into one, you eliminate contention. If the "dev" wants to deploy new code all the time, they have to deal with any fallout the new code creates. As Amazon's [Werner Vogels said][4], "you build it, you run it" (in production). But developers already have a lot to worry about. They are continually pushed to develop new features for their employer's products. Asking them to understand the infrastructure, including how to deploy, configure, and monitor their service, may be asking a little too much from them. This is where an SRE steps in.
|
||||
|
||||
When a web application is developed, there are often many people that contribute. There are user interface designers, graphic designers, frontend engineers, backend engineers, and a whole host of other specialties (depending on the technologies used). Requirements include how the code gets managed (e.g., deployed, configured, monitored)—which are the SRE's areas of specialty. But, just as an engineer developing a nice look and feel for an application benefits from knowledge of the backend-engineer's job (e.g., how data is fetched from a database), the SRE understands how the deployment system works and how to adapt it to the specific needs of that particular codebase or project.
|
||||
|
||||
So, an SRE is not just "an ops person who codes." Rather, the SRE is another member of the development team with a different set of skills particularly around deployment, configuration management, monitoring, metrics, etc. But, just as an engineer developing a nice look and feel for an application must know how data is fetched from a data store, an SRE is not singly responsible for these areas. The entire team works together to deliver a product that can be easily updated, managed, and monitored.
|
||||
|
||||
The need for an SRE naturally comes about when a team is implementing DevOps but realizes they are asking too much of the developers and need a specialist for what the ops team used to handle.
|
||||
|
||||
### How the SRE works at a startup
|
||||
|
||||
This is great when there are hundreds of employees (let alone when you are the size of Google or Facebook). Large companies have SRE teams that are split up and embedded into each development team. But a startup doesn't have those economies of scale, and engineers often wear many hats. So, where does the "SRE hat" sit in a small company? One approach is to fully adopt DevOps and have the developers be responsible for the typical tasks an SRE would perform at a larger company. On the other side of the spectrum, you hire specialists — a.k.a., SREs.
|
||||
|
||||
The most obvious advantage of trying to put the SRE hat on a developer's head is it scales well as your team grows. Also, the developer will understand all the quirks of the application. But many startups use a wide variety of SaaS products to power their infrastructure. The most obvious is the infrastructure platform itself. Then you add in metrics systems, site monitoring, log analysis, containers, and more. While these technologies solve some problems, they create an additional complexity cost. The developer would need to understand all those technologies and services in addition to the core technologies (e.g., languages) the application uses. In the end, keeping on top of all of that technology can be overwhelming.
|
||||
|
||||
The other option is to hire a specialist to handle the SRE job. Their responsibility would be to focus on deployment, configuration, monitoring, and metrics, freeing up the developer's time to write the application. The disadvantage is that the SRE would have to split their time between multiple, different applications (i.e., the SRE needs to support the breadth of applications throughout engineering). This likely means they may not have the time to gain any depth of knowledge of any of the applications; however, they would be in a position to see how all the different pieces fit together. This "30,000-foot view" can help prioritize the weak spots to fix in the system as a whole.
|
||||
|
||||
There is one key piece of information I am ignoring: your other engineers. They may have a deep desire to understand how deployment works and how to use the metrics system to the best of their ability. Also, hiring an SRE is not an easy task. You are looking for a mix of sysadmin skills and software engineering skills. (I am specific about software engineers, vs. just "being able to code," because software engineering involves more than just writing code [e.g., writing good tests or documentation].)
|
||||
|
||||
Therefore, in some cases, it may make more sense for the "SRE hat" to live on a developer's head. If so, keep an eye on the amount of complexity in both the code and the infrastructure (SaaS or internal). At some point, the complexity on either end will likely push toward more specialization.
|
||||
|
||||
### Conclusion
|
||||
|
||||
An SRE team is one of the most efficient ways to implement the DevOps paradigm in a startup. I have seen a couple of different approaches, but I believe that hiring a dedicated SRE (pretty early) at your startup will free up time for the developers to focus on their specific challenges. The SRE can focus on improving the tools (and processes) that make the developers more productive. Also, an SRE will focus on making sure your customers have a product that is reliable and secure.
|
||||
|
||||
Craig Sebenik will present [SRE (and DevOps) at a Startup][5] at [LISA18][6], October 29-31 in Nashville, Tennessee.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/sre-startup
|
||||
|
||||
作者：[Craig Sebenik][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/craig5
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://shop.oreilly.com/product/0636920041528.do
|
||||
[2]: https://landing.google.com/sre/interview/ben-treynor.html
|
||||
[3]: https://opensource.com/resources/devops
|
||||
[4]: https://queue.acm.org/detail.cfm?id=1142065
|
||||
[5]: https://www.usenix.org/conference/lisa18/presentation/sebenik
|
||||
[6]: https://www.usenix.org/conference/lisa18
|
||||
@ -0,0 +1,68 @@
|
||||
什么是 SRE？它和 DevOps 是怎么关联的？
|
||||
=====
|
||||
|
||||
大型企业里 SRE 角色比较常见，不过小公司也需要 SRE。
|
||||
|
||||
|
||||
|
||||
虽然站点可靠性工程师（SRE）角色在近几年变得流行起来，但是很多人 —— 甚至是软件行业里的 —— 还不知道 SRE 是什么或者 SRE 都干些什么。为了搞清楚这些问题，这篇文章解释了 SRE 的含义，还有 SRE 怎样关联 DevOps，以及在工程师团队规模不大的组织里 SRE 该如何工作。
|
||||
|
||||
### 什么是站点可靠性工程？
|
||||
|
||||
谷歌的几个工程师写的《 [SRE：谷歌运维解密][1]》被认为是站点可靠性工程的权威书籍。谷歌的工程副总裁 Ben Treynor Sloss 在二十一世纪初[创造了这个术语][2]。他是这样定义的：“当你让软件工程师设计运维功能时，SRE 就产生了。”
|
||||
|
||||
虽然系统管理员从很久之前就在写代码，但是过去的很多时候系统管理团队是手动管理机器的。当时他们管理的机器可能有几十台或者上百台，不过当这个数字涨到了几千甚至几十万的时候，就不能简单的靠人去解决问题了。规模如此大的情况下，很明显应该用代码去管理机器（以及机器上运行的软件）。
|
||||
|
||||
另外，一直到近几年，运维团队和开发团队都还是完全独立的。两个岗位的技能要求也被认为是完全不同的。SRE 的角色想尝试把这两份工作结合起来。
|
||||
|
||||
在深入探讨什么是 SRE 以及 SRE 如何和开发团队协作之前，我们需要先了解一下 SRE 在 DevOps 范例中是怎么工作的。
|
||||
|
||||
### SRE 和 DevOps
|
||||
|
||||
站点可靠性工程的核心，就是对 DevOps 范例的实践。[DevOps 的定义][3]有很多种方式。开发团队（“devs”）和运维（“ops”）团队相互分离的传统模式下，写代码的团队在服务交付给用户使用之后就不再对服务状态负责了。开发团队“把代码扔到墙那边”让运维团队去部署和支持。
|
||||
|
||||
这种情况会导致大量失衡。开发和运维的目标总是不一致 —— 开发希望用户体验到“最新最棒”的代码，但是运维想要的是变更尽量少的稳定系统。运维是这样假定的，任何变更都可能引发不稳定，而不做任何变更的系统可以一直保持稳定。（减少软件的变更次数并不是避免故障的唯一因素，认识到这一点很重要。例如，虽然你的 web 应用保持不变，但是当用户数量涨到十倍时，服务可能就会以各种方式出问题。）
|
||||
|
||||
DevOps 理念认为通过合并这两个岗位就能够消灭争论。如果开发团队时刻都想把新代码部署上线，那么他们也必须对新代码引起的故障负责。就像亚马逊的 [Werner Vogels 说的][4]那样，“谁开发，谁运维”（生产环境）。但是开发人员已经有一大堆问题了。他们不断的被推动着去开发老板要的产品功能。再让他们去了解基础设施，包括如何部署、配置还有监控服务，这对他们的要求有点太多了。所以就需要 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][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[BeliteX](https://github.com/belitex)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/craig5
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://shop.oreilly.com/product/0636920041528.do
|
||||
[2]: https://landing.google.com/sre/interview/ben-treynor.html
|
||||
[3]: https://opensource.com/resources/devops
|
||||
[4]: https://queue.acm.org/detail.cfm?id=1142065
|
||||
[5]: https://www.usenix.org/conference/lisa18/presentation/sebenik
|
||||
[6]: https://www.usenix.org/conference/lisa18
|
||||
Loading…
Reference in New Issue
Block a user