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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1711|回复: 0

一起探索ITIL和DevOps的边界

[复制链接]
发表于 2018-9-25 16:09:54 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-25 16:14 编辑 8 ~& ]# C% K0 m

$ T& a) ?6 M5 @" f3 p7 M# E
   其实在今天的运维领域,ITILDevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。
8 T* T3 v* l! W& m- ^0 k! f+ _2 X7 q
. V1 \( O2 D% H) e- g
+ _! e$ s1 u, D/ |. [
        在EXIN官方给的DevOps最新框架中,把很多因素糅合到了一起,对于整个产品生命周期来说,可以看到几个典型的阶段,如敏捷管理、持续交付、IT服务管理。
1.png
' Q/ p2 {; ?9 C+ H, r
        
! X/ Y' Z, u$ e7 f
当然这篇文章不是简单的从DevOps与ITIL的全/子集的关系来探讨,那样就可以直接下结论,退出讨论作罢。

( v% y. E: f) O

+ L5 K  h7 k* [! i+ E! O
首先让我们来看看持续交付所声明的原则:

9 B$ i4 s5 g' N1 z5 V2 V6 K

: S3 p1 n) q# O" _. ^( V; `
•为软件的发布创建一个可重复且可靠的过程
/ N1 l) }: e4 w7 {' Y

( g( b8 F" f: ?! _. c* l1 j& j- d
•将几乎所有事情自动化

# U/ O. O1 Y% k: O) E, W" ^
( s2 w# a/ _& M$ Q' y) [* E
•把所有的东西都纳入版本控制
2 w  H  ?; |4 F( o7 T5 c$ U0 O7 n
* Z) [% _/ W- k$ d9 n& k$ M9 x1 F5 i
•提前并频繁地做让你感到痛苦的事情

' P9 d5 a9 @1 Z! r( T- \

4 }% b+ W* f7 |8 {& o, K9 u
•内建质量

7 \* h( q5 B5 G& M% }

& }$ S( N+ z; X; l, d, f. e
•“DONE”意味着“已发布”

# [( r" n, u  z- ~, s: N! s% B5 W

/ f9 ^% s8 o; S  w- ?5 d
•交付过程是每个成员的责任
) k+ K7 A+ H5 [- ^  b# y! n% j* R
+ q5 k% d: O9 F  ^* a
•持续改进

# H3 t+ v* o1 o' y) C; x" K

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

, i* C* W: G- V9 t0 \+ B& E; `6 j
       其实IT运营和产品运营有很多的类似之处,只是两者看到了对象的不同,一个是IT对象,一个是产品对象。所谓运营都是在建立一套服务流程或过程(有ITIL部分),整合公司内外有限的资源所展开的一系列活动,以便更好的服务客户。狭义的IT运营可以理解成维护,广义的IT运营可以包含产品体验优化、用户满意度提升、应用性能管理、安全、质量控制等等,质量控制算是IT质量运营的一个维度。- A* O1 x5 j" v5 R1 Y" a# W
2 G3 X2 j4 P. i# E0 `  I! c
" s+ S$ I9 R: G0 X' @( q
        既然在前面讲到了自动化的原则,那么针对运营过程的自动化到底该如何做?如下图:
! s& U, w$ Z: P% M0 u$ w1 u9 ?5 X1 {
1.png
9 S0 Q! ]7 ~+ v3 W4 ^. I
      

) _6 F4 ?- @* N0 ?, x6 w5 j# k
可以把流程或者过程分成两部分:一部分面向管理过程的“离线任务”为主,一部分是面向“在线服务”的执行过程,管理与执行兼顾。从互联网现状来看,ITIL的作用力越靠近应用越弱,在传统行业这样的表现力到还没体现差异。
3 q* i$ E7 y4 r4 n; N: j- \

6 i) S5 ~1 q$ D/ o+ E
    两种流程如何结合,有三种模式:
1.png
1 U1 Q( U6 h/ j/ g9 b1 |

$ P- a3 G' M1 }3 w: h+ ?
% {$ S! A* I% G8 y$ [1 U
注意:左边是管理流程,右边是DevOps执行流程。

" y, ]+ m7 a6 E, N' r. x# I2 p
# w" A  m6 z7 _, p1 H' g; Q
    模式一:每一个流程节点都需要调度一个执行工具去作业。

3 G1 {2 Z% B! L5 w( v5 _% F( \$ k2 d

# M  S4 H4 E1 y) Q( [
优点:流程效率大大提高,整合程度高。
, Y6 a; c2 @3 T9 ?

* v: C  j  {+ p0 e& J( I+ X
适用场景:CMDB资源申请流程、一些配置变更流程等等。这个模式已经不是从审核者的视角去看待,而是关注执行者的视角。

* G# t% M# V, {' }( o

; x9 f* ]$ _( y! U
例子:CMDB的主机上架流程片段(某证券)

$ c' o$ `% F% Y

5 H7 I- m$ M3 s  q

5 G1 i8 [& \" k0 s  t
1.png
3 }& }* g6 i. k& F3 v. a+ Z
8 h( g* @: m! h, i2 u: O, w
Process是流程平台,CMDB是配置管理平台,RFID是主机管理平台。流程平台已经开始直接去驱动相关平台。这是当时设计流程的时候(对应【选择机柜】环节),该环节和其他平台之间交互的时候画的交互图。
2 a& v3 r/ a9 k

& c5 y+ n8 u- c) f6 d# h1 d
    模式二:审批流完成之后,执行流程才得以进行。

9 `# B2 {* x! F+ N: C+ r7 }

8 y3 v; F' f( `8 Q' o
优点:流程规范优先、兼顾流程自动化能力,但流程本身的效率没有多大的改变。
3 ~. Y' _, ^/ D) @
# |& o! r* v. r2 I# y/ g0 `1 T( d/ L
适用场景:对于大规模的变更或者发布类工作,或者传统企业的变更流程。该模式是从管理者视角出发,把效率与流程兼顾起来。

* m2 C. {/ m! \  \

  Q; L1 }8 Z+ K  D7 k3 g
    模式三:在执行流程中设置一个节点,定时去check管理流程的审批状况。
9 t! `9 j% S$ l3 `: {+ u$ w
, x8 E- D; ~/ z+ T* V# U
优点:效率优先、规范之后。
1 D, a" I, L- F; v6 U

$ _3 b* K% [* G  m) O! N
适用场景:互联网化的变更发布流程、持续交付流程、运维变更流程等等。该模式是从执行者的视角出发,以效率为第一原则。

5 Y1 j* _$ ?" T$ _+ A1 E
: h# u) Y. z+ M/ e
例子:这个模式遇到多个真实的客户场景,我都推荐采用类似的方案。特别是一些流程不在ITIL中的情况,比如说他们使用JIRA系统做研发过程管理(如发布流程),而运维部署平台则是独立一套,两者如何打通和整合?JIRA系统中会有某次发布的流程,此时在以应用为维度的变更升级流程模板中,会有一个Check的节点,它主要用来查看ITIL流程的状态,如果审批通过,部署工具中的执行流程则往下执行,称之为“红绿灯机制”。把ITIL比作马路上的红绿灯,把DevOps执行工具当成马路上的车子,有序、效率、安全等各方面都能兼顾。
/ `7 t8 y/ W- S5 y, e! T% }
- W" p$ P4 v3 H! U, M! m3 ?" t
1.png
/ F$ \# q8 _# \" p3 O
7 r5 F% Z4 W3 L  Y6 {$ p3 i6 ?
        

/ Y4 M. Q; D; D. h, b" m6 Q7 m
红绿灯的复杂度也是视道路复杂度、拥塞情况、车流情况等多方面因素决定,这也就如同企业的流程复杂也各不相同,不要一概而论。
7 Z9 O* r" K9 S! q" Y% ^

/ p: l' A- i+ i, s3 u& @8 u" e
        今天思考DevOps,要用结果来定义你的IT模式是不是DevOps,比如说版本交付周期,故障恢复能力等等,这一定是效率优先的。同样我们思考ITIL流程实践,也要兼顾效率,带着工具思维去简化流程。不可否定,他们有各自存在的价值和场景,用管理和执行的方式来定位,至于流程的模式,我也总结了三种供参考。
2 b# T; r: v$ v. _# |: F
/ B; b& p. h+ m. V
@ITIL是面向管理过程的;DevOps是面向IT运营过程的。
+ F2 q( x* x( e
+ G/ i  T1 f; V* W6 A
@ITIL是规则引擎;DevOps是执行引擎。

! f' i0 x1 ]8 _$ g2 y
8 p8 o0 _7 M3 N+ h1 W
@ITIL是强调规范的;DevOps是强调敏捷的。
0 ^: U( E1 Y& u& _0 U7 K

' J: [/ L/ t# Q( S
@ITIL是以离线任务管控为目标的;DevOps则以在线服务管理为目标的。
: O( H$ W$ p4 p6 g6 E
  C7 y3 ]1 `3 X1 [7 m! Y3 q
@ITIL不等于追求稳定;DevOps更不是以牺牲稳定而一味追求效率。
! P$ M" Z+ A! j& j7 ~
+ V' i; _6 N" t9 M7 i5 e0 ~) G( Y
原创:老王

. P$ K# h% r% ^8 \




上一篇:DevOps转型是度量驱动的?
下一篇:2017年DevOps使用状态报告
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 03:18 , Processed in 0.106038 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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