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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑
, ]: F: C# t0 s) _' M: }6 k: V
$ H+ Z) z" J" f! w" l. H3 L
摘要
" @% ^) L9 Z: Q: N6 Y  Y
) t: P: r2 z' `8 X5 h/ }) G: P
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
; B' X, F( {0 K

" \; g8 C: q! U
DevOps的全局理解

% E1 E: G7 l# o' A2 |# o% F; U
1.png
; I$ N/ a+ W/ v
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。9 l, Y7 [9 m& d# l5 s

* S! z, y- r. e2 `$ d
DevOps与ITIL的对比融合
8 p$ K# [" F) I0 v5 ]* r0 ], N

" Q/ J6 ^4 F" t8 e
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
9 L) [/ t( v6 @8 o- g

. e" L) G$ o- T) }; y% `
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
" a- [: t0 Q3 f: W' o
4 l( w3 a8 X# J
DevOps自动化与ITIL规范之间的融合
) ^2 |- v: P, t% [  Z4 ]0 r- H" q
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

2 k% d' t8 ]2 j5 C& \

2 |" z" U' i* p# f. H
  • 第一种模式是在线服务开通流程。
    . A1 X5 A1 Q" I. Q  j
9 J" z4 N" p8 s1 p  n% S
  • 第二种是重大变更流程。
    . G9 c! j; E/ I% D% U
" r- O$ X% w* U% [7 Z! X$ k
  • 第三种是敏捷发布流程。

    3 z5 H& v# d$ {+ i! q7 w1 a, @
6 u. D/ U3 @7 s8 l' U. Y; R5 }: Q
从软件研发模式看DevOps/ h# T8 C) \  H5 T' [! N" N

+ F$ i4 T9 }3 a
2 m* z0 p% J. t
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

3 T  R4 L: T; c( v
1.png

+ W2 Y0 F& ^! M; ?( d2 h& r# F6 `
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
+ s1 p# C' g  X" m
DevOps的落地经验谈

4 E7 n" r1 R' |% \: U1 w
一、理念与价值先行

! ?; h6 w! j0 {$ V; c3 p& |1 `, R

2 G% x0 }1 R' [- P
强调五点理念:

/ T% Q$ g5 d9 V0 S

. _! g! }# ~- p# R3 x
1、通过持续的服务交付价值链打破孤岛。+ a( }' E* c+ y) N' F% C8 i
. y* }) A, a. f& z  C% W

: e1 ^3 W* o$ j. H+ _: i+ V: v
2、整合开发和运维的能力,成为一个协作的团队。6 ?$ B6 |3 \, |

% R3 j0 R3 l. z5 g5 [4 X
7 n3 ?& ?' {' V4 K
3、端到端持续交付流程的变革。7 t# p; A1 K) y& N* E
0 {) D: w! a( n2 Q- P
$ H0 ^% I: W* g- a  U9 }9 B/ l
4、对新的应用和服务,加快且缩短实现价值的时间。9 I4 L) G& x; R4 m

$ k. H& O5 K! n2 }5 ]6 o, n- T

$ y& e2 R; H' Y7 y0 m
5、不影响安全性、兼容性和性能。
) Y" Z6 d5 Q; v: e
1.png
7 ^' L0 c. o2 b3 K8 D6 _) B: r
二、顶层设计与全局规划

0 i' z6 w# L3 U6 ^8 T, j! ]& d

. q( |* @2 [. ^  {' D
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
1 Z5 ?) g$ }; K. T& q, P& S

! j# Z# F2 S. L6 ]  r! u4 L2 b
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。
- H9 h, V  M1 c# _" K& f' J
( ]! [' E* E( z* S2 Z
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。
' ^' J0 R  b, K- a" V* A

7 H6 C6 w! @8 N, {
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

/ ^8 p/ }. _% g$ q0 ?& Y% Z# z

5 q* o0 y" ~0 W: H0 B
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。
' x- @. w5 T; J  k% c' O8 b
( D; i. l0 F1 q- c- }% x
基础设施:虚拟化到容器化的平台。
: j) ~# H: k3 l. ^$ R7 h9 |

. \: n" p/ n+ r  g, ?4 ]. q
度量:度量体系能不断驱动能力优化。
' }0 i% r- F) N3 u* H/ T; Q
% F0 l* @4 g, c. n, t* v* c
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。
7 G; \. n7 M- A  C% l
1.png

9 {* h- m" y& i: J8 v
  x. K/ C' H  ]0 ^+ y
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

9 Y4 n9 W. A# R9 C. k2 `3 n; b, y# n" a
$ A4 y' Y* x7 S- W
三、Start Small,从小做起
/ i' g6 [+ Z. ?2 ^1 X6 U. c

, d+ P* w' R- s2 Z$ x  ^. |
基于某个角色和某个场景去进行从小做起。
3 G$ M" F# W; H% [& P' i
+ H4 G' t6 F% Y! _% h
基于某个系统或者某个功能域来实施导入。

, [% k/ J7 H" L+ {
  S7 J  _8 D6 A2 O
切忌贪大求全。
" O# r  ?1 o) T% j# V' i

( t9 X  c2 D1 i# u& |$ T
四、构建IT元数据平台,驱动IT平台间整合

( h2 @: |! l: p0 k& z, O8 H* ?6 U9 C

/ P% i8 J  w* D% }, S
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

# W6 n+ p# {1 u; C, i
1.png
5 W# _% b* |9 A6 m
五、痛苦的事情优先解决

5 p. A6 v, w8 L
: V  N" a' n$ a
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

$ {9 ]; S. q, z# C5 w
' r& P: N1 i- Y. j
六、工具也是一种文化
4 |( N/ _) e4 W6 E

3 F" _( E0 r4 Y: Q2 F
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
7 m! _, W- c- W: L# p* E% U

9 b3 V2 X) p' k. T
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。
; Q- N$ p& G. H2 t4 z

# M; u( R0 u- z# q$ N3 E# i
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
) L- j7 ]" o' J; b2 O

5 O! B( R3 M, ~0 V
七、组织二次元,加群落地力

. _2 }0 T2 n1 o, _/ t% z5 I! A

" ^# z/ O% L9 e3 |$ F8 P8 k
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。8 a" ~  X' o5 S3 h
3 F& s! k  x* B- e/ O  |6 |
八、价值拉动,而非事务驱动
1 S: c& Q- m8 A9 n

  C  x, b  g2 _* _0 n2 V
经营核心的准则就是以家客户的价值流作为驱动。

+ k# c; ~* o2 b7 R
1.png
) V# v4 c3 f1 O2 _$ c
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。

6 X: y1 u& L; O& X  ?( s, X

$ z) v% z7 a+ r5 @1 u
九、平台+插件=服务能力产品化,和组织一致

1 Y; b" [: ?' B7 w* O# v" L

! s5 [4 t3 K6 Z; }
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。

( ?- e. B; y% T9 Z( H  a9 n

/ u! s4 l' s* A
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

" N. p* P- L0 p+ k+ T' s
5 `1 [& ^! O; w( H$ P0 Y; A
十、自动化别人,先自动化自己

2 F2 m7 }0 T7 ^
+ r/ a, m* u; s
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。
$ S. f# w7 C# I' S; y8 E1 J

: \+ l6 J# |9 l* W$ i% _
十一、持续交付是DevOps落地的最佳实践

% |: j/ U: b) r1 o; G( V* j! B

) o( N& b- ]2 I; G. q9 K
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。
4 S# B$ k) H9 t
1.png
/ N5 P! U* ~- `- k* m1 I  \

0 v: \/ `+ }; m  Y" Q) i& E
十二、IT运营管理驱动Ops能力建设

  Y( Z. Q. E! V

5 k( I" K, w" E6 `: k1 P7 [9 d
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

# M( q( C( e+ R6 }

, h% G4 F8 Q0 b6 g' S" O
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

5 ?& _* H9 G- {* M9 U- W
1.png
: D4 k( Q7 m& W: T3 f

1 o1 i* l' f! v6 Q0 X6 ?9 W: E
十三、构建面向应用的最强管理驱动力

! K; f4 Z8 G6 R$ N9 t1 h
7 @' Y; U7 {' X1 a
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
; X3 }9 }' c2 w- q
3 _/ `! g" {  `6 C; i# i3 M$ i
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

% l$ _, Y3 L; n5 u% }2 F2 T, g* a2 u0 _7 M

; A1 B3 D3 Q( W, H8 n% e
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

' r5 ^. F! S) o' H
" {% r5 u  r2 w/ M1 Z7 c
十三、构建面向应用的最强管理驱动力
4 y3 S: c, m" Q3 @6 o
0 a* w& |/ f5 }) M2 K8 W
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
, M8 m. U( O/ v& Z- x

" [2 x' c/ J; G/ z+ \. `' R$ q
十四、构建指标,驱动DevOps落地

/ n: @9 B' H) e8 G6 l+ o3 x" h2 i
8 s2 v5 A& R9 [/ w( {3 B, ?1 Q+ z
1.变更时长
8 p) p/ b; `) r- r5 y

3 W% q3 I' y# o3 |3 m$ \0 s0 O
2.服务恢复时长
$ M# p  ^9 M  C2 A

4 b5 i  \5 N; W7 m* w2 {4 j* h
) X5 v* o- v- e/ ?
3.发布频率

; w- ]: `9 k* u9 t5 _& S
6 f0 V/ o. q7 b) U! T
4.变更失败率
# P7 z! C, c5 X, _% p7 `3 f% T& }

! S  D' W: K$ Y# c- `) u
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
9 w9 @: b) ~% q8 h4 _$ w
7 j. k5 J  l+ ~0 U1 d. i
我的分享到此结束,谢谢大家!

; j6 A( H. q& n1 j: [$ t# D' ~

+ i$ s( G# @# R9 i
原创:王津银

* s; U+ _6 j3 G  k% |

本版积分规则

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

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

Baidu

GMT+8, 2018-11-15 08:25 , Processed in 0.264889 second(s), 40 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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