运维工作如今已经发展到智能运维阶段（AIOps）。经历了人工运维、自动化运维两个阶段后，推动运维工作发展主要有两种力量：内部驱动力和外部牵引力。
内部驱动力是指随着业务越来越繁杂，传统的人工运维方式逐渐到达其生产力的极限，内部逐渐增加的运维需求越来越得不到满足而产生的矛盾，产生一股强大的倒逼力量，促使运维人员进行创新，通过提高技术水平来增加生产力。业务的繁杂主要表现在运维需求的复杂多变、调用关系的错综复杂、频繁地变更发布、运维数据的剧增、运维专家经验的主观性等5个方面。
外部牵引力是指刺激运维工作向前发展的外部力量，主要有以下3种。
- 国家宏观政策。比如当前国家“十四五”规划正在大力推进企业数字化转型、新基建、人工智能等战略，会指导吸引市场资本进入这些领域，进行人才和技术的产业升级，推动行业的发展。
- 企业战略。企业会紧随国家政策和产业变革不断升级企业IT战略，应用前沿技术，实施企业数字化转型，升级传统运维生产力。
- 技术进步。前两种力量属于宏观非技术力量，它们需要依托第3种技术力量。没有技术力量，或者技术还未发展到可用的程度，前两种力量也无法产生效果。好比没有AI算力的提升，大规模深度模型的训练迭代是不可能在多个领域成熟落地的。
外部牵引力和内部驱动力对传统运维工作均具有正向推动作用，但外部牵引力并不像内部驱动力那样，每时每刻都表现出百分百的正向作用。例如，外部牵引力中的技术进步这一力量中的，在现有的各种运维场景中，并不都适用。但在如今各类技术名词铺天盖地出现一项：人工智能算法时，投资人关心企业是否有前沿技术、企业领导觉得使用高端算法更能体现企业科技含量、研发人员觉得高级算法更能体现自己的技术水平等，这些因素会促使算法人员花费使用深度学习模型解决一些运维问题。
再者传统运维工作的重点是各种技术管理工作，如机房管理、服务器管理、网络管理和系统软件管理等。DevOps是由开发+运维组成，AIOps是由AI+运维组成，但具体分析可知这两种“+”并不是一回事，前者是通过自动化工具将开发人员、运维人员协同起来，打破两类人群的合作壁垒，实现在敏捷开发情况更能适应产品或系统的快速迭代上线，两类人依然在各自做着自身所负责的工作，并没有谁帮谁工作、谁减少谁的工作、谁替代谁的工作。而后者是AI算法工程师辅助，或者说帮助运维工程师提升工作效率，算法工程师和运维工程师属于不同部门，双方明显是一方帮助另一方。
DevOps与AIOps的不同主要体现在以下3点。
1）参与人员不同。2）工作方式不同。 3）工作内容不同。 关于第3个不同点，两种运维在工作内容上存在明显的差异。但实际中存在软件开发+人工智能+技术运维3部分重叠的工作，这部分工作应该属于哪些人来做，就会产生职责不清的问题。
DevOps是基于一套开发管理工具将研发工程师和运维工程师组织在一起协同工作，两类人员是在这套开发管理工具上进行协同交流工作，并不是融合在一个实体部门里。他们依然做着原来各自的职责内容，研发工程师做系统开发类相关工作，运维工程师做运维相关工作，只是由于他们双方均在这套开发管理工具上开展工作，增加了沟通、提升了研发效率。具体来说，可实现项目统筹管理、资源协同多共享、效率多质量提升的目标。
这类开发管理工具可以做到将运维人员的意愿100%地通过自动化实现。而在自动化运维的推进过程中，一些较为简单的运维工作，如单指标异常检测、指标漂移引起的数据波动等问题，可通过动态门限方法来诊断识别。这种动态门限的阈值可通过Z-score等方法通过自动化运维工具实现，这类工作有时通过研发人员开发的Java程序直接在产品中实现，有时通过运维人员在开发管理工具中实现，均不需通过算法工程师。那么这类的工作是属于DevOps还是属于AIOps？因为它既涉及一定算法又未通过算法工程师来实现，而是基于自动化运维工具实现的，因此属于AIOps。
随着DevOps在企业不断被成熟应用，这类软件开发+人工智能+技术运维混合的工作会越来越多。DevOps其实是AIOps的必经之路，随着企业的算法团队日益成熟，运维相关的智能算法会逐渐独立出来由专业的算法工程师来实现。前期由研发工程师或运维工程师借助开发管理工具代劳的算法工作，将逐渐独立化、专业化、体系化、平台化，即从DevOps过渡到AIOps。
