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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑   r* d! a# a' S4 O( R# d1 w
6 R7 H$ d  Y& S5 t" N* u, _

6 c. T; _6 C6 B; `( |
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
% ?! Z5 s; {" e/ O9 y$ Q

7 D- l9 D& E; j, _6 K1 l
( W  G9 t" i* z8 m( D$ k% x' B8 H
挑战一:敏捷文化

( E, a" a* i; k& w$ q
8 j& D$ `" ]+ K' T( O5 d
1、切换敏捷之前的过渡区
# O1 G" z% M8 e8 ?

7 s% u% v8 b: K
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?
; s' }1 U+ q& `: f+ X
. M$ c/ b+ H& N" P5 m
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……

9 q0 |' w! ?$ Z1 d) d% u, ~

( f* j9 G3 n# i0 R1 U1 f
开发结束啦,已经提测了,你问问测试吧……

3 e/ Q4 I% z; c4 c/ x, b

' \0 H, c& _' ]- L1 ^
问问测试吧,什么时候可以发布仿真环境……

  H& a% B; m! O2 X

& n; @/ r+ F: k6 i
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……

7 l& W7 s5 Y8 P. l4 v7 S

8 u6 F# u0 v. X  O# h) l
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)
- F$ y4 G5 I9 P4 t3 b; u
5 c. R3 R% ?: ]& W
先用迭代让业务快起来,敏不敏捷不着急
6 F3 g, d' J' X  |" x/ I* W4 G
4 k2 o9 w/ R( k" u! f  ?9 ^2 @
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。

' L8 i( i8 f! y! N; Q& e. I& f2 C7 r
/ d) K- ^! H* i; F" Y
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)

7 Y7 w; g+ r; Q2 q% {  r; d
+ a1 C0 n8 T0 ]! E9 x  }
$ m6 |9 W9 g( w5 K0 ]% h) q
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

7 u& a  x& b2 Z" z' h
1.png
(图:瀑布与迭代的区别)
# g8 o5 G$ a/ ?- L% h
, R9 ~( Z+ q/ ~8 q& s) ?4 B7 Q
1.png
(图:瀑布的特点)

" f6 r9 \+ t2 Z" V; F
1.png
(图:迭代的特点)

. V6 r& F- f* N+ m5 J8 q6 N
1.png
(图:迭代与敏捷之间的区别)
7 u( a% m7 F, S4 G( [; p
% F/ \# @3 u$ q9 Z$ Q" E7 M

2 f8 i' R+ V7 X# s" K4 S
2、大家都缺乏敏捷文化
- G! B& t$ ^/ f( l
! R6 D/ m! ?- {% b& ~0 @+ N
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。
, r; g3 H# ?& h  n! P0 m0 z3 g

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

5 ~, x- a7 ?; I6 o$ v" n1 Z" {
1.png
(图文:跨职能产品化的组织结构)
# R# C2 H7 X4 T6 b4 _8 ]

# V6 r3 L6 Z# T% ^, E9 I$ b: S
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。
' F* ~+ Q2 s, X% Y  @* G" h

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

' S# _% `' v/ I6 b$ c

5 u$ `% Q4 K  R; @3 z# N9 P/ {
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
4 b+ S- J2 l# r
  l( J0 |( j& s+ r8 b
( t* O, a. p# y1 Q1 Z  s
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
, w. y# U5 y% d, r# W
1.png
(图:网络游戏 - 混世魔王形象照)

( Y% r; t# c# ~3 {9 ~0 S- A) Q
3 v1 |6 E8 I$ d0 B0 h1 Y2 F) J. p5 F
1 o# L1 O9 x% `2 V* Z- W- f
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
  B8 L9 S2 Q. ~2 C

; h1 ]1 F6 x, q, u" G7 H& D
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;
9 v: K+ i8 z1 w0 M% T- W+ e
: \3 ?  t. a- S  U
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
+ T2 \# o4 l8 w. c5 c2 D+ K

6 M! R3 R: s( L) H
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

# P0 a$ E5 |* ]8 l" d# G. ^6 J
1.png
(图:敏捷,乃至DevOps所需要的文化)
1 v2 |/ ?' E6 a; p
) O2 ?# ]7 U# R" I/ c' S4 y- v
/ n- M- l' l8 y: g$ G7 e& F6 Y
挑战二:配置文件的困惑
! R$ B3 r" V. u5 l
8 b1 l# q; y; b, s
1、没有DevOps之前,配置文件是怎么玩的呢?

6 Z8 L  N0 p8 m0 J! Q

$ O, O* p4 V( m' v) @
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
1 e& Y% ~8 ?) h  b& Q- h. l+ X' W- R

; C4 y2 N) h" {8 M( u
配置文件位于classpath下
  }+ H6 e; c( a  h0 T2 Z; F

  x  o7 T3 f" S0 ?) M+ L0 |
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:

; X; U) I/ q  W! b
1.png
, C* C9 o! ]8 w) O4 X! y

3 G6 _. q3 Q8 X. R6 f, b
' [. Y5 `$ u9 d
如果有多个配置文件加载,则:
) ~% j7 r% H( j8 M; @6 G) H
1.png
* k2 g" H5 @0 d. J5 n+ M' X
配置文件位于外部目录

! b% m* I6 ~( ~5 @4 t
- R6 q% |" p- Q2 }! `$ ~
, ~' f0 w/ d' k! V- l
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
  e; R1 n$ |! a3 e# [, O- z3 \
1.png
  T2 j% Y+ s! [8 Y( x

% i( U, d( H8 @; B3 R4 r! ^0 m

* C4 k* B1 V7 ^+ M5 |% v, \
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

1 M  r; k8 [% H, y
8 A0 d6 [" E0 K1 H
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
; J' ?- e0 V  Q; t5 }  m( o* @9 H% a
! ?4 S, V; s9 \: x( z
5 F6 z2 m! }! ]2 d/ h& ~
  • …………

    7 \. P$ s% K& r. q6 h) G- `2 R

# `3 O- m( x6 q% n: S, t$ e, Y
; w2 ]' h) U" s7 S7 W& [
  • 配置文件的版本如何与程序版本对应?
    ; @$ ?$ b! x  u1 E/ \

8 m& d/ f2 [( e# K/ U9 K
  • 配置文件的管理如何更加简便?
    * O" q2 k- P  q
# ^7 R; F; E" }. [1 g) R1 E  C; s( J
6 Z% c) Q1 n/ E% \7 p
  • 配置文件的修改该有谁来操作?
    1 j) R& p4 P& b) X( y7 G

: A5 B2 p# f5 {2 J! e9 G4 H% @

/ P( H; m& ~" w$ P- F
  • 配置文件的更新是否可以不影响正常服务?
    7 Q0 d( x9 g& W/ d+ w! M

, j% Z* Q3 z1 N- o; A1 D( z
  • …………

    " f) P) g- a) }3 n) c4 ?' U8 w
& L) J- A5 u2 @/ A
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
7 k& n" s! A. M( |7 ]1 P( v  r
0 T( k9 ^/ b  ?$ c$ H; E
撸起袖子,不要怂,咱们搞个配置中心吧。
2 n4 M! s( ^# R. V, `( Z8 ^% V9 O

4 J( W2 Y+ |7 j
2、有了DevOps之后,配置文件又是怎么玩的呢?
! ^, \; v0 w) D8 ^
: I; e  r5 F" F9 [# [( a" b) R2 ~0 J
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。

1 {8 _3 ~' [; d( n
9 W' Q# G2 P1 o
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
* A, x7 T: N$ U# F0 d( c- y/ r% Q
! p/ F) W# H; G5 W0 z
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

9 W, T6 t! a. c7 k+ N$ P& `* T; p
7 C) X: g" R% o7 g( B* e4 g+ o( d
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?

9 F% |9 \: d  m6 q
9 V6 c. }9 X0 {9 }
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
3 b& G/ p4 _+ ]- K5 b! R) V, `- [
2.操作风险:配置修改随意,无操作痕迹,易出错;
3 [! ?0 b0 ]/ V& N( Y
0 P. \2 s, t6 u/ q/ \7 k8 Y
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
* U$ j9 a8 c9 u0 i9 R) J9 X% e7 l6 Y& O3 B; E
% ?/ m& i, ~8 }- q/ s
% `; l5 c* X2 m$ {1 f
1.png
图:配置中心在DevOps快速交付通道中
/ ?+ L% n" c6 C! N# {
7 E3 d& i8 v3 g. z$ i
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

; }/ |; D0 }. y' t" O

% R+ \8 r, E" Z, @) ~" l
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
1 B. n  ~3 a; O6 E/ m/ B6 }! h  J5 N
4 U! s" `; ]2 g. ?" _# w2 G
无法满足我要求的,我不接。

4 w% q$ N9 s3 ?

* X# q: K: Q) x& P+ r, y6 |
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

. A- O% }' K, |# n
3 V% }  H2 [) K' H# ]
三种适配器
3 }7 E! T  H& s1 ~

2 C" m) K2 D( h) p
1.png
图:适配器Trade,满足原有使用Properites的诸侯们
4 }0 l- w! ?1 _0 h: m
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

) f( A, @5 t$ k, k2 @( Q+ M+ A* U
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们

/ a) [9 N8 y( i8 }8 I4 M  U  v: H" g& ^! ^; y& C8 t4 u

$ K! X  n4 d7 N
两种推进器
. p+ a3 ?# a4 \0 l3 X* @' N

/ }* ?" H1 _: @: u; A
1.png
图:希望采用 “文件被动加载” 的诸侯们
) Z- v# B) |' ~" G' z: k
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们
. t" L* y# Z# y2 m1 o5 a+ T

1 Q0 f( [0 u% I! o
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

5 E0 V/ X: k7 N  K

! U! R* l& |! e
有了配置中心,诸侯们的确享受到了福利:

) S3 G' O+ w- T  Z! K3 z
; N" b9 o  V, s$ H. c2 a) Y+ p
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
$ S+ [2 E5 \3 o0 Q
1 Q+ M; v# i' b: H. D6 m
2、配置控制台提供鉴权、操作日志等服务;
) H5 v! ^  L" P, g9 Z% g; z# U7 o' @6 \6 _% i7 ~7 N. b" q6 K( s

! I0 A, B( \* o" w! I3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
$ P" ]8 a  E9 W8 U, ?
* `+ q: r& z3 z- B2 F- \( R# W( M$ p' m- p
4、配置发布后,实时通知应用端,无须重启即可使用;
# Q! t! m2 [: t2 n4 I  T% Q, J( ^4 ]) k1 D# [6 ~7 j

6 n/ ]& D) K* V5、配置版本支持一键回滚;
  m( L2 k- n% n) `5 j" [
: ^6 Q6 d% Q  B/ |) A; p; N" e: G
8 [  T' v- _8 |5 l1 e6 U6、配置控制台实现了整体复制、导出、批量修改等功能;6 \: Q" k2 R3 T1 R/ M
3 l$ b$ ^8 n# i) o& S( [
0 g4 r, m6 p2 t$ u% h# P
& |; D5 S7 `( j' a
3、小结
. M/ G5 e# C- d3 j3 G5 m. R" @5 P0 k

: K- u7 }3 A' p) s
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
; P1 S2 f% H% c0 \! ?0 a. R5 ?

) x/ t. X" K5 u0 o' @
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

( h; J! O% Z6 h

本版积分规则

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

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

Baidu

GMT+8, 2019-4-22 18:30 , Processed in 0.211623 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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