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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑 & x( `) |+ O1 y7 P  L1 @

) t+ x2 Y: ?& m

: S0 _" `$ [) O2 X
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
/ F+ z) p) w0 {; F# M
# D% V, H- F7 l* K9 m

) L# I. _3 [) M/ t4 Z  m2 H. t0 q2 j" ?
挑战一:敏捷文化

0 D( ^3 W# ~, p: ^* d. A$ E
9 E  C/ |% c- \) ?7 A& W2 g: `' I
1、切换敏捷之前的过渡区
3 e% a% D: R1 o/ g

5 v. U! }$ g8 {
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

9 v* q# X# p/ ~8 O) J% p
3 C; {8 c& H8 p- N8 E; b
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……
' ?& j: h0 q% Y" R8 N$ s8 d
$ p' [" z! B! H5 B
开发结束啦,已经提测了,你问问测试吧……

' ?7 K  x' U5 z6 q
: s) N& P9 @. i0 a. e! o4 `
问问测试吧,什么时候可以发布仿真环境……

5 @& i- N- M- p9 C: ]) m
  X  u- [7 Z0 v0 _. [
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……

, E: ^( y3 `+ {! d9 h

* q  m3 E) ^( T/ v# o
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)
5 I  k  J+ I; x$ l9 h9 S

* \5 d7 N& O8 \* c
先用迭代让业务快起来,敏不敏捷不着急

8 M) I- @; e1 ^7 i: V
6 b5 E4 ^5 g2 D! P1 _5 l; T1 R
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
; i" V2 g) p) M3 K" k' P: e1 k3 H

( {* U* S4 H- l& i2 R- J/ F$ X6 f. j
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)

: L/ n; X9 Q& J8 @1 N
/ N' p7 j: j" z! M! k0 s& I
8 K$ u# \2 G& F/ a3 Y8 k* P
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?
. I  T8 M8 C5 t" _- Q* z* O" S0 {
1.png
(图:瀑布与迭代的区别)
, {. p0 b7 ~0 y2 n1 J2 W
; E6 c$ X" y- D( B0 y
1.png
(图:瀑布的特点)
# _4 {1 J: I/ `) Z: I* w
1.png
(图:迭代的特点)
4 O& q  O5 G+ J$ {' i
1.png
(图:迭代与敏捷之间的区别)

1 m* a- o2 G% S

, O3 t3 V: V  l2 g5 q
. R# P- t( b7 y/ S& x# T: `
2、大家都缺乏敏捷文化

  h3 o% D2 G/ X1 x

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

, \+ N! x3 A' S3 j" ?9 E

/ g6 F) y# d) c* J1 J
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

6 h  a* W; C* z; a; ?0 }
1.png
(图文:跨职能产品化的组织结构)
) p; [- \7 U9 N: l: U0 T
  o7 F/ @) |8 ?% G  O4 c/ m: I8 F
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。
% Y3 O! i& U3 J1 N6 L  H# ~

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

0 n! k7 H4 |# {( A. V5 J
+ r$ i8 ^) i; G5 @$ E: g
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。3 Q) A7 ]/ ^: C! t4 {" ?$ e' d

+ x, w. T" ^! U
- {. x' `% j8 }/ {( L
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
* J: J3 U, c6 L5 J  U. C, F
1.png
(图:网络游戏 - 混世魔王形象照)
4 }; F0 l: s' R3 S& p9 H

3 [$ ?8 a8 O3 y- r, ~+ M2 U2 ?
9 |1 x+ ~+ N' G, g  T3 m* G
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
% c+ K/ E1 g8 Z+ ~

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

4 l+ _& \! j$ y1 ~( K% M( M5 z

' V2 k2 X. R' G5 g/ O8 M- _
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
' `: C! C7 e% F
5 q( Y' Y! q* o9 ?% ^
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

. A. w* L) v) p( n/ C# @1 `8 L1 a* Q
1.png
(图:敏捷,乃至DevOps所需要的文化)

$ H1 C* b9 H' L7 }7 o7 N
2 G1 H5 I0 I4 D

$ Z" _) p' m3 T/ C; k9 m
挑战二:配置文件的困惑

/ q) K; \: [  Q; p: o

- ~$ c( v9 ^/ e+ o: W
1、没有DevOps之前,配置文件是怎么玩的呢?

. M/ w$ o' ]+ o- a2 j4 Y$ n" J
; F/ x4 o. |" g% R
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
; T5 L4 U, \1 |6 ?6 ]

9 O- _! h( x/ C
配置文件位于classpath下

) K5 w, _: A' G& y

( R' h! C/ o$ _- |! {/ R# m
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
6 q( J5 N) W. y) p) j- b
1.png
- L( G7 k, c/ K: q: R+ `
3 h9 g7 I/ `: s2 G$ S$ |! M* a$ y
8 D. P. n* U9 t
如果有多个配置文件加载,则:
, O2 j7 S+ Z0 a( D7 Y1 b! C& Y; }' w
1.png
3 |) k- r1 R. T. h* s9 ]
配置文件位于外部目录

6 M( P% F" G  v/ [+ e
0 c+ t" y3 Y8 |$ Q: R, b1 e7 [& \) L
" ^3 y  X  O: B# e9 W2 c4 R6 l
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
  m. h3 W+ ~2 ?
1.png
$ g2 ~4 e( o" T" k4 f/ B% O' L
1 l0 r: ^% i  f+ T& m4 N# M; R& a& i
$ H5 i3 S0 W# w4 c- I
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

# ~! |2 v5 d: O- u9 v2 r$ f
5 a! v* U! I2 a9 \* `& D# R) C9 D
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
6 C; {8 h2 m/ N5 s: H
. V3 H! O+ P! B2 `' w/ V' W
, L$ D) \7 G  w0 h9 k$ J
  • …………
    6 {: o8 m0 Z2 _. w; m8 k
8 Y0 M7 e  \2 Y  P2 F

4 I  ^4 k+ l, g/ ^% u/ t- x( P
  • 配置文件的版本如何与程序版本对应?

    + o: g7 n! _5 w% i' Y7 Z% X) K
1 v, ?. s: R; y- Z6 S
  • 配置文件的管理如何更加简便?

      A0 H8 [& G4 m& c; D$ d! s

0 A5 M* m7 a5 D3 z3 Q* [! m

3 P  K" s8 I6 i9 v
  • 配置文件的修改该有谁来操作?
    * i/ r! X. H6 C
  F  U1 \3 g) v$ n" H
7 C  W% ^+ K7 u, O$ |1 C, d
  • 配置文件的更新是否可以不影响正常服务?

    ! _- d8 `6 O' h5 C3 S. M" r
0 c- t+ ?9 c- q  B6 e, c+ B
  • …………
    0 w  K5 V+ q8 w9 n( l+ T( g

/ E" v1 p2 k: l0 G
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
; S! w9 J! \6 Y3 M+ e4 U
0 Q' K) @4 `7 \5 {; A
撸起袖子,不要怂,咱们搞个配置中心吧。
& S( J4 I# f8 p
- D/ s7 Y0 i8 s9 a8 V9 B- j4 k
2、有了DevOps之后,配置文件又是怎么玩的呢?

6 P1 U! F! Z4 {2 u8 S( u

/ L6 x  `0 F* h, M; d  P
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。

! K* p1 @+ [5 m$ t2 G1 d* J
5 l, ~: J8 `- \8 w2 o
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
  x( F! V$ @4 z: Q

! P1 I( j  q, c  N2 ^
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

6 ^+ `+ Q9 e" m$ d2 h" ~+ Z6 X# y1 @( T: y+ `. P
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?

  G* R/ r& {' r7 {
  _+ k, W) g; Z4 n
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;* K; h& L& k4 K
0 |$ M9 w1 M8 _& E
2.操作风险:配置修改随意,无操作痕迹,易出错;
; T3 I. z3 h5 s2 U# F: ~8 ^, e6 |" g" ^) E1 d
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?: E$ {) {$ y) F

3 U8 c9 z/ o7 b4 l+ m/ a' B
' \1 P9 B, I; e; |2 i
2 l0 T; {# ?+ `4 p# Z9 m( |+ g" Z
1.png
图:配置中心在DevOps快速交付通道中

3 J# `) b3 q" }0 m6 W" C) }
0 \; q+ d9 o$ Q; V6 ]) U
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

- Z9 M5 @* y3 T; t  a' b- e6 X
3 |/ Y" ?- H2 J: v  W) p- n
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
( I) U# S  r4 W- V
8 S2 F1 e* R  b
无法满足我要求的,我不接。

+ _6 v; g6 m" ^' t2 F
2 M) D9 d- ?) Z% X1 X" ]1 n
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

' @" {% v+ p: G# P3 E: {: L* h( G0 d
; K2 W  g, \6 ~# [
三种适配器
3 V. N, ]/ @- B2 o
6 L  n$ s: o: [; T
1.png
图:适配器Trade,满足原有使用Properites的诸侯们
* F. |# G. S3 U2 h
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

2 }' x3 |  ~* Q% D
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们

! k. x7 m; O5 l
  w) Z  K* \# F$ Y4 r. x. _, z( f6 r$ l  D8 i( P+ p: `
两种推进器

. Y' g, |, @" |  a" K& l6 j. j2 l3 V9 x
0 S  c/ g  ]: J
1.png
图:希望采用 “文件被动加载” 的诸侯们

% r6 \5 u8 W# \$ k- r" v
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们

1 `& B5 p0 B- S) m+ L8 \
; {: _/ X6 ?. s; r
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

. e5 Y2 H( f$ d
" C- `" d! M( H  t( m. Z+ q
有了配置中心,诸侯们的确享受到了福利:

; [# e! W' t3 b0 s* A! F6 I

; l# x: K9 k; H5 A( e% O
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
- z9 z7 H' b3 O  [! @1 S
6 U) v8 ?  ^9 h+ X* W* N
2、配置控制台提供鉴权、操作日志等服务;
( h- j! s  b; m& ]; p0 o
# |& N' e8 r+ [/ S  p. a4 ?
  G! J* J9 x" a% V; ~  l" E3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
5 Y* W& c$ A! V# v
% m: [" s8 u0 ]
$ Y/ I6 U- C7 E0 b$ f2 P4 \* d4、配置发布后,实时通知应用端,无须重启即可使用;& Z' U# V% e! s: w# D/ `

/ o" b8 s. q5 I0 M
4 u$ m3 ^1 d* _, D5、配置版本支持一键回滚;
/ X5 k5 u- v; V7 E3 E! A
2 P/ T7 k/ W- _) t% d
  k2 u9 `" ~' g9 U/ O8 D- J6、配置控制台实现了整体复制、导出、批量修改等功能;
. V" l: e" C9 J; H3 ?. S  R
3 U3 I! R) a0 A  v6 ?
2 ~  a9 j& [. e% v
! s1 k% g; m/ q$ _. u
3、小结
4 g" n5 P" X4 x, }$ p$ L- l2 i9 B& Q

# \- m, X& _% g7 }
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
6 N5 I3 C  I! i1 U0 A$ Y& H

: W4 n- m! \- \+ P1 z# X$ Z6 m
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

: B5 I0 B& r% y  r4 E

本版积分规则

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

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

Baidu

GMT+8, 2018-11-15 08:27 , Processed in 0.206998 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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