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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 % y$ D0 k, @( N* P9 V1 R
2 [0 Q, D: ~( J9 }
摘要6 M+ o# ~+ _3 ~0 Q

4 @5 y: P2 L5 g6 H9 v5 x
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
9 x. s/ T* E  P7 t0 B# a

# G, T+ T7 l" h' G0 l# ?! y
DevOps的全局理解

. P  W: ?% e: f

/ U# D$ m; x  F) h. y
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。
5 C) y8 B! I8 Z- b" Y# f  r, ]  S
$ G' X& b( s6 y6 F  N, W4 t
DevOps与ITIL的对比融合

1 }& X% W) b: W4 N( r- L' j
# Z- n2 k! o9 g5 s- n+ F) e0 L
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。

) H7 P$ `, V% P5 P6 `- o& d3 l6 a
# x1 `, O7 f1 ~" ~! C
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
/ m( c5 f) ]) \$ c9 n4 W
+ j4 `# ~& I: ]$ \
DevOps自动化与ITIL规范之间的融合

* v9 U7 d, N3 W4 o, N1 K" c
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。
& i5 \3 N+ U; U4 K. ?9 T. e
3 Q/ k7 l# E3 k; X& K# ^& m- r
  • 第一种模式是在线服务开通流程。

    7 }$ _& e9 J5 B3 B0 p4 Z: N" d
6 v" H6 a& q5 Z
  • 第二种是重大变更流程。
    4 A9 H/ j- K( |; C& O! [
: O- W; [6 g8 K4 j% t
  • 第三种是敏捷发布流程。
    4 }, i9 I$ ~# G! V8 m* d2 A
8 X3 ]) ~/ V7 K9 V% F8 {2 T& U; h
从软件研发模式看DevOps
% e! I; t) D  b7 F, A
3 f, B* A% b9 o0 g8 G

1 d3 Z2 e) t1 ~  Q
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
- d4 T+ @2 t# `* {+ b

( B6 L  ~6 j0 H- N( O* L
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
% @: x/ Y/ y( F5 n3 L+ Q% z& ~6 ~6 N
DevOps的落地经验谈
- I  P; n- x: G9 m' W
一、理念与价值先行

+ c- n9 j( N" O5 {) M; s: S$ r

, ~6 Q1 I" c4 r) o/ D3 F" g7 S+ P! q
强调五点理念:
1 m, ~8 d3 ~4 V" g9 A& |
; d+ o  J% j, j0 }: @7 @* K/ b+ U
1、通过持续的服务交付价值链打破孤岛。- X4 {" C) c' I# c6 z. l2 j( t

+ ~5 ~2 [0 b. ?* g6 c( z
/ w4 S7 U/ n4 s4 S- T7 X
2、整合开发和运维的能力,成为一个协作的团队。3 O! O6 ]- T" [& H! C

: ?( x3 i2 c1 g  b

# @; x% i* i' U" Z0 h
3、端到端持续交付流程的变革。
% w4 e5 Q  x7 n8 j. i$ N# ?6 \/ V" X# J! V* k& _' u* u/ j
8 z# _) |! W8 v
4、对新的应用和服务,加快且缩短实现价值的时间。/ P- E2 ]4 `7 {
7 M; \9 K  M# W0 _
6 ^" a% Y! L$ I$ K9 H- i
5、不影响安全性、兼容性和性能。
% h' A, f) N6 ^  p

. M* s1 Y# R5 t" \8 {$ {
二、顶层设计与全局规划

6 v" I. u0 X# q3 W: U8 V

& E, V: p2 _' c
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

( N, `( j( n  C
# T& h/ b. h" \) ~2 r
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

& S+ U' P# q8 ^4 N1 Y) i# Z9 M1 p
+ A) z7 Z, L, q2 D$ U7 t4 f" L' Q
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。
' T0 p# n* b' ^  `5 o. E% e

8 I1 l/ F" \' C$ r
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

; _' G' n3 O: W
0 [% t% n0 y- W0 K' v( w, r2 N
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。

$ S5 q# h, [* h
7 O$ P% g5 b( z9 P; v
基础设施:虚拟化到容器化的平台。
5 M7 a4 g) H) K" K" m; w
2 i; D, L  \" `6 _, ?: R& b- K$ m
度量:度量体系能不断驱动能力优化。

4 b+ P9 n4 O: k

- b- q9 I& w9 D" F
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

! o- Y# u$ ^6 Y
7 i* o& a. j" P" ^4 B9 U3 O( p

; `5 k5 _! ?8 e' O
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。
' z% e. @* p+ j
8 G9 ?/ H7 [  h3 O; c* B- A
三、Start Small,从小做起

- ]8 u/ M# j) b2 W. e% I
1 B! J3 u1 \3 F. T& s$ e1 c7 g
基于某个角色和某个场景去进行从小做起。
& y& a% w0 `  ]+ J6 _5 {
; [3 o, e4 {2 i0 a& t. N! z. X8 A, s
基于某个系统或者某个功能域来实施导入。

$ a! _( y& E" M- p( K

; ?4 t- g, J, Z* u
切忌贪大求全。

( y0 L+ t& W6 D1 Q; @
6 f- Y/ F$ |4 \
四、构建IT元数据平台,驱动IT平台间整合
: M/ Q+ I2 ~# @' d# y8 T* M
& Q' s6 h6 _6 I5 J& U; U4 Z
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

+ I7 D# \, H9 v( }' J
! z& ^% p% W3 r1 Y- ~) ]1 T+ j
五、痛苦的事情优先解决
: g% \1 O% n4 z
! I' E. q7 `- r
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

5 {  K( w. m" X0 s$ V9 A! g0 y7 h% t! H& w9 U  E$ x7 C
六、工具也是一种文化

" P2 \+ x* Y) t5 c; e: Q! z! ~

& d4 [# b9 P" K8 |5 @: `
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。
4 S. |! V2 W* D
* O2 E; y) P$ _1 M- ^1 {
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。
8 r" H! G: q) s$ `: F+ A3 O- I

5 W$ r- O5 z! u; @4 L7 P( Y
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
' e8 H  s' s* u0 M) X3 z

% d- G  G0 u) G2 }4 `5 w& S
七、组织二次元,加群落地力
0 ?6 O6 [7 u' G6 M' @) \, ?

% E2 A, j; f6 M8 H5 r
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。
' h2 Q/ E- M1 N/ Q
7 @) s" j, r  f1 g5 l+ {6 h) U
八、价值拉动,而非事务驱动

$ V" y$ C$ w/ i! F
& ^4 g- B/ i& X) a/ G
经营核心的准则就是以家客户的价值流作为驱动。

+ ]# V/ c/ `  E0 f' h* r2 ~9 I' g4 j

) x  ~1 q1 e! n( F& @" L
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。
) n8 b9 X  p0 n0 \
+ i5 y2 S/ y' Z% k: E+ J( |
九、平台+插件=服务能力产品化,和组织一致
0 m7 p% ]+ a; e; S; M
" [) e0 m5 x7 X2 m* z/ j2 J
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。

8 d- T  L3 ^& d. z/ h( c
3 i, m5 G% ~" R  h* w
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

) J- w% J, P6 _' T
; a5 h% h1 j. A, n& h* ]6 y- s
十、自动化别人,先自动化自己
* [, g& V6 }+ a! w

. \/ M( Q- D" R8 M  M" l
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。
- X2 a( v% W) |3 a2 B; `

& }' p) d2 t; P9 A4 ]% `' T
十一、持续交付是DevOps落地的最佳实践

4 F6 r# m7 _- }; }' G* [
6 @, h5 P2 Z5 g1 Z
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。

( f2 ^1 Q$ I0 S' B4 V( _
# ~/ z: t1 u' s  {9 r7 R+ O5 n

. W$ y4 {- M6 b' t0 z2 U
十二、IT运营管理驱动Ops能力建设

; @8 b& w, A( z: d

$ z4 z. K( _9 l: o* ]# Q
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

7 V' U$ g1 o+ H: f
$ E; ?4 Y) r/ U5 _& ?# C
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。
4 @8 z! [: X/ y; R9 X

$ b- X$ [8 }) ]

6 F6 Z' u, {& u9 [! c1 ?
十三、构建面向应用的最强管理驱动力
9 Z2 a" D: L2 B- K

8 m' Z. _/ T) _9 [1 D
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
9 x9 F5 {1 ?; ^. e5 Y: Z# N
# j: g$ M3 ~8 x
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

2 a0 c! _6 E! R* `
3 [9 Q! e! K, s# Y
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。
! e: n8 u$ b  |. Z

5 Y0 v$ ]6 v2 s1 g6 |7 b8 [6 _" O
十三、构建面向应用的最强管理驱动力
$ J  f4 F# c9 t  @9 }9 I; t

, T% d% M& Y2 u0 G3 Q: J
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
3 k6 Z8 j, v* E2 ]8 |$ \. U
: O; t. d5 B; n9 X, V
十四、构建指标,驱动DevOps落地

" p! R5 }9 n8 |9 |) R1 ~% p
& g& {# Z1 V  ~8 c
1.变更时长
/ C. u" S7 O# N3 l0 {" N
6 S( i1 v( C# W5 y% |
2.服务恢复时长0 Q3 m  D+ z: O2 ?1 j/ p+ n$ m1 @5 A. [
$ C0 F  t4 A7 e
* I7 w+ ^  \& S3 a
3.发布频率
9 o+ [# ]" v# k$ N: U6 q% n
1 R' a5 a  j8 m0 B/ k% r! b  _+ T
4.变更失败率

& G* h2 r  |/ c$ H: ~

9 v; b+ s) |& M  E, T! |0 b1 R! I4 W
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
) H, R6 |% {# U3 E/ Y( P: ]4 }! G) e. I
6 t6 R  F8 V" O  `$ t
我的分享到此结束,谢谢大家!
8 ~- R$ ^+ X; _1 k2 A
; \' }4 R# A; j0 h4 e
原创:王津银

* X$ K( b4 [9 n; o. R' c

本帖子中包含更多资源

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

x

本版积分规则

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

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

Baidu

GMT+8, 2018-9-21 01:05 , Processed in 0.198163 second(s), 36 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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