什么是运行时开发：
是运输维度还是其他运输维度，是研发还是其他研发？
如果哪个擅自跨越国境，就称为SRE DevOps或运行时开发，这和前端容易成为全堆栈一样。 都是稍微越过国境的结果。
也就是说，你比别人能干了什么，成为了别的职业。 嗯，我想是的。
谁跨在哪里？
运维不能研发，所以我想离淘汰不远了。 当然，喜欢脏工作和累工作可能还需要一些时间。
无法进行研发、运输、维度。 虽然不能淘汰，但是很容易被运输维度吊起来，所以最好能下单。 至少不要给运输哥添麻烦。
开发运维意识流：
当然，如果持有“上司为了减轻我们的负担而招募了运维开发”的思想的话，运维开发肯定只是高级运维。 这个运输伙伴和团队没有被吊在研发上，而是最后自尽了(理解业务的人除外)。
运维开发说：“哥哥是研发人员。 与运维on call无关。 哥哥有了不用考虑运维的成本和维护性”的思想，到最后制作的东西就会增加和删除cms系统。
不以结婚为目的的恋爱都是流氓。 同样，不以运维为目的的运维研发也同样是流氓。
总结：
所谓“终极”，应该是赶牛的运维被研发或研发具有运维意识。 我觉得那个时候运维的研发也没有必要存在，但是现在是过渡期，在一部分制造商、云和人员的技能提高之后，这个职位就不存在了。
到时候再说第一句话：
是运输维度还是其他运输维度，是研发还是其他研发？
基本同意@自信的领导人的见解
我最近把产品经理的角色作为运输团队做自动化系统，包括CMDB、持续集成、批量管理等主要功能。
另一方面，运维开发团队中既有原本从事运维开发的人，也有原本从事其他业务(电子商务的后端)开发并协助运维团队的人。 试着和他们合作一段时间，总体上感觉如下。
运维开发首先是程序员，而不是运维工程师
*良好的运行时开发必须包括“运行时理解”和“开发能力”。
*对“开发能力”的技术要求低于游戏、电子商务、搜索等其他业务形态
*对运输业务的理解难度低于电子商务、游戏等业务形态。 也就是说，对“理解运输业务”的要求不高。
综上所述，运维开发是一个深度不太深的职业分支，但目前对运维开发的需求越来越高，主要是因为老一代运维的一般研发能力有限。 例如，当我们有开发自动化系统的需求时，往往需要程序员的协助，但程序员制作的系统对运维工程师来说并不太方便。
此时，一些运维工程师升级研发技能，开发出便于使用的运维系统，受到运维团队的好评，大家纷纷称赞“运维开发”。
所以，大家把“易用的运输系统”和“运维开发”等效是一个很大的误解。
其实“好用的运维系统”也等同于“运维理解”“开发能力”，其实这两种能力是可以分离的，不一定要推给运维开发工程师一个人。
资深运行时能细致记录运行时自动化需求时，最好的“理解运行时”就是仔细考虑自动化系统的设计、体系结构等思路。 此时，通过向具有较强“开发能力”的程序员交付该可靠、使用方便、细致的需求文档，可以得到最终的“使用方便的运行时系统”。
在开发流程(如其他业务形式)中，“产品经理”(Product Manager ) (策划)程序员必须具有分离的两个角色。 不能说需要会写代码，又能满足需求的产品经理。
所以，运维开发只是一个过渡的产物，在运维需求得到充分理解、充分分析，资深运维获得“产品经理”能力后，运维开发只是一个普通的开发分支，根据需求对文档进行编码即可，再多一点这是我内心的终极状态。 （