DevOps是时候退场了

DevOps

notes：文章洗了一下 版权正在申请 实在不行就用洗稿版本。

摘要：

为什么DevOps和自动化没有解决软件开发的核心问题？Michael Duffy给出了他的看法和解决方案。

作者： Michael Duffy

正文：

DevOps的出现是颠覆性的：软件团队可以快速开发、部署或更新软件产品，避免了长久以来在产品、开发和运维团队间的内耗。Michael Duffy认为，DevOps传播了自动化、运行监控和软件设计工具，带动了虚拟化和容器化的使用，为敏捷开发带来了巨大的改革。然而，Michael Duffy呼吁，

是时候杀死DevOps了。

Michael Duffy表示，这句话不是说要回归传统的软件开发模式：但是DevOps不应该成为独立的工种。

Michael Duffy指出，使用工作方式命名工种是可笑的：没有公司会创造一个叫“敏捷”的工种。DevOps同理：即使给工种加个“工程师”的后缀，也是换汤不换药。

在大企业中，一切照旧：还是存在一个“看门狗”的角色，只不过有了DevOps后，这些人联系起来更简便。开发团队变成了一个个独立王国，争抢发布资源：只是效率提升了一些。

开发人员之间的摩擦变成了开发团队间的摩擦：传统上开发和运行团队间的冲突挪到了团队内部。CTO有可能想裁掉运维团队：既然DevOps的Ops代表运维，那么为什么还要养这样一群人？

Michael Duffy认为，DevOps的弊端在于所有人都是全才，在设计整个顶层结构时，因为公司缺乏在架构方面有经验的人才，公司发展到一定程度就会出乱子。作者表示，各个团队都因为“让全才做专才的事情”而受害不浅。

为什么会这样？Michael Duffy发现，企业一向认为，开发者直接发布代码的行为过于危险，必须有人监督。然而这个问题在现代软件开发流程中已经得到了良好的解决。那么自动化和DevOps为什么没解决软件开发的核心问题？

如果一切按流程操作，任何软件的开发大体如此：分析师规划架构，架构师进行审核，开发者写业务和测试代码并添加监控，交给测试者检查，在通过所有测试环境后，发布代码。如果要加入新功能，开发者检出一个新分支，写代码，发Pull Request，审核并合并代码，重新发布。任何人都可以检出分支并要求合并新代码，如果代码没问题就可以合并，有问题则打回修改，不能合并则说明原因。

那么为什么有些人觉得需要等待DevOps团队发布代码？Michael Duffy把原因归结于以下两点：

一是大部分团队其实没有使用自动化流程。他们抓来个DevOps工程师，或者干脆创建个DevOps团队，装作很新潮的样子，然后继续跑老流程。很多事情没有或者不能自动化进行，例如修改DNS记录或网络架构等。虽然技术上这些事情都可以自动化，但是需要走官僚流程，整个流程还是阻塞的。

二是开发者都很心急。谁不想马上把代码发布出去？任何一点耽搁都会让开发者气愤无比。开发者不知道的是，DevOps为他们挡下了很多杂务：由于企业运行、安全、内部政治和审计需要，申请新资源远不是去AWS控制台点点鼠标开几台机器那么简单。

或者，有可能整个流程被某个部分耽搁了。例如，某个功能已经开发完毕，但是需要等待其他功能才能发布。解决方法不外乎将所有相关人员都拉来参会讨论。

如何更有效率的开发软件？Michael Duffy给出了两个建议：

1. 只有开发一职，不分什么“DevOps”、“测试” 或其他职务。职称应按工作范围分类，例如“架构工程师”、“应用工程师”、“测试工程师”等。
2. 只用推送新代码的方式修改架构，所有人拥有所有代码库的权限。

第一条可以拉平开发者的区别，没有岗位之分，只有不同的专长。团队内所有人的管理标准一致。如果有人阻碍了架构的开发，算作分工失误：所有有可能成为其他项目阻碍的功能都必须预先和架构计划好。讨论过程应简单明了。

第二条比较有挑战，整个企业的所有变更都由代码进行。DNS修改？修改代码。需要储存空间？修改代码。开新用户？修改代码。以此类推。

因为，如果一切都可以自动化，那么为什么不能让开发者发送Pull Request？如果有问题，所有的请求都可以修改。所有的公司资源也可以抽象成代码。这样整个公司会向自动化发展，所有人都对情况有明确的认识。

作者呼吁，保留DevOps的习惯，但取消DevOps这个工种，因为公司里所有人都是开发者，只不过专长不同。

查看英文原文：We Need To Kill DevOps