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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1389|回复: 0

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

[复制链接]
发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-9-6 16:09 编辑
6 S! L( v; S) T+ O, X$ S( i, l  l7 Z% L. {: D
" y) k% K: i# B8 x
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈ITILxf.com" target="_blank" class="relatedlink">DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

! {& L6 k) y4 d. M( ^7 g# ~9 [
# d: M+ L- s$ F& I5 J
1 K3 k6 n, X, S: g8 d9 M6 N
挑战一:敏捷文化
% h( v/ ?6 I" Z/ }1 t# r1 G
7 k" S- y9 k  w) ~
1、切换敏捷之前的过渡区
/ r  x5 S- R3 J, _& ]  x# y' O

! c" d5 q( N, K) g' [
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

9 D( b( z9 b& ^

4 {  L2 B" m- u! C$ h
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……

6 ^% o1 e$ j& g! _
. O9 F. H1 M% d& O2 ^' t( W
开发结束啦,已经提测了,你问问测试吧……

( K0 M' p. N7 H

8 E2 C' F0 S% ]- z. ]
问问测试吧,什么时候可以发布仿真环境……

) V+ b% k* x; ]4 @& n8 n

( x% L/ _/ j- ]0 t! B: X( z
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……

: y5 ~8 d) u7 n/ C" m' c/ i
# [, L5 ]* u9 c( c7 O3 B& r
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)
* O) w% v, h/ U# m
( a& [& L, L0 g; q4 q1 Q/ @
先用迭代让业务快起来,敏不敏捷不着急
( H6 b8 m7 K# M% ^3 \1 H

+ g8 S' [8 P$ V/ p& k; d
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。

/ B) k  @2 O$ m! s2 F; M$ b0 N
( h" K5 B* u- m9 j% ]3 f
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)

/ D* q# K% y' R/ r. m8 S3 l! b2 s" t/ `

3 j6 m$ i3 H* o7 y! {9 n
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

( S- D4 G% i7 Y7 q- m
1.png
(图:瀑布与迭代的区别)( F6 u- s4 C! I- t% }$ M
8 J1 Y* \: z$ n# e; t/ C
1.png
(图:瀑布的特点)

3 M3 p. d; `, f, g5 u* I- ~
1.png
(图:迭代的特点)
! ^2 B' ]6 G( e4 ?9 P: M" h
1.png
(图:迭代与敏捷之间的区别)
+ S8 ^9 ~7 Y( [7 ~. Q7 J  }

- X/ y& r5 M( ]

! e. f. |' T5 y% F7 o1 `" A
2、大家都缺乏敏捷文化
& E# v* S: T3 g
' w! U6 x: s8 _: n7 K4 D
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。

% X& u4 h, p4 }' m( y! X8 F0 k0 u
6 D! j% z& Y: a" A/ P1 S
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

' S- a6 e2 u, C- q$ s
1.png
(图文:跨职能产品化的组织结构)

  _* j4 y* f, O+ S* q2 e+ ^
* ]& j' ]/ i1 E$ M9 a/ q
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

+ o" S/ s% X" d. g& U" r- [2 ?) H
( k8 R' ~  A4 r+ A: y3 E
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。
+ q2 V4 E) r' C' v* O0 l1 ?3 w- b6 ?3 X

. `0 z/ ^  \% q5 X* g1 D
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
- j5 O& s+ g# c4 I* c% x

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

) d/ Y' R) {7 A6 i  [# ]& c# @* h
1.png
(图:网络游戏 - 混世魔王形象照)
' ^. V7 v* ^- \/ r( |: J& X5 {
( w1 N& \  Y- p' `2 n0 I

! e3 l& ~. S* {. p
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
0 J7 O( j& a8 h# x' k
6 k- L7 G8 c  q& x+ N) f
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

/ \! ]  m2 \) l7 @; ~

: y& o- k( L5 i7 K0 q
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
3 R# k1 _: j. w3 ?% K
  W7 B+ ^* S) u2 f" \1 s
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

6 F* o6 l( @9 L. T: w
1.png
(图:敏捷,乃至DevOps所需要的文化)
$ e0 k. Z) W" G2 ~3 |, P# |% @* c

. _  i! P. E0 U5 B2 n  U- f
' n- h5 o- z  g( C, \+ R
挑战二:配置文件的困惑

* i. O& _' a) T& c

  Z! ^: V4 E- K$ U% _  A2 b% R
1、没有DevOps之前,配置文件是怎么玩的呢?

8 a( e' c5 u4 U. k1 X

" `: S4 x# o( _; O$ C6 L
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:

, |" T, `: `' O& u) D
' o2 m/ |2 D2 m; B
配置文件位于classpath下

$ U0 P- W+ Q9 l7 h4 u$ a6 C  w" v8 R
# `% e# u( H3 e0 L( B/ z+ F2 Z
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
5 Z5 e6 G  R) J/ a  n( w
1.png

9 n. Z$ H3 i! O

6 D- J+ V2 W4 G. ~& d- c" h
' O6 v1 a) l$ }' F! k
如果有多个配置文件加载,则:

/ \. u9 e2 O2 j
1.png
) }. q* S1 ^! S' n
配置文件位于外部目录

% ]  y4 d0 z9 x2 z

( p6 |7 |1 _- L
) n/ x5 G$ {. d( H( S
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
3 Q" {- W$ `0 V% @
1.png

6 d: @* i- d7 g1 {+ t3 t+ h

# P% R# ~6 ~( {6 ?% }4 ^# b
0 Y) h6 f2 T2 w6 x
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

/ W  e& }8 h/ B3 v8 U) Z
5 k7 p7 F; y; H7 s
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:+ ~: b- W" ~: b+ b

! f/ S( ]4 P3 E) V3 Z2 w
( }- `# y0 j, b( j6 o* T% j
  • …………

    - E1 Y' A# K# I1 c
" v  a8 c; F7 z; b6 L& f
2 ^$ \; d# X4 _- E
  • 配置文件的版本如何与程序版本对应?
    0 t4 c) C: k- S/ ?2 k/ J

, X. @) S0 v8 M: t9 {0 L
  • 配置文件的管理如何更加简便?
    ' {3 q" ^8 c! f& a" k7 J1 A

/ t2 n2 }) B- i# C  }" `2 Y

+ t) u& v+ ]) j1 }
  • 配置文件的修改该有谁来操作?

    # N* F( y0 A6 ~4 F
& J; k) V9 m2 w- B

9 K  d' }1 ]' w  S3 I- s
  • 配置文件的更新是否可以不影响正常服务?
      D* l4 u$ a: z* d; g) h) B" y# [

) Q9 |: D* g: ]7 K4 @) E- W7 Y
  • …………
    5 ~- _6 m1 u8 d

( V- L8 J& ?# y4 K; t- P
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
0 m4 l" f& h) l  B7 U$ X* _- i' w

0 s) T$ g9 t; Q+ ]- x5 D; U
撸起袖子,不要怂,咱们搞个配置中心吧。
0 Z7 O( a  C( ]0 g0 H
; B5 B! N  [4 P6 K3 G3 ~
2、有了DevOps之后,配置文件又是怎么玩的呢?
' B5 W4 w* ~3 g$ L6 n& ]' T
' K) R0 w1 h* ]* S* a1 E
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
  }7 L' p% @7 j# r
( H* k  _/ `; Y; ~4 l+ |
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
# S! s6 ?) Q9 c7 T

- U7 e9 ^& r% ^  x1 W
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

/ b3 I* t7 ~8 ^1 K
/ w3 Y( J- E% `+ ?4 @
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?

+ @5 ?7 m/ K) J3 D( n
3 U1 j/ p5 j: [0 T2 _8 s
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
5 r: U+ I/ G( L1 Y2 Y4 K3 H7 |  S0 g0 y+ @
2.操作风险:配置修改随意,无操作痕迹,易出错;
2 m- I; ~/ b( D+ u* z' x! a+ R+ P
, r9 s: o. S$ Z# d) N
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?1 y+ ~2 O! j4 N* r# s4 d* l- q- s
5 y' q; q  ^) w3 u& ^8 j

: _4 b  z! e' k- M/ v

5 w" R9 R. r: t2 ?
1.png
图:配置中心在DevOps快速交付通道中

, x2 I' g$ f9 j* f8 p1 P$ u* Z

4 m* V, O, V( a1 c, \
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。
5 O" J, [, v' s
7 x1 K5 R* ^$ I: N% Z& z. c
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
2 i4 K7 W* G3 N9 S9 Q+ o

1 W5 C. B9 y6 I) y
无法满足我要求的,我不接。

- f3 u9 |" e3 z: L; t$ ^8 z

1 X6 K( E4 o: t/ t: H
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

/ @' o7 V, Z9 P+ B) l1 Y$ D" P1 {6 j
三种适配器
' ~' e) R; N/ Q& O# w) H7 o7 N- ~

$ h/ G" A' U% v# u$ f4 z
1.png
图:适配器Trade,满足原有使用Properites的诸侯们

4 {0 \0 f" N& k( t. W/ N, l1 T/ i
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

. S$ b& C% d  e" T/ C! h; i
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们
/ N: Q1 x' B: K) I5 Y$ k
6 t8 U8 ?/ e# r: w5 y, [! \8 H; w

. P) D8 D2 l2 w8 O) ]$ g
两种推进器

2 _$ K' S9 J/ ]0 @& D
5 F3 o$ {4 x3 E9 W* l
1.png
图:希望采用 “文件被动加载” 的诸侯们

3 Q* b) Y5 N' z* L
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们
. A# q4 H! N, _. ^. p- O
: f0 c: i& v& W) a; W0 Z
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。
0 O/ f& q( D2 x8 I; b

4 `$ U7 f. V1 V
有了配置中心,诸侯们的确享受到了福利:
9 q- w( L' _) X( k9 O

2 u# n- m& x+ @$ |
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
4 [* ~/ S' F( L; m- z
5 X* P/ F7 U, A$ e
2、配置控制台提供鉴权、操作日志等服务;
# B' v9 B! c! a/ f- H" f2 N9 ?. `; q( L' O. h
  _1 j0 W6 p' ?3 M" R
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
  v; \+ ~- j! M) M" G& {. T$ \, c) W1 n; A7 s+ O
9 S- f4 J( n* C0 Z0 }/ s
4、配置发布后,实时通知应用端,无须重启即可使用;
8 [( e/ E8 y: n; h8 i6 p$ H
" e6 i. V5 L) M$ {& g$ l2 C, i  q2 E" t
5、配置版本支持一键回滚;
, w, r8 h. k! I
$ _+ a1 v5 p/ C9 P$ v+ R% ?& }! O, i7 f! p
6、配置控制台实现了整体复制、导出、批量修改等功能;
' E6 n/ f$ @1 t8 Q- |

& G- {# ^& N; C8 w
  m& }/ m  o' H: g2 F) W8 O
% G/ P' x- M; D1 [
3、小结

" i4 `, j% q3 N( D* U

5 z; @6 l  R3 w2 `( p4 _& i
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
- V# c% y- S2 c6 E. T

. G  b' y+ t: f5 V' N" F. v; O
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者
( \$ V  h5 b1 ^9 F/ P




上一篇:DevOps三步工作法第一步之建立全生命周期管理能力
下一篇:关于DevOps术语表--已收录202条
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-5-23 05:10 , Processed in 0.123802 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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