ITIL与DevOps对比

传统企业的服务更多是站在企业视角,基于自己能够提供什么来设计,内部的IT服务也是基于这种逻辑。互联网模式则必须站在用户的视角,基于用户需要什么来设计产品,对外提供服务,同时为了快速响应用户需求(甚至有些时候是为了快速试错与纠错),内部的IT服务也必须高效敏捷。

企业对流程都会有诉求,不同企业之间流程数量的多少、流程颗粒度的粗细程度是肉眼可察的,其设计的内在逻辑更是差别巨大。流程规范的本质是增加约束,其设计初衷说得直白些是为了立规矩,业务需求千奇百怪、层出不穷,如果没有任何规则,IT服务提供者即便疲于奔命也很难应对,服务交付质量和价值也很难衡量。对于复杂的流程和审批,其流转需要经过众多节点,设计上看似面面俱到,但也有可能无人真正履职,导致对于操作者就是一个通知,对于审批者就是点一下按钮,使得流程的作用变成了满足合规要求,最终流于形式。

对于科技团队来说,开发和运维系统出现问题在所难免,差别只在于问题的多或少、早或晚。这并不是说事件管理、问题管理等并无用处,而是说不能始终把关注的焦点放在这上面。引入众多规则、流程、约束,除了让事件落地执行越来越复杂外,没有其他助益,那不如换一个思路,怎么通过立体化的监控体系第一时间发现问题,甚至在事前预测事件可能发生从而提前干预呢?当问题出现以后,通过持续集成、自动化测试、自动化发布等手段快速处置,这些也正是DevOps所倡导的。DevOps也需要流程,不过它的关注点不在流程,而是效率,它建立各项流程、运用各类工具,都是为了提升效率。

举例来说,发布变更不管对开发人员还是运维人员来说都是非常重要的动作。若按照DevOps理念来响应发布变更的话,则建设重心会是建立自动化发布系统。在此过程中,一方面要通过制定标准化规范,对要做的操作进行抽象,统一标准,化繁为简;另一方面则是借助工具,对要执行的各项操作进行封装,隐藏细节,简化步骤并实现可视化操作。自动化发布系统建成后,要执行与发布相关的操作,通过视窗界面点击按钮即可,肯定比手动执行命令更快、更简单,也更可靠。在这种模式下还需要流程审批吗?这要根据企业的实际情况而定,有可能还是会有流程,但会是一个特别简化的小流程,因为执行的逻辑都是在系统中固化好的,谁来执行都没有区别。大家也可以对照一下自家企业发布变更流程的流转节点设计,看看有无可优化空间。ITIL中强调职责边界的清晰定义,变相强调了分工而弱化了协作,这种情况与ITIL过多强调流程、甚少关注文化也有一定关系,而对于流行的敏捷模式来说则是推崇高度自治的小团队。DevOps从开始就强调团队的敏捷基因,比如无边界沟通、团队协作、版本快速迭代、持续优化等,这种倡导创新、协作的文化对团队的行为影响是非常大的

在ITIL中,运维是IT服务的直接提供者,“服务”是看我能为你提供什么,“流程”是看需要我为你做什么,运维人员把开发人员当作服务对象来看待,接收到来自OA系统的工单流程后会快速响应和交付服务,同时也会考虑通过SLA等衡量运维的工作质量,但终归是被动角色。在DevOps中,没有纯粹的服务对象,开发、测试、运维各自承担自己的职责,甚至IT运维人员也会站在用户视角去思考,如何为最终用户提供有价值的服务,并为最终达成基于产品价值进行交付。

ITIL重视最佳实践,在实施过程中很多流程确实很有指导意义,不过很多时候它变成了一个规范,甚至在选择ITSM产品的时候,也会自然而然地以此为标准进行产品选型。这里要顺带提一下,当流程性规范形成之后,我们要改变它真的很难。而DevOps倡导敏捷,提倡不断迭代,所有的流程和规范是嵌入在自动化平台中的,相对更容易解决这样的情况。

发表评论

相关文章