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

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

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

扫一扫,访问微社区

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑 ; G  K$ z' g, l: X# b6 n7 k
3 l( g' J5 ^$ B

- D9 t2 ~3 E  D$ T
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
5 K1 P) h- B8 B+ B
" `6 `( ]' s- h5 p7 d: J
2 ?7 o$ J; X5 X: @! G) D
挑战一:敏捷文化
% a3 |/ k9 l4 j+ h

& Y2 ^% p9 J* q5 |$ E+ e. {; O; o: ]
1、切换敏捷之前的过渡区

( j- D3 ^3 m4 N
3 d5 A. G$ z6 w) s* D
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

+ H$ L# y& `' o% R, G, y
& c! f7 n4 l5 {: o) }
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……
4 B7 r7 O) U# O: [6 n6 X
: \5 G& R7 \( d( Y+ D8 U* U
开发结束啦,已经提测了,你问问测试吧……
. e( ]$ }6 U/ `+ T+ A

' @$ w1 g- O8 s  _, _) A
问问测试吧,什么时候可以发布仿真环境……

* _0 z! a2 C2 w5 N/ N; D- M
) o, o. `* C8 j  J! o# g
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……

5 [- \; N. H" B9 O; Y

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

* P6 M8 @+ _; m* K6 e4 X. `/ t0 w1 w1 a
先用迭代让业务快起来,敏不敏捷不着急

1 D) o- d4 h/ N' J. U

7 H. O% Y" T7 m6 h6 s: j* T; R
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。

: d$ G* ~* x( |0 d4 e( z

! D0 R$ Q3 n/ Q& ^- P1 G3 N
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
(图:正确理解迭代的方式)

% W5 F& r- q. e! ^* D
  _1 }' a  ]1 z8 w9 M6 ^* B
2 h4 w( f- I% S: Z
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?
3 q( v/ T4 Q( ]( S: i
(图:瀑布与迭代的区别)
) V6 A$ W/ W& J- N) w

' k8 o+ Z, e) h
(图:瀑布的特点)

3 o1 _7 q& G' A! C
(图:迭代的特点)
% Y, |4 ~  K; ?! d9 Y
(图:迭代与敏捷之间的区别)

/ E) Z0 w" W9 M1 W6 E# E+ p% N/ p

/ N" \, \. o/ A$ w

3 v/ @. G7 R8 W; D! x
2、大家都缺乏敏捷文化

& G$ d; u/ i* G
2 s! I/ j1 Z- u2 i/ X3 S4 X
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。
- v  H1 o" G$ b# H
" C: `( z" q' K% a1 F, F' Y
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

- N7 L5 \3 ~* O1 Q2 F5 l. T7 F% w
(图文:跨职能产品化的组织结构)
) ]1 N! U4 _! R8 S7 I

3 T* c% f$ F* }) p* h7 x
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

+ l9 ~2 t  o" \: \8 Y* t' x2 F; d
  y. a( ]/ o) ~/ s7 G2 |+ |' r6 o
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。
& v  d6 s& [  \& c: d( Z4 y
1 s; |! J, q1 ^/ I9 `7 r/ r
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
0 C2 C, }. G3 x! w9 g  G7 w) n

, O3 H( t4 D7 L7 Y8 R
5 s, ~$ g5 w* O! Q( j
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;

/ U$ J4 f+ n5 T& L+ Q
(图:网络游戏 - 混世魔王形象照)

2 V. E' [! ~8 G5 {1 h9 J
% ~3 \: q# N' Z; |! C7 C: L6 a

# y- @* I) y6 S# `
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
( n" y) I2 c' [2 T

* A0 V: H1 y" Q: ^5 r1 n
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

" j; d6 {0 a" f7 |; d- O4 ~7 v( _4 ]2 J
7 N# N2 X1 A" K8 X( {
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
9 o9 [: x7 X/ ~* H+ U9 C2 y
2 I6 ]. I8 ~0 G4 d
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

2 ]  y, R' f) k7 `. a! e
(图:敏捷,乃至DevOps所需要的文化)

: ]- f6 ~" ?( P; d/ ~

: r. s$ |" r1 ?- c' }8 f

3 J3 w! ?; W) m, q- d2 ^; T
挑战二:配置文件的困惑
! C) V% f$ _5 P$ D, g, T

4 W$ Y2 f3 Z! y& j. R4 L
1、没有DevOps之前,配置文件是怎么玩的呢?
. j1 [7 @, Z$ t. ^6 A4 h

9 g) V7 b$ k- I% V$ f1 N6 w
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:

. Y: L- a9 t: t  r4 P% \
/ Z! y3 g* s6 }/ G  r' |
配置文件位于classpath下

1 v5 ]1 w" C1 M* U! p
3 V; [+ [' {5 v0 t) o: Y8 V
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:

! r" k: S  a! p
4 R4 ]  R, O% `9 U
. T0 `$ Q3 O. Q. S5 I; X$ `
/ D% N! J6 C! t# f' D% Z
如果有多个配置文件加载,则:

5 j* ~  ^7 U. n/ n7 P. N7 W5 [
' \8 R  J" l% J2 X6 x
配置文件位于外部目录
$ d2 x/ }. B: D- S
1 A0 X9 i6 `$ f+ i' U  Q/ D% n

, m% P0 w; d9 I0 r& n
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
8 A5 M" ]6 t4 v1 y3 b

2 r) h" `) Z2 z* S. R
2 j7 r1 n5 |/ y* R8 [6 O. M

8 z3 |2 i$ j  _+ Y7 D
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

' P3 c8 d# T5 ~, {" \
' R& g6 u/ k4 E1 @9 @
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
! a! H$ A: ~: T$ ?, s

9 t5 S3 a# {5 E" v+ c: l) E
2 o  ]* ?* Z4 ^# L
  • …………

    ! t* T. J$ i8 @* ]

) |$ X: [% [& ^& Z7 r# P/ [& z5 \
4 R2 }  c& W0 w$ L
  • 配置文件的版本如何与程序版本对应?

    $ O# ~' G  R4 w7 o" U: X

. m4 g- j$ Z. y# z& {
  • 配置文件的管理如何更加简便?

      S0 c% l# d* s, A7 s+ G1 {9 `

- N& Y8 H: T8 d! M& Q
% W2 v% G" z' t& I3 F
  • 配置文件的修改该有谁来操作?

    , b9 g1 Y- p, y7 `4 z, @  J
$ x; s, X. p  l2 Y

+ E! o. I4 O9 G" T8 ^
  • 配置文件的更新是否可以不影响正常服务?

    + v, V2 H- O5 D! R; Y
2 i: u4 G3 e: x! s) g2 x/ O
  • …………

    3 H! V* ]( L* O
3 W1 _+ c. B7 k* n5 U+ x1 Q7 a
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
2 q# y* f: `5 e5 q9 Q& ~5 e& J: c' T

9 h' u6 n3 s) W
撸起袖子,不要怂,咱们搞个配置中心吧。
+ `, y0 _+ z; @! A1 y( h8 @$ ]
4 h  q4 h5 g2 |1 H
2、有了DevOps之后,配置文件又是怎么玩的呢?
; P; T& D# P$ J

' t3 K3 P. h$ ^- z& F% n' s
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。

: D$ X/ y$ I  `9 N* v4 D/ v7 F* X8 `6 m
+ Q% m4 [* o+ z$ J( S" G
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;

. o. G% o: i) f5 a( V: c" U

5 j  }' }3 w3 U/ l3 V# F+ ^! @
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。
& c' H0 Y& g- z: R: r$ k
$ Z7 U4 Z+ g' b4 M0 u; W
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
3 R. C7 V8 O6 u* y+ O) P

& N3 P( O, M0 a  G" Z+ t
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
9 Z7 c' e2 h! x; X; N) y' `3 x% O4 U
# M" {/ y' `* z6 Q
2.操作风险:配置修改随意,无操作痕迹,易出错;8 y& M0 W$ D% W8 U1 ]9 ?

0 T+ z7 r% D7 D4 Q/ F) n
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
& A' ^; Q( d+ |( Z7 P+ j7 J$ n# {2 Z) @% p; Y
2 k# D+ c4 d4 e; t/ J, N4 ^+ j3 d

  |4 M! x1 |9 |0 ?7 c' ?& p5 d6 v
图:配置中心在DevOps快速交付通道中

& E3 X' ]! }$ @' f  V; K/ K2 \- O9 g

8 J1 e# m& u3 _3 V
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

: u' u" S1 x6 G, n' b1 M- ?

. u! d( V) T- r" g* T4 s/ V
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
; H8 n' V: P! y. O
$ {4 D0 Z' B6 D; X
无法满足我要求的,我不接。

5 r; o' L4 y* \8 }( T' F
: M) n' J8 S, |& k& r
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。
' d/ Q2 r9 c/ k2 p2 e. R

  D) G+ K/ D4 L2 g
三种适配器
( Q- t. `6 O* F- U  d

+ k9 Z0 e2 R/ I! r
图:适配器Trade,满足原有使用Properites的诸侯们

% B, ]1 t' v. ~4 Z& S& n5 k
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

, R' t* B1 \. ?1 j. x) b. E' I( U+ m
图4:适配器Ccms,满足使用Key/Value的诸侯们

4 ], J  X& l8 O* c" S+ [" ~3 s3 S0 }; w0 B9 [9 G/ g7 v% b; D3 Y

2 k. {; ^& l4 E
两种推进器

2 b( N4 B9 }" ^1 L3 B  z

3 Q; Y% @$ C! M4 O- p; r
图:希望采用 “文件被动加载” 的诸侯们
, g/ D' y1 P2 q6 [' V6 A- {
图:希望采用 “Key/Value实时推送” 的诸侯们

. @0 B. `/ _4 j& A

7 P6 L6 j. F) C: J; b- V3 f
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

: k* U% N) ~6 p" [7 A7 N# @6 r

- t8 n5 }8 w! Z: [/ O6 }3 H. W
有了配置中心,诸侯们的确享受到了福利:

* t' m0 K  u# z3 ^: T# l

1 I% o. c* n2 n& q. f: K
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;

  D1 q4 b; i& q. R' Q
, }+ b! s. h; H! y+ \* r
2、配置控制台提供鉴权、操作日志等服务;* Z8 {* |/ \$ H; w5 A* H

3 R2 Q4 m4 w& l4 S0 |# k6 X7 L+ Q
% a. V/ T- p7 C. Q( D3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;8 w( f* s5 c+ |" j! U. ]1 m! ~

1 n( O6 E' i, r  E( v9 F8 T5 r% a& N4 W( _$ G# f# [
4、配置发布后,实时通知应用端,无须重启即可使用;( [. @% z7 Y6 p. ~& t5 B4 q+ O

6 D# S$ ~8 V4 E
% n4 K# C1 y/ ^% ?8 V6 I5、配置版本支持一键回滚;
% i' @: @8 M: i% J  ?* E  \9 [0 [# ^  u- [7 ^9 Y9 P- `% \

- Q  j  l& O7 [8 z( P6、配置控制台实现了整体复制、导出、批量修改等功能;
2 V' a% X4 ^$ l: y
" [! `1 I: t4 X5 r0 E& b! m
# d9 v5 _6 L" X: s# |* _- c. ]1 W
. N$ y# i7 ~7 E8 J: n9 P
3、小结
9 y# B4 ]1 {/ N3 }4 M

3 L- o5 B0 g5 i, t0 ^+ O$ g& x
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。

4 }2 {" L$ z% c: q+ H1 F2 z

3 r& j; r- P) h* ]: z
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

1 \1 J- k) K8 r) A# z3 }

本帖子中包含更多资源

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

x

本版积分规则

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

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

Baidu

GMT+8, 2018-9-21 12:45 , Processed in 1.088747 second(s), 33 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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