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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 720|回复: 0

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

[复制链接]
发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-6 17:27 编辑
8 }* N. Y# e6 V' ~
& r( ]  c0 N9 H. m4 k' L  h
摘要7 c, r3 H/ Q2 Y, M9 {9 |

1 ~: C0 a) k/ C9 N* `: h
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
1 o2 |) S1 s% I2 W  F: H
, w8 w! S  A7 [7 x6 P. A
DevOps的全局理解
, Z! s- \1 i+ S; [
1.png

6 M! Y7 Y, ]) P$ i
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。
: r) G  r& L3 B7 [9 I1 Y+ t( F6 I
/ {* W; u0 h* B/ a; V  a" `
DevOps与ITIL的对比融合
6 ~8 y8 L% g* P, r$ |; Q: F  y

6 a4 r- f+ t6 N
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
+ R' c" |* t+ J* Y" B0 s1 L, w

7 S6 Y8 |" z+ `+ ?6 Z8 b
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。

+ k3 l: |& {/ G9 E2 G* K
( F4 K! I) Y# g5 c; ~% W0 l
DevOps自动化与ITIL规范之间的融合
, q1 Y# G% n- E( z9 t" f
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。
4 X: Z; M$ W# ]( h8 e9 I
# v1 S8 P8 _+ T3 L
  • 第一种模式是在线服务开通流程。

    ' z: a% J9 @* J# ?! c, ?, K& S
. i2 [0 M' J+ a$ Z
  • 第二种是重大变更流程。
    ! L- j7 C3 ^5 ~5 Z6 G/ N

2 p5 W' X0 S* n0 b& C1 ^: \8 Y
  • 第三种是敏捷发布流程。

    3 A- g. w. I5 s. ~
, `5 E& x' q8 W9 `6 L# J8 x: U# P, k
从软件研发模式看DevOps
7 G3 p( D3 w1 r4 r% Y

3 l. d2 m3 ~6 b; j4 K: e
! e5 Y+ m6 r& ]% Q9 H
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

1 b- S" k. {) N) q
1.png
/ c9 N# E+ a* C+ w4 `! w. f( ~- d
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
. ]3 \" R0 W: u# N% J- D/ ?
DevOps的落地经验谈

; Q. c$ t9 h# \$ H7 m9 O: f
一、理念与价值先行

; Y3 r" w" w# S/ N& K% {, I

& K+ \# q# `, v# b
强调五点理念:
* d- E3 i7 _! J- p3 v# k9 o/ c
5 Z) I9 g- O3 z8 w4 a
1、通过持续的服务交付价值链打破孤岛。1 g6 X2 t4 f" s; l% T' b  M

7 |9 U& `; @. k' d7 b0 p. |& d; y
% V/ p- z: \5 d
2、整合开发和运维的能力,成为一个协作的团队。
/ K  v  X# }- h  F+ W+ L5 Z
: `# L/ j+ |8 W2 ^) {$ g; R

( Z! \' {& u' S) w
3、端到端持续交付流程的变革。4 K2 P1 n: Y1 i

8 ~# _5 G3 c2 E+ Y# E: a7 f8 {
+ L2 `6 K+ W( }
4、对新的应用和服务,加快且缩短实现价值的时间。# I, \4 e3 F5 d
  `* ^! F2 E+ i, s- v

6 _+ }$ P' y$ ~/ r7 M7 |+ N
5、不影响安全性、兼容性和性能。
' z& r; L& ^; p( M8 N0 d5 e( Y
1.png

" D! p8 r9 Z; d  _5 z" ]4 |
二、顶层设计与全局规划

% C" Q( j4 t+ L& m: q+ `+ d3 d
2 S$ _4 k5 y+ ?$ }# E( T; f6 k
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
/ j# @2 w9 o, [) \+ @' N( X& |( q

+ R6 C0 R4 \* P0 [5 ~- [
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

' l9 [! f- t0 U. i" Y8 x6 J1 C
7 Z5 w9 Z( {9 g0 F
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。

/ t0 r& f! {4 z' {7 _; q/ U1 i

# P* x% n3 m, `  z& Z' K  p: q' J3 W, U
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

8 p* |' b6 `. \& r. F* |
, M9 X7 v; s; _& n4 ?* C/ r
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。
. }+ M7 |: |0 E1 o3 p  I
# ~! v: n6 X) [$ y: o& @# v) K' }
基础设施:虚拟化到容器化的平台。

: z' M5 R$ S& w
) ~% l0 P  K: n, q0 \/ `
度量:度量体系能不断驱动能力优化。

* u# H, K; H* ~: p$ p
) F; x! y- _$ U  J0 ?, e4 I
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

6 ?& @9 u2 V" E' E7 ^
1.png

2 z+ G, {( {- f- z- g# R6 H) k, g( L. G

2 _3 Q, O( X! s$ `6 U( u. D
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

" a0 u/ H1 v% @  x. X
3 j6 J( V, c; C7 c
三、Start Small,从小做起
$ T& ^  r; \" x9 m$ G6 C  M1 J( U

% A4 x* k2 B! r( P/ x& j- V
基于某个角色和某个场景去进行从小做起。
2 S( n/ I& K, K1 W# J9 S/ |
+ F- W  }2 w3 ]( R1 \
基于某个系统或者某个功能域来实施导入。
4 e8 c) A5 K, \# k0 P9 M
# {7 Y3 g# B5 Z3 x
切忌贪大求全。

5 _# h$ u! Y7 n( z/ o7 j
3 R- b( d, g/ Q, K
四、构建IT元数据平台,驱动IT平台间整合
9 ^# v0 N# `3 q) D

0 E/ ~  e  q/ O- `' P  v
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。
" @2 `0 z2 x8 B
1.png

; D: {6 X4 Z& G' y. p
五、痛苦的事情优先解决

1 w" A+ p, v7 d" F8 @' p
5 ?) P! _+ B# p/ v/ c+ g( P
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

% H# [4 I2 Q) i: U! u; B. O  G8 J* y
/ E% ^+ ~5 p# H; P
六、工具也是一种文化

; t& r% q1 y( y+ _5 R; D% Z. j

7 {, d  }/ S/ L% n3 r
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。

% ?, m- Y/ e% D$ e8 K4 p# A
# @( p. t& [& p) x7 \) \* h
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。
" r  p" t5 s+ B5 V3 l6 g
$ }) I0 c. @1 [1 K+ m" v+ H
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
& S( c( q  I" R3 b* p

. r1 j& x( n& i& x/ d$ w
七、组织二次元,加群落地力

" ^( t5 t) G: W2 l: Z! e# T' x

! @6 V8 [! J9 C0 ]6 i0 @2 @8 n
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。8 f8 z" E% h9 G' u6 S% A

3 c& a3 d& V: T" @* ?9 t: C: g
八、价值拉动,而非事务驱动

  l* K( }4 u: Q0 k
: R  o7 x* b. K. i  x
经营核心的准则就是以家客户的价值流作为驱动。

# W- R3 D; J1 D7 t
1.png
( V/ [8 n4 |3 m* L1 X) i! I
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。
# w- w' x4 {0 X8 |0 H. O
, _# I3 U7 u0 W6 r
九、平台+插件=服务能力产品化,和组织一致
3 d5 U9 e+ Z3 U1 A4 f6 a9 k

% G: x  G+ E  U% x5 {% j4 A
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。
* H  q8 e" s9 o! S; z
2 Y, X' R2 \' K% I6 f8 [+ q
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

& t: ]: ~' a; J9 w& ?( ?
  e3 n3 D' @; M5 r
十、自动化别人,先自动化自己

" {; `; |7 }& l7 J% o, v8 q4 O; J. V4 }( P: {
3 Q9 x; e! Y- k- J! J
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。
3 ~( }) L$ K9 j# ^7 [

1 q% y6 T0 W+ T. `
十一、持续交付是DevOps落地的最佳实践
/ J; t7 B' }0 z# }' c

; U* d+ p2 T7 h: U
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。

0 V2 R- \. f$ a3 u8 D. a
1.png
" ^1 ]0 c6 p0 B; ?' w, Z

" j7 f7 m9 R( z( _2 I
十二、IT运营管理驱动Ops能力建设
1 ~5 L3 C: C; o8 d
4 E2 _  a( Y- P/ O& Z0 D
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。
, a% t" D6 e1 O) g, C

+ s4 r: I4 g; r" _4 W
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

6 y& @3 i7 z& b1 Z- [, u1 l& T7 ^( ?; }
1.png
$ i6 {9 r$ `9 }- N3 C( w

; T4 R* a  v3 Q. t. m1 L! F7 Q
十三、构建面向应用的最强管理驱动力
$ x! _2 H) b* a0 O" N
7 P+ X. |0 Z/ j/ y( d& U. G
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
7 \# |( B# `7 E  x! G/ G
9 Q+ u2 q$ Z. y% I/ }. L! y2 j7 w$ u, ]
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
1 }7 p4 J/ q' B/ `6 Q( U- {

1 F+ ?# z; Q( F+ k+ Y
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

; _# J0 E- N3 `& u- n6 D3 V7 I0 Y& G, a5 P; ?' Z, ?5 X! V
十三、构建面向应用的最强管理驱动力

, H( a1 p8 v: w1 }

; U: |+ H+ R/ _: j* H/ a
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

* c" D  Y" M3 _( R+ y7 l! }  t. l$ G$ ^
7 o, Q1 }6 V, x% G2 d  {$ Y, j
十四、构建指标,驱动DevOps落地

0 \# h' ]) s9 m$ k9 v

: L6 ^. z8 s6 a# A
1.变更时长

* X) i" w- G4 N) i% r

' @% |* V: ]: ], {( w6 I' y
2.服务恢复时长
6 W/ E: u+ b' j2 m, g

( s/ \7 P+ ]. X4 l1 H7 f

$ N% Q% m9 O4 q# S1 S, W
3.发布频率
- S: T3 `! N6 ~6 a0 B+ V  K: _

7 Z( M5 m- t3 w& g9 u
4.变更失败率
( J8 m% e, h. N4 ]
+ E' |1 Q1 O1 j5 v  ]8 b) n
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
- Q9 f2 l6 h9 V! |8 S* _
& P( ^1 y# @9 }2 H
我的分享到此结束,谢谢大家!

9 j: D  T3 N: S9 x% {: L& X

& k2 v7 U+ S" T; Y/ |2 E
原创:王津银

# S3 c$ E6 g; J& M




上一篇:关于DevOps术语表--已收录202条
下一篇:企业实施DevOps需迎接的七大挑战

本版积分规则

参加 ITIL 4 Foundation和中级过渡MPT认证、DevOps专家认证、ITSS服务经理认证报名

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

Baidu

GMT+8, 2020-5-29 19:18 , Processed in 0.163078 second(s), 27 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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