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

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

 找回密码
 点击获取邀请码 - 立即注册

扫一扫,访问微社区

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 8 n0 P% B3 D: s7 d2 U3 `2 W2 [2 {
6 i) |. M: c& w6 a' t+ m' v
摘要
" f  C# N' ]4 B3 {: p1 U4 ], L

9 K$ d8 A# Q8 W+ N* ^
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
# O  k3 w+ m8 ~# X
) n  f1 }& {& N4 b/ K/ k6 Z) }/ [
DevOps的全局理解
) M, k: i# a' c$ q9 e$ ~& ^: E
. S- ~1 R. l' a7 J/ b
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。, h* M% m/ I1 g! I* f7 E4 \8 x

% b5 ]5 k! f7 \3 ?
DevOps与ITIL的对比融合

) ^/ o& A' t8 y- y

# f3 m9 y$ t, r" V. u
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
; n+ D7 J! m1 R/ t, m1 J( G

5 V- _) u. k0 f0 j
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。

! x+ Z2 h0 N: B3 x/ K6 U/ F. I# P" F

& W9 U- [" r6 W, a- L0 b4 [& @
DevOps自动化与ITIL规范之间的融合

7 Z. e9 Q; i' X
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。
+ L- A: Z1 C& @% R7 i+ a0 u8 x

- \; m* @6 }; B: [; ^" |$ ]
  • 第一种模式是在线服务开通流程。
    ' V. \" B: c7 e; [9 l" r
# S2 g, m1 |! l  ]3 c
  • 第二种是重大变更流程。

    0 G5 o' |' @/ l! [0 D. X- }  F( P

3 \( K$ N6 p8 w' m4 y$ K0 m
  • 第三种是敏捷发布流程。

    3 ?6 L4 H- L; o- D# Y8 Z! b4 a

: h; C4 d( u* |- h# S% I1 a$ {
从软件研发模式看DevOps9 s  l$ I* d# U) m. x
3 _- j: \! E& z: ^8 x& R

9 _" o. X+ j$ m; I. W
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

, {. U" B$ C( ~2 j

  ^4 V# i* h8 f7 Y* D
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
1 W2 z/ `3 L" {+ B( r' ?
DevOps的落地经验谈
$ r& }/ ~; |5 T: p1 w
一、理念与价值先行
+ t8 A6 K9 v9 h' h
  ~- c3 x& q9 x, x( N) w; r2 G1 j
强调五点理念:

- m. b* @0 _0 A4 n( z$ S8 _, L

! g/ y/ L: H! e& V; o  v+ n
1、通过持续的服务交付价值链打破孤岛。8 T% D9 _& _' i, E
% h) O( z8 l: k! ~  }, y4 c. D
1 J/ `' l2 k% f6 j6 b1 x
2、整合开发和运维的能力,成为一个协作的团队。
! Q# z  Y$ v- d5 q4 K& {  `
9 R! o9 F: U" B7 _; b1 e
4 \" r# R* ?7 D# O1 C, p
3、端到端持续交付流程的变革。
) l2 J; W2 u0 |3 M, K
' q& ~7 i! r( w6 {7 L$ r4 ]7 Y

* W* K- m, S1 T; y# U! `" v
4、对新的应用和服务,加快且缩短实现价值的时间。
( ~8 @3 m2 g. y7 Y* V4 r0 _/ W9 M( `" y% `( _/ P
0 t1 s) s7 {* w
5、不影响安全性、兼容性和性能。
" v. B' n8 d0 }

( g2 h( W0 [# i+ L7 q* d- f
二、顶层设计与全局规划

% n& x' Z' \' A) l% x: c0 w- a+ x5 d

5 H5 X2 z$ u$ ?3 o' b
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
, {4 G! I6 K" R& }- V4 y

) n+ n: g2 F9 t( u
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。
# w8 E1 q5 `% j
$ c% G  t, E$ P. b3 z
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。
% b- P8 g: a0 O& X% o3 [  |
9 E9 h" f, g1 ^, O+ p, W  t
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

6 T# N5 p7 x' t9 j4 S& P+ ?
7 `' y/ C9 h# _- P5 e/ W. V
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

1 E' Q' U! Z" ]. }

# [' k: Q8 P! ^9 v0 B" R" ?
基础设施:虚拟化到容器化的平台。

0 d' `1 P) S* u# v! f( L) ]

9 B8 e5 Q) ^2 ~0 m8 A9 T6 }8 M9 T
度量:度量体系能不断驱动能力优化。

# W8 K- B! O/ _' k8 _; w
$ H5 g4 k' a6 K. l/ s. X
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

" r. N; p; v; I8 ]$ ~

! E$ @: T3 C4 ]7 X( M7 _
8 X8 v1 v( q8 [% V" o
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。
6 ?' s9 H9 Q! r* l$ P# y* Y1 ~
. e+ _3 ^* e: C9 i6 E$ B; g
三、Start Small,从小做起

" w  B( o" I, r, [+ Y

6 V( p8 ?  b" {, H6 }
基于某个角色和某个场景去进行从小做起。
0 ~1 L, h6 X. i* a) t0 s# r
" G/ m: ^; h6 O% H' H0 F
基于某个系统或者某个功能域来实施导入。

0 c2 V, @9 g, d: J1 c

( p" a4 |2 F4 h2 _) `: ?% u6 T' m
切忌贪大求全。
% t4 O4 j; a7 B5 W6 ~

) S! ]# ~( }6 T: k# @" s1 w
四、构建IT元数据平台,驱动IT平台间整合

- R3 u5 t1 |6 M* g/ Y
& x: J1 y3 W" W, @
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

9 i# k4 q" [! E( L* B% c$ G* R

. H) D: d0 E/ U5 R- M9 |$ E# A  s% v- {
五、痛苦的事情优先解决
5 e+ ?2 E, m% S

8 X* |) x4 i+ N! U1 B
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

6 ]0 h5 e, L# K( d) m7 J
3 k  X5 U% L6 k! g$ p# T
六、工具也是一种文化
1 q3 S  @0 L( g/ v: t
  l0 E7 {4 b9 k0 [3 P8 B5 N: K
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
: L( O- K0 y4 \" s0 e) N! d
* p; r0 q8 I1 U! `# Q  J
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。
. Y2 v2 Z% n+ k' v* a) g7 R: y4 \
( }, s& T- E: X5 c+ ^) |
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。

1 v( L) b4 x! J6 U/ ^2 Q" Q+ u, X. r9 Q2 s( S+ e
七、组织二次元,加群落地力

' F; U' I9 I; L% V
7 e" f7 L, q! l
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。) {( J# f4 [! Q5 D" O; E% m( s0 f
) {4 ~2 q7 M2 n
八、价值拉动,而非事务驱动

0 |$ Y% ~" S+ G$ J0 a$ v
( U+ _" l# ^# Q2 J- `* Z/ F
经营核心的准则就是以家客户的价值流作为驱动。
! m4 s- S! Q' Q! _) @: o9 L

* L3 y' C  n7 {- x1 [6 z, I
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。

' W: ^3 B+ S- k

8 Z; L+ H. q' Y/ A8 {3 q
九、平台+插件=服务能力产品化,和组织一致

) {/ X' W  U* A( q+ ^; Y6 ]

2 R' D1 M* @& s. [4 X- W$ @( e
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。

0 E- H3 m. `) f
& m* t7 _9 |2 `
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

' r% n5 P& k( G4 M8 o! B
/ k: l  I- N6 l1 T* S0 }. h
十、自动化别人,先自动化自己

1 S5 y; ?+ ^2 r! |1 _4 z* Z' ?8 d

; A( `! i2 d4 T& R0 L. V
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。

2 g! Z% [! p- {+ c1 Y
0 F* g, x3 J% \; v2 g& |
十一、持续交付是DevOps落地的最佳实践

6 E# T0 h% ^( `# z, t) i
: p, K4 Y$ C' b; H! L3 O
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。
! [3 b6 P0 T9 u8 i
! r( Q# L* u' x, G7 t; M
$ G* R7 T; ~0 W! {! J
十二、IT运营管理驱动Ops能力建设
2 i1 s8 ~, T' D$ O% |2 T
; G  |8 `( e$ \/ Q# C: V
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。
# q9 k3 y, s) x4 g4 T  c7 |
0 W9 D9 r0 w) y4 R* S* |+ T6 s+ Q3 l
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

% j6 c" S) P* P( @

% n6 Q% k5 R3 @

' ?" [) d2 ]5 G1 C9 \& N
十三、构建面向应用的最强管理驱动力
( H, D$ S4 ^5 h! W
; G8 \# j' ?  h0 z6 s& d# u
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

9 P$ v% B' [8 L* T
, W+ S4 k5 i9 X9 e- i
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
. M9 n' m( ~5 R- P+ b3 e$ a% S2 M
! ]7 j9 ~. T' }% f( q! a0 e; k0 o
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

, \( }. C7 l; t3 U% g4 ]
1 {' T# Z( E1 R& v. N
十三、构建面向应用的最强管理驱动力

+ |  U/ `, X* O# B- i; I
1 D0 c/ A; m' c, B% w$ e
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
1 J" j7 }$ e9 E  J

# H1 T0 E% @0 ~6 G/ H- x% s5 F
十四、构建指标,驱动DevOps落地

1 k1 C+ f. ~" Z" C) e3 G. f" S

4 _( d! M/ u4 n7 L- ]
1.变更时长

& W* h/ m+ ~. N* j* `6 U

- p6 I- |: p* C
2.服务恢复时长
- M, E& w% o0 f; _. U

1 C0 i: g# q9 |0 j* D

' {3 j. R+ `2 \! b9 e- R. y
3.发布频率
9 X$ {- ?* F! o  B/ Q  w+ p8 ~

$ T( y" ^6 q0 Z5 A0 s
4.变更失败率
1 J" N& }/ i& H( U2 u
- L- \1 E6 P# Q; d$ z
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。

# n8 Q% i0 W. S& Y$ }6 R

, s/ r( Z# B# ]5 a* v& F3 ^5 d( w
我的分享到此结束,谢谢大家!

$ @! a1 p' N. b3 b: f% v
# g" K$ |! Y# H, t9 r
原创:王津银

3 i2 s, A0 I8 F$ @3 y$ _

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?点击获取邀请码 - 立即注册

x

本版积分规则

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

QQ|小黑屋|手机版|Archiver|ITIL先锋论坛五万运维人社区 ( 粤ICP备17056641号|网站地图

Baidu

GMT+8, 2018-9-21 12:44 , Processed in 0.179124 second(s), 33 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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