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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-6 17:25:10 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-6 17:27 编辑 7 [9 l, _' z! v
0 Z- P6 b" V/ F5 Z8 \7 p
摘要
$ j; v" i. q; ?

# [3 q7 V7 M% X5 N2 [0 M; P  ]% b$ S# v% M
在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时,DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地,王津银带来了他的实践经验分享。
# v1 ~6 S5 p; Q( p2 r6 O

- s. ~; {9 Y8 ^1 k1 R. r
DevOps的全局理解

  }* I7 y9 n& h2 k
1.png
, a. }! d" a9 g6 A0 Y% B
DevOps的整体框架首先是一连串工程实践的组合,其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础,强调自动化拉动式的管理。) W2 a2 i( ~- m$ O, M" Q3 Q
7 j1 ^! r; {( C7 B7 P2 c
DevOps与ITIL的对比融合

4 b/ b/ _3 g) y  y8 P3 k8 C

' ?3 X1 @' l. g2 V5 Y
ITIL面向整个管理过程,规范优先,效率偏低,成本偏高。DevOps则是面向IT运营过程,是一个执行能力的自动化。

$ V4 @% X. r! c5 d! R6 D! q

7 Q2 g9 E0 L4 x" G4 {0 s
ITIL是以离线任务的管理为主要特征,但DevOps今天已侵入到在线服务。
& Q: Z7 w5 d5 g9 o  ]

- b- m* }- C  O
DevOps自动化与ITIL规范之间的融合
/ @7 T* x2 l6 ^; T% u# w; b) R
根据我们的实践,在传统行业交互过程中,我们的产品跟ITIL产品做对接时得出了三种模式。

$ A9 j$ ^" i. m# ?

4 b; N+ d4 c+ P! _' {
  • 第一种模式是在线服务开通流程。
      L' d: h8 I; A9 C
% f* R0 t" n! A/ l/ M4 R
  • 第二种是重大变更流程。
    ( T8 E: \& P  q7 B
. L# m3 |: q. b- N' }" f
  • 第三种是敏捷发布流程。
    - d6 A: c0 @: M# j  }+ K! X
. F3 V! r# E( x/ d% c! O% K
从软件研发模式看DevOps$ f; \1 {8 P) ?- u" m5 I

/ f- S  m3 G1 O  s3 J

8 j  _& H$ M7 b9 B
第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现,就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。
  `/ m. p! d# V( j0 `
1.png
/ N; a& {( ~5 ^3 e0 N
随着研发模式的变化,各个角色在里面所承担的工作量配比也在发生变化,研发越来越重要。
) k. v8 j* z( u# d! K6 |0 b
DevOps的落地经验谈
% L7 W% j0 K4 C
一、理念与价值先行

5 L  G! K' l; [/ o. k8 F

% x1 ?3 t1 v2 z
强调五点理念:
) Y6 e/ {" g. N

, t' f6 f1 b: G/ m4 P/ K# \
1、通过持续的服务交付价值链打破孤岛。
5 q/ s; a2 {9 ^% t+ J/ I& j/ @1 F; Q
5 W7 e+ D0 O7 S" x, `, ?
2、整合开发和运维的能力,成为一个协作的团队。: N* L6 k8 T% o0 Z5 n7 [3 y# a5 N
- w* _7 D  o' _4 ~" [7 E

2 K9 K( H3 G" Y
3、端到端持续交付流程的变革。
+ i: C& ~2 A  t' C
% R8 v7 ^5 i9 m# |; ^
) b+ {  K$ e2 Y$ s$ q
4、对新的应用和服务,加快且缩短实现价值的时间。
0 T& o6 R/ _+ |
' T' b+ e  q% P2 z% ^4 M3 m

$ w4 @1 W! e+ F" l& K
5、不影响安全性、兼容性和性能。
% F$ u4 h! W4 L1 M, A% F% ^
1.png

$ o# M; p: _# d
二、顶层设计与全局规划

, z1 B% I. @- o( ?3 v

, n* ~/ b) M. ]. |! U5 A
我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

6 w+ K5 V% w1 J! o7 X4 ~0 q
+ F! ?* O6 q1 F, t6 u
组织:首先必须打破组织之间的隔阂,其次DevOps组织要面向产品而非项目的协作文化。

$ U3 W0 C1 R  X

2 a6 \# T$ L, y! O# t& T
过程:轻量级流程和自动化工具的完美结合,确保企业的高度敏捷性;自动化为先,而后再流程。

3 H2 B/ u- |8 M6 P) b6 F1 ~
# w) {6 P( C& ~# b: @8 G
架构:架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构,基础架构是讲标准化基础设施。

" M3 v# [: M! T2 U0 x

4 [5 z* E: [( X  c# n9 y+ C9 H
工具:把质量成本和效率这几者维度同时兼顾,具备可落地化。
- R* P7 W* {3 M4 {5 I
6 D" N4 U1 O5 x) N; e! C2 F9 P
基础设施:虚拟化到容器化的平台。
4 A8 m, u( L; f) T

2 s& r" J3 [" w1 S0 `" A
度量:度量体系能不断驱动能力优化。
4 L8 p  c$ l" g! b( Q

. v5 O$ Z+ D; I% Z+ k7 O6 R
在纵向的维度上,把能力评估分为五个等级,这个五个等级参考CMI。

( @) k' L3 u9 Y0 d. _! v" g
1.png

' w: V! S# Z" E, W" \- m9 A1 |

" N/ B$ x6 [# y/ J8 ~& }+ j. x) l
Quota定义了namespace中能利用的最大资源,而BatchJobController算的值则在中间来回浮动。

$ f1 q; }+ p' d& K, e
4 t" X& a9 c3 \; ?# U0 W
三、Start Small,从小做起
' X# ]2 @; x6 B! W; x

: Q! {% @- x$ M+ ]: q' H- Y* E6 o
基于某个角色和某个场景去进行从小做起。
7 B8 s  _0 o: \3 v1 g% v
' [/ k: r/ M/ [+ |
基于某个系统或者某个功能域来实施导入。
) E  N7 w; F$ z
* x# c, }+ x' P1 d5 Y
切忌贪大求全。

5 G9 m3 z9 [( ]2 j& ^+ P/ e
% w4 B/ D0 S; y$ s
四、构建IT元数据平台,驱动IT平台间整合
, T4 e8 q0 R; {7 Q  G) D

* K* \4 a' u8 l* Y' ~3 [
因为要缩小范围,CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后,只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后,再从应用的视角看到底用了哪些资源,把这两层维度强关联起来,再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转,在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。
1 j1 }3 b- J5 t
1.png

" v. _" p2 J. p4 F" e
五、痛苦的事情优先解决
/ Q1 h' `1 r/ E; J0 @4 d
( f4 |2 t* O2 ]) g4 z7 x3 N
因为运维的角色很多,最终的能力管理过程也非常多,所以一定要通过角色加场景,最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力,这个能力应被上层各个子系统使用。

3 Y; p6 S- P) p! g9 z! N1 H3 ^' l% v' s8 m; [+ U
六、工具也是一种文化
, d) B: s$ O& E- E( r  O  z2 p$ }

2 ?) V. t* |: F' v) G- M6 G* Y9 c
作业管理和调度管理是一种平台级的能力,不需要对它进行场景化的理解,只要认为在自动化的构成要素里面有个原子化的事物,同时要有一个调度引擎去编排这个原子化的事物,有两个要素就够了。基于这两者的能力,面向角色和场景收敛去归类。

# t! W: y( F& V5 D6 [

. G4 a8 b# s5 j- f+ {+ N" y& S2 M7 Q
工具也是一种文化,通过它,我们可以构建各种各样的原子工具把我们的能力进行拼装起来,然后在各个场景下使用。

0 Z  Y$ s5 q$ v0 |# \6 D
0 I* g5 @' v- W3 _! a  m
好的经验一定要通过自动化的手段去去沉淀,而不是通过文档去沉淀。工具是真正推动变革的有效手段。
/ H- E5 _# z+ l6 j4 t) W

- _- v0 s$ m6 M6 A% A4 q
七、组织二次元,加群落地力

5 z, N  f- v0 \

3 O4 y3 s, t$ C
我认为这里面其实要把它变成一种虚拟组织的形式,所以我把它做了一个改进。把中心的角色去掉了,并用技术化的思维做了一个拆分。但这一块强调技术的能力,要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则,和技术、组织架构完全保持一致。不改变现有的组织结构,通过技术的一些手段来加强组织的映射能力。* l2 ^: z2 r* D) w/ |
1 ?5 a$ Q5 R8 ^" d1 ~
八、价值拉动,而非事务驱动

& z! a6 _9 m& G- y" a" B7 J5 |: R
$ I9 N7 o; R& y% \, A0 E) T
经营核心的准则就是以家客户的价值流作为驱动。

$ _8 v2 s2 f: ^- n, y
1.png
$ T' y0 f* z  O) }  h
在识别整个价值流的时候要看哪些是无效的活动,哪些是不增值的活动,还有哪些是给客户产生价值的活动。
1 f& q+ u& s% A0 f8 ~# W8 b- C

9 `- _# U( @7 D7 c
九、平台+插件=服务能力产品化,和组织一致
  f9 S! t$ x# D& Z* g" H( @% b
- D- t" a7 H1 p; i  D3 }
产品一定要有一个平台化的思维。这个平台化思维有个边界的,不能跨越这个边界。同时要去适配各个公司的现状,怎样把公司现有的一些能力插件化进来。
1 f0 u1 I6 l& g- E8 v& I

5 u, E5 X9 V! h2 i. F- [
从DevOps的角度来说,一定是交付流水线的平台,IT端到端的调度。整个插件的适配层是插件的协议标准,把开发者、测试者和运维的能力,全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

& p+ g: L6 q! Y  N
* A& r# p, H9 }6 s1 ?$ Y
十、自动化别人,先自动化自己

6 D/ B5 [7 X8 v/ o3 H* I' H1 _
7 x3 O1 d4 U4 T  j9 r
一定要先自动化自己的能力再去自动化别人,千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程,还是一个环境逐步覆盖的过程。
6 y) ^- U$ z0 \1 n. @+ i

' }0 [, i! k5 \
十一、持续交付是DevOps落地的最佳实践
1 r: t- M6 S* M, C) l+ m0 ~3 J) t

4 p4 e+ q, a6 v: `
持续交付是DevOps的最佳工程实践,以部署流水线为基础,以快速交付为目标。

7 U) B/ X5 `) ]$ T" R1 s* O
1.png
& W: b6 B+ ~0 h) n5 L* V( d% Y

  l" u  ^6 I& w$ j; n
十二、IT运营管理驱动Ops能力建设

: y; X; x& R0 l
+ _0 j8 O: Z3 B3 T# V. G& W
应用上线之后运营过程该怎么去覆盖合并,我把它分成几个阶段,人工运维、平台化运维、孵化运营和智能化运营。

. _) h' e8 {. Y% s

8 a# j" S* B. ]0 q6 m; D  r
运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

9 @  U9 d! F! e6 ^2 m$ L, a
1.png

4 ~7 d2 U! b, x

! j; m9 }3 l+ F3 P! S4 u6 F
十三、构建面向应用的最强管理驱动力
' D& b& \' K% _- w/ @' X
! _( e/ G0 u! E& e
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。
' f* A/ k; ]# t

8 Y' D  K" s& ?/ b6 t* C
应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。
9 L9 O; F* k9 o

  l' `8 l7 K! L* F3 z" B( u
最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题,数据分析面向整个的服务、数据可视化。

+ c( ^* A7 F/ i8 \* e
; Y$ }) k: b% {6 L6 D
十三、构建面向应用的最强管理驱动力

% W- y, j- ]) W, d! Q3 z* o

( C3 ]' e5 J4 p; w& A* g
应用在今天是变得越来越重要,云的形态底层把能力服务化,那么应用怎样去抽象成三个维度,一是资源的维度,二是动作的维度,三是状态。

8 |) C* L+ v7 s8 W. j2 H

! ^5 T  d$ z5 H) {" C
十四、构建指标,驱动DevOps落地

( W( P2 m1 w2 N9 s

  F. I1 t( w# b# h
1.变更时长
9 v& o! a' q. Y- L/ l4 d

6 {1 w7 A# B; Z7 P
2.服务恢复时长9 P; `: u7 T/ T

1 m, C% H6 R1 {. x" E& L% j5 f

7 X% q, k7 @& P+ x- `( g
3.发布频率
; i  `9 R" \. N2 F6 ~

3 \$ M  O, c3 G: b1 D* {
4.变更失败率

1 ^! X% e0 M( v+ D. T" k# S
# t# u8 J7 G, C- A
合理的指标驱动构建的是不同的组织,高性能的组织、中等效能组织和低效能的组织。
% [3 Z% V0 X+ B0 A
8 H! D/ ~( |. N& o  P1 B
我的分享到此结束,谢谢大家!
& I0 K$ {" H: v/ \7 o3 f* Z9 x4 B

: w- z" u7 e; [3 T1 A/ K3 h* T
原创:王津银
9 K1 k( @; Q8 H# G8 ~

本版积分规则

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

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

Baidu

GMT+8, 2019-5-24 13:45 , Processed in 0.250731 second(s), 41 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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