随着企业信息化的深入，IT系统越来越多，企业IT运维人员也越来越多。 许多企业信息部门成立了运维团队，进行IT系统运维工作。内部IT团队自然需要管理运维人员的各种活动。ITIL为企业IT服务管理提供了一个客观，严格，可量化的最佳实践标准和规范。DevOps则是用于促进开发，技术运营和质量保证部门之间的沟通，协作和集成的一组过程。那么在运维体系中，DevOps的思想跟ITIL的区别有哪些？

　　开发与运维的融合：

同时，ITIL背景下的分工也带来许多负面问题。例如，运维团队感知和认同感很差。企业高层领导认为运维工作没有亮点和价值，是一个成本部门;运维团队也多半认为自己是“背锅侠”。以至于多年前做项目时曾听到合作某甲方运维团队核心成员的一句抱怨：“少壮不努力，老大干运维”。

这可能也是大多数运维者的心声吧。诚然，这里面有运维工作成果难以量化，企业高层不够重视等因素，但是这种过于壁垒分明的开发与运维的分工也是重要原因之一。

企业开发团队与运维团队形成的鸿沟，使开发团队在规划、设计和研发的过程中过于着重功能的实现，在一定程度上忽视了运维团队所关心的稳定性、性能、可用性等因素。

同时，运维团队又无渠道将这些问题在开发前期予以反馈和修复。于是乎，运维团队不断沦为“救火队员”和“背锅侠”，团队士气下降人才流失，运维质量下降形成了恶性循环。

所以，DevOps体系中强调的是开发与运维的融合。

开发运维一体化使开发和运维的信息透明性，运维过程中遇到的问题更有效地反馈到开发团队中。同时，运维的责任主体从单一运维团队变化开发、运维团队共同承担。这使得开发团队也需要为运维中遇到的故障负责，让开发团队也需要将部分的精力和资源投放到与稳定性、性能和可用性等运维相关的研发中去。

当然，并非说ITIL这套体系就已经完全过时，而是我们需要将两者与企业中的开发运维特点相结合，形成更有效的适合企业自身的开发运维体系。只有适合自己的才是最好的。

流程压缩，反应敏捷，效率大幅提升：

ITIL强调流程，但是也带来了效率的下降。在IOE时代，企业业务的变更还并不是那么的频繁，这种效率的下降还并不明显。但到了互联网架构下，这种负面效应就会被无限放大。

举个例子，某运营商发布新的系统版本，往往会经历源代码提交、编译、打包、发布到测试环境、UAT测试、修改bug、再测试、最后上线发布的流程，这个流程往往会经历3-4天。因此，该运营商的版本发布一般只能以月为单位，最快也只能以周为单位。相对于业务周期以天来计算的互联网行业，这套体系对业务变更的反应也就太迟钝了。

所以，DevOps体系则更为强调效率，在持续集成、持续的自动化测试、持续部署平台、立体化监控、技术架构优化等多种自动化工具的加持下版本发布和运维的过程被大大压缩，效率被大幅提升。应用版本发布频率可以以天，甚至以小时为单位。这种为了效率有选择性地放弃一些有点拖沓的流程管理，是IT运维管理为适应IT更好地按需而变，强调更敏捷地响应业务需求的一种更好选择。

　　自动化操作代替冗长流程控制下的规范性：

从另一个方面来说，ITIL强调了规范性，但是这种以建筑于流程之上的规范性仍然有很多缺陷。

再接着上面运营商的例子来说，即使是有再完善的流程加以控制和规范，仍然没有人能打包票说版本上线一定没有问题。在每次版本上线前后，运维团队成员仍然如临大敌，战战兢兢。

原因在于，技术架构复杂程度发展到一定阶段，流程往往无济于事甚至流于形式。在大规模、多类型软硬件设施运维情况下，单纯依赖人的运维体系终将成为整个IT运维的瓶颈。在这种情况下，许多企业尝试将规范性操作细化为各种自动化操作场景，例如，上文就提及过的持续集成、持续自动化测试、持续部署、自动化监控和运维等等的工具和平台。这些高效率、规范化的自动化彻底解放了运维人员的压力，让运维人员的精力可以投入到真正有意义的工作中，而非总是在重复一些机械和重复的常规性事务当中。

以谷歌为例，他们的SRE工程师强制规定他们只有30%的时间会花在on call这种事务型的工作当中，而70%的时间则花在各种自动化工具的开发之中，比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等，这些工具需要他们自己完成开发和维护。这种以自动化工具下高效率的自动化操作代替冗长流程控制下的规范性，也是DevOps体系的一个比较明显的特征。

以上就是关于在运维体系中，DevOps的思想跟ITIL的区别有哪些的全部内容介绍，想了解更多关于IT运维的信息，请继续关注中培教育。