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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

DevOps 第一步如何迈出?

[复制链接]
来自- 美国

参加活动:0

组织活动:0

发表于 2018-9-25 11:05:39 | 显示全部楼层 |阅读模式 来自- 美国
本帖最后由 adminlily 于 2018-9-25 11:15 编辑 ' s+ U3 L+ @# A& ?; b
7 D) J7 ?  h! s9 t- r2 _0 ^
前言: p0 i0 Z- r8 Y6 \$ \
2 s/ p! ]7 v; n- {& ]  s/ R
DevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。 0 z" X9 g2 O, [& r* f8 p6 c; p! @

. I0 ?! y  V- O$ n7 ^2 |; M' @7 c$ W/ e6 p8 E  S6 a( w
- S: e, T! I, ?8 L" S! T4 S

  N/ V# D% Y! N5 Z! j) n
1、IT精益运营与DevOps5 x2 v: I6 [9 H5 M# e& }

, P3 l7 z, p7 l

6 t8 |3 U3 J9 c# [& @3 L5 g; U9 ^/ Q# F$ |/ x( d, ^
随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。7 i/ |! b' T2 o9 I8 x
* n/ i& l- n- q4 r4 _
. C' d6 b8 C0 `. s; ?

; o6 @+ R8 p4 u& A6 W$ u
新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。
2 T  W7 }. S4 n3 S

0 i4 v8 n2 A# [9 L- j3 A
普元实践了大量企业数字化转型的客户,包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下(互联网企业有大量的人员保障),怎样快速地把我们的 IT交付出来,这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门,需要将IT的精益运营与 DevOps 无缝进行整合。
" Q6 M' r& ^4 D8 H
! I2 g1 p& t7 X& G7 _4 O. [' X7 q
1.png

. V# x& O9 S% Z  Q2 K; r( D
+ z7 F5 E4 Z9 a" x  k) K$ A: d
举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。
4 q# o0 y; r1 j9 b8 Z8 J' o

  B/ r1 n9 V! C8 I/ |
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。
导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。
2 d/ w  i' T" v; N

( M7 v# n, R' F6 i; c( S/ e

  S9 W2 l  R: W4 Z. K
2、对DevOps的认知
, w+ Y1 e- U4 H$ d' c6 ^- O5 E

9 ^: a2 n; W. M4 |; n) m  i, `) [3 k* y& }

& O. M# O/ i9 w提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。
8 K  M: I" K8 v
1.png
% l( E% m9 f. b$ _
6 _: ?, ]+ f/ t! B
我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。
: E: a/ q) S" ^! N& j4 \+ I
1 V0 [1 `' [0 m+ J: r
在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。
) [! |( [) ?/ J( q' A' \
9 K3 D( O/ {7 M
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么?
9 N  w" P" W/ `

4 u" y( b$ g8 J
1.png
* M  X" P$ S' E. b' @- o& b
9 v# |1 f( E7 R* ?& Q! W0 W  K
确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:

6 W! s+ F& N8 M

3 i: Y# q+ O+ |
1.测试环境和生产环境完全做到自动化部署;( C' ~* V" ]$ G/ M( J. D; w; D: H/ G
* n9 x' c* U9 t* N

9 ?2 ?; @" J) q1 n. Z! i
2.业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;
2 x- e6 M/ S, R- ~2 s3 W6 m
+ S6 f; K" P& J; ?. k) N
7 a* N/ y4 l: f! H. V1 g3.产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;2 i9 Y! ]  F, J6 t7 b  U4 D5 b. m

$ R; j0 e* X: i2 E+ o$ v6 P( c% U7 C  o. U
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。
. I1 @  I7 e3 z3 z+ k
7 d, I, L) [( A" X" r6 M
企业 DevOps 思维 VS 互联网思维

6 D) f$ c+ @. H; D
, K; H- a* X) m' s2 k
互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。
2 X+ e9 L: X0 B! n1 D" P
0 A$ s' j' O( v$ ]
传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。
3 y2 G9 j6 j5 z) o$ L: z
5 u! M; G. ]" |- F3 Y
DevOps 的本质是什么?

" h3 r8 @  [. t; p0 b9 N6 K( l, [
- U* E% d2 V7 H" H# g; o
    我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。
9 l+ U7 X7 T  P
1.png

, `/ G4 {4 s. W+ G

- i$ T' ^8 }% r  x. k! ?2 }8 w# L
DevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。

+ X" i! h* o! D8 t4 H- r) z

" h5 v4 o7 u6 \6 h7 P! |8 a; O
上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?
2 A9 C; I' F% B8 x3 m3 W6 b
* \: V+ ?* }3 Z+ J
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解:
2 ?2 X2 K* V" W7 J0 r, Q1 S3 B4 q

+ l' ?) j/ }4 _& \' c! G
1.png

. j) M6 }% b: _6 \
/ C! \5 H7 D9 A, J# F2 E# j
主要包括产品(策划、研发、运营、推出)、项目(立项、执行、完工),而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程,要以产品的视角来看待,真正进行交付的时候,也要以产品为维度进行组织的设立(互联网公司通常如此)。但在企业里面,产品思维还没那么强,仍然按照项目的方式来实施。
: I" z5 g" U' M: I3 f

+ T# Q7 V4 t$ b3 ?
因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。
! }& y, Y/ o, t/ u
  L9 A* m6 d8 h/ j: r
DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期
7 b  _5 @. d3 z# |) a# N& `9 X

; i3 y8 h. k+ v3 u# i
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:
' J+ H. d3 e5 W) _! M* [
8 Z. J- L. |0 f- ?! ?2 C! @
  • 第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;

    1 D3 e! c; R1 L! G& o

) c6 H6 C% B4 s0 ~: u: v( }
; R* Z+ E; s0 D2 @6 ]. j
  • 第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;

    - n( n( B9 \6 }: X6 _
; S! u. i6 m0 s% Y
  • 第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;

    - Z; B6 q3 ^1 R9 R6 g1 u! Y3 I

1 N/ y! p( k+ x, a5 F, s8 t: h* v
  • 最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。
    / j% _. w3 X! u8 |
1.png
& U# n0 E& t, U# B9 X

- x, q1 a) Z2 ]5 a6 ]& C) p" h8 B, k
首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。

' [( q+ ^% T: F: s. p1 ~
2 Z% G& h" W$ K4 h) x, W7 ^0 R
这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。
. a; t! \+ p" J) o
9 i+ j6 Y' z& C3 [( z
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
1.png

# c- T# J7 j# a

2 A+ K$ E1 r- c3 p" A8 v& `
从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。0 r! T% B) m/ K; }) G
  y% `% a0 ?" f3 _% g
( h& B7 b/ @. ^" u7 \
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;

! [; q3 C# n/ [+ \# u: K& ]2 L

) Q7 O- N. b8 h; k0 p7 _
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;
9 l+ ^+ W  P2 G  `  j1 p& ]

( @8 @! P) B2 F. q' h. W. R
在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。

# N2 ?$ x% J4 s

# D1 S0 k3 O" q/ n* @, N4 A
1.png
+ u9 j7 B. Z$ |2 z) p. k" K

3 j- B' }3 E% j5 t
在产品管理中,小小的版本号其实内部藏着很大的学问,基于版本号可以快速了解产品的版本,发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联,大家对IT交付过程的管理就会达到一个较高的水平。

; Z6 r1 r) h' P* E8 H) y

, X0 a5 v3 g- c( k0 J
另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。
1.png
4 g- _7 h. H& |

* Z  U/ w; J6 f7 m+ v
这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。

! p* [6 p4 S0 F. Q) i5 ~
* m6 H) H5 }* f# a  ?/ P9 f
DevOps核心观点二:DevOps平台更重要的是提供最佳实践
1.png

6 q1 m' w' O# f* B1 ?5 `. L! |( C
6 I$ F3 }; ^  r$ Q
接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;

6 `/ f1 W+ Q# f
) S3 g9 @! p% g; O$ {  e+ V
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;
$ g- s, ?! r' s3 m" x5 Q/ `' Y
$ g$ `" t) a0 ^4 Y5 c- E0 Q. _
客户满意度、MTTR、线上问题数是重点评估的度量指标;

7 T2 K! ?) v. C& t) r6 ]3 P! m

3 q* {4 q# B2 d
1.png
( |* y8 n3 `7 D
9 T$ ~+ B% H% k: y; w2 {3 ]- f$ [1 c
在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。
. T$ b& y3 K1 o/ e- n" y

4 ~& u: `8 P3 \
DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。
3 P( L0 ^1 u9 |
1 I( h" }; L  n; O
DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。

  @) S& {. p! c* s

  G" q; G6 S# s6 O8 T& E6 Q% D* n
项目交付流水线的示例:
1.png
9 C1 ?; s" ]8 y7 O
$ H$ _7 T- c3 O3 ?: ~
一个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。

) K# K( j" k) k+ [6 f* J) u4 i
6 \; h$ o- ~' _% c
交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。

: d- W  T; A# Z) v, N

9 O7 z4 b4 I$ O; C, |  j4 f
DevOps核心观点三evOps平台,让不同角色更好的在流水线上协作
1.png
6 x- W" E+ m) y

) |/ I8 ~+ D" Q! k6 X- k
再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;
" p" v; z& q) ?( n! X! f6 l' `
2 F) C1 e- z! X  c' t' U1 R
% A- d3 \1 N! y! |$ y- z6 \
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;

. p9 c# n+ k1 z; B+ }0 E) K

3 b$ o' f3 z* p4 i% e! b8 n/ L
需求变更率、任务燃尽图、积压线是重点评估的度量指标;
$ Q8 `9 q  H/ |
7 C- \9 j/ h! `  B3 V3 I
通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。
( s# C; g" Y& i0 g" g% |0 R
6 U/ `( B) |' t) `
1.png

7 x+ L2 K( W  c

1 I" w3 b4 s% N3 e
项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。7 p1 _6 E7 Q# }, ~! f* d

/ C# L' m6 W. H4 F
- B) |" L& w3 H4 Z5 `/ Q! G
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);

/ z2 V  o" y* F6 P  }( L
; S9 @' A5 M) F$ G3 J8 X; S7 I5 J
设计变更率、设计偏差是重点评估的度量指标;

5 O6 T9 q: l" ^9 m% f) m
' R. n* y7 P) A1 _2 R
在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。
$ z% _  z, M+ W1 N* {( F' t$ k# R6 C
' g* e8 [1 f* I: \+ s  o
在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。
4 I5 `& M' B3 _! S! d. Y
- T: ?9 ^' u; l* Q) N  c  }
1.png
1 g* Y1 `% @3 Y5 @3 Q, }

, I* F, K  C5 t' ]2 {  n
容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。
4 r% y3 \, ^5 R5 t, Q" N

. x, \7 ?% G" H5 P/ M) E7 v' x  W: |

* d; q' q, v4 M  ]9 t8 l( H
这样前期就可以定义系统的部署架构,而不是全部开发完成才定义部署的设计和安排;可以有效指导和约束后续的开发工作,使得质量提前进行管控。
DevOps核心观点四evOps平台,管理前移,有效指导和约束后续工作

; V! L  ~. _/ p1 ?% x& N' [5 A0 l
9 Q! ?( `/ n6 @2 a( B# P% P
1.png

) Q- Y, P/ t5 l# L
. l" W  r: h' }: |. d
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。

9 A6 Z' d" E% Q

/ d9 T8 ~6 q# Y0 G" Y8 n' E
DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;

/ Z. d+ S6 V7 I* [4 B3 M2 r2 |
  H& n, s5 H' b, b; \, E
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;
: _- j/ }: g- k4 d6 `6 u; |2 {% w

2 c+ u3 y) M* R" L2 b3 O6 K
对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。
3 s5 y- i$ {, ^* \, I$ Y

' l; ]" \) O! A# Y$ `6 x9 y
比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。
% B& ^7 c: E2 L; o% u

. K" {+ p# q/ M) ~( V# I" v; [% P
1.png
% F! ?* ~' d+ o2 i# ^, ]2 [

, u! m9 r, K6 w6 Y( t
DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。
4 |% B2 q* I* }% ^, w2 m

! [3 h/ B1 ^2 v1 S: e" E/ Z( j
再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。

8 F5 k' Y) Q: e/ y9 F) Q& D
0 E+ n2 H* R5 e
1.png
0 i1 P! d( p6 r; n/ |
6 X4 Z; b' X6 Q! ^- N/ B
我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。

; X6 G" I' R: z, t- x0 J4 [4 w
* y, p% A  A  r5 t+ z6 d% ]1 Q" E
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革

5 m/ N* E+ ]: v+ T
1 a& D7 I  A4 k% d, g) O# d
1.png

& F  L) `, t8 F+ D9 T
- Y' y" A  P$ ^* W# X! V5 r5 @! E
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
* T$ v1 @6 q$ V: p5 C8 S
7 X$ @  j/ a5 Y
" b' G) z( q7 ~  A, }6 N
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;
) }) N% B) {" l4 F+ k: {0 R& g
; t2 v& Y9 t1 N' E4 w( f/ x" T
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;

" P6 T$ V# K+ H- y) k3 S2 l9 e9 {" H0 G

4 g* t0 c# y3 J7 i# y$ Z* i
在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。
# R" v  M% J7 e9 A7 |, K! x  Q

6 v' p  a; q# X" b$ }7 ?
1.png
- I: U, U" T' u5 O7 Q  E4 V
0 E5 K  T: X, W6 ~8 S+ g
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。

5 r. h7 ]2 ^1 p5 k0 E
2 g3 A6 u- H6 I0 v
DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);

6 n, q" Z1 H$ r% e# G2 T# T, r

4 ~; P1 u5 P/ e7 m& @
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;

3 v7 h# Z$ W: R+ A
# m# T, J5 p# F  t, g2 B) S2 I8 Q
大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的?

) x" s' a% Y: [6 l) o

# Y* y; d" N/ Z! t
1.png
' p: x6 w( A, t" w# C0 H

- ?- `) Y) a% R1 ?. a# T, u9 Y" _
再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。( C& k- @. u: l! e

- I/ F' B; p) X3 K
3 |  T" k. v5 ~5 s) T
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化
) n; d: m6 S  X" ?' |
$ S- n" a( M' v( M0 n) M! y
总结一下,我们对 DevOps的认知:
7 ?3 b+ U* _& J* @

& ^) Z7 B0 ?0 Y. u9 C0 O
  • DevOps是一条IT生产线,核心价值在于提升工程效率;

    / }  c# S( H0 L! L

4 @* z& k; t& n( x2 h
# }7 H; f: u* N8 u- r' }! Q) u. P
  • 覆盖产品、项目领域

    " E& C# }0 `+ z7 ~
; S- e8 N( B$ p. A, c' Q
  • 体现出最佳实践
    9 |4 X, Q- C, U- M
9 W1 {9 `! y. u, Q1 a' c, q
* [7 Z5 e5 X% S5 K* g' l, C+ f
  • 加强协作

    2 [3 [0 {+ y% c) R% M; u( w
+ J8 ~" P% L. [3 n2 A& c* }
  • 优化架构
    # d1 R6 ^" `8 w: m4 W9 w
% [' Z5 F/ l  ^
  • 可控范围的自动化
    ) Y$ y" l! J$ x  w
: _8 ?, c/ A" c
3、企业实施 DevOps 的建设难点
   
# X2 J6 p; ]; P- H
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。

" t% k* l- K: D: J* W

) F0 `- @- x5 c. \
1.png
5 G. x, Y0 r1 T/ k# p
+ z' u  i: i# a7 Z+ J
  • 业务:/ y  `8 O: V/ m& ]. ]. i
    , H% n9 Z0 z. B+ l: z! g
9 P, {, l. S  F; z
+ o5 p* T, a& O5 \1 c& D, H
    1、对于企业已有的工具,我们需要考虑怎么集成,集成哪些;绝不是大而全的集成。如果专业系统足够自动化、自助化,建议逐步纳入到 DevOps 平台,比如针对于底层的 IaaS 平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管(专业的使用方式,还需要登录 IaaS 平台进行操作);而对于 jenkins 这种敏感资源,更倾向于把整个 jenkins 封装起来,不对外进行暴露。
/ U7 ]- ?! u! K- Z! e
/ U; z4 {4 w/ R8 X' e/ M8 _4 X  V
    2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。
" @" v, ^, A) v  p0 v7 R% E9 a5 d- a
% \; {6 [/ G8 N% p
1.png
  

) |* ^# w# F' K% P9 E: c
3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。
1 n/ Z/ g7 y8 c5 |/ f* Z& f

/ E. O% ^, T% N7 P) L7 D2 u

3 T: K1 b$ T' H4 B
  • 方法论:

    - s& e: r; L: s1 q. t; x+ C  K! b; D
. d: X9 I( w; F; V1 B
    1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量;

$ _( J9 d$ S" |, q$ q( [7 z9 L

3 v9 b) {3 Z# C
1.png
   

( R/ q/ }0 w; ~( h, R2 M3 b
2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;

5 y. Q* x1 Q7 m( m9 @: F/ Q* }
1.png
- {6 S* |  u: D3 F: s; r7 {6 K
, A6 l# V  a# G& r9 M. \
  • 技术
    % Z' v% i8 R! A+ T7 X

  ^% N; N6 @; C3 R, O, N
    采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具;

$ j( [# X2 t; v$ H- H

& t5 G: M  Q1 N2 o  I" A
1.png

: ^/ h' n3 M6 @% V# E$ L6 Y' d8 i6 |
2 C% H7 ?( ~6 |/ z) ~
6 }  _" E- C- ?5 D8 U( C$ O% d
4、DevOps 平台关键设计

7 `+ p0 U8 n/ [' h# }
/ `; z4 o+ w( E# o1 o, P$ f. c* K
DevOps 平台完整功能如下:
1.png
9 Z' p: b+ g5 K* q

/ R/ H6 S* m5 P/ W
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。
% z% A8 ^: J& N
2 e- o2 T# f) y
关键设计一:支持多种应用架构

' c2 |3 @$ `! u, \6 O. V9 Q$ p% i
" X3 l6 M1 Z) B& p
DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。

$ x$ h5 ^4 z/ s
6 p3 z' L* Q/ X* y; Z5 p
1.png
6 i# Q) v* v* N$ B" b3 c% |
6 J4 A6 t" g! `- e" U1 p; }
关键设计二:支持异构设施的多策略发布
1.png
& a% b+ S4 r. L* b2 q( e
* }, F" E. \2 y" v5 v
设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。
) V2 m* |8 g% Y$ u5 B8 R/ Y& Q
2 R% I' |. Y2 X! C3 B8 D

) B8 D4 [* c) f4 n
部署转换:将部署装配和资源(包括物理机、虚拟机、容器)进行绑定并生成部署计划,按照对应的部署计划进行执行,可以将应用推送到不同的环境中;支持灰度发布、全量发布、金丝雀、蓝绿部署等;

- O/ G/ l% j" ?% D( C1 O
: m8 k* o$ e/ ^0 {
组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;
8 e  y: J: }3 V1 C+ t* h
1 |* R, U$ j$ p! Q
采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。
1.png

4 `, M8 ~" X( q: U. Z/ N
! \( B9 {( Q, W1 m
关键设计三:将企业最佳实践固化到 DevOps 平台5 z. @: F* A* g6 _) E) K6 L* _- a

) d' B" m, W( D& ^; z4 Q

- F# |8 X* k7 h0 m
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。
) N" z9 x- a$ }" X. X

+ v" z* ~' p9 T$ v6 c3 j
1.png

6 R9 ~3 m( @! v
8 B8 q3 M. G$ s3 D  G" m

+ _& W8 t  W, ^+ Z9 w2 U) T
5、如何迈出DevOps第一步
% d/ k1 X  {5 Z+ }- A, f4 U0 e4 O4 L

# |" e* a! O0 y
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
1.png
3 d/ }. X0 F) t0 R* W

. S( O' q& i  S3 c( }- v: C
这里我给大家建议了三个方向:$ w- I/ m5 P+ x4 l: i$ G$ }5 B

9 r4 t: J/ g, R" Q1 F

& ^! V: P5 v" Q; ^, ]
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;
8 I. L9 ~0 m% S, B3 u: s$ P' M

# @  d, `6 f# y9 ~5 N) L0 o
第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;

2 ~2 O5 V* Q1 Q( C0 J

6 N7 Q8 p* A4 ]; d& H
第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化;

0 Z. K+ I7 R1 [

* E& F6 X2 b! {& R+ @

$ A4 ]9 W) v9 ]# @  h4 V
6、总结
1.png

+ t6 N( f. ^$ h1 S' U
9 D' ^+ r. O2 \0 ?/ i, W& a
最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。

! q# T0 ^; |9 r  O+ S  W, |

  i- J  b# J' D# x7 F& ^: R' F, Y, v$ `
原创:刘相  普元 产品部副总经理、SOA 主任架构师,计算机应用技术硕士
十年IT行业经验,专注于企业软件平台,擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》+ B8 k) Z$ p! b- T5 |8 P
! C1 B% A/ K0 m4 ]

2 a& L. q+ |4 B4 ^
1.png
1.png

本版积分规则

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

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

Baidu

GMT+8, 2018-12-15 20:24 , Processed in 0.277799 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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