运维工程师和运维开发工程师

要建设运维自动化或者实践DevOps离不开运维开发工程师的参与，要怎样才能更好地发挥运维开发的作用呢？

我作为运维产品经理的角色和各种类型的运维开发一起协作过，团队中有本来就做运维开发的，也有本来做其他业务（电商、平台）的开发转来协助运维团队的，和他们协作一段日子后总体感觉如下：

运维开发首先是一个程序员，不是运维工程师；
一个好的运维开发需要具备「运维理解」+「开发能力」；
对「开发能力」的技术要求低于其他业务形态（如游戏、电商、搜索等）；
对运维业务的理解难度会低于电商、游戏等业务形态，即对「运维理解」的要求不高；
对运维相关技术栈的掌握程度要求高，如Linux、git、nginx、zabbix、docker、k8s等等；

综上所述，运维开发是一个深度不算太深的职业分支，而现在之所以对运维开发需求量热起来了，主要由于老一辈的经验丰富运维普遍研发能力有限（比如我T_T），这是有历史原因的。

对于从业8年以上的经验丰富运维来说，他们刚开始做运维的时候更多的是接触机房、机架、主机、交换机、防火墙等硬件设备，然后对接业务运维后，一般通过shell、python等脚本来辅助工作，等到业界提出DevOps的时候，他们往往已经专注于团队管理、容量规划、架构调优、运维服务质量等*范畴，所以基本不太可能抽出大块的时间来重新学习编码并开发自动化系统。

所以，当我们有自动化系统的建设需求时候需要更专业的程序员来协助，但是，一般的非专职运维开发的程序员做出来的系统对于运维来说往往不太好使。

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

所以，大家将「好使的运维系统」和「运维开发」等价起来，以为我们只要招来一个运维开发，那么一套的运维平台就能自动诞生出来，这其实是个很大的误区。

其实「好使的运维系统」真正等价于「运维理解」+「开发能力」，这两种能力也是可以分离的，不一定要强加在运维开发工程师一个人的身上。类似其他业务形态的开发过程，需要产品经理和程序员两种角色分离，企业也不会说要招聘既会写代码、又会出需求的程序员。

所以，当经验丰富运维能把运维自动化的需求细致的文档化下来，把自动化系统的设计、架构等关键环节确立下来，这就是较好的「运维理解」，这个时候把这份靠谱、好使、细致的需求文档交给具备强「开发能力」的程序员，较终就可以得到「好使的运维系统」。

当然，经验丰富运维要获取产品经理能力也不是那么简单，而且也需要和运维开发无障碍地探讨技术，个人觉得*具备且不*于以下技能包：产品规划、产品设计、面向对象、需求模型、领域模型、设计模型、设计原则、设计模式、产品工具和文档能力等等。

所以，当运维需求被理解、分析得足够透彻，以及经验丰富运维获得了「产品经理」能力后，运维开发就是一种普通的开发分支，按需求文档编码即可。再往*发展的话，运维开发也可以替代经验丰富运维出需求，升级为运维产品经理，以程序员的思维角度要解决运维服务的工程效率和质量问题，我认为这也是类似Google所提倡的SRE文化。

较后，很多运维可能考虑要不要转运维开发，当你觉得编码的乐趣远远大于其他运维技能的时候，尽管争取努力去转！把自己当成一个真正的程序员，以程序员的评价标准来要求自己，不要觉得运维能力和编码能力各自半桶水是好事，正如我前面的那句话：”运维开发首先是一个程序员，不是运维工程师 “。