杀死“DevOps团队”

DevOps团队的持续存在为那些懒惰、不诚实且被误导的人在IT流行词的庇护下假装做出积极的改变提供了机会。

在一个充斥着流行语的企业里，人们通常会说：

• 我们有敏捷吗？看，我们计划好了后三个月的sprint！
• 我们有Kubernetes策略吗？看，只要再给我们一个月，就可以让它上生产。
• 我们有DevOps吗？看，我们招了很多DevOps工程师，他们在各自的团队里负责编写YAML文件、运行Ansible脚本。

DevOps团队是一个非常常见的反模式，为了让高层相信他们正处在流行技术的最前沿，采用了一些让人迷惑的术语，但实际上，这些角色的职责和文化与几十年前并没有什么两样。

如果你的公司里有“DevOps”团队，那么可以肯定的是，你们所做的并不是DevOps，甚至很可能完全相反。

真正的DevOps

现在，我可以告诉大家，我的一些非常好的朋友就是DevOps工程师，真的！

我们先来定义一下真正的DevOps：

你来开发，让它跑起来，然后它在凌晨4点把你吵醒。

所以，当HR把没有做过开发的“DevOps工程师”的简历塞给我时，我会觉得很荒谬。朋友，不要再这么做了。

有关DevOps更准确的定义或许是：

DevOps是指让一个跨功能团队负责应用程序或服务的整个生命周期，从创建到运维和支持。

我们先来看一下DevOps都有哪些好处。

DevOps会让哪些东西变得更好

真正的DevOps会带来更高的效率，缩短产品的上市时间，并提升产品的质量，原因如下。

开发软件和负责软件运行的人是同一波人，他们对软件的质量和可维护性要求得更为严格，因为在软件发生故障时，他们有可能在凌晨4点被叫醒。

除此之外，他们就像是一种“共同体”，关注彼此的问题。

他们之间不存在沟通边界，降低了变更成本。沟通边界会带来延迟（比如出现问题了要提ticket，等待另一个团队来修复问题），而他们之间的沟通却是同步且及时的。

在写这篇文章的时候，一位工程师向我抱怨说，一个客户的REST应用程序要求使用加密数据才能执行操作，否则就报错。为了生成这些加密数据，需要先运行其他应用程序，并调用一个特殊的端点。因此，需要有人负责部署这个应用程序，并监控它的运行情况，在发生问题时调用端点，用加密的数据重新配置应用程序，然后重启。12 Factors并没有明确指出这个用例，但我非常确定的是，如果应用程序开发人员就是部署应用程序的人，那么他们可能已经找到了一个更加自动化的解决方案。

NotDevOps

在你们所处的组织里，是否看到过以下这些NotDevOps迹象？

• 有一个叫作“DevOps”的团队；
• 有一个叫作“DevOps工程师”的岗位；
• “DevOps”团队不负责开发应用程序；
• 就算软件系统在凌晨4点出了问题，开发团队也不需要做什么；
• 开发团队需要通过“DevOps”团队来帮他们处理问题。

如果你们的组织里有以上这些迹象，那么不好意思：你们做的是NotDevOps！不过好在不是只有你们在这么做，因为还有很多公司也在招聘“DevOps工程师”。

在以前，我们管这些人叫系统管理员或配置管理员。他们懂Linux，负责把开发人员的代码部署到生产环境。而在今天，如果你是一个懂Puppet/Chef/Salt/Ansible/kubectl的系统管理员，那么恭喜，你就是一个DevOps工程师，而且你的薪水会涨个50%。

正如之前所说的，开发人员不需要让其他人帮他们做这些事情：

• 创建CI管道/Jenkins作业；
• 创建Git仓库；
• 把代码打包成Docker镜像；
• 把代码部署到某个运行环境中；
• 从运行的实例里获取日志。

如果开发人员需要让其他人帮他们做这些事情，那就是NotDevOps！

如果是这样的话，你的雇主就无法从中获得任何好处。他们认为你们在做很酷的事情，但实际上你们在对他们“说谎”。

NotDevOps比没有DevOps更糟糕——你给雇主制造了盲点，用各种好听的术语毁坏了那些做对了事情的人的声誉。

经常有企业向我们咨询如何能够更快地交付价值。交付价值的一个最常见的障碍是低下的流动效率，也就是说，更多的时间会被浪费在等待上，而开发活动和运维活动相分离是造成这种等待的最主要原因。

那么，DevOps团队必须死吗？

当然不是。

我们要做的是把“DevOps”团队这个名字去掉，不要再管他们叫“DevOps”团队了。

我们不要再假装在做一些很酷的事情，而应该让人们真打实干。

如果这个做不到，最起码不要自欺欺人，或者“欺骗”那些付你薪水的人。

如果已经有了这样的团队，该怎么办？

那就让这样的团队通过构建自动化工具的方式为开发人员提供自助服务。

DevOps团队不应该参与事务性的业务工作，但可以构建内部工具，为开发人员提供自助服务。通过这种方式，DevOps团队为开发人员实现了真正的DevOps，为他们提供了运维应用程序所需的工具：日志、指标、生命周期控制，等等。

DevOps团队不应该只是为开发人员做一次性的工作，他们需要持续不断地收集开发人员的需求，把它们加入到产品待办列表中，然后逐个完成这些事项，为开发人员提供自动化的可重用解决方案，帮助开发人员更好地完成任务。他们要做的是长期的产品，而不只是满足临时性的需求。

我们把这样的DevOps团队叫作平台团队。尽管我也知道，在我们的行业，像“平台”、“服务”之类的术语所表达的意义正在被淡化。

如果你有一个DevOps团队，他们所做的事情都是正确的，那为什么要管他们叫“DevOps”团队，而不是根据他们所做的产品来命名呢？

做正确的事

让我们避开嘈杂的流行语世界，静下心来仔细理解这些术语的真正含义。如果企业不想办法减少浪费在等待上的时间和降低产品的上市时间，那么再昂贵的DevOps工程师也无法改进他们的价值交付过程。

与此同时，我们是不是应该叫停滥用术语的“恶习”？是不是不要再自欺欺人，总认为自己在做有意义的事情，但实际上并没有？

原文链接： https://www.engineerbetter.com/blog/kill-the-devops-team/