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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑
8 K5 ~( [0 ]2 E& B) G0 O4 `. f& x- u/ C( \! i3 z2 {
摘要( {6 Q6 z- K- \2 Y- |

% \3 k5 _: \' d& e; v7 d
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
& g/ V' P* f7 j
) I0 ~0 P& m! z* ~9 M" v5 w
DevOps的全局理解

# v# ~9 u% t, T' p
1.png

6 N7 i& @6 L  z6 p: [
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。
/ c5 U8 v. R  d4 Q. `6 K. Y1 k

: U: c  D; s& {" h( R' g
DevOps与ITIL的对比融合

* e, [" }0 z7 N  b9 ]

3 n/ K, m! m. {4 j8 X# g% x
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。

; |) J8 Y. q: A4 r3 w; b0 r8 M2 [
$ Z% k. U- f" U$ k; n. J* v
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
: A+ Y- Y4 I3 o" ^, a
4 E& D0 V1 Y( }7 D, F6 F2 ]& ^8 E$ ~
DevOps自动化与ITIL规范之间的融合

$ {2 R& ]. F! d* `  n6 o8 X
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

, _  n/ L  q3 _8 K6 G$ T
4 K5 I" C2 H6 |8 d. D/ v9 a7 E
  • 第一种模式是在线服务开通流程。
    / ^5 i5 m" Q. |9 Z9 s& H

& k) u6 ^) r& z
  • 第二种是重大变更流程。
    9 k0 ^( R7 G) y0 O

+ {7 |0 h9 y% \+ J' z
  • 第三种是敏捷发布流程。

    : }& M1 H) f/ g  M+ y

7 B3 d( w0 {* @2 b( B, _8 b% i0 [. O
从软件研发模式看DevOps
; l7 Q. D# I4 ^$ Q( ~& @/ e

; ^3 l5 `! j3 D! G& t/ B  ]7 s
9 R/ {4 h  {2 a
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
4 D9 H2 W: n1 H  `) n) D' n" w
1.png
8 C4 ^; ]! w; H" Q' B7 C$ j
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
* e0 E0 {# D( w1 H0 J1 S0 b
DevOps的落地经验谈
8 [) o) }. s( g" L' n
一、理念与价值先行

/ N3 D$ T2 A8 ~2 X

  I: z" q$ A% l, X  N& T
强调五点理念:

# z- ]' H& c. m' @0 {* D
6 @: ?* j, N% e, z- ^* L
1、通过持续的服务交付价值链打破孤岛。! U, n* l4 z" @# @1 P* R' x

- e% D+ V: V; ~! M- u8 b# x
0 U# Q! l; b+ A
2、整合开发和运维的能力,成为一个协作的团队。5 ]4 d# X7 p9 x4 D( [
! ^( d2 @4 z+ X, w9 W: Q
. z  j" W$ m1 ?
3、端到端持续交付流程的变革。1 Q/ q( s' v" Q% w
! k1 ~. c2 _! C

0 b: k4 I3 ~5 e# ^7 h6 L
4、对新的应用和服务,加快且缩短实现价值的时间。
$ y) @+ V! ]( d6 C
* R9 t6 x7 b  N
# Z, s/ V7 m4 S
5、不影响安全性、兼容性和性能。

; R) o. `+ S' a. Y0 M9 ^
1.png
$ R# T( i6 F( x7 ~# L2 }
二、顶层设计与全局规划

8 n* `  k1 p3 O

2 S1 s0 ^5 R2 V0 g/ E( T/ @
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
1 G8 k8 e" D9 X3 B+ Q* Z0 _" n4 s

4 _" f! ^9 c6 S8 s" [) h) N2 q- M
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

+ ?, s7 a2 Y& {: X
( z: ^6 ]( L1 I$ a
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。

* F0 g; I5 W: N/ S% n/ t8 q
+ E) y7 J  \  t3 N6 G( w9 x) d, s
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

" {2 t  A; a- V

0 V3 ?3 m; H5 y* \
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

0 N% {% o. U. v6 v7 \7 l/ m

& @$ Q# Y8 C2 a3 O  Y$ F1 O
基础设施:虚拟化到容器化的平台。
" w4 G$ a9 H( Y; s8 U
. v# Z5 ^/ E2 j% O3 D+ H
度量:度量体系能不断驱动能力优化。
( c& T. J* ]. o$ l

6 S8 z4 m6 \2 A2 G; ?6 U4 Z
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

' m/ Q; i2 f/ K& n/ ~
1.png
; ~7 D% o2 R+ {
. W) v2 P, Z4 M* R) ?$ t3 v3 `
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。
$ o% l# n7 y! L/ J& }. \
# L$ {. ]* F: i; m3 B5 K
三、Start Small,从小做起
1 h/ z+ z/ a" E8 w* w8 _
' i+ ~0 S) L, \0 I0 c! s# Z
基于某个角色和某个场景去进行从小做起。
% v6 A0 L4 \: R* [/ O  _, ^. ^' d

% E% Y9 J$ K+ l0 s) R* D# G% e
基于某个系统或者某个功能域来实施导入。

; l* T: c- \. X# E! V* K* N
: Y, g! f' E9 ?9 F  e9 R7 @
切忌贪大求全。
+ n6 l9 E, \) u0 g0 v
- m1 e' h9 H7 S$ n
四、构建IT元数据平台,驱动IT平台间整合
. f2 H. o* J$ c( I5 }; R- W& h) P

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

; j! Z0 {& p5 m0 n8 ~+ R
1.png
, G2 S! G3 w) ?$ W1 T: n% A
五、痛苦的事情优先解决

- B. e& r: W6 o: c
- F1 {+ H6 c. k& p; z
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

* i* Y. x- H7 W% G% t) `7 u8 C; p1 S' [6 I
六、工具也是一种文化
% o$ P- x' r8 M/ B; A  m4 j

7 ~# P9 V6 R* _8 g7 `  P' ^
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
( w( L3 R) O) h, V6 D) ?$ u, }1 c
" C6 X4 K* {8 j/ \$ y) s2 {
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。

/ \( W3 l( r4 y% c

7 K& I0 A0 l3 M
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
* ?; q' a! m. e1 ?1 J$ r( V/ t, w

8 K7 L- ]7 j9 _, q$ J2 O, x
七、组织二次元,加群落地力
% b* u4 X/ e! F# n$ L
0 m. |2 [3 p! o" @7 b# b
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。
5 j. Z4 U% d" g' T* H+ D

- Q/ R/ ^) T) ^* A
八、价值拉动,而非事务驱动

, z9 B& K  Y3 G! K! N, K

; `. K4 X9 p: Y6 ^, ]
经营核心的准则就是以家客户的价值流作为驱动。
# e4 p, `" p9 H1 |4 {1 m
1.png
6 y% b2 D' @) i9 m8 h
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。
0 S9 {0 T, _8 d8 B1 o4 N

2 }5 O2 h9 [- K$ {* \# a) w3 M
九、平台+插件=服务能力产品化,和组织一致

0 t# L" x) ^4 s7 B8 |. [' y' \8 R  g

* W1 _0 R' X8 k3 l6 D* d; C
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。

  D- b, p4 z: x2 v) m

% i. s% V4 k2 `; t( U; E) v3 ^
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。
0 K' P, B" j; R5 ^; o6 `

6 [9 P* W! b' a8 U8 q. {$ S
十、自动化别人,先自动化自己

' _6 ?- B: y% U/ |8 _
5 U: T# y7 V0 T; c
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。
( h: v: ~3 b, g3 R: p5 D! ~8 s

4 o+ s6 R3 Z1 S; M
十一、持续交付是DevOps落地的最佳实践

4 J8 [9 c) R8 O+ ~" U  H$ c1 [

8 i  v4 l+ m  R7 C
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。
6 @  [/ V7 |$ W
1.png

$ I+ |# j# j8 K9 t6 v
; C; X3 m7 Z% C
十二、IT运营管理驱动Ops能力建设

! N; P( S* m- m& A+ R" Y

& _+ ^% X! l5 C# Z9 ^- Z4 C+ c" N* a0 a
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

$ R' Q5 Z. w& m- a& n  Q( J+ B

- ~# M. y7 [, v% }9 I+ [7 j
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。
& k. N* ^% R/ D$ P3 B
1.png
- Q/ J8 X, O$ j7 P
* _! ^; o: }& \4 l# k! A5 ^
十三、构建面向应用的最强管理驱动力

5 _( N7 ^6 S" K+ H
% v+ F/ H; D9 B. k5 A
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

' e7 n: \5 n" _0 c: `& ]

& v% w# R6 |" f4 f# H) ?
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

# K' a' U, o1 p! J5 `2 ~9 G

, p; ~7 j* U2 L4 P
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。
! C% K/ A" F; |9 E- p2 S; Q

! [2 P9 U" Z- e. Y
十三、构建面向应用的最强管理驱动力

2 [1 E5 `( e: ~4 x; w

0 q& K  v' n8 G$ ?/ U/ J
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
. d5 b* r/ v/ |" b4 k; U
* T( W  |, p5 b8 Q8 X. U
十四、构建指标,驱动DevOps落地

% n9 B: R8 Q- S
0 B! S* s+ B, P  ], d; v" A
1.变更时长

" F& d! g5 M4 K, C
, I' J7 K& u" \8 ^, H
2.服务恢复时长4 P2 l( S/ z7 M4 ?% e

/ V! I9 T5 _. y
" b3 W( s8 C+ H( {4 s6 g1 e
3.发布频率

# s; X9 H  D9 p
+ A( k( d8 d6 P( l/ R
4.变更失败率

7 U. F. \. z! x  o8 c

: d" C1 W# v3 [& o! }* j4 w6 V
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。

  u- y7 O1 Z* B) y6 E) d( t
: z  U5 z9 N5 L
我的分享到此结束,谢谢大家!

9 }- U8 F! @, E4 k
; m8 l2 N* v5 v6 ~2 M& H0 o
原创:王津银
: N0 O$ {( J+ K/ O$ b2 a( \9 \

本版积分规则

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

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

Baidu

GMT+8, 2019-1-23 22:23 , Processed in 0.281785 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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