基本同意 @陈一梦 的见解

我正好最近以产品经理的角色为运维团队做自动化系统，包括CMDB、持续集成、批量控制等主要功能。

而运维开发团队中有本来就做运维开发的，也有本来做其他业务（电商后端）的开发转来协助运维团队的，和他们协作一段日子后总体感觉如下：

* 运维开发首先是一个程序员，不是运维工程师；
* 一个好的运维开发需要包含 “运维理解”+“开发能力”；
* 对“开发能力”的技术要求低于其他业务形态（如游戏、电商、搜索等）；
* 对运维业务的理解难度会低于电商、游戏等业务形态，即对“运维理解”的要求不高；

综上所述，运维开发是一个深度不算太深的职业分支，而现在之所以对运维开发需求量热起来了，主要由于老一辈的资深运维普遍研发能力有限（比如我 T_T ），当我们有开发自动化系统的需求时候往往需要程序员的协助，但是，程序员做出来的系统对于运维工程师来说不太好使。

这时候有部分运维工程师升级了研发技能，变成了运维开发，把好使的运维系统做出来了，赢得了运维团队的好评，大家都为“运维开发”点赞。

所以，大家把 “好使的运维系统” 和 “运维开发” 等价起来，这是一个很大的误区。

其实“好使的运维系统” 也等价于 “运维理解”+“开发能力”，其实这两种能力是可以分离的，不一定要强加在运维开发工程师一个人的身上。

当资深运维能把运维自动化的需求细致的文档化下来，把自动化系统的设计、架构等构思好，这就是最好的“运维理解”，这个时候把这份靠谱、好使、细致的需求文档交给具备强“开发能力”的程序员，就可以得到最终“好使的运维系统”。

类似其他业务形态的开发过程，需要产品经理（策划）+程序员两种角色分离，不会说需要会写代码、又会出需求的产品经理。

所以说运维开发只是一个过渡产物，当运维需求被理解、分析得足够透彻，以及资深运维获得了“产品经理”能力后，运维开发就是一种普通的开发分支，按需求文档编码即可，再高级一点的话，可以替代资深运维出需求，变成运维产品经理，这是我心中的终极状态（还有更高级的总监、CTO等，这就不多扯淡了）。