本文共 1142 字，大约阅读时间需要 3 分钟。

技术界一直就是新名词不断的风格，DevOPS这个词话说出来也挺长时间了，一直以来对这个不算太明白，以为就是指OPS应该不仅仅做OPS的工作，而是应该同时承担起开发自己OPS工作的系统，注意指的是系统，而不是脚本，因为很多的OPS操作是一个流程式的多步骤组成，并且多集群，多系统的交互，这个时候用脚本去实现是会比较难的，而且还要处理诸多的异常等，系统是一个工程性的东西，不仅仅是功能的实现，还要考虑很多异常、稳定性等的问题，但最近的一些思考，让自己对DevOPS有了更多的看法。

OPS去承担起开发自己OPS工作的系统这个比较容易理解，最大的原因在于自己的痛其实只有自己最清楚，很多家公司估计都尝试过让一个专职的团队来开发OPS用的系统，结果就是专职的这个团队和OPS团队挺容易引发争执，然后系统也通常不能很好的解决问题，而一旦转变为OPS自己来做系统给自己用，那问题被解决的可能性会大幅提高，而且有不少公司确实也是OPS采用OnCall轮转的机制，Oncall的时候专心干OPS的活，不OnCall的同学则专心写系统解决自己之前OnCall的时候手工干的活，不过这种方式下比较容易碰到的一个问题可能是写出来的系统的质量不够理想，例如对于运维系统来说，在成功率的要求上会远比在线系统高，但在性能、并发这两点上会远比在线系统低。

除了上面这个点外，运维团队通常还很容易碰到的一个问题是研发交付的系统可运维性不太好，这种时候通常只能是纯操作方面的事运维先人肉顶着，但碰到一些故障的时候，如果系统可运维性比较差，会导致排查过程极度复杂，耗时长，而在有研发和运维这两个独立岗位的时候，这种现象很容易导致的结果就是运维在苦逼的处理一堆的这样的事情，研发呢反正也不是很能感受到这样的痛（因为一个研发可能就负责一两个系统的开发，但一个运维通常可能负责几十个甚至更多系统的运维工作），于是也不是很在乎，最终导致很容易出现的现象就是运维推着研发做很多可运维性的改造，无论是运维体系标准的建设，监控体系标准的建设等，但这个推动通常其实不会那么容易，最重要的原因我自己觉得主要是体感的问题。

所以我现在理解中的DevOPS，我觉得是消除OPS这个独立岗位，让研发和运维合并成同一岗位，研发系统的团队轮值安排OnCall，这样会让研发系统的同学深刻感受到系统设计不靠谱的时候给运维阶段带来的痛苦，从而把本来就应该在设计阶段考虑的可运维性考虑进去，同时也避免了两个团队带来的协调成本等，并且对于研发而言，由于“偷懒”的特性，很容易就会去打造系统来解决手工干的活，站在这样的角度，我觉得就很容易理解为什么叫DevOPS，而不是OPSDev。

大家也可以探讨下你所感受到的运维是怎么样，你觉得变成什么样是比较不错的。

转载地址：https://blog.csdn.net/zl1zl2zl3/article/details/84035528 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！