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/
评论