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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

DevOps 第一步如何迈出?

[复制链接]
来自- 美国

参加活动:0

组织活动:0

发表于 2018-9-25 11:05:39 | 显示全部楼层 |阅读模式 来自- 美国
本帖最后由 adminlily 于 2018-9-25 11:15 编辑 % \% }3 u# e. N- O2 s2 @& W7 Y

+ B0 }& t* a5 Q! c前言8 F1 o7 @4 \2 g6 C

4 J6 N& X; _) WDevOps 不仅仅是打通开发和运维之间的部门强,我们认为广义DevOps是提供从业务、研发、运营三者之间的一个完整的闭环管理,更高效便捷的实现产品的敏捷发布与管理。DevOps 构建整个IT交付的生产线,提升IT的工程化能力,实现工程效率的提升。 # i( S# d4 ^& k% A( j3 Y

" y$ m" e1 Y& S, Z  ?  P
0 @) m  s( w& F3 L- V

8 ^- w. w2 l% `8 P# v2 x) r
2 h/ j2 r: [0 I
1、IT精益运营与DevOps
* f3 y6 ?2 O0 V2 v4 P4 y% a# D# m6 m0 {9 z  D! ^$ d* ]

- c& o( z- G1 w9 C! Y6 {
( v9 F4 E! e) Z7 I随着企业的数字化转型问题,要求IT从对内服务向内外兼修服务方式转变。传统应用的特点是:服务内部用户;需求相对明确、功能全、覆盖广、大集成、适合稳定发展阶段;难以快速变化、维护成本高,快速变革的新业务态无法支持。: }8 t- k0 `! H$ Z& }

& {( k3 p( }) Y8 k

$ O# \$ U- O# Y  [: J( d" W3 O, Q  M$ K" i; X( [1 Q
新兴互联网应用的特点是:服务外部客户与合作伙伴;需求变动快、功能简单、独立和分散、分布式进化;应用规模变化大、大范围广泛的测试、易失败、对业务弹性、快速发布要求高。

8 h1 U4 b) P* U8 Z2 L

: W6 h/ c& R6 u8 x  b1 {9 P
普元实践了大量企业数字化转型的客户,包括红领、蓝月亮等企业。从IT仅为内部客户服务到逐步转向 2C。转变的结果导致IT交付的压力变大。在传统企业 IT人员又少的情况下(互联网企业有大量的人员保障),怎样快速地把我们的 IT交付出来,这是 DevOps 要解决的一个重要出发点。让整个IT部门从传统的支撑部门慢慢的变成业务创新部门,需要将IT的精益运营与 DevOps 无缝进行整合。
) l/ s$ ?( b) N5 [+ o
1 M5 {- ]& O% [* v4 ?9 S7 P+ k- t
1.png
+ o8 \' d. f2 m9 W/ `# `; u

5 v8 `" x! `) ]7 u+ ?; @
举个例子来讲,在飞机晚点的商业时刻,需要服务商帮助客户做酒店变更,客户的会议日程也要做出变更,所有这些事情都要求IT是自响应的,不需要像传统的方式还需客户进行自我服务。
9 a& C8 r4 ?3 t/ M: g
' _% q1 b- b/ l3 x
这种创新业务对IT的交付要求变得异常苛刻。当然在IT建设的过程中有很多协作的问题、大量的技术债务、新的技术架构的冲击(微服务、容器等)。
导致业务应用变得非常复杂,交付困难,在这种情况下,DevOps平台或者说理念就逐步的会普及开来,以支撑业务的敏捷、企业大规模敏捷。

% P7 C! s& [! m$ n

- U4 m8 _; C2 [7 u/ Z8 V0 M/ m

6 g1 Q' M2 O  s* C' g9 N0 S7 T
2、对DevOps的认知

- S; V! x- R7 i8 O$ F- h9 A
6 n' X; I6 Q# S) N6 O" N4 D
9 y' m' q) {4 g% c5 H1 t1 \% |
4 H. g" r5 C) y) Y+ {
提到 DevOps,可能每个人心里都有很多的图。有各种基于技术、流程、文化维度的,还有类似元素周期表的。

# A! K) K7 G0 @/ t1 m7 d+ Z
1.png
1 H( y. }* m( R# A0 @
/ n7 Z- v8 v5 P: N$ o# ~
我想说的是,在做 DevOps 的时候,到底应该解决什么问题?其实这是我们必须要面对和回答的,只有回答了业务上带来的价值,才能让 DevOps更好的落地。

7 h5 G3 }* C2 I7 U
! [' S8 f( a- {# I
在传统企业里面,我们投入钱做IT建设的时候,它要的是投资回报率,也就是说我投了1块钱在IT上,究竟给企业能带来多大的业务价值。

3 l9 t6 c" |' V6 m+ z. W2 d

# \- Q5 f  n/ M# R# v# s
结合我们实施的一个客户案例我们分详细 DevOps 实际带来的业务价值是什么?

, \- R+ Y! C+ N( d' B, i

$ ?/ A+ R- b. v0 ^4 G; v
1.png
8 W6 U. ?* T  r

  R3 I0 L/ \( }. h( o" N
确定了一个很明确的业务目标: DevOps 平台建设完成后,要求IT效率提升 50%,具体拆解下来包括几个维度:

+ P4 J( O* Y. [/ v6 E; l$ ^  y

9 d3 t9 t- c6 y* Z+ F( @- y: N" O
1.测试环境和生产环境完全做到自动化部署;3 Q* e  ~0 A" i+ `: Y% i8 H

. R! t$ `- O. t  K, y' b7 R9 G0 c+ b  U; I8 W
2.业务流量有峰值或者浪涌的情况下,要能支持20倍的应用伸缩;
) S, k4 d5 _9 Q5 C3 `; M5 a1 y4 Z3 x
; C0 |" I2 Z) m% v
3.产品研发过程、项目管理过程完全能够做到数字化,对整个IT团队做数字化的考量;! _" u  E3 z$ M7 F

( p4 ?0 }/ h" S" G; v; d1 }
2 ~7 F0 E0 Z$ p) S$ M
基于具体业务目标而非技术目标,可以非常容易地在企业内部推广DevOps的建设。
) E/ y! }6 b% @! F: B+ J" h; M# c

/ q/ ~7 S1 l# W, v' T, A# {
企业 DevOps 思维 VS 互联网思维
2 n1 ~0 F8 B3 W$ j, y7 _( z
6 }; D( B6 f0 j' Q
互联网里面强调的一个字就是快(快到没有任何底线),要求你的业务快速上线,周上线、天上线,甚至一天多次上线;而对于企业来讲不能完全照搬互联网思维的快;在企业里面他们考虑的第一个是风险、质量。
5 ~: a; L! S; j9 T

9 s7 v$ M  X5 `, A) D) P
传统企业和互联网还有一点不一样的地方,在金融或者保险的行业它是有监管要求的,不是说要把所有东西都做自动化,那是不可能的。在企业里面更多的要把应用的快速交付和质量保证找到一个平衡点。

, z: w0 H6 r. W" c; P$ C% r. F: r
) G; T0 E3 Z% q  o  U
DevOps 的本质是什么?
4 n" R" e8 ?3 J# N( b! D/ R. s
1 S& l, H% Y0 J9 i* a
    我们认为 DevOps 就是给IT的生产、研发、运维做了一条交付线。本质上是提升整个IT的工程效率,解决软件生产的工程化问题。

! y: c! _+ u) k; s  Z
1.png
+ W0 x5 q* Q; y  F5 i- O1 j

+ v! o& V& R4 V4 z# s
DevOps 把生产、研发、运维和云平台(各种资源,IaaS、CaaS、物理机等)这样一个大的流程无缝打通。DevOps 建设的重点也是围绕这样一个大的流程做一个全链路的打通,固化企业各种流程和最佳实践。
2 [. @8 i2 ~2 @7 a+ d

; I* `5 i- Q- x; O( p: I
上午分享的专家也讲到,未来的运维要从传统的运维走向面向应用的运维。其实 DevOps 也是一样的,DevOps 一定要站在一个应用的视角去做管理和把控。站在一个应用的视角,我们要做什么?
5 ]! {8 s$ l. R

7 ?5 U. U1 e3 `$ B0 a# R* h
这个地方我给大家介绍普元 DevOps 平台对产品全生命周期的拆解:

$ V, i2 I8 T6 c

7 v/ [4 l& E% {: M6 D, v4 m' m
1.png
& U" p( H0 T9 w2 W5 [0 o
5 J/ o+ i# O. g4 F; ~5 S- Z! d
主要包括产品(策划、研发、运营、推出)、项目(立项、执行、完工),而敏捷、持续集成、持续部署、持续交付都是 DevOps 的一个局部的阶段。
DevOps 在支持全生命周期的过程,要以产品的视角来看待,真正进行交付的时候,也要以产品为维度进行组织的设立(互联网公司通常如此)。但在企业里面,产品思维还没那么强,仍然按照项目的方式来实施。

5 H+ d, x/ i, V7 g0 M  m

0 p" c$ Y. p- g: s* M
因此在企业实施 DevOps 建设中,要从产品、项目两个维度来进行考量与拆解,关注每个阶段管理的工件关键流程、关键度两点。普元自身在进行 DevOps 建设过程中采用了 OPDM 的方法论进行每个环节的拆分,进而梳理出 DevOps 在每个关键环节的支撑能力。
, x. g( l* l" S, i
& o8 j( d: s1 d- m/ f" l% K* p
DevOps核心观点一:DevOps平台需覆盖产品、项目的全周期
  o# [9 e" O* r6 U) q' {) n
0 p8 C) O1 ^; W2 K9 p5 q
接下来我会给大家以一个 OPDM 的模型对每个环节做拆分:
/ K. ^8 E7 `2 I

; f6 d, \5 ~3 R9 M
  • 第一个O是管理对象,也就是在 DevOps 每一个生命周期环节里面,首先要看我们的管理对象是谁;
    1 G# [. N& t- x  G4 W  F0 p+ D1 t

0 t1 x  L" F8 Q# C# a2 P
6 m4 O" Q& ]$ L& ]9 m/ z6 h" v5 Z
  • 第二个P是要知道在这个环境里面,谁要在 DevOps 上使用,服务的角色是谁;
    2 J7 C# V* l3 d7 `' l9 `+ f, B; Z

, @- `# w$ @( R9 z1 R9 H3 B$ p
  • 第三个是D,有了这样的管理者和参与对象之后,要知道我这个平台关键的升级点是哪些,我要支撑哪些流程,有哪些最好的实践能够在这个平台上落地;
    * H; V% _! Z8 G% t/ K

4 o, B7 u3 \/ d( r; m8 P
  • 最后一个是M,也就是度量,这是衡量在 DevOps 平台上落地能力最好的度量工具。
    : h& [6 }; \7 d$ s) L. O, v
1.png
9 a% P: g% y( E' L/ @2 o

, P- s! }8 C# M( U( V" ^
首先从产品策划这个角度来看,主要是产品经理使用;管理的工件是产品愿景、MRD(市场需求)、BRD(业务需求),以及产品间的关联关系。DevOps平台设计过程中需要关注不同产品级别的流程设计,以及提供整个企业维度的业务域的划分与管理,包括业务模块和产品线。
# c) N7 B) V- y5 ~6 D. [0 ]
4 `. f1 ?8 Q3 s* _, {
这里面有一个最关键的点,你要针对企业未来生产的不同的产品,定义你的产品的运维过程、开发过程,以及它的支撑等级(每个级别的交付模式、运维模式都不同)。

4 H8 X# B' X$ j* j8 a
8 S  k( A! p1 f! z% l# l
立项周期、市场需求到业务需求的转换率是组织最重要的度量点。
1.png
. N& k8 h8 U/ n" S0 {
- _7 \' j; @( \' i
从产品研发的视角来看,研发阶段主要是给产品经理使用;管理的工件是产品版本、 PRD、里程碑、路线图等。
$ G& E3 x, g5 ~9 |9 H: {

  |6 k2 o+ \* o- @/ o  j! a3 ^6 h2 R

# B$ K) h  w9 i) u9 o, j: l
DevOps平台设计过程中需要提供多版本的管理,以及类似版本号的最佳实践能力;
( I* Z! Z  H& s7 n$ y
$ a5 D, _& m) Z- X) t) t! s
PRD积压、PRD变更、路线图偏离度是重点评估的度量指标;
+ r' i% N" }. C

% B  g1 e6 u0 a; a& E8 y  e+ D5 C
在这个阶段我们最关心的是未来的 PRD 的积压,因为 PRD 的积压就说明了你的IT团队生产能力是什么样的。一旦我的产品需求大量进入backlog,团队知道部门的生产力跟不上,如果团队要多接的话,就要牺牲产品的质量。
, N4 U* h& f6 \4 [& Q' ]$ N
0 \2 j: S5 r. o  d3 D) ?
1.png
3 `& F: y" t$ c2 k
+ i$ [+ i0 Y. l7 T" I/ T9 R' g
在产品管理中,小小的版本号其实内部藏着很大的学问,基于版本号可以快速了解产品的版本,发布情况。甚至根据产品发布后的版本号可以快速回溯到关联代码、关联设计、关联任务、关联需求。如果能做到这些维度的关联,大家对IT交付过程的管理就会达到一个较高的水平。

: h# k9 _: \8 Y) ?8 z
( @+ W. d; C( [7 \, C
另外基于版本号,非常容易实现产品的版本看板管理,随时了解产品不同版本的进展情况。
1.png

( k& ^! p, ]& {. m/ D7 |8 n
( M* u; x: Q( S7 @$ ~2 B( g& b
这是在普元 DevOps 平台上,我们的产品管理看板。在看板里,你可以明确知道我的IT产品里面有多少是正在研发的,有多少是在上线的,包括在不同环境里的产品状态。基于这个视角,我们认为 DevOps 要提供整个生产过程中最佳实践的孵化和落地的工作。

5 J  F7 c' y- w/ |+ A
: `# h- z3 L3 ~  I
DevOps核心观点二:DevOps平台更重要的是提供最佳实践
1.png

7 j" m7 Z3 e$ ^. a/ P$ Q+ V# j
* W' J% l, k1 Y4 g/ r
接下来是运营阶段,主要服务客服、运营团队、产品经理等角色;管理工件主要包括事件、问题、配置、服务的SLA;

* W; r/ S9 [) Q5 y3 q

4 k5 A  g9 R1 W4 S% A2 X
DevOps 平台设计过程中需要产品发布的演练、紧急发布、故障处理以及知识库等积累;
- k5 W" u* z3 t1 G6 x- p: Y: h
, V" n" I# C4 B8 R8 ^! a
客户满意度、MTTR、线上问题数是重点评估的度量指标;
& s5 T8 ?7 O4 ?* p$ v4 I/ g5 }! _

7 S; u0 ]# h% F, B$ l
1.png
2 S. c2 t, W9 A0 L9 f* Q: d/ O
+ Z% Q8 O/ [7 L$ A5 p8 T% [! P
在整个项目启动和立项的时候,我们一旦把产品定义完以后,接下来就基于某个产品要做项目的开发。在项目的立项和启动阶段,最主要的是组建项目团队包括权限,提供环境的快速开通。

* T: Y6 u3 N) C5 z
; ~% }5 v( @8 Y3 Z% y( t7 O
DevOps 平台要提供整个团队管理的能力,提供不同的角色在平台上进行协作,分配不同的权限。

" X+ b% ]$ ~% k- M! x5 H; `! y
! @6 }# f1 N! }: a
DevOps平台需要提供关键的流程支撑,包括对过程的选择(Scrum、传统瀑布模式等),定义对应的交付流水线(每个不同的企业和项目对应的交付流水线都不同)。
1 A2 E- F* S" L5 E( U2 G

% I, G" A) Q; i7 H# V
项目交付流水线的示例:
1.png
/ [. @+ I' }: d- f
+ z% H4 [# j+ n* L. j
一个项目的交付流程一旦固定之后,整个团队按照 DevOps 平台上对项目的交付流程进行协作,在流水线环节上定义具体的业务动作(集成、UAT、预发等),并可以设定自动执行还是人工接入;可以把每次交付的过程完全数字化、图形化的方式展现出来。
1 w& t- a( Y5 _3 k

2 J# U4 H* s, O4 K
交付流水线确定后,相当于我们以前推动这种项目制度规范的事情,可以通过在平台上按照流程的方式执行,把企业的最佳实践能够固化到DevOps平台上。
6 I' i9 i0 b3 Z9 P
4 x9 a; K! i  k  U( x: t
DevOps核心观点三evOps平台,让不同角色更好的在流水线上协作
1.png

; _# M: v8 J% F* {$ _- X
7 z& z" G' I& x. d6 ?: D
再看项目需求阶段,对产品经理、项目经理和架构师来说,平台要提供基于敏捷的需求管理,包括 EPIC、Feature、 Story、Task;  C  Y! \8 \7 y
: `' \1 S5 m) F) y% f  T
$ K$ ?5 y" u1 \# ]' l
DevOps 平台关键设计需要提供基于工作项的管理,包括需求、任务、缺陷的管理;

8 \5 X) [1 m$ K7 f- Q

" P; }6 I: }% n6 l$ [
需求变更率、任务燃尽图、积压线是重点评估的度量指标;
9 P* O( M/ f2 i8 Q: v% H6 x" O
+ K  w4 T7 G7 a/ A; G7 @/ m5 |1 Q
通过 DevOps 平台需要做全流程的打通,打通了以后能够给我们带来的好处是什么?可以从一个缺陷反向追溯隶属的产品版本,对应的Task,对应的需求,这样其实是做到很好的全链路的回溯。

0 H  y+ r& g$ d+ g4 D, L

1 Y' A/ W- q; t8 @" I3 O3 [
1.png
4 O6 r9 {, b  Z# u* Z8 I. U

. u+ V( W/ K# d4 K3 F9 f9 s
项目架构阶段主要提供给架构师、测试经理使用;管理的工件是系统关联、接口定义、部署容器、组件。/ }" _/ y/ i( a
; B3 c! q" R0 d' S# p
2 S$ }9 n8 @& v* |$ u/ b! P
DevOps平台设计过程中需要提供部署拓扑图的设计,以及应用架构的设计(系统关联关系、接口定义等);
! E% e, ^- H, `1 ?; @8 v
' T; }- Q4 b7 W5 [- C7 p: ~% L# h
设计变更率、设计偏差是重点评估的度量指标;

/ e! n, V$ T) u
3 m! h0 S$ Q6 W1 a* C
在架构里面,最主要的是要把我们的产品关联组建拆分、以及要确定它的部署架构,包括有多少组件;有了这些设计后,DevOps 平台后续可以根据部署容器进行资源绑定,实现自动化部署;根据关联关系确定依赖,进行部署器的依赖管理工作。

8 [7 E* T* P7 n, m1 ^5 b: e

+ [5 V7 {; z6 a' \4 q
在部署设计中,提供了基于部署容器的概念,不同的部署容器可以编排依赖;在每个部署容器内部可以进行组件的编排。
6 ^, @3 [- c8 Q, z* I
/ t: Y( U& }- |. ~5 i, G! P
1.png
9 K8 t+ |; o' j/ Z+ S+ }' r

+ K- ]1 m3 {1 P- I+ z
容器其实是一个最小的部署设计单元,在部署容器内部可以定义组件,包括依赖的应用服务器、JDK、甚至包括操作系统等。3 j7 t( M) d4 V+ ^

: F6 u# O( I- i8 m
) M( S0 k3 q* X( L  c
这样前期就可以定义系统的部署架构,而不是全部开发完成才定义部署的设计和安排;可以有效指导和约束后续的开发工作,使得质量提前进行管控。
DevOps核心观点四evOps平台,管理前移,有效指导和约束后续工作
' P: c- T! n+ P+ M5 o
% a% x& P% G4 _9 B7 z, o9 u
1.png
: ]9 [" }+ O) E
2 B" c/ E5 x& G- C* h# Y# H
构建阶段主要管理的是代码库、代码的 Review、构建定义和构建执行。

! S& S! R; Q: r
% r) B7 v. A# S
DevOps 平台设计过程中需要提供最优的代码库使用方式,完成整个关键的构建定义、构建策略等工作;
( _& n. b0 [, f4 V7 r5 W
$ o) s5 V& ~9 E" @, J* T4 Q
代码行、代码提交频率、构建次数/频率、构建时长、构建成功率是重点评估的度量指标;
! l# \6 n+ w" Q9 z4 ?

$ N% l; [& r- Q) d% i  E
对于代码开发模式,提供 TBD、GitHub、Git 多种不同的开发模式,让团队根据自己的实际情况选择不同的协作模式。
2 E# I6 E0 G7 ?  j, W
0 L2 v" w5 A" U, {8 p* S6 E* K
比如 TBD,其实是基于主干的开发,需要在主干上随时可以打出最新的版本;当有新的版本需要发布的时候,需要进行创建分支;在对发布的版本进行维护的时候,需要将代码提交到对应的分支、同时需要提交到主干。
8 ]+ |/ i) Q& w  g

% ^0 n" d' K* i  R0 n
1.png

  b# B& U9 P: O7 a

( o# e- s4 p. g! a
DevOps 平台就是要把这些最佳实践固化进来,让项目团队成员去使用。

  L0 B  T' Y+ P+ W- v8 f' L
% _" ~% U, v. \# Q- {5 Y% G7 Y
再举个例子。我们都知道要做持续集成,做完持续集成之后,是不是能够把最佳实践展现出来。在代码提交即触发构建的情况下,如果编译时间特别长,你怎么解决?如果你每次代码提交完以后,三分钟可能开发人员还能忍受,5分钟、10分钟甚至更长的时候,就是实践的浪费。
7 U  v: c% n+ y8 Q% {

1 D, h; h. ?- s' P) b0 `
1.png
% l6 I" D7 r  M7 ~
* ?* \, E  p/ Y" ]1 k! s
我们通过在 DevOps 平台上让开发人员设置超时时间,一旦超过这个时间,则认为构建失败。DevOps平台会自动向架构师反馈并提交一个缺陷,要么是架构拆分的问题、要么是构建存在过多的依赖,来实现架构的优化。
) b1 j: ]9 v( o8 w. ?
4 e' W$ \2 r& A3 {2 I1 M5 L- S0 ^0 A
DevOps核心观点五:对于已有系统, DevOps平台不仅仅是通过新的工具链实现快速交付,更是一种驱动优化的变革
; ~4 z* n. }/ y8 B( {
" o- A: ]: a8 D, f- F+ _
1.png

; Y, v, u" d/ A) j2 B4 x
7 q$ e/ {9 X8 I# P2 ~
测试阶段主要管理的是代码质量、测试用例、测试计划、测试报告。
' ~/ f1 S& X) F5 A
9 t" H( g# c8 ]1 p% v  G

1 ^& o/ G; a- R) A% T: u/ s
DevOps 平台设计过程中需要支持多环境的自动部署、多策略的部署,提供测试团队进行快速的集成测试;

' q9 ~' D7 E6 j3 V. D. m# P
  [  i8 i0 c$ m, g
单元测试覆盖率、自动化测试比例、阶段 Bug 比例、Bug 打回率、部署成功率是重点评估的度量指标;
1 }: E. \: U4 _( N' x

) L0 x2 a0 x3 D3 m7 T7 L
在测试阶段,需要尽可能的对测试用例进行自动化测试,能够大幅提升测试回归的效率,产品负责人可以快速的评估产品版本的质量。

5 p/ R) p0 @# N6 w5 F/ S

2 u2 ]0 @, n- X/ `
1.png

" Y; ~# t" Y: w8 C6 M
: F0 f, c# ~4 f4 a
预发/演练、上线阶段主要管理的是部署环境、组件实例管理、部署计划、交付物管理。
- J* x" [) d& ?: E: @; E0 L
- b/ w; i. n. W/ X- m  P3 |
DevOps 平台设计过程中需要支持多策略的发布,包括全新发布、蓝绿、灰度、金丝雀;应用可靠部署模式(集群、多主、主备等);
3 t4 ~6 q6 ^8 y5 U& ^6 U& K

& n, b+ `* ~! Y, Q& k) U
单元测试覆盖率、自动化测试比例、阶段Bug比例、Bug打回率、部署成功率是重点评估的度量指标;

' ]6 Y( ]: x/ |6 a( _* |" l0 H

: J6 c3 W- B+ u: a
大家在讲 DevOps 一定要做自动化,但是我们认为在做 DevOps 的时候,肯定不是全部的完全自动化没有人工参与的。给大家举个例子,我们做滚动升级的时候怎么实现的?

! h# }  @1 i4 f; N8 n* L- q) T$ D

( Z# E- A6 Z; q$ S2 S+ ?4 p
1.png
/ p/ X+ q& _3 J: @; d. i4 l

: F" f8 X$ X" T7 u) I
再基于步长的应用伸缩过程中,第一个步长绳索后,需要测试新增节点的可用性,在OK的情况下才继续做后续的伸缩并可以设定新的步长。/ I, q7 n/ n. z/ g: [# _+ ?. v
+ w2 S; Z$ u' ^, Z7 f

! u: V( b9 P' ^/ v/ ]% y
DevOps核心观点六:DevOps平台,并不是自动化一切,而是在可控中有选择的自动化

7 j6 c2 a  f% m$ U$ {
, j1 I$ `4 t( w/ I6 W3 F# g
总结一下,我们对 DevOps的认知:
1 s6 P+ m. K  J

! l( ]& _2 o- `6 |
  • DevOps是一条IT生产线,核心价值在于提升工程效率;

    " A+ Q% x# M0 I+ ]" J5 f

8 |! d& s9 G# }9 M; s7 f; z% s  j
  • 覆盖产品、项目领域
      l4 q4 W; N+ ]& e1 j

6 W  [# S0 y' g3 Z  u0 G
  • 体现出最佳实践
    0 u3 V- m! P/ S

. ]4 z% P0 N8 s6 W- U
( u. z! M; x; b/ ^$ b& C
  • 加强协作
    $ [) F, t& h. o1 M
$ }; B: C; z" \. Q3 u( X# P* o
  • 优化架构

    % }8 b( @& i% p% \  ]

5 Q; F2 P6 r$ i5 M  @+ S$ l  G
  • 可控范围的自动化
    * u5 c. _! H: G; N
! A4 {; e" x( r8 l8 ?
3、企业实施 DevOps 的建设难点
   
# }! A3 G, s' y8 s) n! q
接下来为大家从业务、方法论、技术三个维度分析实施DevOps的建设难点。
+ L' X% x. U7 Z: Q9 j4 G

6 o4 ]* u( u# }
1.png
4 a2 ]# n. b8 o" G4 _/ r
8 {& |0 G8 b1 ]. d
  • 业务:1 r$ I( j& y, Y5 l
    " |* V* O6 D( a/ e& V" L
, H. |8 Y; V& q; R4 a: I  v- F

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

7 T' G, G, W, R  m0 k) ]

/ W# X" p: f$ [. T+ n; T0 _- x
    2、关于 DevOps 的概念模型,平台的概念模型如图所示,划分为5大领域:产品域、组织机构与权限域,项目域、部署域、持续集成域,在实际DevOps平台落地过程中,可以从某个局部的域开始做交付。

0 T, ]2 P2 I' s1 r$ a1 F/ n# \

, ]5 p. k, T/ J3 V( R4 [5 k4 J. I5 e
1.png
  
: w7 R2 D. ?: C) y% D5 M" Q
3、在实施DevOps平台时,需要把企业的标准、规范固化和落地的平台,如果我们仅仅是把工具打通,带来的业务价值是非常低的。. U+ u- O' `- U3 I' w7 @
) ^6 u, I2 Y! p' ~8 \
# Q1 b$ [/ _" T; b
  • 方法论:

    $ d- h$ C' D3 s0 i% w2 B
4 }, _% @& @) N. C
    1、从方法论来看,首先建议大家从工程效率或者工程度量的角度来衡量;
! _1 m/ x8 o' J! F2 k, a

6 q; ?$ M# E) t. m! x
1.png
   
8 g3 t* l. H  V8 t& A
2、采用可迭代的MVP的方式交付产品,每次交付的都是完整可用的产品,方便快速对产品进行验证和反馈;
/ E; h" B6 E2 G
1.png
8 o. t) c6 q1 _! H6 v0 s4 q; r# O

1 d  y7 r/ V; [: T' K3 D0 g6 `+ `, |/ \
  • 技术
    ; D0 S6 P( r# B% N( p

+ ^6 I0 }) R/ K2 u# l1 x
    采用微服务的架构进行平台建设,按照功能的维度进行微服务拆分,每个微服务内部严格定义 API、SPI;API 是 DevOps 平台对外提供的接口,可以方便集成;SPI 是对外集成的接口抽象,未来方便更换不同的集成工具;

" G& e2 A* A8 _5 e8 u, x9 X- S

0 L1 B# {- n2 x! _
1.png
0 W$ R8 v3 N6 i4 x' t9 z
5 F3 C) _4 f9 P1 Y! V4 m' f& w

7 w. {9 V! @4 h% A7 i$ `& v
4、DevOps 平台关键设计

& D- @7 }* c. h5 ~8 J# A: p3 O
# {2 n: S) \" F% h- C
DevOps 平台完整功能如下:
1.png
5 \' k9 `: y, e6 u

( U. G& [# F0 Z# S9 q
整个 DevOps 归类了六大块能力,分为敏捷过程、持续交付、度量和优化三大能力,其中敏捷过程包括产品、项目;交付流水线包括构建、部署、持续交付。
  O- P4 @( r/ |' F/ w  q+ R! e8 S. S( j
* a3 t/ ^+ \6 ?2 _6 U+ q( G  b
关键设计一:支持多种应用架构
( c5 H7 u3 `6 T8 R

) e+ D' r+ Z) i9 v5 m  E
DevOps 平台能够支持多用应用架构,对上层的应用其实是透明的。
. X6 Q2 d# |1 [$ i& B1 _, }0 [8 d# M
* }+ F9 v% x5 v0 G9 s' Z; g4 P0 N: H; ~
1.png
% ]' A+ P. ]9 Y' B$ u4 {4 C

8 [! n3 p* d/ D
关键设计二:支持异构设施的多策略发布
1.png

* n% R) z; M- ?7 c9 [4 t  F/ r7 h7 }

( l& {$ E* j7 N) q: t, Q
设计阶段:将部署架构分为三层:部署装配、部署容器、部署组件。设计(Design),是在装配(Assembly)内对应用/系统的架构的描述;而应用/系统,是由含有多个组件(Component)的系统(Platform)组成的。, k" f# m/ ~3 j

/ A$ P0 g$ {& t# c' q: \) b. g
5 J" K7 v; F* J: V
部署转换:将部署装配和资源(包括物理机、虚拟机、容器)进行绑定并生成部署计划,按照对应的部署计划进行执行,可以将应用推送到不同的环境中;支持灰度发布、全量发布、金丝雀、蓝绿部署等;
: O8 R! D* m, M

7 N. D7 N9 [% V) z- _
组件运营:对产生的应用实例进行运营,支持启动、停止、重启、状态检查、应用伸缩能力;
2 ]0 f) O# P5 r) @2 g$ a* d9 a

5 X5 k& M1 E) y8 ^3 H
采用部署容器的设计,可以快速添加新的部署容器类型,下面给出了一个扩展支持移动应用的部署容器,可以快速的接入到 DevOps 平台中。
1.png
# ?! a6 C6 c$ B% }. d. @; b, R% e
! l" e8 M; _# g+ i: G1 L& d
关键设计三:将企业最佳实践固化到 DevOps 平台
# A' C- R2 S8 G% ^0 n: g
1 }  I2 [* Z4 Y& P
9 I0 z7 A4 J- _7 _9 y
需要总结梳理出固有的流程、规范和最佳实践,将其固化到 DevOps 平台中,可以将项目管理(日报、周报、会议)、实时沟通工具、各种模板、版本管理策略等最佳实践落地,保障所有的团队可以快速的掌握和使用这些技能。
, `; A: p0 w  O: p  H) ]1 k

7 p3 v* c4 C% b
1.png
  ^3 [# l5 S# @4 J7 l

' q2 T' Q8 `1 @- n' |

+ l, I4 f7 M2 O7 b
5、如何迈出DevOps第一步
9 c% a1 z# h' i$ `) E
5 m  b, t  h* H+ l9 A/ y1 h1 C
最后介绍一下我们是怎么在企业里面开始 DevOps 第一步的。
1.png

7 h# Q* H0 \/ f' ]
, z9 W/ s% S) Y
这里我给大家建议了三个方向:  a  T8 I# s: A* e3 U0 _

. M$ S( W+ q4 n/ v3 J. D; h
5 I8 h9 ?. A* G: Y+ z) v
第一,从统一的组织架构、认证、SSO。企业里面有这么多IT系统,先做简单的打通,否则后面做 DevOps 是非常困难的;

$ `. G& P2 T9 b5 l! d

& Y1 \  w9 L# k* L8 y7 f
第二,从集成和自动化部署开始,这是最容易实现,也是最容易让你的业务部门和老板感知到DevOps价值的入口;

, q. r  g5 h+ W/ k4 H

! P% {* Z, R) A. b9 T- ~. {7 s1 J
第三,如果真正系统化地做 DevOps,我们需要把整个企业自身的研发过程和运维过程梳理出来,然后固化;

% D) y2 Q8 _2 p3 q" Z
# ^% ^; ^8 [- o" k" K3 U
0 x. p, a' G, Q9 H1 F3 ~7 d0 C
6、总结
1.png

- Y/ ?0 [# A, e' P2 b
6 p% X  m( l! ]& X0 G. T
最后总结一下,我们认为企业里面做 DevOps,本质上就是做企业的IT生产线,最终是实现整个企业级的数字化生产线。目前大家都在讲企业的数字化转型,相信通过 DevOps 可以先让IT部门进行数字化转型,最终实现企业的大规模敏捷。
5 q7 h1 \" u9 a( ^
% _- {/ z" V  O
原创:刘相  普元 产品部副总经理、SOA 主任架构师,计算机应用技术硕士
十年IT行业经验,专注于企业软件平台,擅长分布式计算、SOA、BPM、DevOps、企业架构设计等领域。先后主导公司微服务应用开发平台、BPM 流程平台、云 PAAS 平台、DevOps 平台等系列产品的架构和设计工作。著有国内首本解析 SpringBatch 的中文原创图书《SpringBatch 批处理框架》
0 b. ]0 Y7 @( f5 p8 D5 L' j7 s( Y
8 n' o4 y! U3 T( m: O4 e4 L
* b5 Q3 p) J" V
1.png
1.png

本版积分规则

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

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

Baidu

GMT+8, 2019-2-24 14:00 , Processed in 0.232443 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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