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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1805|回复: 0

DevOps 第一步如何迈出?

[复制链接]
发表于 2018-9-25 11:05:39 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-25 11:15 编辑
7 w$ F5 F# F/ M. `! i: i7 y2 V+ q3 k5 D/ w. a
前言, T/ U# k! V3 }
2 H/ U' B& _- u1 ^+ x# R
ITILxf.com" target="_blank" class="relatedlink">DevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。 & P  Z" C) C1 \5 F% W& _. M
* S* {" b& F5 _: ]; e
2 k7 ^* C+ o1 b) g- q

1 |: S6 d1 E3 b9 ]8 z% M) O! g, k
1、IT精益运营与DevOps  y0 v" z. x$ p& X5 \

& s2 M" q4 d; t( Q" t8 @( o
! F5 _7 o$ I3 d5 b: q

4 p% T6 Y( h" A' `6 G随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。5 ?2 _" j2 E3 L" W$ ]

4 H( W4 N1 I) ?9 q$ Y! j$ k0 ]

% q: V; J& Q( n) X. L) c
# q- G. t+ F1 _9 @( |1 o  F
新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。

6 Y7 R* f! V8 }

7 R& s" t2 ]% p- k7 v' ?% t
普元实践了大量企业数字化转型的客户,包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下(互联网企业有大量的人员保障),怎样快速地把我们的 IT交付出来,这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门,需要将IT的精益运营与 DevOps 无缝进行整合。

6 ~' M: c5 B& ~! U
. \9 {6 u0 U" f2 ~, d4 w- g. f. q
1.png
* @! R$ O) \' S$ W1 ~, J

5 P/ t" }" X& f7 J0 W- v
举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。

0 N3 v3 @7 S/ l" V) x, X+ h" V
* N% p+ F! j: |' o
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。
导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。
1 G7 a' {, f# U9 l2 p; T, g% F; P' y
# h+ ]* B# j) U* ~9 g

) w+ r; `9 Z1 c: z# K
2、对DevOps的认知
. j: P( P" w- Q! a% \4 O; ]( w. e
) L' u- B& B  K  [

4 |! [# b5 w3 R$ O; A  B/ n
  ~; Z# h# i; v' p& V
提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。
, j$ L; x/ B5 L4 ~
1.png

3 O% s2 v! r( i! v, W1 z/ h. p5 y6 H6 N* U3 A+ W
我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。

) k( u8 a! S9 T, x$ m" n; n

, c- ~0 x# Y: A4 L3 n$ m
在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。
, r  w% c4 v/ C6 Y; `
( N- a0 O- V$ g7 U! }' {
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么?

" L1 I( c8 r5 F2 I; H

; o* W/ F3 s6 o
1.png
# H$ j7 U" {' G) c, w* o

3 T% l9 l9 a& c. m
确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:
% [3 w/ K0 g  [

/ p# T3 d' q9 J. e2 @7 m+ E
1.测试环境和生产环境完全做到自动化部署;
. v2 e. Q! L( j" @$ ]0 k, S7 L3 D* r2 n6 v( X' e. ~/ a
" ], f. ]# J+ u5 ^' S* R
2.业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;0 Q2 W2 x" Q) d8 `7 O" N/ W* _

9 t, n3 d  d6 `0 C) A. o7 i) v- k7 [. B
3.产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;* H5 V" ~" A& [6 X
3 z) m5 n1 T6 W
' l% ]0 Z5 u  b$ z" U: g- T( B
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。
( {: w2 K% n! v4 C3 ]4 E
' m, i5 G  o% H% L% H. f8 E8 H/ P" c
企业 DevOps 思维 VS 互联网思维
& z: u' |4 m9 K; @, Z

+ l4 @  `1 B! \* v' x
互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。
' d, s# t) y! C, v. D2 n9 T
& ?! m; o& f$ T3 K
传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。

! N: f( P# _. j" A8 b
% ?/ M. N- o; B# g) j* U
DevOps 的本质是什么?
8 `4 ~6 e: q5 ^1 Y9 ~

" Q" X1 r4 X* N3 f/ ?4 u( M
    我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。

( w! l! l$ _5 J0 K
1.png
% I! `  i2 a0 c% h( \

# v! I: k8 v( f0 q- t8 s
DevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。
, d6 J$ I. r) _% E! L$ W
8 W9 e0 {& M+ D
上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?
2 ?/ e" Q# B; [
- N4 E. M5 A* p2 m& X" u4 O& q  U
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解:

( p5 ~& y8 i7 ]5 P( J
( T9 h' k0 B3 \* g
1.png

. e' C0 ?  d; |/ H. ]
1 r7 Y% H" n( c. j5 Q
主要包括产品(策划、研发、运营、推出)、项目(立项、执行、完工),而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程,要以产品的视角来看待,真正进行交付的时候,也要以产品为维度进行组织的设立(互联网公司通常如此)。但在企业里面,产品思维还没那么强,仍然按照项目的方式来实施。
! }& B! {# {5 r& t2 f- b! S6 A9 w

- b  q. X2 J+ q5 Y: S3 @  i6 k
因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。

- l8 O  T2 R+ I* M  `- V" Y! N

- |9 R  k1 P' _8 X
DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期
; h  h- D) V: F, S0 [" O

- v$ ~9 a- Y3 _- U/ w6 h! h
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:
! h9 k$ j3 V- E6 L9 {7 n  B
8 v  a. O1 j5 E$ C
  • 第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;
    3 u3 v- V+ s$ P1 v$ }# m* W0 ]

. F0 c* v' O6 g9 H$ @3 ?$ I6 L

  F3 s; M' Y1 Q/ ^& W  v+ p( A
  • 第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;

    * k& a: k7 N& Z; e

) D  }' L8 c; N( W
  • 第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;
    6 Z$ R* ~3 t7 O. j: |$ Z0 m* o
9 X9 g- N. I& d' P% ?- q% W$ Y
  • 最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。

    ' t- I; \; a- E6 _" }6 s2 u! |- Q+ U
1.png
& F# E: N# e( g) ^  ^! R) S

. S( D" m* T, Y, g/ n5 h
首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。
; l8 c, @5 O; g

) ~* g8 ~" R- u# [1 B9 n
这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。

0 D7 ?. l- G' Y/ \. C! i. q" L9 u
. Q) N; k' f, _" Q
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
1.png

# X( v! k: h; E8 K1 B( ]
  k% _. B( @- Q2 M- h9 e! D
从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。
9 I1 _4 H# v, U& E! _8 k" H! h0 p( T

. B4 q3 H1 P& k! P# T0 I

  W% h1 ]  g  Q$ F
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;

2 T$ D# A0 h+ [. l5 ?/ `% {% r
  P2 L6 |7 L" h& J3 f9 T2 t
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;
$ T: X. M! j4 ?0 n3 j
7 }- }9 |; _3 S+ r8 M
在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。
" {; R4 w7 P! j! H+ ~
1 K7 n3 Q' s- i2 T/ J' k2 x
1.png
% Z8 V' e% g/ D+ B

( A8 d- S) k' l" x' `! U1 ^+ [
在产品管理中,小小的版本号其实内部藏着很大的学问,基于版本号可以快速了解产品的版本,发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联,大家对IT交付过程的管理就会达到一个较高的水平。

( q5 {0 N8 ^# A2 R0 Q: o  m

/ w- K+ A) f$ q5 g6 o% h, D, _% N
另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。
1.png

: I% N+ G3 o6 e
( ]" B- \. Q+ H/ p, f7 k; D
这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。
, n* i! H0 E# H( A6 @" `
! b2 c; E' A  L! f) Z
DevOps核心观点二:DevOps平台更重要的是提供最佳实践
1.png

, R' ?$ K( K3 p; R
$ D0 S6 N- F# i3 z
接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;

" r: X+ X  q" W) Q
4 g0 E; |; G# w3 }
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;
5 h/ c+ }. F* s4 P* E! H
' ^! X5 k7 w' N% ]% K5 _
客户满意度、MTTR、线上问题数是重点评估的度量指标;
7 _. D5 D2 N; \) a: R

! X5 y: B, k& B2 K6 U/ a2 F
1.png
) V1 b4 `% O" m0 S: ?
' c) Y, x: p( k( Y
在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。

, \9 {2 H' U, F4 ^( ?( g2 A
2 \  Z7 g3 z' }- v+ c
DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。

& i4 \' |5 o" D- x0 _
2 g! H  ?! ~, ]
DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。

; }4 U) S) e2 J; A/ ]1 ~3 x

* |) _0 j( q# B/ d5 }  `$ G6 }! z
项目交付流水线的示例:
1.png
- i1 w1 C6 p  H$ @
' f3 X( P' t& i$ f4 ^5 s- K
一个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。

9 ~" t% [7 z; E4 h9 {0 C
: h; C" k9 m+ h& x* y7 n, _
交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。

2 {+ O" @$ M' S( m6 i

+ L' v# S& b; x% T
DevOps核心观点三:DevOps平台,让不同角色更好的在流水线上协作
1.png

7 z& V* H3 n8 A: p

! n* ]: |7 L2 E4 l: o
再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;
9 v; Z# q- W8 D; w2 _
, I" X2 W$ Y% X3 n7 a- g

( {8 h+ }7 u: h; I3 S% L+ r$ S
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;
$ s, x8 q5 v7 Q: _6 J- }' Z4 A0 @

( E% v; n' ~( b' T, N/ q
需求变更率、任务燃尽图、积压线是重点评估的度量指标;

/ P. ]" X0 e* S9 {8 M' a! U
3 T) I( q1 f" m4 H* |: `7 p5 v
通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。

# H( V4 r6 K1 q' Y; g# ~9 K
1 s( C3 D% p% ^! q; w" ?
1.png

; Q  W  w& z) D% |! y$ ^
+ f- U! N# C+ I3 ]1 }2 W
项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。
/ y1 f2 m7 l) Q
) A) x- L9 a, r8 s& c

/ F. ]& j# m! b$ A. ]9 q, v
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);
! i; {# M" Z. h! w; n. M

3 y. D6 R8 v1 f' q6 m
设计变更率、设计偏差是重点评估的度量指标;
% b4 ^' a5 r" u) x% H
6 c& g5 P; m' F
在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。
. D) Y& o- ^. i/ i' F

! L# j- r- g: ^1 d6 g8 n
在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。
" l# w4 y4 M5 j) o. a/ x$ u

4 D2 @8 T6 S7 H2 ^9 O  m2 I
1.png

  k: V; Y4 P+ u0 {" E

8 x. d& z: F  h. ^; }4 w# @
容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。- X3 j: ?3 z: h  }8 K
$ h" [! e: W1 J+ ^

9 h/ @6 M$ l8 A* y7 w; k
这样前期就可以定义系统的部署架构,而不是全部开发完成才定义部署的设计和安排;可以有效指导和约束后续的开发工作,使得质量提前进行管控。
DevOps核心观点四:DevOps平台,管理前移,有效指导和约束后续工作

+ U3 e  L" r, l9 [8 e& R

3 c) a+ ?/ f8 ~* b
1.png
7 y! P. N: f6 D- K* b

$ x- W8 m0 m/ U7 Z+ |7 i% B: E  K
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。
& l- L# e$ c% Z( R* v- ]. Y$ C+ z
3 Z# P& s9 p; C/ S. N
DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;
$ F2 J$ X. c4 }7 [# ]  W1 q, O
  u6 d* L0 P0 N' _9 I3 f
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;

4 p' M- X* A5 m3 _7 F% X+ L1 i( X
" I( T+ v9 x- Y) A. }
对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。

* n  e7 E9 W0 C5 ]
  G2 b; r% ^* B* }0 F2 K7 F% C
比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。

* u* t0 @: Y* N: K7 ^
' m" Y  h* Z9 W8 d/ u/ X& r
1.png
) F: A2 j: U4 y% ?
. X% W& g% b. L1 L+ \9 i+ p# `: f$ U
DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。

# o' M- Y6 g# I6 N* x
* }, o) A6 E! R5 U# _* M
再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。

0 j- y- J( L7 b1 `1 R

' X" R/ M0 g6 J9 a1 A/ X
1.png
+ v7 z$ g, @5 E7 ?3 U1 }8 s1 s) `; A
0 l& I9 j/ X, n$ N/ G2 F. ^
我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。
* U8 C  X4 r' @  b9 X& }( n5 h; f
' t8 {+ C- i7 z" M1 ]6 A0 }4 X
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革

+ r. Q8 u! @! v3 d
7 T) i. E! N# ]# D
1.png

! l/ P1 ]8 e& U# I
9 K! L: [$ j" Z) {% l, B% ^3 E1 N
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。8 p" D- p! B$ ~. q$ F2 j

2 W0 [% J, y- ^% X& F7 y1 j
% O( a# G! F/ ^. P( m8 @
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;

% g) @. Y1 m/ w2 z% w1 W" A1 v

  S& r5 |, s% J0 U" Y) X
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;
( M. D4 t( F, s  A

+ M& R( P: L# Q& Y$ `
在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。

+ \) e8 a% h# @' a

/ l2 X3 ~1 E( r# ]; N- X2 `
1.png

9 J2 z, S  \( g6 T

* I9 x, A/ X" V! I3 x. p
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。

7 v% d7 Y: g% Y  [+ W7 f+ y1 Y! I; ]

" ]. J# K! d; a" }3 i
DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);

6 i3 g) w# T* K
( X" C+ ^# B8 F; [3 D( {  W, K
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;

% K( Q5 o3 [5 V. I* R
$ ?8 j, l9 ~6 N) ^) B
大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的?

+ g! M) n5 j. x2 {. R
/ d2 [- a9 P/ q; x' Q8 ~
1.png

' |! ?9 N& {; k+ G: T+ m5 o& H
+ c1 n, E% s$ f% @
再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。
9 [2 P: v+ Z/ e2 E
7 K& Z- D: s: O5 e0 Q2 t7 X7 |9 i) W5 o

% c/ F* T; A/ C/ q0 a- s! R6 [
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化

# U' w5 N; {/ A* l
1 t, F5 Q' c: }: _
总结一下,我们对 DevOps的认知:
! p4 y  `8 _( }" m& a- v

5 d: T. B: {- N5 q
  • DevOps是一条IT生产线,核心价值在于提升工程效率;

    : D# l2 v" \0 V4 |1 w$ H
9 B' d  X; A# d4 W, j3 a
3 ~  Z  r+ a* b+ [. _3 }; q
  • 覆盖产品、项目领域
    4 y+ G, C9 Z2 v$ D8 P; ~

. W0 i, I8 I+ C) ]% ^
  • 体现出最佳实践
    9 r  r" x- [' V. j, T

5 \$ e; s# W1 J+ X) D7 U

' b% N$ G: U% A& M0 A. I
  • 加强协作

    2 w' @. e2 p3 S' w; `/ W
0 w1 }$ O# d! |0 h
  • 优化架构
    . `2 s2 H% c, b' Q" D
/ K- k/ X; _+ {& ]7 g
  • 可控范围的自动化
    / f- S" T7 `, T% u9 ?$ }) m
* r8 z8 U9 o. {# I' l
3、企业实施 DevOps 的建设难点
   

! A# Z1 z9 ^. w. I$ S& L# ]
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。
! ]5 p* P) A& r
& C/ k" i6 u0 R# p- w( b& x" o1 h
1.png

& @" _* ^3 c% a4 }; e* V* ^; b/ \3 O, X
  • 业务:, P8 R: X  W9 x; B

    9 v! H& }. ^; G5 r+ [" c
( ?' C( ~: [3 u( s! @3 O6 G4 b
9 ]0 K' y0 W% E. C+ l/ w: V
    1、对于企业已有的工具,我们需要考虑怎么集成,集成哪些;绝不是大而全的集成。如果专业系统足够自动化、自助化,建议逐步纳入到 DevOps 平台,比如针对于底层的 IaaS 平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管(专业的使用方式,还需要登录 IaaS 平台进行操作);而对于 jenkins 这种敏感资源,更倾向于把整个 jenkins 封装起来,不对外进行暴露。

$ k$ P+ I0 G8 B8 D  P/ F
  q. }' A& E4 i, z
    2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。
. |8 H  r& d/ ~: c* }* i7 k
4 g  h! U1 O) x. ~; Z7 ^* X
1.png
  
( ^$ B- U5 P; Z. c; K9 q
3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。% D: X: v  g( }  G
- Z% z1 E; x) U! j8 W
5 T- U' o: i$ _1 W' [
  • 方法论:

    : d' N  ^/ O4 h9 h% E' z

2 Q/ R& v! _0 i0 c% W- V
    1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量;

" @$ L; v- x* }! |# O0 l* [# ^
: s- ]$ b2 r4 s( j/ ?; Y( C4 x
1.png
   
! W8 G- |3 P7 a% E2 y' c7 Q( n
2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;

$ Y  B" o! @8 I, w. `2 G
1.png
9 m( a! q+ ~3 b4 A! e# F1 B8 y8 z

( d3 z. r% U+ F( H1 d+ y
  • 技术

    8 |# b/ U5 {7 P

) m7 `/ c; V1 i0 g* q0 c" F
    采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具;
' V- H/ z# d" W" m- A9 X- `
* H( F; k9 w8 @
1.png
# G& n7 H1 T6 Q+ u& n

8 f3 l; w9 A' B' G

5 H6 [$ {+ z1 R4 Y
4、DevOps 平台关键设计

! l( x! g! X* y  t1 w: \# K
7 U. a8 F+ [+ z6 ~. @: c
DevOps 平台完整功能如下:
1.png

5 z( I6 U+ h; \% e+ {8 Y9 V
  L  O8 r* }% M( I$ t1 s
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。
4 h: D2 h4 g5 v7 g) m9 ]

: |( q& r. ?& ?# ~
关键设计一:支持多种应用架构
$ Q! e# j" X$ K( l+ C- ^- h9 E& z

1 y7 E% g. _* v' h( s
DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。

6 \9 L3 C) Z" ^

) C7 g' {+ v2 o8 Z1 ?
1.png
' C# w) r: }; V: A
( }# d8 F$ o0 a7 h3 n% z5 D# K
关键设计二:支持异构设施的多策略发布
1.png
1 M+ a' n4 G/ X$ q9 G! d

6 z3 o3 E9 U6 V. B7 e
设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。( R4 @$ m) y; V' Q- n: W0 Q
9 C) }9 [( P/ |0 Z  A6 Y$ z/ D8 p

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

9 J" K' u  n" O0 R0 R* d
- q$ o4 |5 j1 V5 i& T! r6 c
组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;
6 n+ K8 R; R% |" b! u: @
0 z4 |4 |' g- |. q% q2 n  K
采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。
1.png
! u4 K5 e) a" [8 V

  n. N& k& |8 S3 V* g5 s6 a: X+ M
关键设计三:将企业最佳实践固化到 DevOps 平台% d+ W/ ~3 D( x

7 E) r! z: X! {! |/ t& _
8 U) r3 k6 }* b2 V! o! z4 x
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。

1 P1 W2 ?; c: D* w( {
$ ^% K5 A: t% }3 H8 k: Q  W
1.png
7 s  f, G- m" t3 L1 V

7 W$ E. R; _, n1 {1 N/ N; D1 b
8 U; s4 {& q2 W9 w2 u
5、如何迈出DevOps第一步

2 n, B8 S+ F+ t/ T

  T& _" j% ~2 U( r3 n
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
1.png
/ L- S6 Q% X, L+ r: Q! ^" i
+ f2 W+ z- c0 V% v$ I% `
这里我给大家建议了三个方向:
$ M- J' [6 P9 H. x3 c9 E

3 ?5 E5 H5 X3 |: a1 q
4 R' Y3 W1 }! |, J
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;

0 m, k! N1 e9 G6 _) o! n& R

/ n; m1 j. B6 K
第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;

& i( m, o* _8 _; r
4 L; s3 O$ [2 e' `/ ~& E: @
第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化;
( ?' X; N+ C/ G7 {3 V6 h
6 D% w. g; w  t# p8 G6 l3 K

; q% @8 k: ?! u+ S
6、总结
1.png
* ?% T. `8 H) ]9 J" I) p! T

  ~9 u( \7 J2 f: n8 w
最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。

3 _8 C$ e0 e0 }" x( S% }3 A

& H' @( v( q  X9 c& W
原创:刘相  普元 产品部副总经理、SOA 主任架构师,计算机应用技术硕士
十年IT行业经验,专注于企业软件平台,擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》
* e3 Z' W7 w# ^- p7 D" Y; x
3 M! w" u( A5 K2 |& t; D1 L" a: W% M5 i, q6 G# o* m
1.png
1.png




上一篇:快速指南:在DevOps中如何实现持续交付
下一篇:DevOps转型是度量驱动的?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 03:39 , Processed in 0.134934 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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