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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 * H, `& K/ }. Y' R* |: b

" q! t  ~' M5 |! G
摘要( [+ r! ]% X8 d1 t3 j

7 Z4 m0 q) a" T8 \+ R
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
2 w2 R1 O7 F4 s* e* a

/ w$ X7 o9 n! ?% z" e
DevOps的全局理解
  ~- K+ X& x# F4 J5 c& P
1.png

2 G8 ]1 Z3 F9 H" G2 X; W
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。4 m0 K% n6 J+ [3 Z7 ]# T1 {
1 f- W% c- L) g5 ]
DevOps与ITIL的对比融合

6 Z/ Z& [  ~$ W( O5 u+ O1 D

' a  u/ B  ~8 u. H
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
2 G0 |$ _# f5 t: M
: r4 @: X9 q, f3 d! i2 T" q9 [
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
- q. D6 D: D3 V' d! H  T

8 u- X* G! ?: V. l* e
DevOps自动化与ITIL规范之间的融合
7 [$ h  w- d2 c. U6 C
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

2 g+ _9 ]1 p$ v- Y

4 ]3 c9 _# B' |! ]
  • 第一种模式是在线服务开通流程。
    * p# H/ C- M2 ~
% T; T% o5 P( I
  • 第二种是重大变更流程。
    & Y9 g* R, O: S
" E6 A9 Z: t9 a# e, r8 Y
  • 第三种是敏捷发布流程。
    7 T8 n& @* e% a+ T% a
' @6 N% W4 [7 s" l" j4 @
从软件研发模式看DevOps
/ M, D. N9 t: I* \7 A9 z3 W9 L6 R
6 e/ q; r! p$ U% {' j

" x" ]' j9 t  r8 {
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
0 f  e9 x9 p; w7 q* S$ @3 l
1.png

0 I+ H+ x: G5 r3 W. b# m! ]4 u
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。

9 k9 e8 [9 ~( A3 C5 m
DevOps的落地经验谈
: m  k7 K8 ~# I) i& ?* l$ X
一、理念与价值先行

. \* ^6 p" x  q" P8 |8 J

* @- g0 k  o0 L3 D1 O
强调五点理念:

3 O. `; h* H$ y# m+ |% G+ r

# o/ T+ G& T+ ~+ F8 d9 n- w9 P9 a
1、通过持续的服务交付价值链打破孤岛。& P1 T6 [2 ^0 O+ ]- I) ^

- H7 J  W4 ~7 Y" l7 d5 @' S
2 P, x/ \* U8 O: r5 R
2、整合开发和运维的能力,成为一个协作的团队。- m9 B- u* W) m. {9 F

/ l- F  P0 S% M" _. C- c9 I
/ I% W0 ?. S; r( Z7 s# c
3、端到端持续交付流程的变革。
) P% H, n/ f$ o, Y- S3 \6 x
8 p% q! s* C7 h  @5 M6 t6 P
# H* a! [* ]0 r. p) ~# }! @' u
4、对新的应用和服务,加快且缩短实现价值的时间。' `; p: V! C$ K1 w* a! H
, a9 u4 g' V- I' D

6 |% N- @" o) H$ a' H1 r
5、不影响安全性、兼容性和性能。

  i0 \9 M# \1 N' l; w
1.png

+ T  Y9 j7 n4 ^
二、顶层设计与全局规划

7 b. |/ [  a+ B4 h, a

4 a! ~* U9 _+ ?0 v4 T' N
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

8 ~" n( Q' @' r
; U  l% X6 u" g3 y3 M
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

! Y  T* J- b6 Q; D. O  M

- d8 p2 n* ?' |" U. F' I  x* j: }. G' t
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。

" e6 t2 K$ k5 t  F, x

9 L. W5 g* M% S
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

3 y) o% o! D2 D  ^9 J' v- a

! _" U, s& ~3 o. U* K: E
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

% r7 v# ~7 }; X0 e' j# X, d) O

, o& ]3 V2 G5 I% l+ j. j) h1 z
基础设施:虚拟化到容器化的平台。

& }, P  m# `& N
- U9 L( |) L5 ]7 ?- c2 C
度量:度量体系能不断驱动能力优化。
2 n% x) }( Z7 m& N, ?

; e8 i, A' m5 d/ ~: H3 Q6 J
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

. p/ \5 ?' f( L9 ^, R( M: o0 G
1.png

7 v% q# Q9 K  ^8 Y) ~
+ p8 d" e$ l% L% N$ ]
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

2 H% E$ ^5 v! k; }; H2 ?" v

- d9 ^3 g4 ]/ p  C4 x
三、Start Small,从小做起

: T* V- Y1 E. |4 q# V

7 @# v% I+ G) w( t' M: P+ V* f; f5 X7 p
基于某个角色和某个场景去进行从小做起。
7 a! m1 e& P; t  f1 N4 g

9 L3 i0 u/ H- O3 P4 @
基于某个系统或者某个功能域来实施导入。

9 `, O" d# u  W3 u6 r: C

% z% v1 l6 D. ~% L, P0 f) B
切忌贪大求全。

$ D" ]9 {$ l$ u; \2 d9 ^, B

& v5 x! D' c5 \
四、构建IT元数据平台,驱动IT平台间整合

- u, @/ \5 H; v5 K# u# I
) K% n) Z4 `& X2 M6 Q, A: _9 F+ O
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。
1 Q9 u, A0 m" I& k
1.png

4 ?# p7 `% X5 \# N5 h
五、痛苦的事情优先解决
( N# y6 r, [* o4 n' }5 _4 M- o

+ Z  q0 `  s; y6 z# b) z
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

( S5 b7 x2 k3 p- R$ @. l" L' K: L- I& y& d3 A4 D
六、工具也是一种文化

" H2 `2 G; v; m7 B0 T
) V: c; ?. B) C
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
' S3 l. D/ ~& |0 s' i
. U  n% o; m5 T
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。

* s9 J8 O, t5 w3 z* B* Z3 K, Y$ R0 Y

7 y+ {4 q8 l6 R! L! D
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
) U* O$ h# @' g4 R5 w
$ a) W/ N2 s- N
七、组织二次元,加群落地力

/ x7 ^) g8 @8 Y5 ]8 u9 o
1 H1 n  R7 q4 w% K
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。2 w; v3 X& i5 j  H
: X5 w2 v8 v2 v1 B
八、价值拉动,而非事务驱动
" J, Y5 Q9 z, Z+ w/ x2 B% ~$ h7 V7 k
; Z7 y8 Z' }& R7 z& h5 u0 E
经营核心的准则就是以家客户的价值流作为驱动。
: `; s: m# D  M1 M& Y; n7 ^# v
1.png
% X2 e6 W+ q  t9 a
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。

5 F/ m- i$ O, w- W) l. H: ?1 ?
* V) b2 s3 U! M" _2 v. o8 q
九、平台+插件=服务能力产品化,和组织一致
$ q7 @( s$ {2 }; m

; P3 M4 p' v& x5 F0 y; Q
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。

# T$ ^, t! b6 ~, B" X4 x
3 ?' K* I1 R2 \( x/ P! V: ~. \
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

$ `2 D1 P" B' C8 H' k; C
5 c1 b* G& h/ ^" a9 Q8 r/ a0 e
十、自动化别人,先自动化自己
9 \9 y+ e- {, B& C
% x7 V/ Y- h' ^: v5 X
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。
$ s* \* O, q; f: E

4 f, O  n/ r: I7 s2 g0 x0 }# k0 X
十一、持续交付是DevOps落地的最佳实践
, f( G( O7 ~" L& x; [
9 ]. z1 v5 d7 [% u/ d
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。

# _" D7 w# X8 [
1.png

9 ~; B0 ^1 n6 R/ K, r# y
, x% b5 H3 D3 |' [" @$ T
十二、IT运营管理驱动Ops能力建设
8 E. t" G- i" i) N9 \
2 \# o% W1 W+ \. }* ^8 F6 O+ A8 X
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

$ e9 i+ Y5 \, [9 ]6 P

" K6 F8 C5 G% A' `
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

9 m# a* f" H8 A, D
1.png
! o9 `+ Z! S9 \, e: _6 {" l5 s$ d

6 w5 ]% Y& \+ ?* Q8 l' K, S
十三、构建面向应用的最强管理驱动力

: H6 _8 N; v6 u

+ a. }5 }& u/ d- w4 T: t! l* h
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

( B8 m, P: C$ {% h4 V
: V( ~( f# e9 ?1 K+ E3 j7 C. k0 O
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
; A0 b& P" X7 e) v3 }
" q7 t( V" V1 a+ T8 G2 n7 K
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

3 t" M/ }, ~  _9 G4 v; U9 l7 q
/ @* Q& J: P5 t! [- O3 U5 F
十三、构建面向应用的最强管理驱动力
: d# T5 M% E( J7 C. n
( a5 I& P5 j) d1 {& ?! v+ ?
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

2 R4 ~+ i/ v  E$ U9 S9 X# A1 v

" u; }( ^8 ?- Q; a
十四、构建指标,驱动DevOps落地
) T9 a/ B6 Z4 v

. c& q0 Y. p# h* U  O8 v  J3 k
1.变更时长
0 a9 l$ W8 c9 ]! |( A/ G
- n: B# R) t- V2 m/ |
2.服务恢复时长
9 S5 B  f6 ^. X2 S- c9 J. s( K

7 ~. h. o% W) X" ]0 ]4 ]# ?2 v. v  g/ z8 C8 n

$ L8 r% l  I9 w( h
3.发布频率
) e' j7 Z7 M8 L. \2 _

6 U; R! E% c1 Y, }) u- |
4.变更失败率
; d( d& M; p4 T* n7 F

+ D4 a3 [+ J9 g7 l$ ~6 I
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
) d# N" J  a& E9 X; X

" N: x: Y) Y8 K, T5 V5 m) G( d
我的分享到此结束,谢谢大家!

; t" R( K. @; G+ k2 [

# _6 @0 Z  X) t! |6 v, j
原创:王津银
& f+ G" t- |! M* Y

本版积分规则

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

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

Baidu

GMT+8, 2019-3-20 03:31 , Processed in 0.805280 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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