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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 9 V1 U( Y- U! [8 W" ^

0 s5 r4 l; g2 O* U3 Y- X3 m3 I
摘要! a" D* R& i2 r" k
" `% X4 A3 X( J7 u) h
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。

9 Y% x; c' ?5 j# P
5 S' a" K9 n0 ]
DevOps的全局理解

3 y5 Q$ r# y4 A) Z5 c! I
1.png

6 ~* C" {6 K/ z; d
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。
7 c' C% X" @& R0 {
9 w6 H3 E# A  ]) u
DevOps与ITIL的对比融合
1 J' N+ Y" u+ J1 h

% x) B1 O- {/ h0 b' J; D4 K7 ^7 W
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
3 s+ A6 b2 t  f: ~4 m' e) t
3 o4 h2 ~5 F' W2 T4 a) \
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。

! R3 ^3 L$ R5 c( L5 V9 F

8 y1 w# `% v% t2 I9 c
DevOps自动化与ITIL规范之间的融合

" K: U- }6 p% b' }: T* \* o1 j
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

/ Q2 e& U; _- Z) Q

1 L' T; z1 n$ {$ d
  • 第一种模式是在线服务开通流程。

    " T" ?' H& e1 R* A  J9 r

& k+ @4 W3 V9 e" S7 X' L
  • 第二种是重大变更流程。
    * e; |8 a" O9 g- z

$ n5 \$ h- `. t2 B- @
  • 第三种是敏捷发布流程。
    # r' t# ?, W$ y4 |
6 {1 X0 ^4 a% D$ O
从软件研发模式看DevOps# R+ E7 T8 J0 I

2 V7 l! a5 T# L* k/ `4 ]

# W0 X# u  I9 q+ ^# T
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
' Z& K  B- b* R6 \& k7 Z, S: t
1.png
. d1 M4 y- N' s. b+ n
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。

; s3 \& Y. k# m7 T9 H/ J
DevOps的落地经验谈
' c) F0 Q9 o2 I  S" V
一、理念与价值先行
, d; P% \8 T! H

' V- t4 L6 {3 C5 f/ S; H$ u* B8 E
强调五点理念:
$ u# E7 |" h1 C9 v) C
+ ?. g6 N8 c# ?
1、通过持续的服务交付价值链打破孤岛。( t7 ?+ T/ D/ J

) D: |2 J5 l$ ^# ~: g' V
6 H) s/ ~+ G  u' {" W0 `2 W( C
2、整合开发和运维的能力,成为一个协作的团队。  a- y% m" q+ d3 E/ Z
1 U& \4 R( n# f9 v- _
9 D% ^8 X7 Z' g0 n
3、端到端持续交付流程的变革。
. N3 S3 N* q* K6 O# g8 i* A
- _; M/ e9 _* q5 C2 |
; f5 W2 v+ U* p8 |
4、对新的应用和服务,加快且缩短实现价值的时间。
6 e+ L7 ?" X5 |
" c, X- S9 }8 p7 w) `  q

7 R/ J9 t, ]3 `- h8 f. t+ x+ x
5、不影响安全性、兼容性和性能。
8 a- @7 k; a; f
1.png

6 j. ~$ J/ \$ Q
二、顶层设计与全局规划

" y# [' @( Q# n: R, n9 @4 @: G2 y. S
) B+ |3 Q0 Q  i7 h$ ]6 Z
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
' |( O% i+ [& `! M$ m  M( c2 y

! p. V  R& u' |/ X, z
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

" P+ _6 w1 U0 I3 h  q% ^

( f, O. `+ G) f
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。
6 r( s9 L% p+ H8 i8 `
2 Z+ [, {* i3 w0 e
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。
' M( W7 ?; R5 r1 ^9 n1 W: s/ _

1 Y) m9 n0 f$ }1 r# W' b# V
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

/ D- b7 F7 _2 {

" i. A$ K& o4 i
基础设施:虚拟化到容器化的平台。

  L: V- R% y! Q& @

# b' s7 A2 Z3 ]
度量:度量体系能不断驱动能力优化。

3 m& S$ `" U4 [+ s
: _1 R5 Q' R7 x/ q$ J! g8 e) X
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。
) y: F; U% k) D) O; a& l4 E
1.png
5 J! Q+ e  ^3 x; [1 \* a

" k) o' {, }  _# l* v1 [* k$ o
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。
) c. M1 a& C$ {  I4 `+ t
1 y& ~5 ]1 j; S* Q% o
三、Start Small,从小做起

3 f7 N+ U% ]1 `8 a( S' A( T7 W
/ D' [! `5 Q' U1 ?. X. ?; {1 A+ ]
基于某个角色和某个场景去进行从小做起。
" `# j# u( e/ e: ~: j. B' p7 q8 G

2 c( |7 R: D8 N$ W7 ^7 M3 l3 y3 W
基于某个系统或者某个功能域来实施导入。
. M5 E0 p; X" J3 Z8 @  ^

0 |- G% G7 E7 ^- g' r
切忌贪大求全。
' J8 O, F- d9 j, H: X

* l' a; q4 G7 A, t" N
四、构建IT元数据平台,驱动IT平台间整合
9 l1 L" U% n( L1 G0 T
9 @4 D$ A3 y: u% z$ R7 w; m
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

; H+ L9 M7 S! D+ @: K5 J
1.png
, M7 ?. M" J8 }4 s. c
五、痛苦的事情优先解决

/ {0 s9 Z& u7 I# z5 k# c
( L, r; K" \0 D- z! s
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

, K% Q" u! q3 x: D! M
7 j% Q6 G4 m/ Z
六、工具也是一种文化

8 y" `' x/ o9 H

' v* F8 ^) w$ g, Q' F$ y% y
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
0 m; p, }$ {/ w+ s4 Y; f
6 u: O5 q" A' F& C9 C- t+ M
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。
; T1 J4 R3 M- q! }" u

4 I1 s% u2 X. {% z* o! H
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
% ?9 Z, T7 v4 n' u2 g

' L5 [' \4 O/ p2 F) W+ c
七、组织二次元,加群落地力
, o' k, K3 ?' ^4 h2 \- _3 Z& k

# [0 z& E, k- j: k1 P- Q
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。
  O( |3 ?6 n' |+ x. w. g. e( o

9 ?" \, a6 l+ m. y
八、价值拉动,而非事务驱动

6 u4 X# u# }0 i( u6 H, R! f
6 _7 l% D: `5 ?9 J* X1 F1 V
经营核心的准则就是以家客户的价值流作为驱动。
5 h9 T2 l& u( X/ @! `- y( m
1.png
  B$ A: x8 _+ k) o! P0 L
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。

; ^1 h* q2 n6 f

0 C3 K+ P9 O, g9 y5 Y' c$ r5 N
九、平台+插件=服务能力产品化,和组织一致

7 j9 {% X/ Z( a: W
- w9 |* @2 R# J7 B- l
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。
$ b/ ~6 ]) z" `5 Y
' h! P  B. R5 E# v% V1 q
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。
. `; s$ z+ m% ]- o
) |. q% M' F# U: g/ \# }3 f/ ^7 d
十、自动化别人,先自动化自己
8 f7 F3 u/ q% e  B* r; ]
1 L9 q& l$ O" P, F) H0 o7 D
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。

1 R9 a8 d* X5 i, O" f5 L& C9 R! B. w: |% o. L& r  ?6 I7 M, \* R6 B* `
十一、持续交付是DevOps落地的最佳实践

7 v7 l+ n4 ~8 ]; o! m; r

9 r. d1 y% q. V+ T( ]+ j/ M
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。

: L' G% }' S% x
1.png
5 |- {  c: }: E
- g) g- [/ [+ S; G0 i
十二、IT运营管理驱动Ops能力建设
( h2 T0 e1 ]+ E/ Y) l
1 _* Y+ I/ o# y' Q
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

  |' j) g' o& Z/ B: K& V
4 K" F% t: `# \/ z
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。
2 ~, E5 P2 v6 Z1 I. E
1.png
  }) _; I$ W( G& n) B
2 V& R9 X4 C4 a- Z1 K1 g+ T
十三、构建面向应用的最强管理驱动力

* o& C7 D8 p& |' f
( @) P& c/ }% a2 Z
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
9 U: b( o- H. X3 Z  g
+ p& A2 B+ i% I& D4 L# v* @
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
0 O) d* \8 W, O' o# w/ B
2 g/ U$ x4 F# n" d
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

2 |- `) A& p3 p) p$ h2 a6 U0 r
: X) m3 K2 X' G5 O- y+ Y
十三、构建面向应用的最强管理驱动力
  B* \5 X: ~. }3 F$ j& K/ s
: m  A' Z) N0 K# [! s7 E8 ^
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

; S, O$ q5 Z- _; q
) Q6 F0 v2 W- S' ^
十四、构建指标,驱动DevOps落地
7 o6 k. v+ S: _( u9 e- X; u

! b7 m$ ~; L! S2 c8 ]
1.变更时长

4 ?+ I8 {! U+ w0 h( s, H6 Z

1 q" j: {6 S( t# J) I+ T
2.服务恢复时长, n6 {: t3 U) N% ?, P
. W/ X: P/ l% v! p- c/ ~
0 ]" n9 O# m4 e. A4 Z
3.发布频率

2 B% `$ p9 P! V

( ?9 M. i& E, G/ g& Q* P
4.变更失败率
  }/ }$ I7 X) s0 q  J" t" v

. Y) U; U0 x. V- s8 R2 f
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。

2 w7 R1 p( ?. _  \9 R

7 Z7 g# x5 W; V7 B. v0 k
我的分享到此结束,谢谢大家!

: X* K' S6 K. a6 |
: L$ _4 H1 s- w$ x# T, w
原创:王津银
) E5 Z* ?! A( t" g

本版积分规则

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

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

Baidu

GMT+8, 2019-1-17 11:17 , Processed in 0.289334 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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