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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑 7 ~' v7 Y6 c3 p1 B* Z0 e" L5 c

* c+ w. h) ?! h- X4 m8 ~
$ o2 h1 t* O$ x* L2 [+ S
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
$ q1 o6 {* r, p6 K2 \5 I7 u0 |8 S' K

5 u2 y/ O# w" c0 d% y
' N' q7 @; Y9 w9 T, ?
挑战一:敏捷文化
8 L  S6 j, J( K$ M( K+ f' ~; V

- a. D+ b, R& n/ N. V/ i4 S6 {
1、切换敏捷之前的过渡区

0 h4 T3 S9 ?) L# a3 E

+ \" K2 V3 _( o
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?
# v9 S" p; E1 W4 \$ T4 ]' a$ A
. [, b/ R! f+ u" H1 b8 [/ M* L
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……
3 _  Z/ m1 L/ o; k1 x' P

% V- q+ \; b# p
开发结束啦,已经提测了,你问问测试吧……
" b" W& P' T8 F* y, G$ `

" _6 F- G& s2 _: `% ?: _2 D& V
问问测试吧,什么时候可以发布仿真环境……

' `: N- M2 e* `$ o7 Y0 |3 l

8 v8 Q" g$ i0 r3 U
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……

% }+ l& t4 N$ f8 V. n) I5 Z

: s5 X. }8 U4 \" W
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)
& ^6 x. K6 Y' i1 p! r
. ~) y+ {( f0 N
先用迭代让业务快起来,敏不敏捷不着急

/ f3 K7 U2 I& K

# a" B* [2 k0 Z" w, t
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
8 e; v0 ^5 N0 ~1 a
' H  _3 A. X7 {; [& L- X, g' q; T
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)
; Y2 Y5 t1 q. w! _2 ?$ g) Y

8 Y1 y- f, k: H; k6 y$ }: [, `( c3 i6 S, V6 j) ^4 ?
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

4 g* A; C- Z. N/ ~9 X8 w
1.png
(图:瀑布与迭代的区别)- K8 ?1 h# U& s3 c+ V- b# U

% I2 W* s( e, p2 o. M8 \1 z4 d
1.png
(图:瀑布的特点)
: [$ E5 b( c" d' Y4 x9 b
1.png
(图:迭代的特点)

* f" s4 W0 T+ h& U" o
1.png
(图:迭代与敏捷之间的区别)

0 y9 ?& h  Q4 S5 m/ `6 T5 M+ @

" o' o" W4 T% G& x
7 X& e/ B& x3 K: C. q
2、大家都缺乏敏捷文化

& v; M  w) @3 M7 a

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

* g* r5 p5 I$ m; o" _+ g6 u

5 S1 ~3 k* {- A. u) Y0 K; V
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。
" j8 c  t( M1 T2 e% G1 D
1.png
(图文:跨职能产品化的组织结构)

+ q9 ^3 Z( P! e' d) H. D2 x7 ^
# D0 [/ j' m- ?# S5 P. U% O
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。
4 I  j& Q+ ~- j/ s$ m3 k

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

% L7 W6 Z2 o9 l; q9 X% @/ L
1 q  w) e! o. }! O& m; u2 x
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。" z9 |( P5 ?! l4 ~

  I1 _" [3 x. e: ?' u- z

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

; X% e2 C4 G7 h
1.png
(图:网络游戏 - 混世魔王形象照)

- k! w7 a/ D. `5 n. ?- X  q

6 I0 I8 U: l. _' h. }

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

+ g. f! R' o. h

& J: b+ v) M% U" v7 H) @+ B
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

. M9 c/ {. X: C* t% f' D

1 H: A9 T4 h2 ?
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。

' _6 i- N0 q5 A% j/ X% }. y- W

3 u) [( B6 L  {* D5 h
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

  b5 O/ J: ]. [, t, n5 z
1.png
(图:敏捷,乃至DevOps所需要的文化)

! r0 w/ p$ r" Z
3 a6 X0 Q2 Y/ C$ ?$ b6 q2 j7 L! J
" N  `2 Z! @! H8 V2 @/ B
挑战二:配置文件的困惑
& S9 r6 L, q; _% A2 m* Z7 Z5 P8 I
& w. y! S6 \/ c8 T6 I5 T
1、没有DevOps之前,配置文件是怎么玩的呢?

5 D! o3 [& J! k0 Z2 U" {* X* p

3 c4 J2 t: _1 A" }2 p
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
# Q( P$ G3 }, n2 i1 W

& ?/ |" |3 H( \7 q3 t* x. z7 y$ k
配置文件位于classpath下
: N/ Y/ R9 g4 w: l
+ ^, S; G6 x  `) A, Y% V* Z4 j! C3 r
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
1 T5 R: A6 k. b& [0 W( ~" n8 n
1.png
3 q  T  I( l2 C
* i- N7 t' l! I0 B% w( s+ r! j

- d" `: S! `* r, s9 z* {
如果有多个配置文件加载,则:

8 {  o9 ~# Y, k2 e
1.png
# z+ y& E# h8 R0 z8 G8 c9 z
配置文件位于外部目录
7 V6 U3 t- t8 B
4 [5 h+ o, R" e3 Q4 Q, F4 ~1 C

( ~  O& q5 p' Y% D; V
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:

# e) b% z! X+ Y6 x, I, ^$ Q
1.png

* @, E1 y3 }9 s

/ C  s& c0 a' x7 B5 Q' C( c
2 x! o5 F0 Y. ?, ], F# B2 X
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。
* D% L; d9 e* e- q, _) ?: C# P
5 r" k; h0 o7 ?+ g" c0 e
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
3 c; b$ m; j5 t9 s$ D8 H& w
9 ]* G4 `$ x; R$ X

# f) n  y! c/ o9 s
  • …………

    7 Z$ K+ x# ^, a+ W/ b

" r' G# b5 }! {& _

# {  K5 ?6 H0 t6 z; [# P6 \7 c/ L
  • 配置文件的版本如何与程序版本对应?
    ( Q2 e9 o9 b9 e9 a; C/ S+ c, ~

3 K) J2 G) k' q% Z0 \! _  W
  • 配置文件的管理如何更加简便?

    - E2 y* |1 U5 `( L% z3 x- Y- }% j
' C4 O, Z, B5 l
0 ~! Z5 y7 M2 h! C$ f- ~5 u
  • 配置文件的修改该有谁来操作?

    4 F9 X8 U0 v' c: f
5 r3 ]6 S* v9 w

! q0 r4 ~/ |( {. }
  • 配置文件的更新是否可以不影响正常服务?

    ! i: Z% e4 W1 A% Y- {! _4 K8 r
9 o  g/ ?" c# s- L
  • …………

    1 x& {% Z! j6 Z) B
& X+ [( O8 M, U1 @8 e
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。

6 ?+ k- q! f: W, s# f: m/ O

% c+ B. H' t6 M% i8 A& K# {& \( A
撸起袖子,不要怂,咱们搞个配置中心吧。

# H; Q, T- b1 z' n( s

; A7 ~( h* x* @; k3 }4 |. M& n
2、有了DevOps之后,配置文件又是怎么玩的呢?
% L. V) [7 e  R8 L  p
% M+ r9 t8 d1 x3 X
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
: b# ]* G, l0 E/ a
; }7 B' S8 R! U/ f2 r/ M6 n
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;

- |9 c- l: ^0 y" \! h1 Q3 n$ s

/ w3 a, K+ {; o! O5 n
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。
: W: ~) w4 v& ]8 W  Q- h- z
0 t6 C  j/ |% w
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
8 b& z- B0 X5 H( y( R0 ?* f9 M
( W; h" U, L7 p: J1 W3 n! ~
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;* @8 i" e+ z; W: |' }8 |

  G5 T: Q6 B4 H# c! ~+ k, W  {
2.操作风险:配置修改随意,无操作痕迹,易出错;* a9 [' _+ B" G+ k8 O3 z2 g
1 h# o7 y# c5 K+ ^# r# @. \
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?# E+ q2 }: O5 a6 i1 l

  n1 X9 Q2 ~9 h. ~. C* `) P# n
( Q' f3 U+ l3 i
% n! K# x* m# s3 Y; l/ e3 C, T* N
1.png
图:配置中心在DevOps快速交付通道中

& z1 d/ T- p# J
, ~- m( a, |. o% Z
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

* ]* P: t" [+ W+ V
3 {6 i* w, j% f4 @& h6 j
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
& z0 F! `2 m' A1 Y7 \1 Q) P* X9 ]) w9 v

$ @! S+ M5 p$ ?: X9 B
无法满足我要求的,我不接。
- G3 r9 _; i) y/ U; F) T- x# k) S, w

# X! j8 ?6 P# p/ Z: }
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

4 f; _0 N& N* w( n) o# |7 {  h, V% a/ R1 w1 M
三种适配器
9 V; f. Y( X# k9 \0 {+ W3 Y# K) q
6 l0 ]% T# b# P  d" _/ \) T$ `
1.png
图:适配器Trade,满足原有使用Properites的诸侯们
0 c0 a* g+ h' _' s( @# m& \2 s
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们
' U+ [6 ^2 @8 e$ G; B+ [  ~; x
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们
- z  r& l& D2 @$ K! Q4 g: |
+ h6 I9 I  z8 s; z: ~

& N6 x6 O6 t' n! ?3 m
两种推进器
2 f$ P, T: e; _( o3 X( C0 D  U
% R' H7 s9 F$ f. e0 ]  c; c  s
1.png
图:希望采用 “文件被动加载” 的诸侯们

& u) |' z  ^& ~5 w& g' w+ S
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们

3 @( i* N* w1 A  R& u; {- D( @

7 `/ e9 _# ?, H7 k3 r
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

& t% v* e8 s$ b3 R
" a/ X; U/ |& c) F; y
有了配置中心,诸侯们的确享受到了福利:
9 r) p" z- N& i& w/ u3 ^3 \
3 |* s% R- V- N% o* G
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;

. n$ o% _  r1 e9 {
; j1 e: {" P' c- A* ]6 o" N/ P
2、配置控制台提供鉴权、操作日志等服务;
6 V' [9 e/ e) l% Y6 S: \# j6 \3 G7 T) ?* L( o9 n' ^$ H
2 [2 H: \1 L+ J0 K, I! f
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;% U8 {3 V, n. I0 [/ p0 ^6 f
( e$ Y4 @! a8 \7 ]1 S

  G, T; S' b9 |* N2 e; l& B1 K4、配置发布后,实时通知应用端,无须重启即可使用;& Q& m: V$ O/ U5 J% \
& m: F0 q0 x& N
+ B" d9 L0 j4 N
5、配置版本支持一键回滚;
- W2 L7 z; K+ Y: J3 _5 N& c) ~" m
" _: r- l, c. m( x, M
6、配置控制台实现了整体复制、导出、批量修改等功能;& A9 t: ]( `5 _1 E! n$ S) M5 F3 @

! x0 I; L* f' [8 h  Z& _5 i* r
) U  p" ?) @& Y+ s; X4 V( x( E
. I; e8 e3 e- g
3、小结

( S& t1 K1 K5 {' Y1 _: `' x( E
2 v1 p! M0 O- Q+ ]# h
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。

* u4 A: q' C* ~. r- J  P2 x4 e

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

: D$ p6 i; p7 g. ]6 U

本版积分规则

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

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

Baidu

GMT+8, 2019-1-17 11:21 , Processed in 0.215712 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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