在文章之前，我想花点文字来说一下D/O分离，在工作过的几家公司运维，都曾经强调过D/O分离。个人承认在早期，比如说运维团队成立初期，D和O此时没有职责界定，这个是非常必要的，它能快速厘清各自的工作内容，然而随着团队逐渐规范，甚至在向ITIL过渡的过程中，过分强调D/O分离，其实带来了很多问题，典型就是相互推诿和运维团队的边缘化。相互推诿是因为在工作中很难把所有的事务分清，你做也可以，我做也可以，那谁来主动说我做呢？运维团队的边缘化是D会逐渐把琐碎的事务转移给O，O会逐渐陷入到这类频繁的事务中，无法找到自己的存在价值。因此我一直对D/O持否定态度的。
在讲完D/O分离之后，我们回到正题，其实把这两个放在一起对比，许多人觉得会不伦不类，因为两者差别非常大，特别是不同的行业，更能看到他的差异，比如说在金融行业，DevOps很少提及。而在互联网企业，也在逐渐弱化ITIL流程的作用，倡导技术驱动力。以下我就从各个维度来阐述他们的不同点。
1）ITIL流程导向，而非技术导向，DevOps反之
ITIL是企业内部IT服务管理的最佳实践，ITIL V2中包含了六大操作流程五大服务支持流程一个服务台，进入到ITIL V3之后，顶层设计引入了IT服务的生命周期概念，形成一个PDCA环，能够持续去推动IT服务的优化。在ITIL V3中，除了原有的流程之外，增加了几个流程，比如知识管理、服务管理等等。我们从这些ITIL版本中可以得出结论，流程是核心输出。而DevOps相反，从一开始DevOps就把技术作为核心驱动力，从持续集成作为入口，强调对用户服务的价值链的整体管理，并结合自动化平台工具（jenkins/puppet/jira/bugzilla等等），固化价值链中的每个流程节点，并最终完成对用户价值的输出。DevOps以技术作为强有力的切入点，快速的梳理了各个团队（产品、开发、测试、运维）其中的关系。
2）ITIL强调对内服务输出，DevOps强调对外服务输出
ITIL是强调服务支持团队如何快速IT服务交付到服务需求方，这是内部团队之间的服务交付，比如说开发需要一个服务器或者开通一个IPTABLES。这个概念在ITIL V2中体现的尤其明显，在ITIL V3中，还可以看到供应商管理这一个对外管理维度。其他的服务发生更多的是在不同职能团队之间。而DevOps则不是这么看，对DevOps链条上每个节点强调的是，完成的是对最终用户的服务输出，而非线性的把服务输出到下一个节点。
3）ITIL强调规范，DevOps强调敏捷
ITIL作为一个最佳实践，的确在实施的过程中有很多指导意义，很多时候它变成了一个规范存在，甚至我们在选择ITSM产品的时候，就会自然而然的以这个为标准进行产品选型。这个地方要顺带提一下，当流程性规范形成之后，我们要改变它真的很难，因为涉及到大家多做少做的问题，必然不情愿。而DevOps改变了这种情况，所有的流程和规范深度植入到平台之中，在一开始就倡导敏捷思维来解决这些问题，提倡不断迭代。他们就如同两种研发模式模式的对比，传统的线性瀑布模型和并行的珊瑚礁模型之间的对比。
4）ITIL甚少关注文化，DevOps是一种文化
ITIL在V2中对文化制度甚少提及，在V3上如果说有些文化的因素，就是把服务当着战略来看待，然后这样的抽象无法进一步快速分解到操作层面上。而DevOps不是，从开始就强调团队的敏捷基因，比如无边界沟通、团队的共同协作、版本的快速迭代、持续的优化迭代等等，这种协作性文化对团队的行为影响是非常大的。
5）ITIL把D当着服务对象，DevOps把D当着合作对象
在ITIL和DevOps中对待的D也不相同（D是开发）。在ITIL中，运维一直把开发当着一个服务对象来看待，如何快速的交付服务到开发服务手中，更激烈的变化，是把这种交付变成SLA来衡量自己的工作质量（可悲）。然后在DevOps中，此时不是这么看待，D不是作为纯服务对象存在了，它在完成整个产品价值输出的过程中，他需要承担自己的职责，D和O此时是一种平行关系，而非之前的线性关系。更好更快的最终服务输出是我们共同的SLA，从此大家就有了共同的绑定。
6）ITIL最终价值指向是客户（Customers），而DevOps最终价值指向是用户（Users）
客户是指两个主体之间产生了服务关系或者实体变更。而Users则没有，浏览网站的每一个人都是用户，但不一定是客户。如何提供更好的服务用户体验，这个是DevOps聚焦的最终点，由此反向驱动持续集成过程的不断优化。
这么多的不同点，那是否意味着我们真的要选择其一，而抛弃另外一个呢，其实不是，从很多层面上来说，ITIL依然在流程方面起着指导作用，然后在敏捷运维方面，DevOps不断在驱动着ITIL的流程优化，不断推动着服务交付速率和质量的提升，这是DevOps存在的根本价值。
