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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑
. v0 B+ G+ j; |% L7 v  S2 h* v8 ^  V. B
摘要/ C! J8 Z  F4 `- U
( J; r  L/ @. z
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
% S3 m% ?/ m. I# C" g9 r& V

& {1 s- m: U3 v0 M4 D4 ~8 p6 e. J( b
DevOps的全局理解

9 E9 R2 S) [9 P& N
1.png
* ~- K* C( @  t* H6 o7 T$ u# s: s
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。
" x7 i9 u0 H  ?" h
0 c, K% M5 e! M
DevOps与ITIL的对比融合

! U& g. P7 B/ D5 A* a/ k

, w! m* f+ @. ?
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。
' l0 ^; k5 A1 X" T1 E( }" _
7 v  g/ C; z2 K% q0 E' F. J! V
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。

) D# L% ]6 z3 \" z5 ^! s

( h- p! Q% V$ o1 s2 v
DevOps自动化与ITIL规范之间的融合

- m; e) Y/ f2 j' d
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

8 P, ^6 ]2 C$ N' G/ q

" m$ j7 Q! J! ~: a
  • 第一种模式是在线服务开通流程。
    ) X% m& T2 L1 i/ z3 M

. F1 i  Q* L( i& F. S
  • 第二种是重大变更流程。

    9 J9 q1 X7 p7 Q( @8 Z3 L' D" A, X

7 @- A7 p" F$ e  I1 b# i
  • 第三种是敏捷发布流程。
    9 j% z- L' V% t$ @. B

! T* p0 R% K- {# R! U* n
从软件研发模式看DevOps
$ {! n& J8 h$ ]

9 ?5 Z; O6 F4 m* i6 u8 m0 C0 h, U

- t& E; q& h: ], i9 h
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

  ^5 n, _& B. X5 N$ Z
1.png

1 D/ T1 s7 K: }$ [
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
# }; t5 Y; v" z
DevOps的落地经验谈

, J. u, P" e+ B( N! ^  x
一、理念与价值先行

! z  |2 h& O$ z: A) d% M
! s7 M& B% s( ?$ E9 \4 n
强调五点理念:
1 L/ v( `8 h9 f8 y; @6 O

# U! |" S+ v: l4 A2 [# Y+ }
1、通过持续的服务交付价值链打破孤岛。7 ]4 D; p4 [/ S* }! ^
" l6 B  l: L* o1 C
/ {% s, k1 I3 G9 L6 J" K
2、整合开发和运维的能力,成为一个协作的团队。
+ @. F0 z. B3 X4 v5 V7 o0 }* A$ `( o. L
1 Z& `: ?7 |; U0 j9 C! O$ ^
3、端到端持续交付流程的变革。" H4 r  q9 @/ W. }$ u' ]3 L+ [
& u0 k. |1 W6 }; h# l8 B

+ f( [( s# L( _4 i$ P& P4 Z
4、对新的应用和服务,加快且缩短实现价值的时间。4 |1 W% i$ O% e5 R: `. \: O; b

& U' e; C! v2 b+ E0 a! {

; ~. W; P6 G! B+ N- {. ]( h
5、不影响安全性、兼容性和性能。

# j6 V+ r, A- c
1.png
' `9 i' s! q% {, W/ |6 i
二、顶层设计与全局规划
! J( B( X1 h5 \2 @8 v$ |; f$ q6 ]6 j

0 j! M( H. ?& y8 g( q# K
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。
1 T: M# l- S* E3 N& ~0 e5 Z" v

" |; D0 Z! J: Y4 `
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

9 e6 ?% d% X3 R

, j7 e# L# Y+ I
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。
1 g% a2 j/ |) K4 [

; B; {* e: [/ s8 G  J) M% Z
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

3 }: t% I0 K3 y# A2 z/ }

* K9 T6 U7 a9 w$ v  k6 U" l" ^& x
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

/ R' ~: p9 c) v# P* p, x  n0 x

- m1 W6 J. M0 ~! i6 _. I- {  h
基础设施:虚拟化到容器化的平台。
* k  `- B1 b9 f0 I% O

) B1 u( T0 h7 d" p: J4 z
度量:度量体系能不断驱动能力优化。

- R5 M- D8 e8 A+ ~2 p( A

* w& M' v) b& H0 V6 W) Q) [
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

* w1 ?1 o( Q; }
1.png

' K  k6 f# E$ q8 z
) {3 Y8 j/ ^8 z9 {0 W, m! [
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。
" ~: `6 N+ R; K+ |7 q8 t, B
1 }% a. w/ a+ n$ x
三、Start Small,从小做起
5 t& a; f8 O2 z, b8 p
- }6 ?2 E' K( I6 ]
基于某个角色和某个场景去进行从小做起。
! Q, l7 Y, R; h8 C2 t4 \

. x+ \& I1 w! b) y- O
基于某个系统或者某个功能域来实施导入。
& p* N2 [- r0 x/ Z
  R3 d% b/ _  z+ }* f& c/ }" l
切忌贪大求全。
6 |$ O. Q& o4 z; A7 \4 n' `% T

) E; n# i/ b# l6 ]. f' H
四、构建IT元数据平台,驱动IT平台间整合
+ x2 X  p: v8 s' _+ u/ T. K& @
# E1 W6 f8 H  O5 f: s, V8 G# J
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。
+ R% I& V6 C5 Y' b, N; f) n8 C
1.png

! ?, D% ^* e7 l- s
五、痛苦的事情优先解决

) `+ O9 N" @# l) @7 I/ g' |: B
1 q% M& ?7 D" t6 p
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

+ i  g5 q# ~- \* w
+ F2 F- i; c0 k2 ?( N* F! l$ A) {
六、工具也是一种文化

* X4 D2 l" A$ @
; }* Q8 ^! q* k( E$ N9 v* K1 |
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
2 Z: u% v2 Z& k3 X( h9 g* Q  P& d/ s

$ t( r) b% U( a# C  Z0 W) K7 H
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。

3 A. E- X, X& u

! x$ s* u" Q5 U+ v; ~% v% w1 [) }  b9 n
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
7 r$ g6 R$ k- v9 Q  `$ H: ]7 u
4 [" S) {! o; s4 f1 i) N
七、组织二次元,加群落地力
0 @$ B4 b4 w7 ]5 z0 T. U

" W& n- v* [% o" Q/ j! x5 H8 E
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。
2 G: w) w- K. w# I& f

( N9 W& |8 e4 W* ^
八、价值拉动,而非事务驱动

8 a* d* \  x; M2 W

# c8 ^  T6 J7 x8 z7 d& R5 S
经营核心的准则就是以家客户的价值流作为驱动。

/ }6 k$ p' g) k& b" l) b: [
1.png

5 s) d# ~4 V2 U1 W, D4 J
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。
7 c6 w& T8 p2 P0 X3 X

) d0 a, l, Y+ t: Y
九、平台+插件=服务能力产品化,和组织一致
) d9 I9 v& w  T& V) ~

" Z% H* u8 w7 e( j8 ~
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。

# l/ g. S9 X" U! v, T

* j  @: ~- K, }: m) s' p# H" ^
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

8 E1 G' S' ]+ m! a" p4 G
. u1 |( D3 B, D( Q! [
十、自动化别人,先自动化自己
6 ]  ~/ ]$ E) M) Y$ L& E7 p% [
* s& X! W% g% X* A5 L1 O
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。

  C1 x- I4 k% h: V# V3 s" k7 U5 x6 Z8 h+ d+ C  B5 C
十一、持续交付是DevOps落地的最佳实践
/ T$ E8 Y4 j1 a
' v: L, d( s( k. V+ E8 K
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。

+ l  _0 u" @6 w& [$ P& @
1.png
* S) F! i4 r) i( C3 }! n
1 |+ x7 j* u5 Z
十二、IT运营管理驱动Ops能力建设

0 W$ R* \1 B& o; E
: i% s1 ]+ {" O% Q, }/ \. w
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

# ^9 o2 D0 T! G8 l; T9 G% _
- j" N' _: g( }  g$ Z0 `
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

: \9 A: ?4 G2 }
1.png

# v: x( s& g/ `. S

/ p" X' ~- h; C) L; v
十三、构建面向应用的最强管理驱动力

. [0 @6 ^. v' u- {& `* a: y& J+ \

1 p. E9 Z1 y- v# W* h+ s
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

; L! x  p* }: Y, Q  c2 l
& M4 @8 `) ]4 \; q) N  y
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
/ r- W6 r" ]. g1 p
: g3 Y0 ^6 z. x. h
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。
4 m* N; v/ E% \7 [! X$ d0 G
: ~3 {5 t) p0 P! p6 d0 A. d& Z
十三、构建面向应用的最强管理驱动力
0 e$ m. f; q- j  j

# z6 M4 ^8 t) P& L# a
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
1 `) X' @" n! s4 F: D

7 L5 e0 J" ~  Z$ K# ]+ A- M
十四、构建指标,驱动DevOps落地
4 j6 C( W$ w# V: W( x/ U* X
  a. k8 h, H5 c( C0 O
1.变更时长
1 R7 ^0 b# D* J4 p

5 ?& M+ c& ^  z7 C
2.服务恢复时长2 P. C# k. i: `1 V7 M9 A
* s8 `7 u0 O: d* q

, P& Y2 f; R. P; {, W. T2 p
3.发布频率
! n$ o7 i  u; J7 J. q. T# d

2 e" R6 f  i& [3 c
4.变更失败率

/ `9 U7 E# {5 a9 R* |

( I  D  n( Q9 e- [$ N( @* H
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
6 H' W6 S3 R" g7 G5 h* E$ P, J
2 s  M/ m: `) h6 B
我的分享到此结束,谢谢大家!

! f+ g# T6 p4 w+ t1 t
4 {! A. o+ ^3 E
原创:王津银

# j0 R+ \* o, S5 ]7 C2 k

本版积分规则

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

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

Baidu

GMT+8, 2018-11-14 13:10 , Processed in 0.248905 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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