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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

DevOps 第一步如何迈出?

[复制链接]
来自- 美国

参加活动:0

组织活动:0

发表于 2018-9-25 11:05:39 | 显示全部楼层 |阅读模式 来自- 美国
本帖最后由 adminlily 于 2018-9-25 11:15 编辑
" B# F; P  ~- M9 c$ m
5 M+ y8 f! k$ E  }0 n前言* R* O% ~7 E: x3 O( M4 @6 U
, l! C* d# F5 B0 L# \, l* G
DevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。
5 [2 D9 ?% R; J5 R7 t: L) [

5 x8 N8 P+ |$ v1 J
- l0 B  [: M# @9 Q
2 \! |8 e! Z. n* f( o0 \
- J2 R3 S0 b9 Q& ?
1、IT精益运营与DevOps, c# c3 X! ]; M$ ~* x6 R' }
* f7 @7 P' s4 w$ }, y
9 {8 i6 s8 t% t5 a

% |  Q" J8 p- R: w随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。% g* v2 {# ~* O4 E9 Y
& ^% J+ b9 o' Y7 c! w3 T

8 W; x  z4 w# Y+ J& y; W; v, L$ ^0 ~, H1 X1 l1 D: V
新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。

! M# |; f7 K  l6 b! H

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

: T  O/ f& k. a! r

7 ?& j0 P8 p; ?# x& }
1.png
# V- ^  c9 z) k" l* z
, b5 a' S" s) c+ W, @( N0 R, E
举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。

& e- R) q4 c) z8 W5 h# z' W

- }' B3 t4 P, l
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。
导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。
) n% Y& x$ [  Y+ ~: y
% Z! E8 X0 o4 @" }% g
! @+ {1 v7 R! f8 b: q+ x
2、对DevOps的认知
9 L# |" }) M# k
/ T) X3 L0 J4 f3 K* o6 Y0 o8 f$ u
  e0 l+ P" b" |. Q
5 q9 D3 a( g8 l
提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。

! G# E+ T$ |3 P) i( N
1.png
1 n& v$ V/ _( Z0 O& `
% h0 f" g1 Y' [2 b
我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。
/ g* ~1 X1 C8 H/ x# r" J

6 }! O2 @2 F8 C# M, r
在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。

* g, W5 E8 O! `

; e8 U; l) X* r8 ]/ U
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么?

1 ]% |. l! T) X
  x; K) D# w* Q+ }0 K2 m( L$ Q% o
1.png

) @: G- y' H* q7 j

; z$ f* R" V0 u, o
确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:

/ a2 E, M4 z7 X/ o, O' ?( g
+ H- t8 Q0 i- f$ N, N, K2 g* X0 t/ @
1.测试环境和生产环境完全做到自动化部署;; \" u2 V' C3 F' h5 t

3 N1 P) l0 W6 }1 B+ \& x6 k/ Z; M2 `$ k8 |7 ~0 Y5 _  t1 o
2.业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;
: z# _( G! f$ ?" p; s5 K: P
5 j& @9 A8 U) Q  l3 Z! Z& y- T1 O2 c/ F- E2 S& R8 x! j; B* J- b
3.产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;
% @9 @8 k9 D. r6 @+ L! V

1 |/ w6 Q4 O- g. a2 W
, ^2 f% W  }; x2 p- s9 E
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。
9 k( q+ p6 }6 V6 \& g- q+ V# ?5 r8 q
# y, W2 {, y+ h
企业 DevOps 思维 VS 互联网思维

( |( c) ]7 d* |/ E3 z  q3 R

" u* o: q6 C4 O1 {
互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。

) L0 E) I9 A; f2 O; o
- N) f. Y5 c" |/ d
传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。

* ^$ w) X6 @4 f4 A
+ W6 Z$ @8 H: m) j, s9 K
DevOps 的本质是什么?
" g! `  n+ F: H4 f$ x
6 E/ C: ^% `. m
    我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。

$ ~$ C1 i# p$ Y! T% n& ?- [
1.png

3 \  }7 m) b2 e7 t0 \  k, Y* v' `

  g) W+ r  W7 i: F6 E2 C
DevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。
3 i, w3 E. E6 }; R! @* V$ e
9 |0 H9 M, Q) e+ ^
上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?

& P7 s0 z3 B. ?( Y! H! n
! \8 l) Z1 x' S4 d% f
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解:
; N6 _& ^. \+ Z! v! l
8 d, i) `- ~4 Y1 H* E6 r, U
1.png

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

- y6 x) t# n7 H2 B* x

% I6 S, U$ ^. |; K9 N
因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。
" M1 f1 u# _# {3 l: E
8 n4 b7 ~5 ?% Z) K
DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期
$ X% E9 ^' Q$ B6 Y, p( q) m' Z7 [

* V7 n, M" v$ P/ B7 p& M
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:

* S5 J7 W: ~7 [, ]
9 A" Q, {' P; }6 X; T
  • 第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;

    6 r3 U& T. P6 u  k/ U

# g2 }- u% \9 P, F, B. e8 b  Y, S
; o" K! X' U( R9 ]  T. l2 T
  • 第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;

    4 I0 k9 s* W) ]+ M, S

. N5 r0 u4 z8 q2 ]% P9 a8 U4 i
  • 第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;
    . {$ ]2 X* Q- M% t' {
, x5 B, B' C9 M( i( J. S5 Q5 P
  • 最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。
    6 x' k6 f3 H  Q7 s9 Z) k
1.png

2 a& o# j' Q) J; I0 I7 L$ _4 ^

( C% d4 Q. A7 K) y3 M5 M2 d
首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。
) W5 S$ D' [. ]; G) J! m

# h: n2 F9 P$ r. \$ F( A! l
这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。

. D9 }2 R# F3 Q$ T9 x

2 F" O4 [4 l8 B" L+ ~# P
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
1.png
$ P+ D" U  v( ~* r- D7 A4 R& d
% g/ D# [5 X; j* R% _' E" f
从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。, J4 T7 D" K& h8 ~: A
7 ^2 O, a4 {) c& e3 \% a
! K$ x4 v1 y2 P) \1 _
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;
, ^: ^: i8 k8 F4 g; k

9 t4 r# j9 F! h/ V/ O
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;
2 ^( B" J* N) @% V; U4 Q

5 E. t4 p/ }; s2 [' M$ z  J
在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。

1 T& _2 b' o+ A- [9 D8 z. x
9 D; ]+ w1 i- [$ S) F& p
1.png

1 @& B7 v- k* H8 k& p4 k

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

! h/ J% q( V. @3 A2 q
$ |. Z4 @6 G& X8 c0 `5 r
另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。
1.png
2 I! M6 ?6 X8 d1 s: U2 w7 F
2 Z' `( i$ i8 P6 s
这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。

9 u' C9 K: ^" |% V: z: P: J, e
$ ]7 A# Z0 E$ v
DevOps核心观点二:DevOps平台更重要的是提供最佳实践
1.png

* {# [5 A. W0 A! g% h  D
' g3 P* s. G& U! z
接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;

0 B/ e/ n+ M7 c: Q0 B- D! X9 k

: ~/ L$ v1 [3 d/ ]: o- c
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;

2 @( h" T  @6 Z6 P( @( Q. x
% q6 P) f! r" h7 w% j6 ?6 ]
客户满意度、MTTR、线上问题数是重点评估的度量指标;

6 m. n: ~6 R* G8 |: a% Z) A  M

( F4 k  R8 ^& |! B" N" W. G
1.png
  Q2 r' \3 @$ }4 B
( v2 c7 Z  G( c( _0 y
在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。
+ u6 p. n2 e8 X# ?

9 Y" C, {. ]. p4 w
DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。
: e) [# ]8 |& i* v  }5 e, U
6 s8 f. p; B. ^1 u; b# @( g
DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。
" [/ R4 \' U: N/ b' B& J+ N

* k# p9 B+ N. Z! Y1 T$ H; ^# X
项目交付流水线的示例:
1.png
" t9 }! @* }5 {8 L) ^& b
) Q3 K* X# K1 f) g' l
一个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。
4 z3 Q# N8 T0 }  e6 V) [, A
" e) ?: ?% s5 A2 N
交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。

5 h. f! N* g8 C" O# }, L/ B1 @
) X" E# K" q( i1 m8 ?( e9 T1 z
DevOps核心观点三evOps平台,让不同角色更好的在流水线上协作
1.png
& F) t9 l+ W% d: d
9 G1 r+ {3 S' Z
再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;9 l# y" }# U& U/ V8 K& [1 ?

% b# c: [1 U# M* r: _7 K
; W  _7 g* X" ?$ u" n8 U
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;

. i/ J  X! b8 G4 w! e  }" {! |
+ |  D$ ~3 C1 D
需求变更率、任务燃尽图、积压线是重点评估的度量指标;
/ u4 x( s7 Q- f9 [6 G+ E5 S
9 y/ w1 f" {  p
通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。
2 n) E) p; ?& M: P4 x+ R% z

3 e5 q+ Q* f; x+ W2 k1 S; v
1.png

( U3 X' z9 d6 S, G) {) z0 E( q4 d

% [0 `1 G0 o8 p( y4 m' \
项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。
1 u' K% T( P" @

) @. X" o% |  M0 P$ D, q$ S: p
% R, k. ]! i: v; o- i
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);
6 F7 P2 o' w, q
$ _- P: A6 ]! p
设计变更率、设计偏差是重点评估的度量指标;
7 b- A3 F7 M! D% _( Q, j
# S: a6 y' w9 j' c9 L; m
在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。

  K* r0 E( ?+ C! U2 n# U
- S7 u4 S% b1 Y* h  L& P  P
在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。

: g6 d) O* e7 c  M

8 z9 \5 Q  _4 |- w' w, ^3 R( R
1.png
$ x$ l9 C$ t) ~/ M
& g# s. k) U5 N  a
容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。1 i" J  k: Q5 a* I
9 g8 Z" e. v5 W

$ ^# Z+ R4 S( w3 O0 I" B9 |
这样前期就可以定义系统的部署架构,而不是全部开发完成才定义部署的设计和安排;可以有效指导和约束后续的开发工作,使得质量提前进行管控。
DevOps核心观点四evOps平台,管理前移,有效指导和约束后续工作
7 c/ C  `4 c5 m8 N

4 P2 x8 u# ?! y7 e+ k# \
1.png
8 S' i4 r/ t3 Z8 \! O: O+ [

  B# L. B8 D4 D5 k& o
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。

4 |  ^8 `* v: m& d

& O: K+ G( i' H8 b+ p
DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;
1 `) Q0 E' ], ]7 l' Q  X$ X
) h0 \/ ^8 n, D& W) y  V$ Q- S
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;

. p! D: d( a# r. }/ H
# j) x6 C" K; O  e" R
对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。

7 @% p0 _, T+ C

6 m1 y! ?/ h$ S3 v5 j
比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。

# P; ~4 X, q. `5 I* G: K

, K7 j: y2 Z) g  E8 q
1.png

5 f) k8 W; E  r4 @6 h, D; L# Q8 {
: m7 L; ~! z% S; a& c
DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。

7 |* e' l4 F( p

. M2 r0 s, \1 ]4 T: _1 b
再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。

$ o1 i3 z+ `1 L1 L* i
( s  q7 D" m" t/ C9 A# x0 P& {
1.png

4 ?; d5 T3 o8 {2 w) V% V8 r- I1 Z; p8 _$ X3 `) R
我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。
& J, Q- D8 N8 @  C

* L, k6 O* e' n8 G& _
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革
* ]' ^% d$ s3 A( d7 w4 C

: h9 o' a* [' z. K0 M+ j2 y
1.png

! Y# `' f; |- W! ^
/ b/ r8 l# d/ t+ y4 D5 `0 ^. `
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
: r( G: a- y/ }7 {: X. Q

9 p& j& y% f8 `( G

& ^* T4 w- i  k: T* @
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;

' ]  ]! X9 B5 Z$ \
2 m: q5 |- R0 w) B. C% U" u- x: m
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;

7 T3 C* E9 o9 `' e. c0 k

) C: o9 S5 v# C( m
在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。
# ]) i  t3 H( C2 }+ \6 K
; F9 D1 ~' j/ d, \& J  L
1.png
  {7 B* @- k8 l" F6 C5 L" M) k
% Y, @% O2 l* Z0 b: e1 b" \
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。

1 `. M2 G$ X5 G% T$ M
$ z- J( y* I7 Z6 w) t0 o
DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);

7 d* }2 N( m3 I' J) d" t
& A/ p+ S3 U) |
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;

4 }% M1 \$ O+ K
$ q' k0 b5 G/ g
大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的?

9 r3 t& x8 P$ d( [. Q" |- V
, r$ n7 F" p) R" ?: u4 @
1.png

, q" J* e, r# B! W7 j

  ?5 h5 v# E3 Z5 o
再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。
# O/ E5 R, l1 C0 T7 U( {

+ r) \# T2 I6 i& `' i

1 i8 i/ B- A0 u. G
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化

7 A+ t. j3 Z! Q6 N  v* x
7 M: o, w; s) E0 \2 Z- K: @' C; A+ `3 _
总结一下,我们对 DevOps的认知:
) Z- o" z" l( p8 \8 V

% k) R  k3 I+ B* @! f) [, G) V, K
  • DevOps是一条IT生产线,核心价值在于提升工程效率;

    6 A% C7 l4 S8 T" j* K$ ^4 r& ^
/ L: |3 {! c6 Y; E* q+ H

1 g* m  G5 f4 g) f, A
  • 覆盖产品、项目领域

    4 q9 u6 D( g  C4 H+ Q6 r8 Q% X! C, j

) e; q7 B7 N9 q) _
  • 体现出最佳实践

    : S7 z& V- w" P. @

3 d/ @# [  }. Y" C, B8 }0 Q: n$ U5 [0 ^! K
+ B6 a' L  ~8 U3 O/ \
  • 加强协作

    " R- J& d8 e1 s* x& n  n8 ~8 `
2 s  y8 Z$ G9 c' ^! X
  • 优化架构

    ' u' x1 B0 j6 k! N% o

2 ~+ y' F1 J4 D' u
  • 可控范围的自动化
    ; {- [( s; S1 ]9 X

% d6 b6 m# S1 F5 M& d3、企业实施 DevOps 的建设难点
   

4 G! Z  T- j9 l5 E7 i+ u
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。
% d) C" @# x+ A' e

0 `# T1 I2 r! w0 u- S- L, t# \: h
1.png

* T& ~: U- x9 Z( s" h; I& x, c- p# s# I4 ?. x  C6 O
  • 业务:/ z, k/ S( u7 _) {' o8 {

    $ ]7 X: S, F, X8 O% Y

7 k" ~5 J. a" J/ G) r7 K: W5 e) Y% W
    1、对于企业已有的工具,我们需要考虑怎么集成,集成哪些;绝不是大而全的集成。如果专业系统足够自动化、自助化,建议逐步纳入到 DevOps 平台,比如针对于底层的 IaaS 平台或者容器云平台,我们就只是进行接口调用,而并非功能的接管(专业的使用方式,还需要登录 IaaS 平台进行操作);而对于 jenkins 这种敏感资源,更倾向于把整个 jenkins 封装起来,不对外进行暴露。
4 I! ^$ X" d! L" f

5 J2 j3 X3 b, g3 b6 g
    2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。

( L9 W2 m3 U( O  v4 R

5 G6 y/ n8 Q5 S: }0 L- U# _
1.png
  

5 P( l/ O) A, {3 ?) g/ Y4 |
3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。
8 @# d; U6 ~9 y. Y  }- q
0 g. B* ^  Q/ S# ]/ T
4 ?: V" Y  S+ h8 y8 K
  • 方法论:
    " j8 @# F& l1 K3 ^* h+ ]5 `, u

! U( a) D' R* h9 I
    1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量;

- Q9 U/ b" o5 ?" ]& R
5 o9 s. Q* R3 S  ]  C5 W" C- E
1.png
   
+ F. \  R8 p5 ]! _7 e
2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;
% }) `- D+ |+ S
1.png
# N; c# P$ H% j* O, [. n

- w% w- a" u. O: e2 o% C' J, [
  • 技术
    1 b: q+ _# u! ~2 G, ?

/ n- R& ?4 u& i7 ~2 ^
    采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具;
4 E2 T8 e& s4 Z. D

1 k- V  @9 c+ v/ e
1.png
5 t& O3 I. F- x9 Y, T

# l$ c( `1 r( m; f) Q+ Y, d! u9 n

+ ^; u7 L0 x& D2 Z2 Z4 K* Y
4、DevOps 平台关键设计
) g+ }" x8 W0 O  f* e
6 ?: L" w5 F0 X2 m: d! l6 I
DevOps 平台完整功能如下:
1.png

6 [4 I" \0 _6 J9 g
+ X$ e9 p: c8 o* F, w
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。

& h& z) y; J) |* F& m9 l. h

. P) V- \7 E1 N( r& o. e  o
关键设计一:支持多种应用架构
: Z; Q" |* s! P
! |2 |$ C# T9 z4 z, ^" W* q' i9 U4 F
DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。
) w3 @( }$ Q) j3 e" G
' Q* ]9 i/ ~; _% d6 `& u6 s
1.png

8 `7 V7 N% y/ k0 X6 q
7 ^0 K6 f1 ]# I% D+ K% _* q/ @
关键设计二:支持异构设施的多策略发布
1.png

0 [; C0 ]9 c" y# O
# G7 K) P8 M# D' S* r
设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。
: r* G, b. c2 d
2 s& S" I- I. @; }3 i9 b' T

% \' P$ p, |! G9 V, X& g
部署转换:将部署装配和资源(包括物理机、虚拟机、容器)进行绑定并生成部署计划,按照对应的部署计划进行执行,可以将应用推送到不同的环境中;支持灰度发布、全量发布、金丝雀、蓝绿部署等;
% ]7 x& g# b, n5 h
# r) y& e  X+ u5 l
组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;

  ?6 o7 C; _1 ]- L
2 t. l! d, O; j% i3 V
采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。
1.png
0 n' z1 K/ ?$ x5 Z
) L+ \" t! K% @* Y# _
关键设计三:将企业最佳实践固化到 DevOps 平台% Q) }- V1 d/ I) X7 [, C$ R3 }

7 W. Q0 |0 j( h- }! V9 t* Y% t7 n
1 n% E% i- M+ }& b, Z8 d& C
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。
7 z$ M3 s" q( c* g$ ?

% M$ U, J4 _7 |2 w) k7 Y, r. [
1.png
; V& F. I, Q$ D; a! ]
7 p: D- b; @; X9 j& P

3 @) ~1 H! i0 r8 A" L! |% o
5、如何迈出DevOps第一步

$ m2 Z- S/ `( J; p1 \7 o9 d

3 ^/ C7 D. j4 Y* `. |
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
1.png
4 r' I+ P* k; ^* {3 M; z. n  d9 S
) J' [0 U* M$ n" Z- J
这里我给大家建议了三个方向:( @: C0 S6 K0 s3 e! v% ^

% H: o) G: l: o' ~
4 {5 g% A4 L: u& K' s0 g
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;

3 l% X$ f, h: [7 q; Z% ?% O

3 P# x( D0 o; c& x
第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;
0 q  i! I: y9 H' G

6 s; c. L# n# d1 A5 |
第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化;
& _9 d7 ]5 n; w
1 Y% n6 H$ h7 X
+ D% g0 y  ?9 G. B
6、总结
1.png

3 u3 x+ ~) g* u8 D1 S3 W8 w& D- z
. K, J. E; S" C' V
最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。

& \+ N9 @3 ]2 L% F' X
) J1 U3 L8 I, s3 x6 ]% C
原创:刘相  普元 产品部副总经理、SOA 主任架构师,计算机应用技术硕士
十年IT行业经验,专注于企业软件平台,擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》
3 V8 }+ F$ ~. w' G, F. _( ~
6 m! |' ]2 E( O  l' N. W; H0 Y' S0 h. K0 S0 ]; k2 f* n
1.png
1.png

本版积分规则

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

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

Baidu

GMT+8, 2019-4-25 00:46 , Processed in 0.263511 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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