请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 238|回复: 0

一起探索ITIL和DevOps的边界

[复制链接]
来自- 广东广州

参加活动:0

组织活动:0

发表于 2018-9-25 16:09:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-25 16:14 编辑   ?# `7 j! v2 @. U4 d4 y* m

6 q, `' ]) H* S* H0 n
   其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。; s# P, s  X4 }4 h7 `8 L# s
+ \+ o( f8 n& j) ^6 h
: ^* y2 \+ [' }, s; H$ u7 _1 Z; U
        在EXIN官方给的DevOps最新框架中,把很多因素糅合到了一起,对于整个产品生命周期来说,可以看到几个典型的阶段,如敏捷管理、持续交付、IT服务管理。
1.png

( |# O$ F+ k; |& e1 `7 R9 E
        
3 z0 Z9 f4 B6 p% f& O* w+ L
当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。

( z( k1 I7 P* q$ S9 c

5 @, M! z9 A( l2 w. K$ b7 t$ n
首先让我们来看看持续交付所声明的原则:

* A- F" M8 p% ~
$ O  g+ h% x/ U9 X# c) v* r
•为软件的发布创建一个可重复且可靠的过程
5 I5 b* h# M( o, N
& j! ]5 J: i. j# o
•将几乎所有事情自动化
9 ~* b8 J0 r/ z
) [+ k# p1 U' p' g) B( v3 Q
•把所有的东西都纳入版本控制
: W; s# P& \& Z2 e' c# ^
, ~0 p: e+ I) j3 G
•提前并频繁地做让你感到痛苦的事情

0 {. t1 ?- V8 n

. G- @. B6 c* f  G4 b3 {) U" f
•内建质量
, J) t( |0 W0 q! e$ _- q$ i

- |& e  ]: t/ T: _
•“DONE”意味着“已发布”

; v5 J: q' ^( N/ u4 b& c$ [0 N2 A
4 v: z: O6 }( H
•交付过程是每个成员的责任
% X6 w5 z, U' ?
' L  g, e9 Q! u
•持续改进

/ M! E" N; Q8 B' m' N- E/ e8 U

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

# {1 w1 {1 ^( R( h# b7 s9 @/ H

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

) V9 \$ b: O; r1 s6 L" g( Y5 ?
9 `' f& l; N$ I& Z2 V
        既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:
* Z  N, I9 D9 m; b7 ?1 |1 v& U
1.png

' N5 A! v1 f) K& n
      
0 b: _, F- P/ D- |6 ?* n/ X
可以把流程或者过程分成两部分:一部分面向管理过程的“离线任务”为主,一部分是面向“在线服务”的执行过程,管理与执行兼顾。从互联网现状来看,ITIL的作用力越靠近应用越弱,在传统行业这样的表现力到还没体现差异。

4 J! R" a( y/ p  f. r$ L% I! D
' o/ _4 g( J+ U2 i8 a
    两种流程如何结合,有三种模式:
1.png
1 @  u; A! h4 v5 l
: Q  x! {3 v9 O$ ^4 g6 k/ N! b

# p7 i$ Q: o8 F6 H0 e( E* X
注意:左边是管理流程,右边是DevOps执行流程。

2 N3 F& t/ X3 l6 N

( g6 d1 r! N. k& ~6 D: x2 c
    模式一:每一个流程节点都需要调度一个执行工具去作业。

5 Q4 k1 |, f! J- b  U# I% m7 |6 X
* Y: T5 z. e5 S5 L
优点:流程效率大大提高,整合程度高。

/ [* q( U7 m' \- z  y
  z! _2 {# M' U2 x1 ]9 M
适用场景:CMDB资源申请流程、一些配置变更流程等等。这个模式已经不是从审核者的视角去看待,而是关注执行者的视角。
3 k7 j" y# n+ o6 Y* m- M
, e7 M: @& I: H6 W; j. y, @! V
例子:CMDB的主机上架流程片段(某证券)

4 T5 h! h( R& n! U
- @8 v6 z6 C- s2 ?& O
, G7 j1 E# B+ K6 i: w
1.png

( k2 y0 Z5 K- Q

, Y# g! U& f+ e6 f
Process是流程平台,CMDB是配置管理平台,RFID是主机管理平台。流程平台已经开始直接去驱动相关平台。这是当时设计流程的时候(对应【选择机柜】环节),该环节和其他平台之间交互的时候画的交互图。
- R4 V1 D- h5 M! R

' w9 G+ @% ]8 [& A
    模式二:审批流完成之后,执行流程才得以进行。
6 i' _# U4 ?% M. I3 k  H' ~
5 z  Q& e9 ~8 T- G2 p5 L4 k9 n
优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。

* i& [5 K! v$ v
& P  _9 Q6 z0 c9 q, N' g1 r/ o6 ?% }
适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。

! P/ D$ H: r; y0 D
: e2 M# K& P; D  A
    模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。
% t0 V$ K) H! P, J2 G
1 r8 Y- y* Y0 s/ t# `' s5 B
优点:效率优先、规范之后。
  G/ i9 ]4 s; W+ L4 |, e! y4 J( H5 ?) u
8 v+ K3 H% l- c& v' I. c
适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为第一原则。
" F$ }- l& y: O2 E

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

* ~. [% ]3 Q0 {5 V- s: j/ `
1.png

9 M9 _% \4 d1 O2 q: @

2 n( `$ i- P7 U- y( l- n
        

. b  H: C6 U) {2 ^; e" v9 z
红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。

1 V& R( a* @; @6 L
9 D3 ]  t8 J4 [7 c# S# a) e  h/ j
        今天思考DevOps,要用结果来定义你的IT模式是不是DevOps,比如说版本交付周期,故障恢复能力等等,这一定是效率优先的。同样我们思考ITIL流程实践,也要兼顾效率,带着工具思维去简化流程。不可否定,他们有各自存在的价值和场景,用管理和执行的方式来定位,至于流程的模式,我也总结了三种供参考。
0 }9 `$ f+ G$ T9 V8 W. o

* S8 l, Q2 W! S8 M& ]. u1 T
@ITIL是面向管理过程的;DevOps是面向IT运营过程的。

2 Q+ I% }) Q' l* M$ k

+ \4 V4 Q- ~, r6 i
@ITIL是规则引擎;DevOps是执行引擎。
' R& y# ?& y7 ^9 _* q

: [- i- y' U4 f" E
@ITIL是强调规范的;DevOps是强调敏捷的。
: a8 H3 K2 |; L) a  i. S
* M" \( }; Z& ?$ I2 h
@ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。
4 P( F+ @/ p0 d6 f
* `$ G3 d( _; N5 h
@ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。

% ~% s( F/ o+ h5 G" a1 s+ t# i6 A
6 X1 A# Z- B! ?
原创:老王

0 u9 k, E6 G" p6 W6 B0 x' H

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2018-12-15 19:56 , Processed in 0.226643 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表