探索ITIL和DevOps的边界

开发 开发工具
其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。

其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。

在EXIN官方给的DevOps***框架中,把很多因素糅合到了一起,对于整个产品生命周期来说,可以看到几个典型的阶段,如敏捷管理、持续交付、IT服务管理。

EXIN官方给的DevOps***框架

当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。

首先让我们来看看持续交付所声明的原则:

  • 为软件的发布创建一个可重复且可靠的过程
  • 将几乎所有事情自动化
  • 把所有的东西都纳入版本控制
  • 提前并频繁地做让你感到痛苦的事情
  • 内建质量
  • “”DONE”意味着“已发布”
  • 交付过程是每个成员的责任
  • 持续改进

其中有一条讲——“将几乎所有事情自动化”,持续交付覆盖了【部署】和【运营】两个运维相关阶段。在过去,我也一直强调运维其实也是在做交付,其实也是由此而来。那么什么是部署自动化?什么是运营自动化?自动化部署,就是通过部署平台,把相应的变更推送到开发、测试和生产环境,不依赖某个人或角色来执行。这里面就强调的部署平台能力是针对所有环境——开发、测试、生产等等,并且要支持灰度部署、蓝绿部署等等。运营是服务线上运行阶段,这里面包含了监控、服务变更、服务优化、容量预测与规划等等。

其实IT运营和产品运营有很多的类似之处,只是两者看到了对象的不同,一个是IT对象,一个是产品对象。所谓运营都是在建立一套服务流程或过程(有ITIL部分),整合公司内外有限的资源所展开的一系列活动,以便更好的服务客户。狭义的IT运营可以理解成维护,广义的IT运营可以包含产品体验优化、用户满意度提升、应用性能管理、安全、质量控制等等,质量控制算是IT质量运营的一个维度。

既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:

针对运营过程的自动化

可以把流程或者过程分成两部分:一部分面向管理过程的“离线任务”为主,一部分是面向“在线服务”的执行过程,管理与执行兼顾。从互联网现状来看,ITIL的作用力越靠近应用越弱,在传统行业这样的表现力到还没体现差异。

两种流程如何结合,有三种模式:

针对运营过程的自动化流程

注意:左边是管理流程,右边是DevOps执行流程。

模式一:每一个流程节点都需要调度一个执行工具去作业。

优点:流程效率大大提高,整合程度高。

适用场景:CMDB资源申请流程、一些配置变更流程等等。这个模式已经不是从审核者的视角去看待,而是关注执行者的视角。

例子:CMDB的主机上架流程片段(某证券)

CMDB的主机上架流程片段(某证券)

Process是流程平台,CMDB是配置管理平台,RFID是主机管理平台。流程平台已经开始直接去驱动相关平台。这是当时设计流程的时候(对应【选择机柜】环节),该环节和其他平台之间交互的时候画的交互图。

模式二:审批流完成之后,执行流程才得以进行。

优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。

适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。

模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。

优点:效率优先、规范之后。

适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为***原则。

例子:这个模式遇到多个真实的客户场景,我都推荐采用类似的方案。特别是一些流程不在ITIL中的情况,比如说他们使用JIRA系统做研发过程管理(如发布流程),而运维部署平台则是独立一套,两者如何打通和整合?JIRA系统中会有某次发布的流程,此时在以应用为维度的变更升级流程模板中,会有一个Check的节点,它主要用来查看ITIL流程的状态,如果审批通过,部署工具中的执行流程则往下执行,称之为“红绿灯机制”。把ITIL比作马路上的红绿灯,把DevOps执行工具当成马路上的车子,有序、效率、安全等各方面都能兼顾。

[[184829]]

红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。

今天思考DevOps,要用结果来定义你的IT模式是不是DevOps,比如说版本交付周期,故障恢复能力等等,这一定是效率优先的。同样我们思考ITIL流程实践,也要兼顾效率,带着工具思维去简化流程。不可否定,他们有各自存在的价值和场景,用管理和执行的方式来定位,至于流程的模式,我也总结了三种供参考。

  • ITIL是面向管理过程的;DevOps是面向IT运营过程的。
  • ITIL是规则引擎;DevOps是执行引擎。
  • ITIL是强调规范的;DevOps是强调敏捷的。
  • ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。
  • ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。
  • ........

【本文是51CTO专栏作者“王津银”的原创稿件,转载请注明出处】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2021-12-09 08:50:35

Kubernetes增强功能版本更新

2009-06-13 15:35:51

ITILIT运维

2023-06-15 07:28:11

运维云原生SRE

2018-12-03 11:42:54

华为云

2012-08-24 08:56:08

ITILBYOD

2024-12-09 12:00:00

Python编程数据类型转换

2012-05-11 17:02:51

IT运维ITIL

2022-04-20 15:55:29

容器架构设计

2014-09-01 13:02:02

2024-12-06 10:00:00

2011-07-26 10:03:11

ITIL实施ITIL流程认证

2018-04-27 14:08:40

云容器DevOps

2009-05-05 08:50:10

ITIL运维管理摩卡

2009-09-01 14:36:32

ITIL理论落地

2015-12-02 14:41:27

2020-08-20 07:54:58

Node多线程解密

2024-02-21 08:58:40

PythonPicklingUnpickling
点赞
收藏

51CTO技术栈公众号