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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 568|回复: 0

一起探索ITIL和DevOps的边界

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

参加活动:0

组织活动:0

发表于 2018-9-25 16:09:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-25 16:14 编辑
6 M3 ?) g1 o3 x# i! Y* q+ Y( [9 |$ K9 F) k$ w4 Z
   其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。
2 q+ e8 z, p$ W) j9 ^7 ^4 m/ t  ~- `

, A1 C) {# ]* R& m# B
. n" ?! ~: T# \* j5 s# l
        在EXIN官方给的DevOps最新框架中,把很多因素糅合到了一起,对于整个产品生命周期来说,可以看到几个典型的阶段,如敏捷管理、持续交付、IT服务管理。
1.png
; x; J; U2 E; h+ j
        

; m. ]& Y" Z! o: i$ z  _; w( R
当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。
* w1 w6 Z- U! o
5 Y* X" w; `" z$ a6 }- Q0 k
首先让我们来看看持续交付所声明的原则:
2 F, w; P  x  E5 |: }& t
# Q9 j7 w# ?+ l$ ^* q& H, d
•为软件的发布创建一个可重复且可靠的过程

" i6 B1 m. d) |: ]$ `

) k, L0 M7 s$ T( q
•将几乎所有事情自动化

! l7 E4 z& \0 _" k( w) m' k
5 P' f  w, w: {1 G
•把所有的东西都纳入版本控制
. v; Y) r, `  u2 B0 o0 v$ _7 h: }/ l
" ?3 P: k# G, j/ k8 v) S4 Z
•提前并频繁地做让你感到痛苦的事情

- M( _3 G; z9 ?2 e9 u( ~! L) s
8 F' O" y$ ~- L. `
•内建质量
" J* n; Y& ~- D5 f6 ~9 o
+ _- c/ }" t# i0 ^4 h6 V
•“DONE”意味着“已发布”

" M) n: E' |9 J1 C/ ?
0 i: j: c" H& `8 b0 Q* X, M
•交付过程是每个成员的责任

6 U! D* ~0 l# q6 m
* k5 l1 l$ P' `( U
•持续改进
( X2 L6 o6 b) v
5 l5 ~/ e7 e( G4 x& p
        其中有一条讲——“将几乎所有事情自动化”,持续交付覆盖了【部署】和【运营】两个运维相关阶段。在过去,我也一直强调运维其实也是在做交付,其实也是由此而来。那么什么是部署自动化?什么是运营自动化?自动化部署,就是通过部署平台,把相应的变更推送到开发、测试和生产环境,不依赖某个人或角色来执行。这里面就强调的部署平台能力是针对所有环境——开发、测试、生产等等,并且要支持灰度部署、蓝绿部署等等。运营是服务线上运行阶段,这里面包含了监控、服务变更、服务优化、容量预测与规划等等。
  ^  y. H( y( s1 J! h2 ^/ K  k
/ N- N" X  a8 F# P, e- o( v  m/ h6 R
       其实IT运营和产品运营有很多的类似之处,只是两者看到了对象的不同,一个是IT对象,一个是产品对象。所谓运营都是在建立一套服务流程或过程(有ITIL部分),整合公司内外有限的资源所展开的一系列活动,以便更好的服务客户。狭义的IT运营可以理解成维护,广义的IT运营可以包含产品体验优化、用户满意度提升、应用性能管理、安全、质量控制等等,质量控制算是IT质量运营的一个维度。
, K6 C% P3 {" n5 B6 [9 L; X  P4 d

# y3 o" v+ _7 c1 ?$ z2 ^

( H- [& ^/ v- f( s$ e6 U
        既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:
2 |% r% r0 {0 H3 Z
1.png
8 m( B4 \  X# F( U( Y
      
4 F: W( s) G+ b$ A
可以把流程或者过程分成两部分:一部分面向管理过程的“离线任务”为主,一部分是面向“在线服务”的执行过程,管理与执行兼顾。从互联网现状来看,ITIL的作用力越靠近应用越弱,在传统行业这样的表现力到还没体现差异。

: s' |1 Y% q: I$ j" J% H0 G. x

( \: I2 x8 t8 l# Y
    两种流程如何结合,有三种模式:
1.png
; @" }# L6 Z! N0 k* G

( V' ]& b! g& t: F7 e

2 u# b4 ^- k; ?
注意:左边是管理流程,右边是DevOps执行流程。

* Q' S# b$ c0 A1 \

6 [4 F3 {4 L4 b. `
    模式一:每一个流程节点都需要调度一个执行工具去作业。
& o. n2 `  c9 Q6 b3 o+ x

1 o7 `4 q5 Q  G8 n8 H
优点:流程效率大大提高,整合程度高。

/ i$ M. W$ L6 T, I: Q

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

5 m  N* X* {9 L9 c; r

5 ]7 V5 I0 s) Z# }
例子:CMDB的主机上架流程片段(某证券)

5 w2 F4 P# k4 s' m* X5 n9 D

. a; }0 @' O+ ?" c, \  \

0 {5 |4 ]0 K& I% I* F, K
1.png
0 I8 D( U2 h9 D4 ^. R/ `( P

) B/ q8 b7 @% K' u
Process是流程平台,CMDB是配置管理平台,RFID是主机管理平台。流程平台已经开始直接去驱动相关平台。这是当时设计流程的时候(对应【选择机柜】环节),该环节和其他平台之间交互的时候画的交互图。
" i8 R- ^: @6 q6 V$ }2 @

. b3 W- `, \7 W  m
    模式二:审批流完成之后,执行流程才得以进行。
/ a# ]7 P2 W! c# W8 b  h3 O. p; t
: x! J. R5 P% l  C/ M, A# o) V
优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。

) c9 M& P; l  t; }" K3 F
) p5 T+ \6 b* {& V
适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。
' K6 r  f( d3 o2 V8 X" u
- {3 v  z( Z4 L( L' d# A$ ?0 \. P
    模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。

* o- B% W8 b3 l4 z
% v, H& h9 U' u
优点:效率优先、规范之后。
6 r! l9 u! N$ B  ]% W* i) J/ r

) Q* A  l8 ]$ f0 f5 ], `3 N+ L
适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为第一原则。
% O. z# A! ]1 e

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

; a6 c. ^( C2 R7 d
1.png

4 O7 h4 |2 z3 k, Y2 c3 Q
- u  g3 k* h. J" p
        

$ o, e: G( a* ~. C0 Y
红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。
& v: X! w6 K/ `, T

8 F- w7 q6 @  k) h4 S, b
        今天思考DevOps,要用结果来定义你的IT模式是不是DevOps,比如说版本交付周期,故障恢复能力等等,这一定是效率优先的。同样我们思考ITIL流程实践,也要兼顾效率,带着工具思维去简化流程。不可否定,他们有各自存在的价值和场景,用管理和执行的方式来定位,至于流程的模式,我也总结了三种供参考。
" q) D# G& ^. Z: N$ I

$ w0 ^# {; D  \& I/ a+ L- }
@ITIL是面向管理过程的;DevOps是面向IT运营过程的。
! p7 [( ]/ {. p7 s  z4 o& {% I0 O

7 j) D3 ~- d2 a3 S( p
@ITIL是规则引擎;DevOps是执行引擎。

8 N$ g% B$ \6 D. H+ N
. V6 C7 d" N! Q9 S0 X: H
@ITIL是强调规范的;DevOps是强调敏捷的。
5 M! n6 D& W+ ^
  t5 e, ?" M+ \
@ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。

1 n* {4 H* x5 v/ s3 F5 s$ y
+ `6 O) g0 [5 I; U& d0 I! w, c3 L
@ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。

3 P- L# R) f, z( w  i/ f
& U  N4 d& D) E2 T* ^6 O% Z. L
原创:老王

8 s2 v# [. Z* q2 r

本版积分规则

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

Baidu

GMT+8, 2019-6-17 23:06 , Processed in 0.211827 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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