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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1259|回复: 0

DevOps与传统的融合落地实践详解

[复制链接]
发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 6 K' e! b( @  i3 Z& H1 u2 n9 b, S
2 k7 a6 l- P' \# g% S
摘要
$ V% ?2 x* [" g" n; U

7 ]* u# ^5 k0 m0 W3 w  F8 i  q
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,ITILxf.com" target="_blank" class="relatedlink">DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。

. u5 U! t# E8 a! J! S% _
) {' v6 G4 U3 U" H: x
DevOps的全局理解
9 o4 L8 Z$ M! \' E/ I( I/ w
1.png

" J' v4 U0 X9 N0 Q
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。
3 q: E3 f. ?1 o) O2 y3 M7 ]

/ e/ P- u/ M$ T! N# |
DevOps与ITIL的对比融合
4 R% N, H4 a# R! l
* ?( t6 v! V8 O( O; A; \2 e
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
% v: V2 ]( i7 T

+ h# u0 t) E, P* F9 j
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
2 S! u3 k  T8 ]$ j  \7 n

  o- o; D* m# o. s
DevOps自动化与ITIL规范之间的融合

" n: g4 O& j- T( c. Q( p
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

8 J) c9 ^" a: E: i( a
# p& V% p& f6 v; \/ P& `6 ?
  • 第一种模式是在线服务开通流程。
    - t* u/ [" l* j: w" a, T! P

1 s1 G# ~+ R; v0 g5 t3 {2 Y0 x
  • 第二种是重大变更流程。

    / H+ }+ L& h7 N" r4 e, k' _

, ~- m3 t  ^2 d; K* j0 X  ?
  • 第三种是敏捷发布流程。
    / i4 M3 E) M9 ?  v0 u: H
) r5 B8 o7 Y9 @
从软件研发模式看DevOps
+ Y, I1 n% X+ d8 A0 Y# X
& f1 h4 \* H# r8 b  K( `2 b5 P6 q
8 w2 v4 n0 a. U+ z1 l1 D
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

' D3 N: _& W' I; H9 i8 o  K! ]& ^2 @/ V
1.png
/ n) n; Q. E: k6 m" z
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。

- P. l0 j3 k' X5 B- m- r8 s  P' ]
DevOps的落地经验谈

" p1 _* `  w! U/ ]
一、理念与价值先行

) X2 y6 y( W+ H- N) V9 W' Q

- a4 g! ^4 y; m; k& g! D
强调五点理念:

9 ~4 g4 z0 f+ v7 l0 N/ b% i3 A  m

8 X% e, o  L5 d: ?
1、通过持续的服务交付价值链打破孤岛。* e# ?0 {8 N( x. l3 x

# X7 z0 P: L% o! Z% e( X

  x" }6 A. M5 P3 B  s; {
2、整合开发和运维的能力,成为一个协作的团队。
# g9 P5 x, ^* n7 w/ K  J7 C0 @8 K" u4 S' Q$ i

( o$ Q6 @! C' H! ^3 M
3、端到端持续交付流程的变革。
6 B, \/ }$ u0 j9 m6 x9 S# Y. t$ \/ i2 G* x" H& E

8 @% n0 H, j( F( G5 e
4、对新的应用和服务,加快且缩短实现价值的时间。
. r) C) }  c' R7 A+ r- V6 F
- o) w6 o8 g+ Z6 n) a! W6 S& W5 B
3 {, ~7 I" L9 G$ y4 ?4 p" b
5、不影响安全性、兼容性和性能。

- ]: w- R& W( B) a9 x9 A* W8 w
1.png
+ L6 y1 J( z) ?$ C% j! a
二、顶层设计与全局规划
# d2 P- h8 \$ f. j8 O' i4 M
' w$ T: K  a. v; x, [: c
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
6 ?* |0 ], Y) y: z% }1 e! e1 B* p

+ E) d+ H8 @. U6 n9 [
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。
( ?% U7 E4 |% H* o: h

) k, u2 i, u0 ^# K) ]- Y
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。

& {- I" j5 }5 y. u* t# t& U
0 k1 i7 B- O7 ^3 ~0 l! W  p/ I! l
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

; o8 k3 C, d. i0 ~+ @
. ~1 B+ h' A: y/ C% A$ w
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

6 m; t: y& c) ?% [( X/ C; f

, L  r3 Y6 J9 [5 U$ e# z6 Z, D4 Q
基础设施:虚拟化到容器化的平台。
% e( ]% u& z& p8 {1 D

' C0 W* ]! ]4 O9 o
度量:度量体系能不断驱动能力优化。
/ @/ \) o: ?& y9 _+ m% N

3 O- {* f, I. p8 D$ f
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。
8 i8 C6 N& H$ O
1.png
% z7 A: {. P! S1 N1 k3 c% h
$ [4 Z# _# ~9 |! D6 x6 P/ k
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

; C2 N, G& f7 X% {

. n/ C) X1 s+ G1 ^. A  `5 _
三、Start Small,从小做起

7 Y8 O$ d' h: Z1 H+ Y5 f7 T7 i* q

5 b2 p) m+ d& ?" @1 u$ y
基于某个角色和某个场景去进行从小做起。
: w; L& }% H- O* n) a( u5 q

, t6 L9 o% ?! d3 @% S) z  p
基于某个系统或者某个功能域来实施导入。

$ F/ ^( E& ]! f; H9 X. T  W3 n
5 ?! C' Y! F& }, r4 h
切忌贪大求全。
- F/ W& {' t. f8 M

5 n0 F+ I7 |# O
四、构建IT元数据平台,驱动IT平台间整合

# O) D3 z* U* v  u$ W: S5 R% x! e, z
. @7 O% u! C, H9 a0 h
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

7 C7 n, @, Z7 q0 z+ ]
1.png

$ p) T! C  @" p! U& p
五、痛苦的事情优先解决

, I$ V& h( M; h. T) H' q
* v8 `0 x# D- B( A8 P; R/ G% z6 E: W6 _* Q
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

/ T  T7 Y: r. A9 k1 ]$ S( Z9 b- V# N$ G4 C( s; L( D
六、工具也是一种文化

) x# u. u4 ~. Q3 L- N3 s/ {8 y+ Y
3 c$ X/ P* @' \% c# T. c
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
+ N- Q7 r. |+ }$ e

1 E/ K" T) d! m* N( q2 L! b* C
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。

' x7 [2 X% }1 d& g6 u- s8 I# _
: N' U7 v3 \' m3 b6 N+ }' U
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
/ q' L; R1 ?& e! ~- K8 }" q0 n

1 C: y% i2 [* c# B, b. G3 U
七、组织二次元,加群落地力

5 i  l: ?# Z' r6 l5 x6 H

2 Q! g5 [$ G" n% T% ]# c( {
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。* @. T+ q  s% u
- J% O5 O' |2 c
八、价值拉动,而非事务驱动
, h. Y' f4 V( x/ W- @0 D
3 w5 O. Q- P( a1 g: j
经营核心的准则就是以家客户的价值流作为驱动。
) Z5 Z% Z" u$ W
1.png

. }3 T, t7 h/ [) z# s
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。

) \. Q% ?! t- {4 n& v

6 F. m. M! e- D( V* q$ D
九、平台+插件=服务能力产品化,和组织一致

: y9 N! c' K0 ]( S1 o) y, S

7 Y  A4 D; i% G8 `' |
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。
8 l. O: P6 Z) c1 M

0 \$ z4 N$ F: m
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。
8 E# ?! B2 `! U
, |& [8 J! K1 M0 R; B
十、自动化别人,先自动化自己
8 I) @6 i- L' Q4 I( v* P, ?
6 k& \7 Z% R1 s" T! z# k$ T( W0 z
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。

( E0 i% k8 @& x- {1 Q6 |! M4 E7 [: p1 L; h6 a; D* B
十一、持续交付是DevOps落地的最佳实践
4 N8 b% @6 z9 a3 V

/ ~9 [' S) A2 h
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。
: ^; {+ f2 Y1 Q! s. d) X: _1 R
1.png

7 y' Z5 P& K0 l6 J' O
7 U+ Z9 E% ~9 U# O5 g# Q, C/ W' U
十二、IT运营管理驱动Ops能力建设

* s# ?: u; W9 e

  A* E3 b9 z) E' [4 ]
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。
9 {& T9 B; J6 o' r
1 s. `4 e( g  X' n0 `( F
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。
, u2 c2 `% i5 \* w( m7 _5 l
1.png

. ^( @# F/ X, I( r

7 ~1 X- O* B! ]
十三、构建面向应用的最强管理驱动力

, ~6 b! k# C2 h) M9 t
1 {5 `' u5 _+ E# S1 U8 C
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
3 m2 ^2 J; {1 j& v4 z- N6 X) F
* C) k% c8 \+ M1 }
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

+ l3 Z( x& G9 h& ~) e  E) D& I+ Y3 T

4 \% U2 B; r# B% f( i' u
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。
% b) d5 V# k0 a2 z- U0 M
* D7 S1 Z/ y2 C+ ]
十三、构建面向应用的最强管理驱动力
7 C8 |  n4 |- X- Y! O

" v2 o' X1 c% z- e) b/ `
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
# G, z" [9 F. `# i% H

7 n: o: Z6 y2 x
十四、构建指标,驱动DevOps落地

+ V* P) I4 ^* o& a+ f: Y' c

6 t& o4 z  b' ]4 ^* E
1.变更时长
+ @, H- h& k# O6 d' N4 M
# |4 B) v) F! V2 f
2.服务恢复时长
- G7 N. c7 Q: x% K1 X5 {
3 Y8 Q/ C" ]. C5 v6 s5 t8 Z
0 e4 K! |# A( q# m$ H, B% \
3.发布频率
* W3 c( K* y5 [3 A5 {+ S/ E
% W5 x2 b# b! U; e, Z* x
4.变更失败率
- R% O* E* n: Y, f: r
7 A1 A6 [4 G$ \, [9 Y  A
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。

7 y( c1 O. X, I9 C

6 Y. D. `& P. d% g* p  p, [
我的分享到此结束,谢谢大家!
; t: t1 o$ m* N- d
4 H6 S7 P/ R, D2 s( o5 ?
原创:王津银
( K. }" C+ c, L) M: o2 r




上一篇:关于DevOps术语表--已收录202条
下一篇:企业实施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 04:13 , Processed in 0.278161 second(s), 29 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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