运维开发工程师在线评测：http://www.gtalent.cn/exam/interview/nsYteJ5wFfWkMdb2 

什么是运维开发：
运维还是那个运维，研发还是那个研发。
随便哪边跨界了下就叫做了SRE DevOps 或者运维开发，这个和前端容易成为全栈一样。都是稍微跨界的结果。
也就是你比别人多会一些东西，然后变成了另一个工种，嗯，应该就是这样的。

谁往哪边跨的问题：
运维不会研发，估计离淘汰不远了。当然你要喜欢脏活累活可能还能挺一段时间。
研发不会运维，淘汰倒不至于，但是容易让运维吊打，所以还是会点的好。至少别给运维大哥添麻烦。

运维开发意识流：
当然，运维哥们要是抱着“老板帮我招了一个运维研发来减轻我们的负担”这种思想的话，运维开发只不过是高级一点的运维无疑了。这个运维哥们甚至团队不是被研发吊打就是最后自生自灭（懂业务的除外）

运维开发要是抱着“哥是研发，运维on call啥的跟我毛关系没有，哥不用考虑运维成本和可维护性”这样的思想的话，到最后做的东西也就是增删改查的cms系统了。

不以结婚为目的恋爱都是耍流氓，同理：不以运维为目的运维研发同样也是耍流氓。

总结下：
所谓的“终极”应该是，牛逼的运维会研发，或者研发具有运维意识。那时候运维研发估计也没有什么必要存在了，现在都是过渡期间，等某些厂商或者云或者人员技能提高了之后，这个职位就不存在了。

那个时候就会回到第一句话上：
运维还是那个运维，研发还是那个研发。

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

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

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

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

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

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


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

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

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

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