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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 514|回复: 0

DevOps 第一步如何迈出?

[复制链接]
来自- 美国

参加活动:0

组织活动:0

发表于 2018-9-25 11:05:39 | 显示全部楼层 |阅读模式 来自- 美国
本帖最后由 adminlily 于 2018-9-25 11:15 编辑   ~5 L- m9 `0 F) x

+ p. q1 Q9 j' ^( c前言
# w) g1 V* p& Z3 T9 g
; m  W* }, P7 i4 t: ]+ D( {3 u) p
DevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。 4 P. Q! c, `. i, `* L* I
4 M- f! Z, e- V( }7 y* o) a
0 h1 }9 D( i0 R& d( U6 J

; P- T0 L# b& r; H9 M; j* m  s! \! g' ?! Y. S4 ]9 v
1、IT精益运营与DevOps2 n7 J8 Y( Z' w3 e9 s6 E& g+ ]
$ w0 q6 S( c/ k" D4 ~2 N  w( M

0 W1 n7 T; l2 ~' h4 H. _3 M7 L, Q+ o3 G1 A9 ^5 I% q! N" w
随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。
7 b6 J  Z1 a4 t3 e9 b6 \4 s) q/ P2 @$ ]% J4 t  k7 h

+ u& T  d% N8 ~. Q4 q0 c- |: n7 P2 V1 }/ ?3 l2 F3 q# ^7 W; m" d
新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。

( u8 R3 h/ `- ~/ ]- o, H4 s
$ D/ C/ D1 V0 r: {
普元实践了大量企业数字化转型的客户,包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下(互联网企业有大量的人员保障),怎样快速地把我们的 IT交付出来,这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门,需要将IT的精益运营与 DevOps 无缝进行整合。
* g; |7 ]* k# c- G+ J, E9 U
: A5 O& I4 z5 r
1.png
6 g, l- w; J# [' b6 d% J" ^

) s$ D( R' ?5 T1 f( r, L$ {
举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。

) H% Z4 e8 j* O3 L+ n
! V/ o. D; c* \( e
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。
导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。
& N* `( X6 w+ k; L
" X9 n9 u4 ?, x/ o, N/ g8 k! o

# _8 q$ k7 q: Q; l! p2 p" o# S
2、对DevOps的认知

6 g7 c& U) K/ }
8 _0 h8 W; i6 h3 h% L  b
' b) t# A6 m9 g1 P( z5 v

/ u5 l# a2 J# C! O提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。

/ r0 |+ b7 l- k
1.png
+ p# q3 k. f+ S" b/ L% v& g% q( q: C
# u( N* Y+ m9 S8 u/ I- l
我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。
- N3 D- j% \; `0 z

' Y1 I8 O+ D, t& v" V5 j
在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。

1 I/ {) a. h$ m# a
8 C# r  V. L) ]* d, P, k
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么?

* \/ U3 H) @4 _, B  f1 _
8 @: ^, c& Z8 _. }) X
1.png
) B4 r8 U. u3 R
, Q1 R- q# P5 k9 [1 A& ?2 D- m! o2 x
确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:
! T0 k  M5 y4 A
. a7 }1 e" {6 C
1.测试环境和生产环境完全做到自动化部署;3 W2 q0 ~+ _7 O- ?
8 T. T9 p$ i/ j2 ]6 C6 L0 r

$ C5 z* D  Y' }
2.业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;5 v4 v7 z) f* d% f; F8 l

5 S  p" A% ?5 r1 \7 \6 j" P4 X, B& N+ U4 Q$ s9 `
3.产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;
/ f4 d, k1 I0 W0 u7 F

0 M* U6 R2 J4 d. a/ ~% C
; W- r, O9 G. M% V( ?& j
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。

6 S. q# p+ y/ Y+ r

# S$ z, y8 }; s0 `% ]: P, S
企业 DevOps 思维 VS 互联网思维

8 p1 j' V( _7 c' ?! @

9 |/ g  }+ |8 z4 f; q/ i
互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。
3 k* y2 u5 u5 u. \* l

& N0 X$ T# @: W3 ~" U
传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。
% @$ V1 J9 z+ i+ w, K8 ^$ p1 y

, v( V2 ]) i2 O6 X# Z* M, Y" D0 g
DevOps 的本质是什么?

6 Z+ M5 \$ V' Q5 @( `

9 i+ Y* T, j( {$ E  _  T8 t, D, x8 r0 X/ X
    我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。
/ E: g7 f* \* q' q% M* d
1.png

7 {  j8 l2 w4 c/ A3 s9 s
) K! n1 e$ I0 Y/ P
DevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。
; E) w2 \+ ~1 g- v# G* Z, `- N
& V2 T  u  v$ }' {( b7 _& m% l
上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?

! e. E# q$ R8 T

, V3 x" ]9 B& m
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解:
4 P6 T# f" }* \0 b6 V

+ K2 N$ p5 i8 l6 x
1.png

: _0 ~/ O0 Y6 D1 O3 N

8 b2 p  T. k) Q: y% I/ l. l5 K/ o
主要包括产品(策划、研发、运营、推出)、项目(立项、执行、完工),而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程,要以产品的视角来看待,真正进行交付的时候,也要以产品为维度进行组织的设立(互联网公司通常如此)。但在企业里面,产品思维还没那么强,仍然按照项目的方式来实施。

# `7 r* f0 q) K6 j

5 u4 d  w( t. R
因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。
7 U4 E" H0 a$ c+ e3 t6 ?: M

! ]" t5 t" O: P1 `! R
DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期

2 F* E. Q4 h9 x
# }3 l9 l1 A. x
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:
1 |) J5 B! I2 U, O8 K' ?$ }# e
/ r2 `1 e( H' _% T5 A" o
  • 第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;
    2 v; X  v% D7 `) E+ ~$ @6 M! H

0 @: c. O3 {' P( |- I9 m% U' G
6 J! s, r4 t3 `
  • 第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;
    * T- Y) {. e$ o8 `3 [
. p- E; Y" F" v" |, i, l, T$ B* t9 K
  • 第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;

    ( s: J, ^: F; J! a) ]( {

- ~  `& R. Z/ i  M- u/ b6 L* o
  • 最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。

    ( R* S5 ]; D  j: j- v
1.png

4 E. x! p9 m2 g: i$ B% o

" R! m" J+ u. V% o
首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。
7 L! V# [" Y+ K/ M4 _& k" X* _

3 Z+ t4 ?$ B% k, A$ p# D8 m
这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。
3 U- Y! ?* S9 ~6 P  t, J% ~2 P( u) z
; q1 G6 F! m. T( }; W( H+ t7 P  T
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
1.png

/ G2 }6 C/ p# K. q& w6 |( k
# m4 w  f0 u: {" a6 a) G
从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。1 u5 ~6 Z  Z9 O% ]( Q
( y# e% g( f6 M" H
9 ]3 N' D5 r  E5 z( d! X( \
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;

( k& P3 X9 a% D' v4 q
( A) O: v* r6 a" B
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;

1 q7 W& u+ P4 x4 c& d4 q' q# }: g4 C
2 z! P7 C# I. I# J' L/ ]& G2 s  |
在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。
! B2 N7 @! ~: |( b! }

1 W3 [6 y! U" A& ~2 e) B% v* O
1.png

; k& A9 n' @1 A

, ?1 P9 o# Y! K4 E# g2 C, A. c6 l
在产品管理中,小小的版本号其实内部藏着很大的学问,基于版本号可以快速了解产品的版本,发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联,大家对IT交付过程的管理就会达到一个较高的水平。

( O- s6 v% Z0 @% i! d

8 z1 V  G) e- d! N9 y
另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。
1.png
5 G) H  L: q& j* J

0 A! W( f) |+ T) Q: x, j4 d: @
这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。

5 j, Z: y9 n* Q, @

0 n3 \& ~! r: R% z
DevOps核心观点二:DevOps平台更重要的是提供最佳实践
1.png
* u5 G5 u: g% i4 ?) W4 U3 ]

' t! a2 ?& j4 {4 B0 Y5 V
接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;

0 w! {1 k. _  z. D, N8 C
5 d; e( ~# \- k9 |, q; @" I* U. f$ j
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;
. R. s! O! [( y0 r7 e" O
! j. [& Z' K: g: ~3 n5 \6 w0 H; c  m
客户满意度、MTTR、线上问题数是重点评估的度量指标;
& K: A0 t. h: v3 a
( K$ `. v, ~% F/ v% `7 b
1.png
8 Z0 E6 S7 b( M# ^5 E  ^  {8 T3 Y

: H1 V; U; j4 H) u/ d7 s8 U* r
在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。

; y9 i) j* |) }' V. W/ t) A
& B0 p& y; c% s$ E5 k$ J
DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。

2 ?. q: K9 `, F, O
# t, f" @, {/ g) W- }" B
DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。
" Y! b6 i  H5 G" `
# ^! k0 l+ ~4 }. V4 F
项目交付流水线的示例:
1.png

" U8 L# Q9 E: C: ]3 x
. }2 r9 d" d3 U3 X: L( X& z9 F& y
一个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。

$ C; H" x* r( n2 h( z. r0 r

# ?9 y- y: c: N4 f/ L/ H) t7 c
交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。
+ d5 p% w* z& _6 R
- n* u* \, p7 @
DevOps核心观点三evOps平台,让不同角色更好的在流水线上协作
1.png

% O) i9 @) E" S4 q$ c

( [2 \/ X; s4 E/ k9 ]) ]7 n4 U
再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;
$ p7 P# R" p0 m0 o" `8 k

8 h0 e8 T/ ?+ b8 q
$ r( t3 D' V) Z  T7 {0 G; F
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;
9 [0 e/ ^# q" V4 x) V2 {& O

" R+ n; W, ^& j3 W
需求变更率、任务燃尽图、积压线是重点评估的度量指标;
, _# q7 j- @* x5 c4 W) `9 o: W# w5 a
+ V/ X0 I5 y. n' k
通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。
% f# |, O1 {5 ^
( N( [1 K+ m% d% w5 [6 R
1.png
3 q  B! F% J5 l/ g* c" d

2 G/ S( [6 d, d! i2 Q
项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。: s& [/ r( b" o
3 [/ }  D: C  G1 F: F; Y  `

! Y5 T; q0 w8 }6 b. T
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);

4 T/ j( {9 n# ~
6 t5 \2 \5 x8 {8 O
设计变更率、设计偏差是重点评估的度量指标;

1 O: `' C: w' [! A' j6 T

2 z6 [2 L- M5 ^% ^- ]
在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。
1 W, g# F+ a+ @; |
* n/ d/ z& V/ `7 g! g
在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。

4 s9 O0 ~& `# z6 Z5 V' Y! J9 ~

! r0 c% y% g0 `* b2 R9 |
1.png
; A4 }2 f  j+ t9 l4 D
2 X' Q9 [! h3 D7 l, B0 p" e; p
容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。
& K* j7 X5 A3 f7 N) R4 E7 P  I
0 [. c2 Z$ ^; Z, B# y/ T3 v

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

+ ^0 g. Z- @7 Y8 R# O

6 j( P* j) W" X. R
1.png
. ~' x2 c5 a) }* y3 M) ?" M- o" \

+ }. U0 l0 V# K/ u9 g
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。
: `! u" J' o: V
7 \% f4 N% H3 F% `$ ?, S, N6 B1 d8 P
DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;

0 C& D/ X$ O' @/ O( K5 _
+ A' N) Y5 B. x, c( e
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;
0 ?; E6 A; o+ V) K! R9 m
1 Y) v) z' a1 x
对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。

0 N% L& v  v* V- @: g# A( d
) }8 n# w, b# u8 ~( q
比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。
. D2 {$ h* b! J: v2 `! ^0 i. N
0 y' z0 a& K, D& @1 h' f! ~8 {
1.png

- P5 E+ N( ~; C* N' i& e

6 \0 g5 c" h' J
DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。
+ Q3 D' Z8 z. ^
8 C  k2 X' R, C* t, Y
再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。

4 M% Y8 D* j& x
+ j9 ], c) U; n& R: L. \* V6 Q% r4 |' O
1.png

* g2 z6 _5 p, j+ z& i0 s1 z
! k' T5 z2 c1 f2 ?" q/ u! Z9 @' ^
我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。
4 n1 M/ \5 [8 B, W. ^. j

4 }8 W/ M  m2 P6 I7 y5 }" d& z
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革

; H" Y6 D( V: R4 U2 H
$ `& X3 N+ X' G0 E2 z/ }
1.png
% X+ h& Z/ f: P

0 @/ {+ B) y6 b/ k
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
# T$ i  U: |( Q2 Y
% Q' O) E4 l. Q0 o5 E. I
! k: d" U  N& l+ V* T% l  f' M
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;
' |7 V5 G7 P/ l: o: u
7 d9 `% Q- V1 m! M
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;
0 a& N+ F" K# g: h: r$ @
( X- [9 t6 r. x
在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。

" q, O3 Z! F4 Y* `
4 x! x* D; ~4 @4 U  \9 y* |, N7 H: }
1.png
/ }2 q3 l9 Q2 j8 M4 }: p- ~' m$ e

+ ]& W0 Z! D, T& K* g
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。

/ X8 v4 C# U, ]* H; M, q
! w3 X# q: `$ `) P0 g* ~! V$ a
DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);

3 O# @& s" R4 j+ x

% ~* b9 A; S2 E* I/ v1 @
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;

% }% `$ T' F* j- l

. D1 c6 U" `; k, u
大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的?

' s9 _* c0 f8 }) d5 U" {, j

% C! {6 |5 O6 l; e& S
1.png
6 H+ C. t3 r$ B5 w: K
+ p* B8 v, P0 }2 n% m
再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。
( L. v7 H/ a* o* b% l) b

' c! v3 O% [, h, `% u5 m

3 V6 I4 v# J2 |2 X7 W$ |/ p
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化

& s0 e& s. a3 z+ [+ k/ J. o
8 E( y7 {+ m# G' X0 M5 _, n
总结一下,我们对 DevOps的认知:
8 s5 c2 x# G( S! I: K
8 W, |+ F6 c+ `+ O! y
  • DevOps是一条IT生产线,核心价值在于提升工程效率;
    ! b2 z( n! K. }

. g) M( }- Y3 z( ?
' V$ ^* a# C4 C0 z) U9 c
  • 覆盖产品、项目领域

    ) A9 {, `  Q+ G
& o& a$ O2 m5 ]
  • 体现出最佳实践

    ) u4 r  {8 ~$ }) ^

# n9 e8 u: S9 L; m

& X" h8 ?' l* c* C1 @0 Q
  • 加强协作

      e- U! D. p) Q) G$ H& r9 D

0 B3 s& t  n8 @
  • 优化架构
    3 M& ^" h/ s# Y1 u

* ~- V3 a1 x2 Q
  • 可控范围的自动化
    ; g1 O4 n. z+ q" }

( ^2 e* s$ j% M* f3、企业实施 DevOps 的建设难点
   

' e( B+ G. N6 z
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。

8 j9 g2 J  w6 H/ `6 T
# H; V; _  W4 I4 W' r
1.png
. a% x; K% Y' l) n

1 i$ ~% S+ q6 H' d
  • 业务:! K" j/ x; u; G% A9 \' w4 }
    / G( Z, e) }8 {3 f8 k/ m. A9 B
: R) @' S0 ~+ `+ Z# @

8 Z+ G; i1 N* s
    1、对于企业已有的工具,我们需要考虑怎么集成,集成哪些;绝不是大而全的集成。如果专业系统足够自动化、自助化,建议逐步纳入到 DevOps 平台,比如针对于底层的 IaaS 平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管(专业的使用方式,还需要登录 IaaS 平台进行操作);而对于 jenkins 这种敏感资源,更倾向于把整个 jenkins 封装起来,不对外进行暴露。

( ^* o) R0 s  V- W0 R& t9 {

7 i& a2 ^% I& I" a8 j* [, v/ E
    2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。

! `" s# x1 L) w7 \5 u
5 v8 M0 l) e; Y  i) d
1.png
  

* y: z& z* z7 P5 g
3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。% |, J- ?! e0 m* o! a
" K% w6 T) L$ T5 C2 l2 u

1 ~- v( e8 H7 {, u
  • 方法论:
    / c$ u5 X  H5 Y6 j1 h
/ F5 W" N, v/ L1 p
    1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量;

9 R& V( t* A: I+ m1 m; s% o
% |6 K6 M# v/ j) j8 A2 W7 H
1.png
   
: T1 i9 D3 x2 K* a8 H2 J# N! _
2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;
1 X1 R: k& u- b7 b0 d* K
1.png

# N, @7 |* j! f6 K' R: @2 v0 H4 K) w/ p6 a+ ?
  • 技术
    - Q. [* F' J8 N( N! }0 @

$ b& k5 P2 D3 U# W+ x# d# J+ b
    采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具;
: x8 z3 p/ v, [2 V# \  {
/ [) I' k8 {7 N( c2 \, l+ i$ G
1.png
* Y7 q0 ?% v/ }  @
6 Z: x) S1 e/ P0 m

6 @( O: ?# n# \
4、DevOps 平台关键设计

( J# }) S9 K1 _! n
/ z! m, }. U% L# V: s* ]$ X* z
DevOps 平台完整功能如下:
1.png

7 D1 i$ B- \8 \" @
+ a% @: I; {% O1 Z$ v
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。

1 R) ~0 W: a+ r1 ?% \3 o/ J5 S

( m- ^4 T- |. j: T$ W7 r  Z4 Z' W) \
关键设计一:支持多种应用架构

1 }/ [9 h/ H, z' M; m2 p: g  Z9 d+ W

" @% L0 k% u, n. ~5 y" t, v; {5 H
DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。
/ N4 [; w3 h9 ]! A, V5 h

! o% A+ m0 l  N; B
1.png

/ _1 H% ?. i& m' `5 N2 M
: R( p+ y0 O: a/ Q$ U, M5 T% k
关键设计二:支持异构设施的多策略发布
1.png

6 ?, K0 F, d# K

# u" m6 z8 X8 y6 }
设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。
, D1 Z4 N/ p! q
% x1 W/ B/ ^/ o4 p2 q! I
- q9 f+ \; T9 R' r; U0 l2 g
部署转换:将部署装配和资源(包括物理机、虚拟机、容器)进行绑定并生成部署计划,按照对应的部署计划进行执行,可以将应用推送到不同的环境中;支持灰度发布、全量发布、金丝雀、蓝绿部署等;

! j0 y& `# z) {2 x
8 x" d6 V; ~( H; R$ P
组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;
/ k/ V1 S3 Z7 p; @! l- F# G5 B
' b5 l$ z, g! i4 p/ X* v
采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。
1.png
+ d. n* g. C/ E0 ?

* d5 {: H% J7 V% a6 v: b$ a4 E
关键设计三:将企业最佳实践固化到 DevOps 平台
; X( t# M: \2 G+ e& w3 f% k
8 _# V+ k8 C  Q/ V
: b2 O2 E; w* J$ P( a' U
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。

; h) ]7 x2 a, C* ~, O( i) ?
) D; u) N9 H; \! ^( `
1.png

! b0 t! ~' `# L
# |$ H4 g3 ]- F7 Q' W. D% E# A

. e/ a4 }: o! u# L' x0 b0 O
5、如何迈出DevOps第一步
( E: q/ F. A8 C; A, M

/ i" B: I* l- L
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
1.png
/ I' @8 q7 m( y7 W/ U+ q5 n9 @

' [% a' ~# Q! R) {! s, O4 t
这里我给大家建议了三个方向:
! ]% K! E7 q+ a
& [' z7 _% Z9 a- J1 o
- K: m/ A+ o6 I- G0 D% {
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;

/ [7 r2 v8 F" @$ c1 c- f

0 N. Z; H/ e: Z  G: O: [0 }
第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;
# Z7 |; Q$ S6 R0 Z. C# Z
& s* Q- B. y( x- t; I$ n
第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化;
# w, O5 K* r) [8 ?

5 T5 d) O/ Y+ X% s% R  t
1 ~+ k4 w8 e, r, F# k5 i
6、总结
1.png

4 f( q  S3 t2 W8 H$ @
" m9 v- S: f+ G
最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。
) R2 E- X- v! I4 z/ s4 P7 x
" u  `6 r, _, x. F: ]
原创:刘相  普元 产品部副总经理、SOA 主任架构师,计算机应用技术硕士
十年IT行业经验,专注于企业软件平台,擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》' q7 C- V. [6 |9 ~$ o1 d
3 Q$ ^+ s. X0 }5 m% i6 ^

8 S/ n0 L' _4 N; c
1.png
1.png

本版积分规则

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

Baidu

GMT+8, 2019-6-17 23:26 , Processed in 0.239083 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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