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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑 " x5 Q6 `' V* X0 X: [
6 {6 j( J) F. C. t+ r

% f: R5 b3 V' V. x  A: H
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

+ Q" G1 P5 O" g+ T! t1 m
0 i' A" G4 ]$ G" Y4 V' G% p/ J
/ x8 A7 D9 \% }+ h' Q
挑战一:敏捷文化

4 N; v' B" t5 [  `" H% W

2 B, N- O& d' m" [; ?
1、切换敏捷之前的过渡区

: `+ g: z0 B  d* n8 k
) f3 ^' f; x; r( p3 p/ F5 h9 Z0 [
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?
4 n/ ?/ V) Y3 m- d5 N+ m" u7 A7 C( a

$ x1 v  v* S4 U+ r
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……

: \; m# k6 P3 Q
# V2 P$ @) I' V6 K6 d8 \
开发结束啦,已经提测了,你问问测试吧……

4 ~6 ?3 `- S9 L  b9 \  Y/ a
1 g( ]& p! z9 @- Y& ^1 @$ N
问问测试吧,什么时候可以发布仿真环境……

! s7 W4 S  X& ]( a, W, X- K

/ ?  L/ x. y" w$ r& _( p$ |# h
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……
! N% F' M! w3 U& ]0 c

1 X! @1 D7 ]5 J7 {( G
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)

: }9 }/ R3 W# [' u; q9 r! Z8 d3 H3 V0 y, j
先用迭代让业务快起来,敏不敏捷不着急
/ L2 o- b7 e! V: }
0 F5 y$ C' q9 S+ Q9 S; F* ~$ U
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。

5 p' K! A. h' t. d: }0 c( _* D

2 q( e4 v7 h/ v7 Y
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)
6 r5 ~# {+ H& ?) u( M  c
) _+ N. f4 d6 S

0 C# v  i$ V6 h+ o5 Q/ @" e
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

; k, K. l, I/ }; K
1.png
(图:瀑布与迭代的区别)
6 {1 d8 }3 n$ e4 r3 d/ H3 t

$ T' O% H0 i6 _# C7 P: d5 d
1.png
(图:瀑布的特点)
! E4 a% a# g8 A# X$ s+ S; Z
1.png
(图:迭代的特点)
9 A) w% p% D3 R, u
1.png
(图:迭代与敏捷之间的区别)
; v, _, E/ |( i- o

1 N- |- c$ Y* z0 x+ q) y

# k" ~- e3 @2 k/ V) B  r5 P0 g
2、大家都缺乏敏捷文化

" n8 X6 M( q7 S# E# `+ Q  t2 ]
6 B6 E) I6 p! M7 a$ E$ n) E
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。
- [7 ^8 E; a7 E2 `( O
5 G% D* L' ^( L( x3 f3 h9 h
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

  c! v( Z  B5 g2 ^6 V
1.png
(图文:跨职能产品化的组织结构)
& E( B# x9 ~2 }9 Y( G
* K5 x* k, [: Z7 z; s
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。
* T; [& m, u8 S0 X% U! k
1 c) T0 F) R( P8 e& b  a2 J' @+ U4 k) c
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。

7 S6 q. I  D( r- E, y1 F

9 L" k, o5 b* G3 C  l9 [4 z
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
4 _1 h) u% a& j

% |1 i2 v. o$ {/ n7 g
7 x$ k! d' C( {
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
( x/ b; `$ h  ^# w
1.png
(图:网络游戏 - 混世魔王形象照)

9 X( E# H, S5 y$ E. O& T; q. e
7 n) ^' u% w7 M3 \8 A

6 \# x: A6 p: J% J- n/ |
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);

- U6 R5 [' N$ Q$ B1 c  G  W& x& C
( \2 E' i( \0 [0 u9 b+ C$ P
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

) `* g7 x" x( {$ y, d! ~9 H( v2 F6 k
* v6 F( ?) C& n+ G$ Q( k# q
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
, H6 q6 w& Y5 \; N6 @' Y
- ?8 {4 z2 {0 V" n
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

, C$ j3 M1 u6 T3 c6 E2 U
1.png
(图:敏捷,乃至DevOps所需要的文化)

+ M- q. f: C$ d" v2 Z0 X7 q
) o" |3 p+ _7 n! o; e* C
- s+ N" [9 \/ d- T* N5 U
挑战二:配置文件的困惑

% M9 d: I' d5 J5 X; [
  G* m/ G2 `( `# S) _' F+ O: P9 g
1、没有DevOps之前,配置文件是怎么玩的呢?

5 b! a/ L* @* Y& E
" u1 h* o& h  e) A4 ^; m5 i- ]8 I
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:

5 @1 j% h7 \1 x7 t; z
! B+ [7 X# {, C8 w( K  C3 q' O
配置文件位于classpath下
3 W4 q2 K& |: Y  ?
1 w' Y# ]9 m5 }  V: p
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:

) }$ I' U9 ], I  w$ U/ \" \
1.png

2 F8 W3 P6 Z8 z9 U+ s$ R

. e, w, [+ l( f/ C- e/ p

: V+ A7 L) A0 O  a) N$ Q2 v4 e* F
如果有多个配置文件加载,则:

  b4 N. g) [7 t% e
1.png

; e( ~4 Q! j4 Y* w( W  r
配置文件位于外部目录

6 r! C3 ~7 ?! b: Z5 f* g6 {/ v: W

. P+ m* ~8 F2 X; Z# L
% b/ ]  O& ~+ b% [
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
) d6 u( |2 J9 i6 z
1.png
& @0 l" N& I% G& N  p: {

# E1 y. r6 f- _3 |

4 ]/ O" h$ h  h" |$ k
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

# ^5 o. z4 H; B7 g2 K6 K) U7 n- n

9 P5 j" J& C6 L6 L7 p) v: U
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
+ f- [% d/ u& S5 q$ T2 d0 V& E  @

$ A1 ?1 p( n* w* D
& E3 q# i) d. g/ M8 V: |) L" P
  • …………

    & D4 F( p* ?' [, P$ G; X. g

! g4 O0 `6 y$ d' W! }$ {0 m
' {% H9 j6 a- T& O; E- p, B9 z; R% U
  • 配置文件的版本如何与程序版本对应?

    3 l( F& A& ?( V+ v

3 s1 [' R& F- R+ D! k; h
  • 配置文件的管理如何更加简便?

    + X( @3 h" K+ }& W7 w' I% E( F
; U& L1 E! ^+ E' w

% ^( Z$ U* p( Q
  • 配置文件的修改该有谁来操作?

    ; \( s9 l: L: p
8 ~, r2 H& c& j" V) {0 D

1 [# [% P% L4 e8 v8 B0 L/ [( S6 i
  • 配置文件的更新是否可以不影响正常服务?

    0 Z9 p. K1 l4 U

. L9 }- `- Q- u& G2 U# ^
  • …………

    5 I& S, Q9 V% l/ E: Q
* g) t) W2 h6 t* o
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。

! f5 ]( c. u) U( I1 o! v

7 L* n2 T8 W+ i+ s. {$ a6 q2 k* g
撸起袖子,不要怂,咱们搞个配置中心吧。

/ I! j& p+ m  w

: a$ B+ ^2 G1 N3 a# M
2、有了DevOps之后,配置文件又是怎么玩的呢?
5 i8 x$ p/ x/ R* `/ B3 G
: Q; o* Y( e; y; l  k/ a" G
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
/ {6 c% j; P% t, w$ h0 f
- y  K+ S/ V% K2 \" q( F8 Q
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
/ z/ j& d" T. }8 @! l3 x  M+ Z( _

5 ~0 E& p% P# m% s' v
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

. _; ~, j$ s! M- M6 t9 [; z. q3 k( R/ n& j
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
# @' s# }* Q& r0 V( O
; w6 ]4 r# q  t' K* v1 i" e- h
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
* w3 A8 U0 G8 N5 S
3 U0 @# z, t& s* d
2.操作风险:配置修改随意,无操作痕迹,易出错;
9 P8 m8 O, t3 r# b/ k
# W7 ^* v2 t9 M
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?; f  K: v- h1 A) `. V" D2 `

9 c* b1 k* u' P. Q
/ k% P; [, b  z! n9 M
$ D$ A. e* {% f2 B4 ^7 Y! F
1.png
图:配置中心在DevOps快速交付通道中

8 R: B+ T0 R8 F/ Q% O7 O8 r

. E) V$ F1 G/ `# Q4 R: r1 a2 K
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。
$ e$ P# f0 \, z3 ~2 V
! y3 S. h' q2 M: E9 A
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
# d1 o( j$ }! K2 ~6 t$ N0 e

- P6 [7 o9 V7 T3 F; ^
无法满足我要求的,我不接。

* N9 V  `. a( E, b& N" K* {9 g

: L, _% q9 z1 @: M
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

  X3 M: b  f1 |& O$ J& U! y9 ]7 X' x+ f! A2 ]. ]9 P$ a; \: Z, Y
三种适配器

0 Y! ?6 t4 X' }- d/ E) a$ R# g

( l/ Z' B9 b% P; k& {* l5 c
1.png
图:适配器Trade,满足原有使用Properites的诸侯们
$ g2 ~7 e4 N$ S4 D2 P) T
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们
* ^$ L4 E* U( `4 o( G! e1 ?$ V
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们

2 ]7 P& K$ u4 G* T3 S3 c- e) S' E* P+ n6 F) [8 A
) c) h1 g( P, K3 [
两种推进器

4 A! j+ y; n4 g/ ]4 W# M% i

) X  A, K9 ^8 ^# f
1.png
图:希望采用 “文件被动加载” 的诸侯们

# U2 ~+ I1 X6 m6 X; h
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们
5 I$ Y- N& u3 d/ J+ p" B7 v2 p

4 m1 j: w. p8 Z( ~
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

' w) Q( U! P1 x' z, y
2 _9 i  f( A8 L( S9 y; X
有了配置中心,诸侯们的确享受到了福利:
; \+ i6 w2 u3 G( z, y9 R8 ~& I' e; W
) n, e2 R# F3 [+ r8 G
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
$ j6 _/ l, @4 _" ^, _* Z
& `  I7 q- w  ?+ Z! p
2、配置控制台提供鉴权、操作日志等服务;
9 B7 U: t" {! ^" U3 F' `+ E8 W
+ E6 y1 j6 Z" ]7 \9 v2 R& |. Q- b; e7 C) ?2 K
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
7 R. w' I% M0 x# p- s! k
; w' i2 E( x; Z6 W" L- U# E9 ?7 g9 [
4、配置发布后,实时通知应用端,无须重启即可使用;, g8 Y4 w9 o* q* W
9 q6 W2 K: ^9 j: m* `

' \1 Y4 a% t" r& T5、配置版本支持一键回滚;% c* i. r+ k; o8 h# E0 ?

( d$ V$ T- h% A* P
3 q( P" a( A& O0 y, B6、配置控制台实现了整体复制、导出、批量修改等功能;
4 q2 S5 i, k! h( I8 ~. H2 a

* E" n8 q/ E6 }: x# I

% b' h& M* u: P8 u6 }
, U  E1 M1 [+ q/ q8 q9 x1 x3 I: k
3、小结
) n+ u0 l7 g5 s% f" s
7 j# B+ q# u: x
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
9 K/ J0 V$ t' }( ~+ ?
6 U- A- @. v' r& t9 B) m' [! \% r
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者
% @2 Q' i! P4 V

本版积分规则

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

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

Baidu

GMT+8, 2019-5-24 14:12 , Processed in 0.244292 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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