[关闭]
@cnbeining 2018-04-03T05:05:46.000000Z 字数 1819 阅读 46

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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注