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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 708|回复: 0

DevOps 第一步如何迈出?

[复制链接]
发表于 2018-9-25 11:05:39 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-25 11:15 编辑
1 k9 h6 s0 O1 \  b) h% _  x; H& m( G# N# n$ \$ {7 l" t
前言! i* b7 B9 e5 [# o

3 g  H' I, H3 F" x* C3 |( oDevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。
7 p% O* I1 b; M. @, N+ k# u

8 o  f) R- }0 k! f0 x( c! f% x2 O7 z/ W/ a3 s( z3 D1 B
$ E# q% ]) E$ Q
( e4 _' _+ j$ h# f
1、IT精益运营与DevOps0 H# C4 `: g. c0 I
- _* D& [/ \5 r$ f8 C

  @8 u- Q8 y/ f, ]
6 \9 _9 F: ^- \7 b: o& t随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。* L& k1 P2 I: p8 S
# F' d2 A, Y2 h2 H% C

, [1 w- P$ L/ y1 |2 T: U0 q0 ~/ u! Y- o5 |# D' I! a& O
新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。
. Z+ K* I( H7 `/ W
2 g3 S# ~  ]2 U& V- m: D! \" s: d. O
普元实践了大量企业数字化转型的客户,包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下(互联网企业有大量的人员保障),怎样快速地把我们的 IT交付出来,这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门,需要将IT的精益运营与 DevOps 无缝进行整合。
1 k4 N$ Z' E3 g  u

1 Z: m$ V1 v* e, w' _4 R
1.png

" Q) x( Z' _' H% r. C

, o/ Z$ _; \1 l! \1 k3 {/ k
举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。
0 l, d3 N- D3 R' Q0 y7 r

" U: U5 K" t8 X4 @% T8 u
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。
导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。
8 p: o1 `* J4 d& \5 ]9 K* s
% V# A  V) G/ B) w
& B! q$ n' l& [4 y1 ?
2、对DevOps的认知

2 w" R) p, i2 w' |

, Z" ]: P$ e$ S! g: T) c3 K+ o/ w9 ~5 A; `3 t4 }! [3 X* O, f0 b0 m
$ t. P+ Z+ k5 a6 }. N; T
提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。

( Z  t1 t7 f1 I. r2 @; U9 N) y" T
1.png
' v( j& p- I" t3 l' l
0 m: T( \' d. V
我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。

0 m7 G3 k" [. L

& Y1 O# {9 V* E$ V# g
在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。

3 j* @1 r6 e. T: _- J( a, O* H

0 X: Q6 R1 [6 z" k+ H' O
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么?
+ ?5 H; x6 \7 [. j. i2 o3 l, D
7 x. }. ]- m3 ^7 Z9 n
1.png

- e3 ^- n3 {" c9 p# ^: L

+ o5 w- K7 @8 `) O, \
确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:
" }' c; @4 @8 k/ b9 Y1 J5 z5 @
# t  K# ^+ B& J4 }( ?
1.测试环境和生产环境完全做到自动化部署;
, I7 T+ o% @% E4 f3 R6 ]* t+ z+ `) p' |
- u8 ?. @% p  b$ [# D1 r
2.业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;
5 W+ V5 ]8 T; [4 f0 f7 k" t
! w9 L% {! e; l% x1 U6 Q0 @) p9 e  M  a  t
3.产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;' S2 v' L% U8 m
; S+ S! N" p: J8 e8 U6 T

/ J; H6 y5 P2 S! b  {5 a4 V3 v
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。

7 X  y" l: l: I/ D4 T* c

: b1 b, x8 E) o& n% U' K% g+ A! p9 t
企业 DevOps 思维 VS 互联网思维

# k; b+ ]5 S+ I9 g. l* \) d
# Z- ^& ~# x6 u2 W
互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。

$ G0 C: N2 B3 \. N# S* e
5 ]6 L7 x" Q1 B, X
传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。
2 ]  {8 Q1 k) C

- {: h6 i; _+ w. w1 K4 o# H
DevOps 的本质是什么?
5 ]; F" z. \- ]# r, M/ o, @; F

' n, i2 K/ q1 D" }+ q$ E; ]
    我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。

: g  Q' D6 |' `6 c0 b
1.png
, ]! h$ `+ ^( D( W
, g) V( {/ P& O, T. G4 [8 L" a
DevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。

! Z1 ^  D) j# Y! d
% a2 L2 s1 G, `% [3 ]
上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?

# e$ ]% t: }8 i

; a. _, r: g" h  N* A- M
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解:
" b; K3 ^  Q% |! R5 |& B

+ Z  c4 ]7 @# x5 ?( A
1.png

1 b$ N" I' U( H
& a+ f. [  U" O5 [! ]( G
主要包括产品(策划、研发、运营、推出)、项目(立项、执行、完工),而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程,要以产品的视角来看待,真正进行交付的时候,也要以产品为维度进行组织的设立(互联网公司通常如此)。但在企业里面,产品思维还没那么强,仍然按照项目的方式来实施。
2 k+ |. c( R: L! l5 s5 Y! g
! T' q  i5 s% _. Y
因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。
" z  `1 ?5 W6 C  u2 Q! K. L
* u+ \) u9 z( ~# S
DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期

8 F- I5 e, z6 Q. E( o; r3 o9 ?

  C4 A# Q0 `2 ]. Z* J! r
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:

# |8 H" }& J7 F

9 O* {4 O! k7 x$ \! G" t5 j1 `
  • 第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;
    / _/ F  D- O7 F! L/ W
7 C3 U1 B# U: f$ F; K5 s. t" w

# b) A7 t' A* \
  • 第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;
    ( |  X$ k- v! G) |0 ~
8 P+ }9 R7 D$ a. h' V
  • 第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;

    8 |; j( Y* h3 j6 v7 K- N+ g

8 U7 w( K! B" e
  • 最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。
    + ~, X& A9 J4 U! I: z0 W! R
1.png

' q* t4 q6 J5 X8 a% R- w) O
: K6 g; g8 \! {3 y4 H
首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。

9 Q$ G* Z7 \, M& e1 q7 p. A, q

+ v5 S! W+ v! e8 `& p4 I' b6 ]
这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。
6 C0 ^1 \5 ?( M# ]9 r- F

4 @+ v6 s& u2 I6 y9 d' l
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
1.png

2 D( v; |7 V5 Z( {: q
1 e0 u( _1 C* s, w6 P# v
从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。; U: \, s) {, X, ]2 F

- |1 ^; f6 q9 z

0 P9 V1 x' t9 m& o
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;

0 y( o  t: t# a1 L9 z
7 U. e$ m. J3 T, M3 ^3 K0 @. {$ _* T( \
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;

  W+ L0 h( m0 L5 {% s$ c) a& a
: F8 k: k: F( q/ r6 Y
在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。
0 d) y4 |/ ]* j: c$ ]5 R* a9 [
" I4 C+ e  ?- J  f- t0 M
1.png

5 y8 @- u% r: m' ~* y! _) l
3 Y) P, l' Q. M% |* e, j6 c; P, z
在产品管理中,小小的版本号其实内部藏着很大的学问,基于版本号可以快速了解产品的版本,发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联,大家对IT交付过程的管理就会达到一个较高的水平。
4 j1 X9 F) L: @) L. d$ |

( |) s/ G3 o; C9 S
另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。
1.png
7 H! W' G: y9 Z+ i1 w" C4 j6 `: L

+ s" T, l( D& p0 |) d$ o' G
这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。
* X" \0 o: I  A. M( ~! b! m

# ~# z: y9 N( _% m" ^
DevOps核心观点二:DevOps平台更重要的是提供最佳实践
1.png

  l0 `/ H8 z: f0 Z( S
; C6 _* q1 d4 `8 O& {1 b. a3 Q
接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;

4 S: h* D/ h- Y4 E% w2 W" @# l

9 h: M/ I* v% t$ b* B& l
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;

( O  I+ {9 u1 o  [2 f$ Y- \6 u/ t
6 m5 U, P# \4 Z0 P1 p1 m8 e3 d
客户满意度、MTTR、线上问题数是重点评估的度量指标;
9 @3 g+ ]4 o7 `$ f6 U$ s
* Y; s! K. o" x' c1 G
1.png

  G0 p, }# |$ q5 D6 v

0 x% a, M+ B: {+ U' D
在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。
0 T9 [$ N0 d9 `0 r2 t* d! r( s0 v

% `& z% j+ [" l% Z. x( e
DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。
: @. L4 m' {  f- _' L

" ]  H; F1 _4 q4 Z$ }2 ~
DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。
* x8 L' ~; n+ Z6 a& J( Q
6 L% g* u/ D% p4 U2 C" M0 r$ B( ]
项目交付流水线的示例:
1.png

. l; O, m! L$ J! ^& ~# M

. n) T* O, A( o
一个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。
1 J3 ~* h5 u( M# J
& p2 y- [0 I0 u2 F
交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。
* ]! G5 T! G* c
6 e& t9 y/ \$ [; z- Z$ o* P
DevOps核心观点三evOps平台,让不同角色更好的在流水线上协作
1.png
/ U$ p' l+ N8 F! G. A
( y7 M" p9 n/ t- f6 a( u
再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;
, Y* O' o: H- n# K3 Z' a8 a
' L0 C( s+ j4 c6 \

9 Y/ A4 V3 f& M7 c$ H- h4 E
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;
) Q3 U+ ?1 A& \/ P9 U
6 M$ I- X6 U1 `- v9 g: V
需求变更率、任务燃尽图、积压线是重点评估的度量指标;
3 O5 U6 Q* O: Q3 K

! h, B. F% q8 ~7 p$ R: v9 K
通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。
( ]0 j; O# L2 Y7 o: v, D* q$ K* i
5 X( ^9 W5 I5 J9 t. X* S' \' E
1.png

! E( @7 ^: ?. \4 q7 _

! Y* a$ {  W4 I) u
项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。
# n, B& N: t0 ]* r& n

# {+ R7 ~4 S+ p8 }3 d! b  Q4 G& \

" C, ~% K% z( u0 B  y& k3 I9 k4 e2 q+ w
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);
' w( ?" _. I( x0 {  m

+ w/ H! G* Y, K! [1 {$ {) J
设计变更率、设计偏差是重点评估的度量指标;

  l2 g9 u+ G1 s5 D: h3 i9 w8 y* [

! ?4 c9 C+ e+ _/ S* A0 U, W* ?' M
在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。

$ m; N* H( n1 L  l3 O9 `9 Q
( {2 [; E) I  u2 o1 l& ~$ _
在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。
, D& Z+ C& K( s/ n3 P
, e/ y  T( r. d  x' W
1.png

5 M9 ?9 R8 Z+ H- }  s9 z) s/ h
) i" S  E/ v  ^. W
容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。
6 L8 z$ H+ n& u; R" O7 p( b

- g3 m; M4 M) k3 m+ V8 y* r
. \8 X+ k! k5 ]- d4 G
这样前期就可以定义系统的部署架构,而不是全部开发完成才定义部署的设计和安排;可以有效指导和约束后续的开发工作,使得质量提前进行管控。
DevOps核心观点四evOps平台,管理前移,有效指导和约束后续工作
: @' {  _  V! G# N
# Q" Y! u" p! n8 W$ E0 Q6 P3 Q& \
1.png
( i: P. O6 G& n; P: |

# C$ q7 i# r3 @$ A7 @9 p3 v9 e$ t
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。
, C2 m! l$ Y* d, A) R+ j) w

0 k0 t) g( t, o& J
DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;

8 [" f' d$ j5 X3 Y. D: {

& B0 H' B) v9 E4 C
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;
( a# J$ A1 u  g* d- C

; l1 j+ C' P% W. o9 {$ [
对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。

8 W8 N: J+ W8 X; z% A

7 O, D1 [: N$ T  ]0 w
比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。

& f# W1 L& r" U3 j2 y
9 O3 F% g. k  U. E0 D8 G& y
1.png
" ~9 Q  h% S& B! D% |: T5 b
1 x! x: _/ u" P8 X! M! b% b
DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。
7 v4 k" N0 R3 j$ |* ]' s
5 d: B1 z4 c8 \  k. X
再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。
0 R" w. S# O" e# \* y( {& A

8 e$ S# }# _5 x* q  l; E6 J  ~( s
1.png
8 }9 v. P3 H# b. M

, }/ a- H; X( U3 J+ T
我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。
" s" _, W7 P4 l* H+ M
9 d+ k2 ]# w  ]( |* Z2 B
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革

8 a: }5 Q: L  j. V* t( c

+ ~5 t# b5 h, Z4 R
1.png
& e1 B  z& p( K6 |, I0 g# z
2 W  v( |4 Z  L- @. _2 f; A, F+ i
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
; Q2 m. v, H; T7 p

  W7 A- U6 v8 Q2 j6 Z; Y

/ H6 \1 o3 G$ q  F! k! {
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;
; P. Z! \7 Z& W

6 I) Z4 S  E3 g+ c
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;

" @& W) _4 M( K; w( g
6 a. F: I: w8 {
在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。

" ]( M- s) s* s* ^- H

& e. ]9 ]# A( a' ^* e, d/ k7 I
1.png

! T. k5 B$ E3 |4 I  q! t

# u) @3 h7 ?& x9 `( a2 x
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。

! l9 C' c! h( Y6 R  y  i4 `

" K/ r% i; I, z1 Y; ~* f1 K* |8 R
DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);
" F' g& m" U8 S) s# C. F

1 x! @' F$ L: q
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;

7 r  [3 x" f$ F

, [/ m+ h9 d  m* D0 v; X
大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的?

; Y+ D0 g. V5 I0 Z

% q# y! H' n# v# i* J
1.png
6 L& q3 w/ u6 ?+ K3 C: k8 V( j
- s' P. w8 v) B# K8 U
再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。9 `: S  }  U, f" w3 Q

+ k: `. l0 }  w7 i7 D

- P" w: }( Q: N5 F
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化
( F" d& h! u0 m' D! W
7 L' D7 u; U2 K+ O" {* \' H0 B* V  K
总结一下,我们对 DevOps的认知:

8 Z  z6 l6 u0 I' l* M( X* i0 r
# y- B& B- a; A5 f' z6 m2 G2 v
  • DevOps是一条IT生产线,核心价值在于提升工程效率;

    ! ~, |, S4 A7 N* D+ @3 h

5 ^$ k: W, u8 G* _9 O
' n, S  }" u+ J& |3 F4 j$ ?" W
  • 覆盖产品、项目领域

      A( C" c$ [2 t) M
9 q6 E# A. r  Z4 L' T, U
  • 体现出最佳实践

    " p% [: D2 X7 W: ?2 m
. ^5 b% o- m/ z6 T& f  F

4 u  ~! F, f; ?# z0 d
  • 加强协作

    9 r, M4 {- d+ S
2 O3 Y. d: h2 H/ d5 n6 u, J. z% ~
  • 优化架构
    $ _$ l2 R" w' d( X$ s. B
; i2 m8 [8 Y& G" M# d3 Y! ~6 u
  • 可控范围的自动化

    ' a5 L9 O7 k; i6 F1 p& D' f

' Q% X: q/ y: t+ h5 c/ `3、企业实施 DevOps 的建设难点
   

) N5 n3 W& o& B* x' X2 F
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。
2 F8 d! H: `- E) ^& E4 d/ k$ d

. F! R: H& m( \3 X$ J+ S
1.png
: C  p& T( I  C
! C+ J. N0 J* p, i
  • 业务:
    0 l( c9 T% Y6 [

    4 V" F8 G5 `, s8 a7 f3 ?! x
1 q  t3 [( X( z, A% M
7 z$ I+ _! l- [  i5 F: N) L
    1、对于企业已有的工具,我们需要考虑怎么集成,集成哪些;绝不是大而全的集成。如果专业系统足够自动化、自助化,建议逐步纳入到 DevOps 平台,比如针对于底层的 IaaS 平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管(专业的使用方式,还需要登录 IaaS 平台进行操作);而对于 jenkins 这种敏感资源,更倾向于把整个 jenkins 封装起来,不对外进行暴露。
3 A1 u  Y/ s4 u
2 s: Y( W# B* j: b
    2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。

* ?( \  W* L0 I- L
7 c' T  b8 j% w1 A) h( f
1.png
  

2 w6 K7 C0 c; H, u, c* ^
3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。
6 l! l% `: q) t; ?+ P& @1 p6 ^

" j% p/ F* \: Z! D; w  @

4 s8 y; R5 }  B4 f$ s* K8 m
  • 方法论:
    ( O, I( w! t- d5 S* X) Y4 k
; y6 H% ~  {7 U
    1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量;
) ]$ ]7 `- ~' Z. i* Q. p4 \

  y6 o! b; a. L0 W3 T% D
1.png
   
5 w' O" n+ O( v  F
2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;
5 L8 ]0 B/ U$ i5 |% T! y
1.png
  L2 Q* P! U! o

) ~  A, c" _8 D. u: F' a
  • 技术

    / Q7 @5 _( i) z( S2 r

0 t% E& h7 `8 S" J. Z
    采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具;

, W7 W3 M+ t. }1 z! J1 k' _

3 y, Y/ N1 J3 l* s- q5 v* z
1.png

* k" H# D/ j4 g  r; x6 D8 f/ e3 S

" C' Y6 l" [9 u2 U2 Y
' {7 E' ~! I, j' r7 a
4、DevOps 平台关键设计

0 L) r" f6 ?! j7 j8 b
. Y1 h! M- R/ C2 k" N  l- B
DevOps 平台完整功能如下:
1.png
9 M1 G* z$ O" k" M) E  b- ~+ ~- }+ l9 }
0 J7 Z, w2 l9 p% V6 o6 Y: z
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。

; Y9 c3 [- C$ B. |1 w3 b
1 B! R: D& b7 }" C$ \! n' q
关键设计一:支持多种应用架构
- K& t& H9 o" D0 S' g- h
; J; [  ]& W9 d8 `
DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。

2 _7 `) A& O& p7 g, p3 T1 C" m1 J
' B( A, E( t; `" {  v3 R
1.png
0 c! O5 X5 v+ j$ {/ P
+ q, f- p) M1 R6 ]
关键设计二:支持异构设施的多策略发布
1.png

0 N( `8 k, c: I0 h% h

4 z6 h5 Q' w5 A8 D3 c/ Z
设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。
  M+ o8 e$ S' N+ f

# M: U( c. x# L

$ l1 J% L) n9 e/ \/ z5 ?
部署转换:将部署装配和资源(包括物理机、虚拟机、容器)进行绑定并生成部署计划,按照对应的部署计划进行执行,可以将应用推送到不同的环境中;支持灰度发布、全量发布、金丝雀、蓝绿部署等;

' u' f! O4 S9 U% ]* B$ A/ M; I

$ [- H0 b* |9 X3 D* J5 J2 T6 _" k
组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;
0 o2 m- ?8 ~3 `- @/ i& ?" Q' s

2 d$ {  w, r, ?; s( i
采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。
1.png

# ]* F+ W" p- w% y) z) e7 I$ o
% d/ A3 m) m* H: v- Y0 r% b1 \5 p/ o0 |
关键设计三:将企业最佳实践固化到 DevOps 平台
# i& L* O) {0 N3 L; Z& b, l3 I- W

( ?' b- |& U0 K

& }) z0 Y* T! Y! x+ {
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。
; r2 p. R6 R! G& g/ [1 }0 e+ x3 {9 y
0 L1 M. R0 X5 w8 @& q8 S  p# [# I
1.png

, H9 n" U2 G. u! i
1 t2 R) F- h' [8 |9 c, k
- ~9 N! n9 l8 w
5、如何迈出DevOps第一步

1 D% R' a9 x& }( O3 P! f1 B8 ?
% P, M) e/ R  h4 J
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
1.png

: R5 `0 h+ `0 z/ V3 \) w: M

: f# z6 \! b/ b
这里我给大家建议了三个方向:. G% E6 @9 v" J) k! u5 \: V

% g; P1 n1 d. Y& R: V$ w5 w

$ W: }6 k' S0 u+ N9 K% K+ ^
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;
4 x+ K! h; j( k, |) C/ H( v

6 O/ z4 P) o9 E/ Y& B' Z
第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;

6 J1 D$ k( l+ ]! {' u2 |

' O" B" R8 F, i% r2 W
第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化;
5 O  b$ C2 X5 [9 q% I$ f5 d

, \* G) U' b# ]) p  R

3 D7 i4 B+ V! I6 H
6、总结
1.png

1 }' b4 ?5 j* T. [0 N

5 s8 T; Q* K- M: w- {
最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。

6 \2 n6 k' j( _$ A- R8 W% B+ G

! I* @% U0 c7 }) K- u5 @
原创:刘相  普元 产品部副总经理、SOA 主任架构师,计算机应用技术硕士
十年IT行业经验,专注于企业软件平台,擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》
/ K! p( I! O" @  ?1 V1 X* k  \7 }/ s3 s

  G- Q) ^. \& k0 K
1.png
1.png

本版积分规则

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

Baidu

GMT+8, 2019-9-23 07:11 , Processed in 0.188744 second(s), 25 queries .

Powered by Discuz! X3.4 Licensed

© 2001-2017 Comsenz Inc.

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