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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 / I) ~3 o4 T0 d8 n/ `5 I; M) B( v

! J" X1 \. P& R+ Y% ^7 l* g: p
摘要
1 [* Z- K: F- h( _) Y+ f! z

: e6 b6 X  M% @  b* S& K% h3 M  L& P
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
" i* L0 `, @6 ~7 ^: \! k
' t. o( D7 U' `; o/ ?' y
DevOps的全局理解

$ `) ^& x# e/ n) k) g& z) D
1.png
1 T9 O! |4 S. C  ~1 y" K
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。2 V. X  p+ p& n: L4 V- H
) z# w! |. P8 d' z* {5 `! V
DevOps与ITIL的对比融合
, @  F1 k/ W- ]% z. ]! h+ _- ~8 |

0 e7 u4 M1 Z! T% N; Z" I& d. M, e
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。

) X% k5 ^* c5 ^- D

" j6 ~3 M8 M1 f
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
: r; G5 H$ Y4 ?3 Y: u/ c3 N% ~/ R$ \
4 \  W5 g1 u/ Q, H) D/ H
DevOps自动化与ITIL规范之间的融合

/ {! s! `; y6 l0 S0 \2 q# }7 x  Y
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

: L8 s! N/ n' }+ g
: @& L7 g+ V: h+ Y+ n0 W+ T
  • 第一种模式是在线服务开通流程。
    8 j4 [1 k9 K- K9 f2 N$ d

1 j# j9 t# |& r" c2 s
  • 第二种是重大变更流程。
    & `3 c, h3 r5 m0 ?& L! ~: I# n
9 P  o$ Z9 A$ d  Q' V
  • 第三种是敏捷发布流程。
    ' u2 t, O/ D% ?5 e

. K4 o2 `: V2 F0 ], H- U4 p) l
从软件研发模式看DevOps
" U1 U% Y7 D; U- _
0 [6 Q1 f$ j* @: ?
! e' R! Y$ W) I  l0 N
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
4 c0 n! d( p5 s# N5 R' c0 H6 X+ w
1.png
( j5 R3 e/ b1 O, X" H
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。

. }1 {! y# x0 G0 C& N9 n
DevOps的落地经验谈
: t# r2 Y& G. [* N
一、理念与价值先行
' K9 O, Q- T( d) ^, I( Y( g) k( Q

+ a% i, U3 q  p9 d1 |
强调五点理念:
* ~0 u$ n2 W4 L

/ C( T* R$ J7 d0 m
1、通过持续的服务交付价值链打破孤岛。( v% b2 x1 _) z0 }2 A9 q( Q, X
7 K5 j4 u7 K% O9 [- {/ v6 V0 u' q

9 W) o, ^, s& B" i! m. Z
2、整合开发和运维的能力,成为一个协作的团队。
$ Z6 ~- l, n5 l7 b6 `/ X* |" a; e% ?
( C5 j2 B3 @' Q
3、端到端持续交付流程的变革。
/ i" y6 S4 }8 z  A* O0 |! d" `* B. g
# E4 L! q& s# x6 X4 H% ~0 _
4、对新的应用和服务,加快且缩短实现价值的时间。
$ J# I: U1 F3 E0 U3 j4 J  J; F+ l  a

5 k& t0 |# v# g6 a1 ~, L
5、不影响安全性、兼容性和性能。
6 }( F. k; _) |
1.png

0 M1 H! E/ e* L# |; R* a3 n
二、顶层设计与全局规划

( a8 B: Y6 C) U+ e; @. x- Y/ Z3 U

: S  T5 l6 F6 j8 S1 c: V$ \
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

4 ]# s/ D9 j8 ~0 e  q! z
& h, m4 N( |- T% J4 [# b! Q
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

- {# C  ?& ~2 n+ S( ]% ]" o

4 y; \4 J9 G# a, g5 D
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。
# T0 ^8 n' M2 m, @- f8 b4 w7 i. t! `

7 Y7 t$ @9 d5 Z0 ^: R
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

! n! a) x! Z3 ~/ c' [4 r2 q$ |

  y2 S2 T& n, h) c+ K3 s+ T0 W
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

) H& h7 o1 d$ T3 F9 f! N

. A( R/ n- p3 Q- f
基础设施:虚拟化到容器化的平台。

" L/ V3 J6 k6 N( \
" r0 `1 s- N% l, ?
度量:度量体系能不断驱动能力优化。
* p3 A  V4 O& t9 P' W3 G4 V
6 k4 Y  N+ V6 E: |
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。
  ^7 P4 f* d4 |- X5 P: D3 G* ?
1.png
) J/ G# ^8 R& ~) @( z
, b1 U- j1 F* {0 c
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

6 j' z4 r* X7 f) e3 a1 Y2 h' k
( k3 K# g* X7 ?
三、Start Small,从小做起

! m: J  y6 y0 \: R* |- W

. U. R6 a/ N6 s3 {' g8 V) p, b
基于某个角色和某个场景去进行从小做起。
+ O2 n$ U4 s, G( [! g

* [9 w; h2 M6 A# T9 f$ A
基于某个系统或者某个功能域来实施导入。

5 v5 b6 C" B3 X
0 b. l- Z' H" R6 Z: e5 w$ W
切忌贪大求全。

2 N1 D" i- t% V, G

, S/ q5 _! C: f# ~$ p
四、构建IT元数据平台,驱动IT平台间整合

: ?$ H; N* M2 ~3 ?' M

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

9 {6 K2 }  |" g+ e# ~4 [" T
1.png

. ^# \$ j* M' p  U. ?
五、痛苦的事情优先解决
; X" J* o, N' ]* }# t( \/ S- z
4 {7 r; U6 }$ e0 r' I
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。
( l/ `6 [1 f  y" U  `9 P" P( S

& F0 T6 w8 I! o5 y- s" I
六、工具也是一种文化

) J8 C) j% [3 P4 q- @/ A! m

( i7 k7 q" N5 ?0 I+ y' R) q
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
. `5 |2 H* m! D* R( V: J

& f/ H" g3 Q1 Q  y! [# e
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。

5 o, F* D' a1 Z* ?+ g
. N% K9 u9 U; M3 R+ d2 X- ]
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
* t; ~* L  Z/ C

! d6 l7 q; B. R
七、组织二次元,加群落地力
5 c" o# N( X  {; r+ a

& u- l) b5 J: O) j
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。. X* j( Q" k9 @

3 B1 Z2 D1 g8 G1 {' u8 r
八、价值拉动,而非事务驱动
$ E4 ^: ~0 Q. O) n1 j
* n, ?9 l/ |! ]0 g$ W6 L
经营核心的准则就是以家客户的价值流作为驱动。
/ `: a4 N2 w  g% [0 o( V
1.png
- S0 |( c3 ^5 X: o6 B# E
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。
5 G* g& M" I/ @6 {* m2 Q2 z

3 ]1 A! y* {: m# j' J& ~/ W0 X
九、平台+插件=服务能力产品化,和组织一致
- M& `! Z5 Y% o' Q. `( p; \/ l

5 O% n( |. K: R3 j7 z7 f
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。
+ p" j: `# d& S1 r; l3 ?9 W
1 E5 e% R8 D+ P0 o; X/ v
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

( z; L8 l( d, x: D! \* {

& k4 ], ~( p+ l+ c. B
十、自动化别人,先自动化自己

# O! K; r( L" ^0 s- _, p

- ^( {3 t" `5 K: t
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。

5 l/ s6 i  U1 c& E% G4 n4 P6 W" |
十一、持续交付是DevOps落地的最佳实践

7 ?4 f3 x* @7 e
9 |9 L5 F% B% c- k4 Y+ N0 w' t
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。
- u! ?$ o+ C8 b0 x7 U2 G4 m
1.png
4 K1 g7 @- z9 m  U4 X

8 \6 T$ s7 ?5 v8 ?& N; N
十二、IT运营管理驱动Ops能力建设

+ w% B; c1 J# S

/ W0 Y/ s" S* u
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。
! {5 ^4 u; @0 m

8 G, x. M9 K' t! `/ A
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。
9 M0 T1 f2 L0 k7 K$ @  A  H5 R
1.png

, p) x. w: e. [- b  }' K1 g' @

$ w0 C7 m1 L* q; Y1 x
十三、构建面向应用的最强管理驱动力

( M$ K1 L" ?. f4 _6 L
# e- d" e* P& J+ X3 z- K
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
6 x8 j: U- z: X) V8 N
+ w0 K; K  }& X+ F5 O8 `
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
- c, D7 A0 S+ S3 w1 P! i$ w4 l$ P4 [

+ K- I$ |3 ], h
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

  v& U8 P" a/ L$ S5 b7 c6 ~2 B$ \( D. `7 o: N: n( i
十三、构建面向应用的最强管理驱动力
- k7 Z+ _" {+ \, G) L2 l1 ]  G
! A& L) r) {3 E' M' ~+ A
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
$ Y3 W2 W8 ]& ]7 C
6 ~/ G/ }' @1 }
十四、构建指标,驱动DevOps落地
3 y& z. c9 ]+ N. F+ D' R! J- a. X
( n4 y& A% c" f9 u
1.变更时长

$ p1 y$ {8 B  O7 f, {  p
3 S6 |  p9 g7 B& k! X- T4 ^& z. B, I
2.服务恢复时长" @( n9 ?. o+ s/ E0 D  ?
: c2 |' W. ~4 i# U, r
) @/ T6 _0 y% t8 f. O' X  k' c& I
3.发布频率
+ C2 o4 T) q) P2 B& B1 j1 w6 R
' L; R( ?: M$ o  {# s* c5 K
4.变更失败率
6 w2 u" L% z0 M2 x$ n# D5 G9 R

3 O; H7 x% C+ [2 v$ x2 y! J
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。

' f% F7 Q1 g- g% s  \5 H) ]! E
5 U2 R& `- n8 N) A
我的分享到此结束,谢谢大家!

/ P  ]7 q6 l3 s0 A# l) u- B+ |, [
; X+ q3 i  g( P3 s$ m
原创:王津银

3 W/ q. J4 H% V2 G. b$ v

本版积分规则

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

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

Baidu

GMT+8, 2019-4-22 18:27 , Processed in 0.242011 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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