说到DevOps，很多人会把开发和运维联系在一起，更准确一点其实就是开发运营的组合。

最近在发布关于DevOps的文章时，发现了一个很有趣的现象：在国外，很多博主都纷纷指责“DevOps”运动，越是受欢迎，他们就越是讨厌，甚至排斥。

简单的总结一下DevOps让其讨厌的原因：

1. 没有时间专心写代码

2. 强迫开发人员进入一个庞大的知识领域（这里指就是需要成为一名“全栈”开发者）

3. 压力大，任务重，不堪重负

事实是否这样呢？其实不然。无论任何事物，存在即合理。再说哪个公司都不会蠢到让一个只会写代码的开发者去做QA，系统管理员或者DBA，所以我认为不能归到“DevOps”里面去。引用DevOps拥护者Jeff Roth的一句话，“专业知识、协作关系与知识共享之间需要找到合适的平衡点，只有这样才能人尽其才、物尽其用。”

以上是对近期发布的一篇“DevOps是如何伤害一个开发者的”文章不同的理解。下面综合对IBMRational中国区技术总监孙昕的采访谈谈我对DevOps的一些理解，欢迎提出意见，拍砖。

敏捷开发

在刚了解DevOps不久的时候，我很自然的把它和敏捷开发联系在一起，认为它们是集合的关系。在有机会和孙老师聊的时候，他并不认为完全这样，说是集合关系是不完全准确的，不过DevOps可以让敏捷开发做的更好。

怎么理解这句话呢，先说说下敏捷开发，了解敏捷的人都知道现在做最多，也是做最好的是Scrum，这是个流派。当整个团队在做到一定的规模后，这时是非常依赖工具的。（因为实施敏捷的时候不完全保证所有人员都能够在一个地方，像那种大规模敏捷的时候，不可能把所有的人都搁置在一个小屋子里面，天天开各种会议。像比较厉害的scrumsof scrums，我是这么理解的）。

这里有个问题哈，当Scrum在很大的程度上依赖工具的时候，其实很多问题就出来了。大家都知道Scrum是一个迭代的过程，需要很多周期的迭代，不可能一次就搞定（那就不是Scrum了）。在这个迭代的过程，需要做沟通，做协调，做测试，做部署，发布等等，那么这些事情单单通过工具是否能够完成呢？我觉得很困难。这个时候DevOps在这里能够起到什么作用呢？回到刚才的观点–加速敏捷的进展。因为DevOps可以利用云技术，自动化部署，自动化发布等技术。特别是测试，当敏捷做到一定规模时候，需要跨部门，开发人员可能会很主动，有啥新功能要加进去，运维就不干了，很可能就会说you can you up！

其实这个是能够理解的，开发人员把一个软件版本丢给运维人员后，其就会拿该版本产品开始准备将部署上线。这时有个问题出来了，他们需要修改配置文件来适应与开发环境大不相同的真实生产环境。一般情况来说他们是在重复之前在环境中已完成的部署工作；一旦出了问题，他们很可能引入新的漏洞。

这就是他们所担心的问题，如果不反复的测试，运维人员肯定不会上线。所以，DevOps的理念正好解决了这个问题，但这仅仅是DevOps很小的一部分。如果再把敏捷往前推，业务管理，生命周期管理，监控管理等等，需要扩张更大的时候，很大程度上都会依赖DevOps。两者之间的关系就是，DevOps可以驱动敏捷加速周期，敏捷也能在某种意义上推广DevOps。

传统软件工程

大家都应该知道传统的软件工程就是从需求-发布-测试这个过程，也就是只停留在研发这条工具生产线上，所以我们看到的软件工程链条还是比较短的。DevOps概念出来了以后大家慢慢的发现，软件工程现在前端部分已经慢慢全新的领域，前端+传统软件工程+后端，无形的产生了一条很大的产业链，这就是我们现在说的一个全新的软件工程。（PS：据我了解，现在很多企业都在招聘 软件工程（DevOps方向）的岗位，很有趣。）

在软件工程的前端方面，也可以称为业务端吧，比如做业务规划。那么产业链的后端负责什么呢？在和孙昕老师聊天的时候他强调的PRE（全称应该是ProductLine Engineer）产品线工程。孙老师还举例说，“像华为等等一些大的企业，它们不仅仅是在做软件，它们所有的嵌入式软件，机械设计，电气设计，软件设计的时候，这些大产品线的本身，其实就是受到很好的工程化管理，从规划到实现，软件在这个部分其实已经占据非常重要的地位，你可以看到PRE当中非常强调的就是后端”。

所以在整个软件的大框架下如何去支撑这些产品线的规划？这时候反过头来看看传统的软件工程其实只是其中的一个环节，其实就是现在的业务需求越来越往前推了。这里也包含了传统领域的产品管理，也就是大家常说的项目管理，还有企业架构，信息架构，数据架构，流程整合。当知道你要做的哪些决策，投入到哪些大的IT项目，然后往你的业务部门，往你的终端用户推了以后，把这些规划好了以后需求就可以变成改软件的实现，软件才会有意义，这样才能获取你的需求来支持你的业务目标。

孙老师在录一段video的时候，讲到中国食品安全时与整个大的产业链是密不可分的，“当在做食品管理的时候，我们都在聚焦生产，比如造奶粉要看厂房有没有无菌室，实际上食品安全管理的范畴已经从原来扩展的很大，原材料、运输过程、加工过程等是一个很大的产业链，仅仅管理一段是管不好的，其实软件工程也一样，我们认为将来你的软件跟你的运维密不可分，频度越快，运维甩过来就会有问题。”

所以，从纯粹的软件开发上升到业务规划，发布部署，还有上线的整个监控，其实就是这样，不管你认为是概念也好，在整个过程中你是无法离开这个产业链的。软件工程现在前端部分已经慢慢的涉及到了业务端，传统的只是在研发这条工具的生产线上。

新角色的催生

目前来看我个人觉得是很难结合的，从前面谈的业务线来看就很难。如果要改版一个传统的组织架构其实就是一个组织变革的问题，这个跟DevOps没有关系，不能说我要使用DevOps就一定要把两个部门给整合起来。

这个时候可能会有人问，这个不是技术需要吗？如果我把技术问题给打通了，那么整合不成问题了。其实组织变革跟技术是没有太大关系的，并不是技术打通了就意味着两者之间整合没有了阻碍。反过来看，比如像一些比较成熟的企业，银行，电信等，他们的组织架构包含着研发中心，测试中心，运维中心等的，组织架构已经是比较成熟，承担的业务目标更不可能只是从研发到运维这两者之间，虽然说与技术之间尚存很大的隔阂，但这是需要时间来让其在这些业务的边界慢慢更好的整合在一起形成一条新的业务线。

组织变革往往也是一些新技术慢慢的改版，而这样所导致的企业文化，工作习惯也会在新的角色定义中改变，进而推进组织变化。所以，在这种情况下，也可能会形成新的虚拟人员跨界的角色，更容易的去支撑整个业务。