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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

一起探索ITIL和DevOps的边界

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

参加活动:0

组织活动:0

发表于 2018-9-25 16:09:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-25 16:14 编辑 7 k& ~& a( U* [+ T; I6 G

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

/ d( }. n/ Z* ]' f1 \. k" ^4 @- t1 Z. B

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

8 Z# F0 r7 l  c* z
        
3 r3 U4 Y; ^: U; K8 d
当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。

1 j3 J! |, [+ C$ X+ {7 Y' d

: s$ y/ v" ?2 Y6 r' d
首先让我们来看看持续交付所声明的原则:

5 D: N9 k& E/ K

2 d5 k) F+ {9 M- ]8 L& h: g! `
•为软件的发布创建一个可重复且可靠的过程

3 |4 l  [3 z9 p/ h& K4 m" x! L, V

% g- z1 O( |- Q3 e1 t4 N6 J$ ~
•将几乎所有事情自动化
" c6 }9 @6 X1 a  r

/ q! J# a& \& |" z$ c- V1 G
•把所有的东西都纳入版本控制

- N6 O& U9 u# z) g# \
3 _/ e: b. E; Z! p' h
•提前并频繁地做让你感到痛苦的事情

1 H: N7 u9 F2 k; L
0 Z1 F7 k6 N, i2 _" j
•内建质量
4 z9 o2 ^- Z6 Y! e$ |

$ b2 A2 u; F, x- }- o
•“DONE”意味着“已发布”
! Q& D- p! C. }. V7 ~# }! v

$ }' L2 H( V. w1 O1 }& e9 j4 V
•交付过程是每个成员的责任

8 A9 r9 |5 C4 c: g" l, C
3 K6 Z" J' C6 K+ F) S3 w
•持续改进
( G6 w/ N, o7 M4 L
! g- l0 P+ ^3 K+ U" M3 L$ s
        其中有一条讲——“将几乎所有事情自动化”,持续交付覆盖了【部署】和【运营】两个运维相关阶段。在过去,我也一直强调运维其实也是在做交付,其实也是由此而来。那么什么是部署自动化?什么是运营自动化?自动化部署,就是通过部署平台,把相应的变更推送到开发、测试和生产环境,不依赖某个人或角色来执行。这里面就强调的部署平台能力是针对所有环境——开发、测试、生产等等,并且要支持灰度部署、蓝绿部署等等。运营是服务线上运行阶段,这里面包含了监控、服务变更、服务优化、容量预测与规划等等。
  R+ F' l, b7 z7 R9 x7 q0 m* e
5 m9 Z3 y9 U. c% Z/ T
       其实IT运营和产品运营有很多的类似之处,只是两者看到了对象的不同,一个是IT对象,一个是产品对象。所谓运营都是在建立一套服务流程或过程(有ITIL部分),整合公司内外有限的资源所展开的一系列活动,以便更好的服务客户。狭义的IT运营可以理解成维护,广义的IT运营可以包含产品体验优化、用户满意度提升、应用性能管理、安全、质量控制等等,质量控制算是IT质量运营的一个维度。1 h# H& G+ A. g  I  j( w' v
* ^0 W! x. X8 d# G' q1 g& ~. G3 ?; K

+ g# Q$ i# a& [) G7 p! g
        既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:
- d: o8 D1 g0 ?4 X7 T, Y" o. Y- q
1.png
" H+ l3 E8 N. r  T! |; u5 s3 p
      

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

& ]0 j& v4 d, Y7 W

! j8 Q4 @) B" m& L1 @# B5 p7 ^
    两种流程如何结合,有三种模式:
1.png
5 C0 `' E6 ]5 a/ y9 j1 x! J
/ J+ O- t% n6 P: l' H
9 y5 M) r/ d, _( P+ ~0 B
注意:左边是管理流程,右边是DevOps执行流程。

0 _( M' M1 M2 a
3 Y! Z* j) [: f# Y
    模式一:每一个流程节点都需要调度一个执行工具去作业。
) t+ _& b# v; G) \! j/ h
9 d0 |5 a. [8 d
优点:流程效率大大提高,整合程度高。

1 ^0 s- V9 O8 r4 [! @
3 f8 b% o2 D; S0 }  E& g. P  R
适用场景:CMDB资源申请流程、一些配置变更流程等等。这个模式已经不是从审核者的视角去看待,而是关注执行者的视角。

( T7 Y$ P" a+ D4 j: j& a  L

$ V% o+ ~1 W7 ^6 n7 m6 k- C
例子:CMDB的主机上架流程片段(某证券)

6 j' K3 x- A; o& G& z9 G

% a, i7 ?. D* C3 w) m7 d$ Y
5 v  T! a, ?3 ]0 f( O  E; o. u+ n
1.png

% s. M4 ?6 T) j. }' F1 A" X
$ n) \& x- L; G" n
Process是流程平台,CMDB是配置管理平台,RFID是主机管理平台。流程平台已经开始直接去驱动相关平台。这是当时设计流程的时候(对应【选择机柜】环节),该环节和其他平台之间交互的时候画的交互图。

; c" \: A/ ?9 Z# d

. u; Z% h9 L6 n; f' }
    模式二:审批流完成之后,执行流程才得以进行。
' E6 B) ~6 I& W: [- ^

8 t8 @" F( Q2 v
优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。

3 ?; T. v9 B* P2 H; u+ f9 o
" @0 w2 J; w; A/ K1 {3 s
适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。

0 P/ K/ y0 w8 l" l8 Z: J( ?9 K9 Z0 B

+ S6 G% v: G# U
    模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。
- u3 {. {) D- L3 U" H
9 I9 |/ w: \8 [6 D
优点:效率优先、规范之后。
" C! t! a2 }- o; n3 m  [8 o  A
* d$ }: ?3 c/ w9 p" m6 a' _
适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为第一原则。
# \  ]- C1 F& ]5 v5 a

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

3 ^! m3 e6 O& g* Q
1.png

- X9 B; M: N  _& Q' P0 Z
5 m9 S) F7 ]! ^- Y/ @
        

) l; L1 z( d6 B) N
红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。
- l' A7 r2 Y- ~; p: C: |9 k
7 Q. y, o7 x2 z& f2 _
        今天思考DevOps,要用结果来定义你的IT模式是不是DevOps,比如说版本交付周期,故障恢复能力等等,这一定是效率优先的。同样我们思考ITIL流程实践,也要兼顾效率,带着工具思维去简化流程。不可否定,他们有各自存在的价值和场景,用管理和执行的方式来定位,至于流程的模式,我也总结了三种供参考。
: F5 A) O- A# |- A

7 V5 i' C! b( y: T1 |# o
@ITIL是面向管理过程的;DevOps是面向IT运营过程的。

. k, g: G1 I6 r$ f
- o5 G7 A9 k7 L' P" B, T  C+ \" T
@ITIL是规则引擎;DevOps是执行引擎。

7 Z! H: N; P$ h/ D) B8 O
7 T9 @1 T% ~7 a& Q9 U
@ITIL是强调规范的;DevOps是强调敏捷的。
. T$ j- t, b5 z. G6 t& G& i5 _

& B; ~& {2 q6 l1 z& L1 @
@ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。

& K3 p9 M# \  n
$ C, e0 D! V- Z3 q) h" h  U
@ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。

/ |" e8 {3 i. e2 s8 g; X! G% }
* N, g: C+ R; u( h- M; W3 {
原创:老王

7 |0 t; T3 r' P9 E

本版积分规则

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

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

Baidu

GMT+8, 2019-4-25 00:19 , Processed in 0.232647 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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