神话中的DevOps工程师

我总是对寻找所谓的DevOps工程师角色的工作说明书持怀疑态度。他们经常提到各种各样的职责和责任。

头衔中有DevOps的角色几乎没有相同的含义。不过，他们经常有一些共同之处。他们试图掩盖传统上不同专业人士的专业化。

不要误会我的意思：跨职能的专业知识绝对很重要。但我不认为DevOps意味着用单一的角色取代多种专业化。不同的专业，如运营、安全、测试、开发、产品管理等，范围很广，需要特定的知识。

我认为成功的DevOps组织的关键不同之处在于它们能够实现有效的协作。他们的目标和北极星一样明确，那就是为最终用户提供价值。

总体而言，我认为我们不应该谈论DevOps工程师，而应该谈论组织中的DevOps文化。

DevOps是一种高度浓缩的方式，指的是旨在缩短软件开发生命周期、增加反馈机会并促进持续改进和试验的实践组合。

-Alessandro Diaferia(@alediaferia)2020年7月4日。

DevOps组织激励不同的专业进行协作。Dev(对系统进行更改)和Ops(希望保持系统稳定)之间存在的内在紧张关系消失了。现在更大的好处是价值流。

不提供任何功能的稳定系统与不断提供新功能的不稳定系统一样毫无用处。

Dev和Ops明白合作最大限度地提高这一流量的重要性，以找出哪些赌注成功，哪些没有成功。

接受DevOps思维模式的组织在试验新功能方面可能比竞争对手更有效。他们快速验证他们的假设，通过翻转仪表板上的开关来激活和停用功能。

总体而言，我认为不应该只有一个DevOps角色，而应该是一组有效协作的特定专业。

然而，这种对术语的理想看法有时可能会与就业市场的现实发生冲突。愿意吸引拥有最新技能的最优秀人才的公司，最终可能会为那些在DevOps原则下适得其反的职位做广告。

让我们通读一下我在野外发现的工作说明书中的几个摘录。

[…]。DevOps工程师是与软件开发人员、系统操作员和其他IT员工协作管理代码发布的IT专业人员。他们跨越和合并软件开发、测试和运营团队之间存在的障碍，并在设计、规划和测试时牢记现有网络。负责多任务并同时处理多个紧急情况的DevOps工程师必须极其灵活。[…]。

互联网上的职位说明书

这是组织认为应该将DevOps原则委托给单个团队的经典示例之一。

规范中提到了公司中DevOps工程师的职责繁多。DevOps工程师应该“同时处理多项任务和处理多个紧急情况”。因此，他们“必须非常灵活”。

可以肯定的是，同时处理多项任务和处理多个紧急情况在任何地方都可能发生：我认为这不应该是组织中一个角色的特点。相反，健康的环境使每个工程师都能处理紧急情况并从中吸取教训。

遇到这个角色，我会认为该组织并没有真正尝试采用DevOps实践。他们不是鼓励人们协作和改进，而是建立一个专门的团队来处理问题和紧急情况。

DevOps工程师将对工程和编码的理解结合在一起。DevOps工程师与各个部门合作，在公司内部创建和开发系统。从创建和实施软件系统到分析数据以改进现有系统，DevOps工程师可以提高工作场所的工作效率。

互联网上的另一份工作说明书。

在DevOps组织中，工程师与各个部门一起工作。但是，拥有一个专门的DevOps工程师角色又有什么意义呢？其他类型的工程师不是与组织的各个部门一起工作吗？非DevOps工程师不分析数据并改进现有系统吗？此外，工作说明书还声称，DevOps工程师可以提高工作场所的工作效率。多么?。它能提高生产力吗？

一名DevOps工程师与开发人员和IT人员一起监督代码发布。[…]。最终，您将快速、准确和安全地执行和自动化运营流程。

到目前为止我最喜欢的。

这是一个相当浓缩的问题，但其中提到的发布方面给我留下了特别有趣的印象。

我倾向于将部署的概念与发布的概念分开。用户体验由版本策略管理的产品更新，该版本策略可能与展开策略相同，也可能不同。这确实取决于组织的战略。

不过，不管这种区别如何，我认为将向最终用户交付价值的能力限制为特定角色会破坏组织的敏捷性。

团队应该能够持续地将代码发布到生产中。诸如功能标志之类的机制应该控制功能的发布。这意味着产品中的代码在部署时不一定会激活，从而使组织能够控制功能何时真正到达用户手中。

一般来说，部署应该是非事件的：没什么特别的，只是又一次合并到主分支中，导致代码最终进入生产环境。

在像我们生活的这样一个快节奏的世界里，组织不应该通过要求专门的工程师发布新功能来约束自己。现代环境要求公司始终进行试验。组织应该授权非技术团队运行实验、分析数据并自主决定何时发布新功能。理想情况下，所有这些都不需要特定工程师的特别干预。

像这样的工作规格给人的感觉就像是他们试图通过改变几句话来重新定位发布经理的角色，以跟上最新的趋势。

我不认为在DevOps组织中发布管理会消失。相反，发布管理变成了确保组织的其余部分可以自主发布。实现这一目标意味着投资于整个公司的自动化和内部工具。

DevOps工程师将成为实现跨职能协作并推动CI/CD转换的成型流程和工具的主要领导者。DevOps工程师将与产品所有者、开发人员和外部开发团队密切合作，构建和配置可供其他产品团队使用的高性能、可扩展的基于云的平台。

这是我见过的最好的工作规格。它描述了一组通常与平台或基础架构团队相关的职责。由于时尚的原因，这些团队中的大多数经常更名为DevOps Team，他们的成员也成为DevOps工程师。

平台工程团队是希望采用DevOps原则的组织的关键推动者。但是，认为它们只与一个特定的团队有关，很难导致一次成功的旅程。

这个团队肯定会负责构建相关的基础设施，使其他团队能够在上面构建，但在理解和应用这些原则方面，他们不能独善其身。

开发团队将需要自主地采用和更改这些系统；他们将需要了解他们的代码在生产中运行的含义；了解如何识别系统是否没有按预期运行，并能够采取行动恢复它。

同样，产品团队应该花时间了解采用DevOps实践带来的新的重要功能。代码在功能标志、集装箱化技术、改进的监控和警报等背后源源不断地流入生产，打开了无穷无尽的机会。

例如，改进的用户体验和实验机会是保持竞争力的重要资产。

我们刚刚检查了一些工作规格，寻找DevOps工程师角色的变体，我已经概述了我认为这些角色有哪些方面存在缺陷。那么，公司应该寻找什么呢？

在盲目地开始招聘受行业时尚趋势驱动的职位之前，组织应该投资于了解是什么阻碍了他们成为开发运营人员。

在“独角兽项目”中，Gene Kim提到了成功的DevOps组织的五个理想。我认为它们是一套有效的原则，可以从DevOps实践的角度衡量您的组织的温度。这些理想是：

为了向最终用户提供更大的价值，对系统进行更改应该很容易：就团队对产品进行更改的自主性而言很容易，在使用中的技术对更改施加的摩擦方面也很容易。

开发人员应该能够专注于他们的工作，并且能够以最小的障碍开发软件。这是通过确保软件开发生命周期基础设施为工程组织的利益而工作来促进的。

不断学习和改善工作条件，是最大限度地提高工作人员的价值流动和幸福感的关键。成功的组织通过使工程师能够构建工具和实践来增强他们的日常运营，从而促进不断改善的环境。

如果一个组织的成员没有提出问题和解决问题的动力，那么该组织就很难改进。这不是通过雇佣一个特定的角色就能解决的问题。组织有责任促进一个建设性反馈成为常态的环境。

最后但并非最不重要的一点是，工程组织，就像公司的其他部门一样，应该以客户为中心。所有的努力都应该与对客户和最终对公司最有利的东西相平衡。

那么，公司应该寻找什么呢？我认为当务之急应该是了解是什么阻碍了他们在所有部门完全接受DevOps心态。大多数时候，你会意识到你需要的一套技能已经在你身边了。阻碍你前进的可能是你公司目前完成工作的一套流程。

感觉DevOps工程师是某些组织追求的一个虚构人物，他们希望找到能够做任何事情的软件工程师的圣杯。

当然，情况几乎不会是这样。认识到单一专业化的重要性是使组织成功并能够最大限度地发挥其组成人员的专业知识的原因。

在DevOps组织中发生的事情是职责被重新分配：开发人员被授权对生产环境进行更改，因为组织认识到快速移动的重要性。这意味着成功的机会与失败的机会一起增加。

消除障碍并创建安全的协作空间有助于开发人员和运营人员在出现问题时携手解决问题。这就是最终导致高绩效团队的原因，这些团队受到激励，遵循持续价值流的北极星到达最终用户。

当然，在技术、工具和最佳实践方面需要特定的DevOps知识，但这不是单个角色应该负责的事情。

那么，与其追求一个虚构的角色，不如让我们去寻找一种更合理的选择，即创造一台润滑良好的机器，在这种机器上，所有人都得到激励，以和谐的方式共同工作，明确的目标是为最终用户实现价值最大化。

感谢您读完这篇文章。我真诚地希望你喜欢它。如果你想了解我所有的文章和我工作的软件，请在Twitter上关注我。