扩展S[a-z]{3，}可靠性工程师角色。

我的一次基础学习经历发生在2014年，当时我设计并推出了优步的原创产品Site Reliability Engineering role和组织。如果我能倒带再试一次，我会做出一些不同的决定，但在回顾倒带的记忆时，我最自豪的是。

人们偶尔会问我关于在他们公司引入SRE的建议，我会给他们一个他们没有想到的答案：不要。一个词的版本会遇到比我想象的更具争议性的问题。我喜欢定义好的SRE组织的方法，也喜欢与我共事过的SRE，但我相信行业对这个角色的先入为主的观念已经足够混乱，以至于这个词实际上是没有帮助的。

To grow a team using best SRE practices, skip the label “SRE.”

标签填料

在寻找标签填充的惊人例子时，很难找到比它更好的Long Island Ice Tea Corp renaming to Long Blockchain Corp. 改名前是一家冰茶公司，改名后是一家冰茶公司，只是一家冰队公司really希望被视为区块链公司。到目前为止，只有SEC很重视这一区别.

一些工程组织也采取了类似的策略，将其系统管理组重命名为SREs。而这些更名大多是本着诚意和遵循好书经, many of them don’t nail that transition. Perhaps a small subset are these rebrands are truly cynical, hoping to improve their hiring fortunes without changing practices, but my sense is that the vast majority are well-meaning folks struggling to land a difficult cultural transition.

区别重要吗？

这种标签填充很重要，因为这两种工作方式是不兼容的，并且在串联应用时会创建一个功能失调或无效的组织，系统管理和SRE组织之间的两个关键区别是它们是如何工作的(1)handle ownership and(2)创造杠杆效应。

管理组分割所有权，这样常规工作流就跨越了他们和他们的同级开发组之间的组织边界：您编写代码，我将部署和操作代码。SRE组以确保通用工作流不会跨越组织边界的方式划分所有权：我将构建部署平台，您将使用它进行部署。

These approaches to dividing ownership also impact how they create leverage for the organization they support. In most system administration organizations, the fundamental unit of progress is工作时间. 这与我共事过的软件工程和SRE团队不同，他们的基本进展单元是working software.

当我加入Uber时，服务是通过一系列高度耦合的Puppet提交和部署来手动配置的。当我离开时，服务是通过输入服务名称、单击按钮并等待30秒来配置的。再多的人力努力也无法满足日益增长的业务对服务供应的需求，尽管我们当然可以做到继续努力，把自己累坏了.

“面试就过滤一下！”

有些人会同意这样一个前提，即SRE标签已经变得过于宽泛，但他们建议，可以很容易地改进您的招聘流程，以筛选您的组织更喜欢的方法。

总的来说，这似乎是一个显而易见的方法，但我发现标签填充对面试循环本身施加了持续的、令人筋疲力尽的压力。人们感到沮丧的是，这个循环过滤了我们伟大的SRE，他们曾经在另一家公司的SRE组织中非常成功，这成为你的SRE循环有缺陷的证据。

有了一个非常清晰的愿景，你希望SRE如何在你的公司运作，你可以防止评估的侵蚀，但为什么要花你的一生去做，当你可以完全跳过标签上混乱的成见？

描述性团队

我的方法在过去的几年中,世界卫生大会t I recommend to others is to drop the SRE label entirely and hire software engineers. Do you abandon all hope of hiring folks with SRE expertise?

不！将专业化转移到团队的任务中，而不是角色的标签中。例如，创建一个负责可靠性的团队或组，并将该团队称为弹性团队或可靠性团队。招聘软件工程师加入该团队以提高可靠性，并雇佣那些你认为会使你的团队成功的人，包括那些曾经在成功的SRE组织工作过的人。

但是入境通道…

The last concern I’ll hear from folks is that if they don’t use a frequent search term like SRE, they’ll miss out on folks who would only apply to an SRE role. My experience is that by posting a specific team job description, you’re freeing up time spent filtering to invest into sourcing and growing your organization’s public SRE brand.

我很容易想象一个组织会发现“仅仅开启SRE”就可以显著提高招聘效率，但我的经验是，从你的长期目标来看，这更像是一种洗礼，你的长期目标是雇佣那些在你的组织内取得成功并与你的团队方法保持一致的人。

---

Summing it all together, I’m not against anyone using the label SRE, I just think it’s more effective to avoid at this point in the spincycle. If it’s working really well for you, then by all means keep using it. As for me, I’ll be over here writing more specific team descriptions.