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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

DevOps实施:敏捷文化与配置文件的困惑

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑   Q3 W* j9 e8 X. D& f
: O6 [! ]4 \5 E7 L+ ?$ W- y
4 r6 f7 H% {. n( e3 x- V' y1 j
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

1 |$ f1 r5 R: T0 I) y2 e

9 e: s8 |& B9 d! C0 g

3 O# m; i6 h0 y
挑战一:敏捷文化
9 Y/ @+ X8 x( D* B4 J) X* J  k
, H) L6 i/ P- t- B$ V. i4 t: I
1、切换敏捷之前的过渡区

! c! O6 I# ?% D" K! v
9 U  y8 M; k' t6 r: b
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

+ Q: @: F0 F' X) Q, C
+ }: b% i4 w& v8 T3 K
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……

  a7 E. x$ g. }3 D1 [. Z4 m) \2 A) }
- U# m+ o/ D3 c9 L5 n( B+ B7 u1 W  e
开发结束啦,已经提测了,你问问测试吧……

) Y: a) u; j: L* d7 r: x

+ @: V) i9 S; R8 {
问问测试吧,什么时候可以发布仿真环境……

1 r' N& M) D* g# t3 ]

! }5 [& m4 k" `/ ?
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……
/ |  s/ j& ?1 Y+ x* T  E# E
3 H- z7 i' n7 w' Q! H1 {/ @
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)
4 k+ |8 N4 J) }$ q( W8 a% \2 Q

( J  {" Y2 |1 ^) ^2 E' @
先用迭代让业务快起来,敏不敏捷不着急
* d/ N9 h- _9 K( F8 {) l& K, g

1 a) a2 h( B; f; y4 H! B1 |" |
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
8 a5 b4 H7 H7 l7 Z; E2 w
# R9 I# P" g5 ]( ~- z3 J0 B% v
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)
- @9 C( k" ^+ W# a% ?! u$ w

$ q3 v) }; G7 \) F8 Q
6 Q4 ^+ @" x2 M& @1 g
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?
6 b; i8 H: K, b3 }
1.png
(图:瀑布与迭代的区别)
0 J/ W% z4 H: b: [5 [/ W

, o; }4 X5 e6 K
1.png
(图:瀑布的特点)

% K0 {. {6 O7 R+ h
1.png
(图:迭代的特点)

( _( O$ R6 x' K8 t
1.png
(图:迭代与敏捷之间的区别)
  y# w; K; I0 B( ~" e3 c. I  k

/ r7 Y. A! i# \- M+ I, m! e

0 s0 d! Y7 V9 n( U1 Q. J! `
2、大家都缺乏敏捷文化
$ ^3 D4 S- ]7 I1 `3 \) q
8 f, f5 o2 U) N( X! a( r% K
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。

1 z  @1 i- |4 a# |
5 L5 G, @8 F6 M' N! @5 Z( @
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

5 ?/ u4 E6 X# g
1.png
(图文:跨职能产品化的组织结构)

1 A5 ~) F8 l: [% u/ n

% I; C& Y( j/ ^$ c" U" W
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

' P) X  F* {7 a. q+ H

$ r$ M& _2 Q- _( v- T2 A/ E
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。

1 z6 ]3 d" D: c  j) q; F

) P4 U6 m0 N3 z/ q- o% @! W9 q8 X
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
$ z% d) l2 G0 U7 W. r6 D8 {0 i' k
5 O5 H& Y* [$ k! |2 n* B5 X5 P
0 t2 x, |( e6 Y$ t+ \
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;

# ?+ R' D- S& r* U, Z/ L4 ?/ {; v
1.png
(图:网络游戏 - 混世魔王形象照)

6 r; j$ q9 h* x
# C, P/ C  r0 ^

& m5 h  z9 `/ _1 U; ?! r
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);

6 y6 S, M; R% S* V3 X

" a4 k( |7 D6 p
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

( x0 Q7 Y, M, p* q* N" h& b9 d

. S! c5 |8 F( F6 m$ X9 ?8 q9 q8 g
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
4 C6 X: |- S" A, T' ?$ s& [  o
, J$ O  B" Q7 c! ]
所谓敏捷文化是个啥?抄袭一张图吧,简单点:
- U7 E3 A! Y4 ^# j1 f- |+ B& v  o
1.png
(图:敏捷,乃至DevOps所需要的文化)
1 R' [2 l7 Y! `7 M, U
. O( n# w2 ~' y3 T( N) S
  f9 e" Z; K, m( C% {
挑战二:配置文件的困惑

( S: i1 d1 A) O8 O! u- y
1 |$ @5 I( Q, e: X/ h; P5 A
1、没有DevOps之前,配置文件是怎么玩的呢?
. k1 A- \) V7 m7 O/ N; ]+ b& A

: }! a, {; Q) d7 `% c8 A
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:

$ O' [4 U; E! s! u) {& y
/ r8 [8 {2 Q6 _
配置文件位于classpath下
( k3 s: w/ |" l

& N/ c& @8 `  i, R7 n9 ~2 B
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
, b% Z, E+ J8 [% E
1.png

) E: U3 _/ F9 C: c
4 f' r' P6 k! W$ G5 d
3 v# U3 D4 {: v" ~
如果有多个配置文件加载,则:
  x+ z+ @; h- t7 U$ v- s8 K
1.png
; N, f* y$ H+ }; j0 B1 X* x1 X
配置文件位于外部目录
5 @) f7 I+ d% m6 v  `
2 U& M. q& g$ j4 Y) W$ u# J  W

' [8 S( d. f3 y/ Z! d& z
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:

% i; r' W( l# w( T5 x2 c
1.png

' \0 d" _. ]  v1 h; G* A
5 }! A7 ?5 s  q" V  N: v

2 p9 Q; w( A8 i6 x5 V- {$ ^
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

4 x2 N6 V+ @: f- f/ i' r. ]$ n4 f* Y

1 B7 D4 m3 T$ Q$ b
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
. D# e: i/ A& M0 W$ C% d! j
8 t- X! f0 s, I& c) \' A4 u  w
* u" V* I4 w1 S4 c4 h& g: R. S2 k% p
  • …………

    # k1 @9 T8 f8 P
, B* _& F: `1 y* |9 P: K
. G3 s, c* g) |8 k3 U
  • 配置文件的版本如何与程序版本对应?

    / n/ M" ?- ~! ^: k% w  v

! W4 U  L" i1 C
  • 配置文件的管理如何更加简便?

    ) B- J/ V4 {& @) U
/ `- N4 |  M$ k5 c: B
" @3 V/ S+ O) d% Z8 o
  • 配置文件的修改该有谁来操作?
    $ r0 K* K6 A0 T& y& C# f

0 m0 A" ~7 U2 F0 k& H+ A" D7 V
: H6 p5 w4 ~) P8 w. `
  • 配置文件的更新是否可以不影响正常服务?

    ! M- y4 C$ S+ c! J
' q8 C$ }0 C! n( M  o+ \
  • …………
    / V3 J4 P9 I" N" K" w; g: O7 P
1 g" U0 H' f$ Y# ~+ u3 a
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
9 P1 A5 B# \6 @* t2 [! o5 w

, B3 g. E" I! {4 \8 K
撸起袖子,不要怂,咱们搞个配置中心吧。

  H0 s7 [2 \" P( g8 @1 W# ]1 f2 S& s
0 E5 g( O) _; q. m, W& l
2、有了DevOps之后,配置文件又是怎么玩的呢?
) B4 W: d) `0 m! V7 o

; g9 D: N3 a5 Y8 c  @8 r0 F9 h
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。

5 R! p* x9 M  S8 G

7 [& U9 r* u/ B
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
* l9 L9 c7 f3 g; i- K
; ?0 ^6 O# g$ O; r7 F/ x
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。
. @, S! L. i7 `- z1 K( G3 L8 g7 k) L4 @/ c
* K. B$ Q+ y" S
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
# g# j- H; R0 E$ U$ G9 ?) B

) ]9 \9 ~% W) ~: V& f4 K' @3 ?  G
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
& Y' ~! Q& S" N! f7 h% ~+ e
! a" E4 f2 Y5 |5 Q! q2 y$ w
2.操作风险:配置修改随意,无操作痕迹,易出错;* F, B; ~& c" |: f8 i) U3 l( [

, ?/ I8 G# b4 C2 J# ~- K0 M1 v
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
- t# S0 _' h' y0 D0 _6 C/ q5 D3 Q7 V6 z' c" M+ s! Z

+ q- W, I4 c- `
( k! H. g  v+ k6 [, k. Q
1.png
图:配置中心在DevOps快速交付通道中
. ?/ @$ C, {3 y
2 O5 \& i6 N: Q# `  ?
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

; O! P8 h5 h) H( j5 X8 E

0 ?- g) O: U& }' b; P/ a) o- P
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
1 Q( }+ a" S" f& n
3 v5 {: s6 ]- b7 ^
无法满足我要求的,我不接。

* h8 Z$ ?& h: r: @4 O

6 z& l' w$ L5 E! H4 f$ ]3 n
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

, q$ j, `7 |0 a7 i/ T( v0 U* Z3 a- u& i- y- j+ {
三种适配器

7 @, X5 H9 M+ R8 j" F. v
$ f: V; }  i" b/ e2 i- H
1.png
图:适配器Trade,满足原有使用Properites的诸侯们

4 o. V2 D& C5 v: R
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们
' `8 z  N' ~6 Z; H1 }: G
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们

* ?) V9 |6 |  |; M: Q
8 J' p# d3 d0 ]$ Z2 R* [; ?' ]3 Q; q) k5 f: U
两种推进器

# f; A+ x4 S+ G3 i) r) n

; h2 r, d5 `1 n: E6 f
1.png
图:希望采用 “文件被动加载” 的诸侯们

* v: q) s; z6 b( z2 S% e1 f0 T; P% Y
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们
5 r- k1 U, Y( m+ M0 }5 S5 J8 M

3 m! v$ Z+ l: x  V7 |$ E3 v3 r0 }  s
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。
, _; t% g6 ?7 V; _$ c& g

3 s' ^2 J1 H8 h" S
有了配置中心,诸侯们的确享受到了福利:

+ y; b) N+ w. r) p+ l$ H, B! i
* {# e( L9 w  d7 a7 a
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
1 O9 _0 ^% J7 c, |! f; U
( {5 N# L1 \5 q2 \- A
2、配置控制台提供鉴权、操作日志等服务;1 V! s4 F  P8 L7 P  Q

. d8 e5 u; t( Z+ a% ?& ^4 W4 R  o1 U! D+ V$ U, R# K* @; R
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
; Z, q. ~/ c% g5 @; A2 c' M2 @1 M5 L& Z4 M* `! z8 U/ X/ }
* q# l1 y4 e$ D7 w, k. C) j' A
4、配置发布后,实时通知应用端,无须重启即可使用;$ z' O9 G* [6 A3 w: d# X& _; f9 I
$ z) z+ c8 Y, D/ |3 ]( z$ E6 I

! v! q. I& r, `) N3 W* M5、配置版本支持一键回滚;( U- V6 s( H  `0 n! [; `. _
/ F, O- G$ t) D3 m6 O# c

! |7 i+ G% @' g/ D6、配置控制台实现了整体复制、导出、批量修改等功能;
- ^9 p$ u7 H! ^5 o) _; X% v1 N
# O* I9 G1 I; b" z, C; G7 V
! M! s; n% s1 F& c, X
( ~1 p% \3 m) `3 V4 y+ n
3、小结
1 ?, `3 E& f; {6 z6 O$ {, A
/ t2 c: i5 |8 g
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
7 I( o  I- Y; V1 }/ J5 Z4 S
7 x; q& O: M7 A) b8 C! G
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者
- K3 \# F. w! \% E' Y9 |/ U

本版积分规则

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

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

Baidu

GMT+8, 2018-11-14 13:35 , Processed in 0.243021 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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