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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 400|回复: 0

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑
! g: ]( d( j& Z3 a  G: _, U, \% _$ K- Q' ?; R: S/ b
摘要
4 Y" R* R6 o) g1 ~0 i! }  X

1 d& P$ v* j6 B6 @6 l
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。

1 L& m2 \$ U4 s3 ?; u2 P5 C+ }2 y5 d/ A# B  x
DevOps的全局理解

- }) O( y2 F* m6 r! H
1.png

' z9 P6 `" v9 K- _
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。. N3 I% I# r+ y2 N5 C* h

, _9 u( R0 D: V8 {: Y+ y% ^
DevOps与ITIL的对比融合

& k& Z1 @8 c- W8 Q: C7 U

8 z" W2 S3 s" r3 r. n7 d( Z6 J
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。

, O' {+ Q" I: V3 ]4 ]. k

& u$ R, s+ ^7 o
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
* z2 Q' K) K% s/ H  X; G( Q. B3 C
/ I! l/ N" k1 e& M7 c1 s/ U3 p3 T
DevOps自动化与ITIL规范之间的融合

' K( ]7 V8 V$ @/ X$ g2 d, o, c
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。
, @2 V$ X8 q! K: U  m% y& f
& v9 [- o$ \* d. ?
  • 第一种模式是在线服务开通流程。
    6 R: l1 \8 T, x/ K) m8 N6 ]& f7 Z' [4 O
2 u# |) c" j7 q1 l! ]
  • 第二种是重大变更流程。

    ; a$ B' n( S9 f2 o# R- i, r
1 {& X$ a8 ]" h
  • 第三种是敏捷发布流程。
    7 h7 M9 u+ H( L' [. B/ z
7 S/ ~! S7 H6 ?! w: U' n8 H6 d
从软件研发模式看DevOps9 y# ^% O. {9 _3 f) `% x* P

+ q9 ?! Y) u1 Q0 c

0 c' b1 [$ h- `% L( g5 X
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
. h* v7 F% y2 }# w# ~( R
1.png

+ j, N* m( ^5 _
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
. h5 {! V. r* n+ {3 x
DevOps的落地经验谈

7 h( m7 E2 g7 b3 o) z1 x* n
一、理念与价值先行

, L7 q# [/ b9 r  c% u. F, n3 C" M; l
3 V8 f% m5 V/ L2 d' O
强调五点理念:

# c% ~* g  A6 u: A' y

# V5 b, z" |4 D( f- \
1、通过持续的服务交付价值链打破孤岛。! U0 {' F( p6 e

" E; L  q5 \6 J

, l6 Z7 E/ C. I' G
2、整合开发和运维的能力,成为一个协作的团队。7 |$ G8 G+ f9 |& L' G/ Y% c% t
+ f" _( C7 R' z/ j
4 x2 y+ N/ v/ B7 w
3、端到端持续交付流程的变革。" `0 r7 v( x7 y% m! m# R+ B

* S; u* L5 m+ Q8 T8 E% G6 n# P
4 e3 t1 O* N3 r/ g: X
4、对新的应用和服务,加快且缩短实现价值的时间。
# E: \7 J) b6 [/ ~
/ ?+ f, D% B& J2 ?# Z
# O) h' ?! [0 B, a, ~- u, l
5、不影响安全性、兼容性和性能。
4 X# U1 T3 D8 |) V6 u, `& o/ P
1.png
7 u- t8 g0 Z; @
二、顶层设计与全局规划
+ m$ ], B5 b1 W/ f" _
5 X+ B8 z/ r+ s  r) T
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

% C3 K7 t+ Q# a# h3 l
3 O; N& p( P. X7 K. J
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

: f& d8 C& k7 |7 Y, ^0 y$ D1 y0 p

& N$ R6 q: X* @, L, f. w0 U
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。

* r+ J8 P/ ]# [

; ]. u" |/ e. }6 L* P2 j% f
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

2 Q. |7 m$ X* {* [6 c

4 z' L: M2 D. n9 v! `1 p. T+ h
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。
  S' r5 C1 E! \- S: I; T% _/ ^

3 `! O4 w+ F4 g
基础设施:虚拟化到容器化的平台。
: G/ X7 n# Z% U- L! A

5 m! B4 L9 A0 Q, p1 B4 T/ @: x" y
度量:度量体系能不断驱动能力优化。
5 g+ q- `. d7 l$ ]

0 y" h/ S4 Z" N8 k# e' u1 v
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

4 y. r" b- |% t  F& v
1.png
2 K) U, V. ^  o

5 S& K! L, s9 H! l3 u
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

% p1 Q/ }4 R( z. q- e) I* B

8 {* c3 a' E1 R0 b0 u9 F
三、Start Small,从小做起
, o$ ?3 l% E; t, T+ d
+ @! a, T9 N- G+ p
基于某个角色和某个场景去进行从小做起。

: T$ c" r- V! R! c

) {: Q; y* V/ P0 H
基于某个系统或者某个功能域来实施导入。

- ]; {) v! E* T  R/ X
8 n& v: l# }1 s* p9 a4 E+ T
切忌贪大求全。

' w8 O: b5 ]8 Z8 o8 `; I; @8 v
5 s$ l6 _& [# s# l0 F/ N' C/ `
四、构建IT元数据平台,驱动IT平台间整合

0 @0 @+ V' q- g5 t7 M

3 D6 P6 c1 H9 e  s
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。
! {+ B+ m+ B) o" k7 l/ z
1.png
6 _$ ^$ D* \1 O* `: G, `( M! H. [
五、痛苦的事情优先解决

7 Y, g' l/ {  o5 m% P& [

# [2 U2 M# p* u
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。
$ U& h6 x) f- E1 x& `6 ^
( |% C- [+ _; H! y8 W" E1 J
六、工具也是一种文化

# A0 f) n3 ?7 V. O
2 k! N1 f+ @( d8 K
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。

" k5 r. C0 L  Q7 j% q

9 m* n) E1 I. K/ m4 k
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。
* B# L: X+ w$ X, V7 n
3 `* [) U3 a' _  r, m
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。

  [3 C! j* M: l0 T: e% z+ b5 U3 }/ z7 h: v
七、组织二次元,加群落地力
. D' o+ X" D5 S! B, Q
' A( h9 K* Z/ ]' I
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。
3 X& g% r+ j) k1 t6 {  ]  v
# N5 P8 `7 V' \: w
八、价值拉动,而非事务驱动
+ G/ l7 G; y% H; J) m2 e
, B4 t- y  i+ a$ Z- k
经营核心的准则就是以家客户的价值流作为驱动。
0 r, f* l6 a0 P  y3 g" D
1.png

& E6 ]) X! R9 \* w7 Y4 t# v8 ~$ Z
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。

; q6 _/ h1 Q) l0 O: i1 Z8 b
6 T% t$ K$ l) N7 T3 S# ~
九、平台+插件=服务能力产品化,和组织一致
& E% X" J# Z! j6 W8 w& [

, q& j7 z- F7 y9 ~
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。
. W. }& n8 e2 [
! \/ d) Q& I% _& t4 c
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。
6 K* b  Q- B  I

6 P3 x5 }& ^- Q5 h! T5 s1 a
十、自动化别人,先自动化自己
9 y6 M. `) V. v, r" H- @5 @# n

0 {, r4 b+ ~' ]- n+ L$ t2 |
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。

* `" N% Q) ^3 z: ~7 @5 |7 n8 _* x1 E, L
- Q4 {# V7 G; u" z( S
十一、持续交付是DevOps落地的最佳实践
5 V: |6 M: u0 Q& c1 I9 R/ g; A4 f
4 k8 G8 {5 N/ s  G
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。
( l2 g) V" `! J5 t
1.png

9 N, a7 Y, K3 ]6 Y
+ h. @* x- c% L6 |0 q3 [
十二、IT运营管理驱动Ops能力建设
4 ?& _4 d3 I& N! W8 z
4 ?2 g7 z" R# h: k9 L
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

4 i! v  w; B! @1 j; p/ m3 P8 D- _
2 @+ I8 A7 l4 H6 @
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

. F/ H0 A2 T# P2 @6 o* M
1.png

# h6 {! u' a0 \" W
7 {* d0 [' R. l1 w
十三、构建面向应用的最强管理驱动力
6 ~6 R* B; e  G- F) L4 P
' k: ]9 c' e: Q9 B$ K+ I8 q
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
2 D: `! U3 ^0 Q$ f' c+ e+ o

8 i% g) Z+ a: J
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

8 \3 [  H7 n5 V/ |  M0 H

& L6 x2 _" l* d: O, X& {+ A
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。
7 p" J) i0 A7 H) Q" c. `' Y

8 ^6 u( R5 a( j4 a8 s0 L
十三、构建面向应用的最强管理驱动力

* z: i: {, F3 ]0 }( r  v; P) c
1 h4 P; d8 |* `7 m8 [9 {
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

' h! G5 b$ {9 }8 o) |
3 k) w' ]# M+ H- P% J( o0 `
十四、构建指标,驱动DevOps落地
; z8 r" s5 D$ F
; J6 L7 s$ K0 n; y4 n* `4 ]' I
1.变更时长

3 R. f; V+ _2 ~# x
3 N3 u+ x, d/ e" r% b& \
2.服务恢复时长
2 Y( _2 K# f1 |3 P! I/ v6 V% N3 v  Z
6 ]: \6 g" s3 q5 l; k6 c1 w" `% W
8 I. T( j- k6 o0 z& O
3.发布频率
1 g* G3 H' `1 I  ~: H: a
, K* N" R1 y& \5 Z
4.变更失败率
- P. @- K, V$ T( Q9 V. ]

- C- W  ~8 ~3 M( Q" r
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
0 l7 l$ ~2 p+ k7 C0 S4 `# }

. }" l  M5 j$ @$ S: p
我的分享到此结束,谢谢大家!

3 r* v! t& C4 }" [" }

- c4 \  t4 q/ p& z# e7 ^
原创:王津银

* ~  [' }" t3 j$ \

本版积分规则

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

Baidu

GMT+8, 2019-7-17 05:04 , Processed in 0.205760 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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