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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 763|回复: 0

一起探索ITIL和DevOps的边界

[复制链接]
发表于 2018-9-25 16:09:54 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-25 16:14 编辑
- J: J% y$ [4 U$ a8 g3 K. k  \0 d) ~! N8 [  g# T- h9 J
   其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。3 n9 |3 j: i3 P4 u5 M9 |# b
; ?$ g! x* c" n- {8 l9 p1 W' F1 F
- M1 R+ K; P+ g
        在EXIN官方给的DevOps最新框架中,把很多因素糅合到了一起,对于整个产品生命周期来说,可以看到几个典型的阶段,如敏捷管理、持续交付、IT服务管理。
1.png

- J- F( l3 M* ^; V- p3 k9 u
        
0 _* H# j! J' e/ T$ q! q
当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。

3 e* y4 V7 z2 ^/ |3 r: s
* i9 O3 G& `  ?; N
首先让我们来看看持续交付所声明的原则:
4 ^" g9 X9 I% t1 o

6 E: c0 d$ B6 U( h/ C& l0 [
•为软件的发布创建一个可重复且可靠的过程

  _$ L9 K! X3 S2 D
2 n; d7 C" \8 Y$ E6 z: |. t  l
•将几乎所有事情自动化
8 m8 a/ e8 J1 G  M

7 j; E5 W: F- k; b
•把所有的东西都纳入版本控制

4 _. [4 n* v9 P$ K6 f5 k1 Y
! k8 }, ?  I8 f
•提前并频繁地做让你感到痛苦的事情
+ }! g3 {# v" t: z* c

& w( k. Q3 Z: n& x' s3 P( O
•内建质量
0 e* _5 V6 i$ n8 ~; |

3 E0 {/ ]/ \3 J) |7 j
•“DONE”意味着“已发布”
/ U: T+ F3 b3 P/ F' x5 n4 I
1 P/ v! Z! z6 X$ _0 l1 p6 c1 Q+ B
•交付过程是每个成员的责任

8 O  R9 X9 w1 M" b
' O5 V' A) u' _; h. V; r2 A
•持续改进

! k7 Q& t- O8 S2 N" K" M: x) D

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

# v, b! }; s9 H/ ?* w% n
' o# c$ ~, {  F$ v) J: K" v# O* G
       其实IT运营和产品运营有很多的类似之处,只是两者看到了对象的不同,一个是IT对象,一个是产品对象。所谓运营都是在建立一套服务流程或过程(有ITIL部分),整合公司内外有限的资源所展开的一系列活动,以便更好的服务客户。狭义的IT运营可以理解成维护,广义的IT运营可以包含产品体验优化、用户满意度提升、应用性能管理、安全、质量控制等等,质量控制算是IT质量运营的一个维度。$ ?9 T9 N6 ]) r, I
  R, }7 S+ h( c

: P4 K# F- N5 ^" X4 b% K
        既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:
5 t9 o0 O$ U1 _1 n: S: c/ E: Y" v
1.png

! l8 e/ N1 S( q% Q" W( t
      
5 ~0 c+ ?5 i) ]
可以把流程或者过程分成两部分:一部分面向管理过程的“离线任务”为主,一部分是面向“在线服务”的执行过程,管理与执行兼顾。从互联网现状来看,ITIL的作用力越靠近应用越弱,在传统行业这样的表现力到还没体现差异。

5 v% \0 R2 L6 v; R

, \. [. h4 c( F! M3 }7 y
    两种流程如何结合,有三种模式:
1.png

, j  d0 l$ ^: I( i: |5 i: K
: y" o0 A% n, T( `1 h# v7 s7 [

- c4 g/ m( X% [2 o
注意:左边是管理流程,右边是DevOps执行流程。
2 F. T/ a! `* V1 u2 p

; F! L2 O% k9 [4 d( x1 h
    模式一:每一个流程节点都需要调度一个执行工具去作业。

! O( i4 q* r7 R( p$ z9 A7 N1 o7 T9 ]" D, ?
5 E- _* i' {  _1 [
优点:流程效率大大提高,整合程度高。
8 e. n2 x7 p- r+ T
9 S$ `' _6 @! O$ S
适用场景:CMDB资源申请流程、一些配置变更流程等等。这个模式已经不是从审核者的视角去看待,而是关注执行者的视角。
+ z, ?5 R: _- P( h" l  G: K4 b
8 p! V) O/ x8 B
例子:CMDB的主机上架流程片段(某证券)

5 P$ L  s& C0 a$ @/ K
3 z( `0 ?! {' P9 T) f' J7 E

! t. V) G! x* z0 {8 d1 J& H
1.png
) H- b' T2 e1 a/ r- j: H; G# X$ \

  H6 v, i6 h: ^' J% N* b3 R
Process是流程平台,CMDB是配置管理平台,RFID是主机管理平台。流程平台已经开始直接去驱动相关平台。这是当时设计流程的时候(对应【选择机柜】环节),该环节和其他平台之间交互的时候画的交互图。
: E; O1 }# b, e' w2 e
' n" q* o" t; J: O- h8 k3 ~/ I
    模式二:审批流完成之后,执行流程才得以进行。
: a; a% d: b  p5 [7 ]  b9 r
$ i( m* d+ ?* I8 }/ ]
优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。

1 O' ^0 G1 s/ n& ]; N# R
/ |6 \  J3 v& @% E: |
适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。
7 X& @# t3 H) c" I5 t2 o& p/ m# M
0 L( j" E; Q8 z' e8 ]: S# p
    模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。
! ^% \; Z2 D: l. I1 e

3 i. |  o6 {/ B9 `! x4 _( m' }
优点:效率优先、规范之后。
7 {  U* d3 x( Q# z
+ o0 o' n* ^! E
适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为第一原则。
5 e/ l+ ?/ |" {  g- N8 n" v

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

) Q9 d4 ^8 k; d5 W# V# W5 a% i
1.png
  Y- Z7 u' B) ^' I- b4 \9 r
  q7 c# |' }) x" w
        
2 M4 Z9 X9 T, _5 X
红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。
' [$ Q2 \9 K% j0 B2 U
* B$ m- \5 b  T0 H
        今天思考DevOps,要用结果来定义你的IT模式是不是DevOps,比如说版本交付周期,故障恢复能力等等,这一定是效率优先的。同样我们思考ITIL流程实践,也要兼顾效率,带着工具思维去简化流程。不可否定,他们有各自存在的价值和场景,用管理和执行的方式来定位,至于流程的模式,我也总结了三种供参考。
' j" W, w1 X. z/ X& n

; o' X+ S4 F! t3 ?
@ITIL是面向管理过程的;DevOps是面向IT运营过程的。

# W7 s! ?" Y" O% I' s; N# B6 X- J

% ^2 E" J6 r, v! {0 M( N
@ITIL是规则引擎;DevOps是执行引擎。
* n5 V- D- h5 |& u5 w# C

1 W. M( T4 ]+ T
@ITIL是强调规范的;DevOps是强调敏捷的。

4 u3 o% T9 t* K7 P& y3 L8 E

+ @$ e# Z# |8 h' [; j! Q( N5 n& B) W
@ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。
/ T! b% s( `( w& {

- e# A1 Y3 U0 D- B# s( i8 f7 x
@ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。

+ [( v8 o. E8 h: ~; b# H
! i$ K( u4 w" g: _. N
原创:老王

+ w6 L! N7 y3 h( ~

本版积分规则

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

Baidu

GMT+8, 2019-9-23 06:55 , Processed in 0.154685 second(s), 25 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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