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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

一起探索ITIL和DevOps的边界

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

参加活动:0

组织活动:0

发表于 2018-9-25 16:09:54 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-9-25 16:14 编辑 . M( n% l3 z% W; `1 P4 H6 l
4 p/ k- N; s0 W5 \8 R! b0 c
   其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。; ?: c& d1 E8 v+ i

  W, i. p- X- A* [( U

0 {& b, d9 v3 v
        在EXIN官方给的DevOps最新框架中,把很多因素糅合到了一起,对于整个产品生命周期来说,可以看到几个典型的阶段,如敏捷管理、持续交付、IT服务管理。
1.png
8 x, E3 C- ]+ c6 k! d) F
        
2 E. \+ y( [3 g# r% M$ l% \6 Q; Z
当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。
$ `& R0 Y! b$ I3 j) t

5 l- b. L' n1 D! K6 u' Y
首先让我们来看看持续交付所声明的原则:
* ?' q3 [8 \7 q  V7 s  X& r

! w2 H1 \% p6 Z6 i( u5 D% K
•为软件的发布创建一个可重复且可靠的过程
6 D1 ~2 Q# R! B& M
+ |1 l4 z# k+ E* r8 P/ ]
•将几乎所有事情自动化

& w: L- g( J  s& K; o$ U/ F

! }) |3 f) t' `; S- t( l2 F
•把所有的东西都纳入版本控制
2 p6 l  l6 l) q3 t( y8 K
+ ?3 ?* V2 [$ S5 x( V
•提前并频繁地做让你感到痛苦的事情

+ d2 i6 }& ~0 j. y" @* D
8 w9 A0 {. u  s0 x, ?
•内建质量
7 ?: P8 x- ^8 Z. P: ^
: x1 v+ c1 ]1 b) n
•“DONE”意味着“已发布”
+ ~# u! d  c# R5 G$ n
* y) D1 s- X0 n) Y
•交付过程是每个成员的责任

- H1 n: y/ p3 P& E
7 n7 z0 q; Z" q. q
•持续改进
4 h, A$ T2 b8 H& Z; j1 E

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

& Z1 _1 O+ \6 w! D! r
3 F" G7 _+ L) W( M/ x& H7 T9 s
       其实IT运营和产品运营有很多的类似之处,只是两者看到了对象的不同,一个是IT对象,一个是产品对象。所谓运营都是在建立一套服务流程或过程(有ITIL部分),整合公司内外有限的资源所展开的一系列活动,以便更好的服务客户。狭义的IT运营可以理解成维护,广义的IT运营可以包含产品体验优化、用户满意度提升、应用性能管理、安全、质量控制等等,质量控制算是IT质量运营的一个维度。
. T, x' K; p% f

- w5 @$ a' a9 N+ d3 h- u% x

' U& a7 L  Q! U9 ~. m$ O
        既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:

- n  V7 y) H+ e
1.png
  U5 }+ h2 L( q: z: M" f- n# J
      
. q+ q) X) Z8 f8 S; X
可以把流程或者过程分成两部分:一部分面向管理过程的“离线任务”为主,一部分是面向“在线服务”的执行过程,管理与执行兼顾。从互联网现状来看,ITIL的作用力越靠近应用越弱,在传统行业这样的表现力到还没体现差异。

' s2 G# P9 t  L: F/ X

5 _, K( |$ j' v1 T
    两种流程如何结合,有三种模式:
1.png
3 Y) t; `- Z( j$ I
  `" W& ~/ y4 s* B- z; L

- G" `5 g5 J6 V- C+ C* v3 i/ C
注意:左边是管理流程,右边是DevOps执行流程。
, f/ Y* u$ g0 D" ~; b
! a6 z& m$ f9 x/ S. l
    模式一:每一个流程节点都需要调度一个执行工具去作业。
* @, d  b9 w5 o  G# D4 I

" A% o* u) j5 R+ h
优点:流程效率大大提高,整合程度高。
. p8 m' |; n' C; D
: z# h7 k9 ^1 @
适用场景:CMDB资源申请流程、一些配置变更流程等等。这个模式已经不是从审核者的视角去看待,而是关注执行者的视角。
8 t  k+ ]- q' Z9 E: a# Y% U

2 x# }0 x5 O: |  w3 t/ O9 p- x
例子:CMDB的主机上架流程片段(某证券)

0 b) e3 h5 h& n' U% Z

* ]; g1 j7 t7 N$ `+ C* V% P

. ]4 [! k1 F5 q+ O: v4 R( A
1.png

) g3 o; h2 \8 y. J, a$ v( \

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

/ m6 F/ E5 ~* X; ]
/ Y; Z. }1 N6 L. y" @( [1 w
    模式二:审批流完成之后,执行流程才得以进行。
0 i1 J' y" P/ J+ j+ u
) @% o  g' T" N6 H, C1 x; x
优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。
5 n9 D+ X! x, G6 `- e

# k" T1 Q8 f* a6 X
适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。
9 y6 z  J. ]4 q- _
3 u% p( i, f  w
    模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。

% k6 f& Q) z" E) T

# t4 p& U; g* J- S" p* M5 v# N
优点:效率优先、规范之后。

* w3 O- c8 q2 m" c: }" ?
, l9 @7 @. }3 ]
适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为第一原则。
- \) v, H! v2 r; \( O2 Q5 B

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

& T) G7 g. p! P; E  v- P
1.png

# s' _# j  h$ N: g9 }
( O" F# o5 b( O
        

7 M1 W- g+ f4 Z5 |( _- s) ^7 f1 r- F
红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。

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

3 q2 m* W, s: n8 r9 X. ^

% x" I) Q6 s5 J9 e5 I6 b% l
@ITIL是面向管理过程的;DevOps是面向IT运营过程的。
: w5 l5 a, T0 d% p
' Y/ `  Q, D- {! n! X# K
@ITIL是规则引擎;DevOps是执行引擎。

( u: }# X( z% i! J+ }! @% y! Q

# w7 O! s& _* k" K, t
@ITIL是强调规范的;DevOps是强调敏捷的。
% Y% [$ f4 _7 G9 G( G/ D- y( V
: R+ b# z  K0 i: V( o2 D
@ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。

8 r$ ?4 B7 r! @' D3 O

$ j% U5 F' ~1 |! w% J% k) |
@ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。

' z/ X: J4 y7 V/ z* g" O& ~/ O; N9 G
原创:老王

' g/ R  h4 i( f, U& a* H. S$ D

本版积分规则

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

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

Baidu

GMT+8, 2019-2-24 13:43 , Processed in 0.231790 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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