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

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

 找回密码
 点击获取邀请码 - 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑 ! @' H2 [- H) ^0 H1 h
' F- A! b% _- T6 y

: [1 B  {, e9 R
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
% P: k) A( A1 o% [
) ]4 c4 l5 b! y, g# r
2 }; v( k( F: e. @4 t
挑战一:敏捷文化
* D1 {" X7 U- \7 t  O

7 |8 A% C! [! ~$ B1 m# c( o! f1 a  i+ s
1、切换敏捷之前的过渡区

# s( t0 Y* R* M7 t# _3 P# {
) a. c" e# c+ d5 R& E1 e
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

2 T) S6 C* H& w6 f" l5 E
2 Y6 E. p8 Q3 ^- Y
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……

$ O% @: ^3 z) F/ D, B. L. q
( q) L# U4 ?0 f" B# t7 v
开发结束啦,已经提测了,你问问测试吧……
; k% r0 ^- Z* A) q: b; r& R+ P# e
" c" a; [5 V( P! {) c
问问测试吧,什么时候可以发布仿真环境……

  f  ^  f! k! y, M7 J0 s

8 ?2 S& T  A0 R- E% r% e3 x$ x& W+ G
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……
0 A& d9 I5 O# ?5 ~6 a8 d

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

8 k, R" Q( e0 K3 J5 b/ J
* {1 s: O  N4 m5 i% ^) q
先用迭代让业务快起来,敏不敏捷不着急
8 R: J6 ?1 L& Q1 K( M2 r
# A1 S( G/ B+ Q" p, a" c, g
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
8 ]( l, Z5 ]9 D1 [6 ^

) i" ?) k7 v7 G4 {9 N
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
(图:正确理解迭代的方式)
2 }6 h7 p0 F4 n4 y' P# j
& I# ?1 b! p8 }4 T; d1 A
% G$ h5 g& U+ m# g. Q
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?
8 u  E. H* |4 X% W
(图:瀑布与迭代的区别)% I0 b4 {! q4 w$ ~/ A  [% r
: W, t9 U4 B/ ~9 W9 O! ?1 ]- w* L
(图:瀑布的特点)

+ ]6 i$ w% c' ?! ]
(图:迭代的特点)

: K# j+ p5 Z5 X( Q. G& y7 l9 l
(图:迭代与敏捷之间的区别)
% E: z  r% D, Y/ H/ D( t: Z
% p3 x5 `3 s3 r3 i

4 Z! Q# M+ c2 ~$ w, @! x
2、大家都缺乏敏捷文化
( ], ^. D. S( B( r% B( ?& `* L7 |

+ S) Q8 d( M# [& ]2 n
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。

( `5 _- T9 _, N5 p' j

# B7 E: K# G, S
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。
: |' K9 p( T- H4 o/ w  T
(图文:跨职能产品化的组织结构)
: _* q7 K5 k. u6 X1 K: a
& V" O0 B3 |- e! ^, M6 I. q9 M
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

- i$ `  }7 q. Y$ L' y

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

# F) X0 O% C0 r% z9 I" {
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
# O$ s" t3 y. O- {

0 S. a. Q; G/ f

& U4 F, a: E; C& Z" f% z) j
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;

: ^' Q/ _7 ]2 }: z
(图:网络游戏 - 混世魔王形象照)

* x. X' I+ j4 L) m2 M

7 {0 L2 L" [5 T7 N' B
4 D. a/ J5 |8 D
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
  A1 {3 a7 Z1 q' D- z
4 t: z4 a; ~8 W* M. g. ~
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

$ h7 i" c4 w5 Y# \5 ~& K
% v8 [( a2 q2 p0 g! N0 d, |
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。

5 R, C. \/ W. L% r! G
2 @9 u! p; H- a6 R0 p, A
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

3 e* m* a; A* T
(图:敏捷,乃至DevOps所需要的文化)
/ X( e$ B' f: j+ l8 M& t
  F0 J# V( Q3 h3 _# z
& ?% k) ]/ ]0 ^% p& _: b1 |, w/ V
挑战二:配置文件的困惑
- W% H+ \$ Q/ Q$ {  ]! ~

7 J1 }$ p* L) R. T. M
1、没有DevOps之前,配置文件是怎么玩的呢?
( G8 m- K* u7 x6 c8 X; m# k' D
6 m3 C7 ^( j" n1 o
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
5 c7 s! O9 B7 Q4 ]) j& {1 h
9 k( Q/ Q, B" k, G8 I) }
配置文件位于classpath下

' S+ E  ]- N. O+ _6 e

4 j: F# [4 J. p6 Q. Z% R
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
2 i$ z7 j% j( ~: _9 y2 W$ u+ G4 X

/ o1 c* @) h! t  |# i) A) }5 j

" K9 U4 z, E8 C' F  @  A
. d# @8 M9 G2 n* ?/ |+ F) D4 [
如果有多个配置文件加载,则:

: }) D/ J  O8 `

- _. ]' \! s& B& |5 q8 o: {: }$ r; D
配置文件位于外部目录
, z- X8 ?- d7 G* n; ~
3 O" N& [6 y- P! R: F

5 w: j* I3 s1 d8 ?  F
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:

* j  a7 Z" w# `) j

- S$ j/ i+ Y; f$ s: D! p; ~5 n
2 q( [" P* s* _: R, N$ i- L
- _' e7 B& W  S! f- J! E& c6 e
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。
" S9 j1 o! O/ [9 B9 Y) |) G

. w: ^! I1 u$ x* t/ ]
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:8 |, H/ r+ ^, O1 b. b0 v2 e

3 z0 }( H% K% v; v3 p' u
8 n3 b  C, I$ u7 b
  • …………
    # a( U: T- e& T) w! D- P
+ U) o, V# Q4 W1 ~

" p3 R6 `: X' ^" u, \
  • 配置文件的版本如何与程序版本对应?

    9 Z0 K! y+ n( H- s
" O# C, Y' m$ c+ o3 K" a4 A
  • 配置文件的管理如何更加简便?

    1 O$ Y5 T( N5 l8 a
7 B: H7 S7 N4 @# m0 x  ?. C

2 e/ j% n9 o7 {6 o/ w8 ]
  • 配置文件的修改该有谁来操作?
    % u" q+ Z. E- D

. g7 L" {, [$ v" M
- }  ?+ L$ Q" f8 ~: n. c
  • 配置文件的更新是否可以不影响正常服务?

    - g$ g4 g9 \' h. l) Z: }
% i( r; u: m  T
  • …………

    3 \. W' o# |; w3 x$ y

, ^" e7 Q; S- G
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。

: E. O7 ^# a) Y
2 S( I1 v. V3 G" |& L' ?  [
撸起袖子,不要怂,咱们搞个配置中心吧。

- M( Z2 n6 V' r, q- ^  d5 r2 T
* [% Q: B% O0 \% \# z! t
2、有了DevOps之后,配置文件又是怎么玩的呢?
& E: K" v' j9 U$ N$ v
4 Y/ g8 M; V6 h$ h- E
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
6 `' U/ W$ l' f

, i1 J' a9 y5 g. z+ z0 a( v, I9 g
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
$ j% g" o- |! W9 g  N) J) v( x
2 I% m: D+ I! M3 I) k4 o2 [
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。
6 G7 M& Q% q  y) d" v
' p$ _9 D# h, u# ?  B# Y3 ~
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
" q- j& w$ y! S. I6 q+ L) q

, z! m3 T3 X2 m4 z- f$ V% V' f
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;1 u: F% w8 B9 w) g/ G: H+ r
7 }. T- _9 N/ M/ q1 l
2.操作风险:配置修改随意,无操作痕迹,易出错;3 F  `- m3 K9 b$ l6 L  A+ V

( o3 l( B! Z- O8 `9 [8 J; F
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
7 a  U4 ?% c# q! {# ]8 @; U: R+ s6 [  f- c
, ~! [7 {5 c0 q' t, U0 }8 u5 y' E

" u- d" X7 |# W8 m
图:配置中心在DevOps快速交付通道中
. z( ~+ n( W9 \, z
8 S2 T; F( C6 ~( I! ]; ?
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

  h+ Y: e; A1 o" }; d

; f1 y& C2 v7 E" ^2 o1 N/ N
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
4 W& k: R0 I* C2 }# D- ^
+ A9 g" g% F! ^1 K1 [
无法满足我要求的,我不接。
! M4 _6 u! [6 u+ Z% P, x4 k
+ {/ H8 k$ y! B* r! M5 L
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。
1 B& n8 @& e& n; |3 n0 U( |

* H; s; @$ q# x9 {8 t; s* B
三种适配器

  R6 W& m- w7 H( i

3 {& h! E  W+ f! S9 H$ r. K
图:适配器Trade,满足原有使用Properites的诸侯们
  |8 u+ _1 v: ?; f' H" f
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

- J& U1 A* h; y8 g! g
图4:适配器Ccms,满足使用Key/Value的诸侯们

' k4 d; s2 {1 E3 x' p
! o$ f% G! V/ ?2 O6 c! m" y4 H- C% t- f6 ?. }1 s
两种推进器
. u; R3 Z) m: y, ], k3 }

# Z1 |: O; w! S. G* d9 Y# D
图:希望采用 “文件被动加载” 的诸侯们

; V; N8 U( Z6 _- X. ?8 y
图:希望采用 “Key/Value实时推送” 的诸侯们
7 {7 I7 h' {% m% [1 B

. f7 p& E6 R0 m( N4 e5 L# s
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。
4 r) l  b+ j3 h: `" I# ]
$ f5 h% z$ S8 x4 N
有了配置中心,诸侯们的确享受到了福利:

" B, U7 P4 V/ H
' Y6 X  {. P) z$ m6 T
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
4 i$ t+ ]3 r) |3 Q  k

  L) o) ?0 R- }% x2、配置控制台提供鉴权、操作日志等服务;/ f  X$ [- A* J  S

/ V3 V5 [& ?6 n/ e# m' ^) f, y# @" |. _
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
3 E; F9 D( O6 |0 N( k4 Y' O% C* W: w9 p# X, n6 K1 A' S' n; y

) Z; N0 j( u8 x. W4、配置发布后,实时通知应用端,无须重启即可使用;
  i# M: R* g' N: r1 Q
$ u( ?; f& X, l0 O7 Z- v3 u+ T+ ]' W+ x
5、配置版本支持一键回滚;0 y* m! T% e6 v; l8 y- w

4 W6 W9 U( m  V  ?' D/ w
9 @& _; L% |: N$ w6、配置控制台实现了整体复制、导出、批量修改等功能;/ W# \' r2 [8 n* B- I- F
" w# ?* x. E" B: H2 q* @
2 l6 Y4 ^3 e# D" A3 I- y

6 c1 V4 g- E6 K! r
3、小结

" ]9 k' n$ d" ]9 b: M- A1 t, ]) S* Z

5 Y  z% r$ Q$ i
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
2 O8 K6 k: [+ w9 N. S
; G. z$ d& ^- ?- V
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

0 X. _# e8 U/ |+ J6 t6 M+ F

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?点击获取邀请码 - 立即注册

x

本版积分规则

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

QQ|小黑屋|手机版|Archiver|ITIL先锋论坛五万运维人社区 ( 粤ICP备17056641号|网站地图

Baidu

GMT+8, 2018-9-21 01:31 , Processed in 0.297740 second(s), 36 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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