我为什么不应该尝试聘请“ DevOps工程师”？

具有的想法的DevOps工程师已成为颇为流行最近，它似乎呼吁只是有一个人谁可以在插槽，并提供了许多的DevOps的好处，如木偶描述博客：

使用DevOps做法的组织具有很高的功能：根据我们的2015年DevOps状况报告，部署代码的频率是竞争对手的30倍，而失败的部署则减少了50％。

但是，我注意到许多反对DevOps工程师尝试进行以下改进的想法：

即使就DevOps核心属性达成广泛共识，“ DevOps工程师”一词仍引起争议。有人说，该术语本身与DevOps的值相矛盾。持续交付的合著者Jez Humble指出，仅凭称呼一名DevOps工程师就可以在开发人员和操作人员之外创建第三个孤岛-“ ...显然，尝试和解决这些问题的方法很糟糕（具有讽刺意味的） 。”

为什么企业聘用DevOps工程师尝试并“实施DevOps”并不是一个好主意，而不是像这样的博客所提倡的组织变革呢？仅具有独立的DevOps角色是否会抵消好处？

TL; DR：您永远不应尝试雇用DevOps团队

基本上有三种最常见的角色可供雇用：

1. DevOps建筑师/传播者
2. DevOps工程师
3. CI / CD工程师

这些角色不同于传统上构成软件工程组织的6个基本软件开发角色：

1. 产品管理
2. 软件开发
3. 工具开发
4. 安全与合规
5. 质量与测试
6. 系统操作（SRE）

让我们一一介绍这三个角色，看看它们的适合性

DevOps架构师或传播者

• 原因：如果您迷路，缓慢，精神崩溃，不知道该怎么办。
• 时间：在计划阶段的流程开始时。
• 什么：管理水平的作用，引导所有的管理人员和潜在客户在整个软件工程组织。此人将规划您的工程组织向高功能状态的整个转变。
• 谁：精通理论，管理实践，文化主题和运营的咨询成员，直接向软件工程副总裁报告。

在某些情况下，对于中小型公司，您可以选择雇用DORA等咨询组织来开始这一过程。

DevOps工程师

• 为什么：
  1. 如果团队是按照上述职能角色组织的，则可以弥合团队之间的差距，以确保跨职能级别的合作。
  2. 与面向产品的团队一起工作，该团队具有团队中包括的6个传统角色中的每一个，以帮助弥合知识差距并帮助实施和采用新颖的实践和工具。
• 时间：制定计划并开始组织转型，整个管理团队都将加入。
• 内容：启用跨职能合作，确保打破团队边界，确保团队内部的局部优化不会对从客户希望到客户交付的整个价值链的高工作量造成障碍。
• 谁：经验丰富的工程师，具有软件开发和系统操作方面的技能。他应该精通与DevOps转换相关的最佳实践，流程和文化变化。

CI / CD工程师

• 原因：为了帮助实现CI / CD管道，请集成您的工具链，并引入可以使公司更好地运转的工具。
• 时间：在大型组织的过渡期间，上述职位已经填补。
• 什么：工程师，基本上是工具团队的一部分，能够建立CI / CD管道并开始集成内部系统，从而消除工作量中的摩擦。
• 谁：工程师具有工具，集成过程，版本管理和DevOps实践的经验。知道他们正在用自动化代替发布过程中的人为控制的人。

我认为您的问题链接中所述的Devops工程师主要是系统管理员角色。在此引用技能作为该答案的背景：

您的攀岩装备。

• 具有使用Puppet，Chef或同等软件进行自动化/配置管理的Linux / Unix管理经验的丰富背景
• 能够使用各种开源技术和云服务（需要具有AWS经验）
• 具有丰富的SQL和MySQL经验（也具有NoSQL经验，因为我们也使用Redis）
• 对代码和脚本（PHP，Python，Perl和/或Ruby）有一定的了解
• 始终可用，始终可用的服务中的最佳实践和IT操作知识

在此示例职位描述中，DevOps Engineer只是一个时髦的词汇，它表示系统管理员熟悉基于云的基础架构，自动化，能够读取代码以帮助进行诊断以及了解高可用性实践和解决方案。

如问题所示，这与DevOps的实践以及开发人员和操作人员之间的孤岛破坏文化之间存在松散的关系。Sysadmin和DevOps Engineer之间有什么区别？

这不是一个好主意，因为系统管理员（他/她对devop的实践和文化有多舒服）不是驱动公司转型的合适人选。您不会因为文化的改变而雇用此人，而是拥有工具配置视图，这实际上并不会帮助您打破流程。他/她的同事也可能对此很不满意，如果事先没有计划的文化变革，您只会对变革产生抵触

对于成功获得开发人员收益的模式，@ Jiri Klouda的答案很好地概述了可接受的DevOps工程师角色以及将带来价值并有助于成功的变革步骤。

我知道这个答案可能不适合您，但这就是我所做的

我是第一个在非常繁忙的电子商务初创公司工作的开发人员，流量非常高。我意识到公司还很年轻，而且在一段时间内，我将是唯一的内部技术资源。

知道这一点后，我决定以某种方式来构建我的基础架构，以便我必须进行零系统管理。

我决定托管在云中，因为这样做减轻了系统维护的麻烦。我寻找了一名具有木偶经验的AWS工程师。我们共同构建了一个可伸缩的基础架构，以cloudformation的代码形式编写。所有配置文件都在puppet中进行了版本控制。

作为开发人员，这使我能够担任这个开发人员的角色。我用python，fabric构建了代码发布工具。我使用相同的脚本将应用程序引导到自动缩放的新服务器上。

这非常有效，三年后的今天，我仍然不进行任何系统维护。我们有一名系统管理员（同一位AWS工程师），每个月工作10个小时，我试图以这种方式构造他的sprint，以免对他造成困扰。这样，我尊重他的时间，并尽我所能管理他的冲刺。

如果一个系统的性能下降了，我就直接终止它，然后再换一个。

我希望这个答案可以使您受益

您不应该聘请DevOps工程师，因为DevOps涉及的学科非常广泛，以至于一个人不可能成为这些学科的所有方面的专家。通过雇用所有行业的杰克，您将雇用一个无所不包的大师。

DevOps一定是基于团队的工作，您不可能期望一个人能够支持整个团队的期望。考虑DevOps的范围。一个人不可能：

• 成为[语言]的摇滚明星开发者
• 成为网络专家，了解所有必需的RFC
• 成为系统管理员
• 成为质量检查专家
• 成为数据库管理员
• 专门从事存储和备份
• 了解站点可靠性工程
• 可能还有其他学科

上面的一些甚至有子学科，例如Windows Systems Admin vs. Linux / Unix System admin，或者您可能使用了不止一种编码语言。

任何人都不可能是这方面的专家，这意味着如果您要招聘DevOps工程师，那么当DevOps团队中最弱的领域是Networking时，您就不能很好地宣传您对网络专家的需求为您的DevOps 团队服务。尽管任何人都不应成为DevOps团队中的特定角色，但您会假装在DevOps范围内没有专家或主题专家（SME），这会对您的团队造成损害。从一个极端到另一个极端（从孤立到伪装，就像DevOps团队中的每个角色一样），都可能引起很多问题。

虽然让团队成员接受不止一个学科的交叉训练是一件好事，尤其是在重叠的领域，但期望他们能够精通如此广泛的知识根本不是实践。

这意味着任何告诉您他们了解DevOps各个方面的人都可能在骗您。聘请您在DevOps团队工作最薄弱的领域的专家-不是“ DevOps工程师”。

在ASOS实施时，我遇到了确切的挑战。我们的目标是拥有一支自给自足的团队，因此发挥敬业精神可能会成为一种反模式。但是，我们生活在现实世界中，对于许多开发人员而言，考虑良好的DevOps实践并不是他们的首要任务，因此他们需要帮助到达那里。

我们所做的是：

• 失去了DevOps工程师的任期，DevOps是我们所有人都应该做的事情，而不是我们的职称，因此我们给他们起了不同的称呼。

• 将它们分发给团队，但每3个中只有1个，这意味着他们不能做事，但必须被视为帮助团队变得更好并解决自己的问题的能力（在指导下）

• 保持中心职能以及充当能力中心并处理企业考虑事项，所有影响所有团队的因素

随着我们的发展，我们会审查此模型，但到目前为止，它对我们有效

我认为您将无法获得明确的答案，因为似乎很多因素都在其中。

• 公司在DevOps实践中的表现如何
• 公司提供什么样的应用程序或服务
• 您公司的结构

我刚刚完成面试职位，最后获得了DevOps工程师的头衔，但是我正在做的一些工作是Sys Admin。由于公司的规模以及在应用程序方面明智地进行管理的性质，这完全没有必要。我面试过的一些职位具有相似的头衔，他们正在寻找更多来自事物发展方面经验丰富的人。他们期望更多的代码编写，而不是自动化的系统管理员。SRE似乎是一个越来越受欢迎的称号，所以这可能是一条路。我的上一份工作是系统管理员和自动化工程师，因为我有时会写Ansible和Chef Stacks。该公司遵循的是非常好的devops模式，每个人都参与其中，而devs与ops一起工作，但我认为他们的未来没有

现在我处于这个位置，我正在尝试以某种自动化的方式来解决这个问题，我们将不得不解决一些人员问题。人们来来去去，之所以设计某些工作流，是因为其他人是这样设计的，而不是因为它适合人们的工作方式。

因此，基本上，我认为您应该弄清楚职位描述，而不必太担心标题，除非标题以某种方式捆绑在一起，或者您认为一个或另一个会吸引合适的人。

如果您关心DevOps的含义，请遵循“一条真实的道路”。您不应该聘请DevOps工程师。您应该聘请一名自动化工程师，一名部署工程师，或平台架构师或执行您需要的其他角色。

如果真正的DevOps从业人员对您并不重要，那么您可以随便叫它。