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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑
/ |3 |# Z$ M, @2 s5 q% z* H2 I; C  D* a3 h- _- x

4 k- m% J! ]5 r* N3 g0 z
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
  F7 W: l" P% N! V
) C3 w6 L: @  r( z& z) m+ W9 E7 ]

$ O* s+ g+ F* l# c- T6 D
挑战一:敏捷文化

6 y3 d4 V6 v5 S- @( }

) M6 {# M, R5 O0 @+ }, f
1、切换敏捷之前的过渡区
# _" c1 t8 h$ n% z* c( d
7 _0 J9 [5 |+ m( {. G" j# N$ h
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

( g1 O4 c( h) P1 J

, ]% j1 K6 _5 Z
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……

) `/ K" I+ J5 L) O8 ^2 U: [

! C5 ^/ b. C: ]
开发结束啦,已经提测了,你问问测试吧……

  _% M+ @1 q) R: Y
* ~) d* s, B4 b" a
问问测试吧,什么时候可以发布仿真环境……

; I, f$ i) S/ {+ Y3 x! C) l

3 L. L! Y) |4 U  Z+ o
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……
6 N. e* p- ^$ j

$ E* v4 c+ p; s, Q! M4 R% [
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)
0 J% o) [5 t' @' {6 i7 N

0 U+ j) ~9 a2 N, r( d" H( S+ @
先用迭代让业务快起来,敏不敏捷不着急
9 V5 ^* H/ Q) y$ r  x& f

$ x* i7 \7 y4 g' E5 I
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。

; X) t  U' y: D  t; z2 m

/ l$ b: X5 h/ q2 \4 L9 [# Z: a
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)

& T% K  Z1 y; F  O5 F5 F! e& c0 t) D. P# L& |. o) f+ E0 |
- i" i, M" V1 x$ e
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

/ @6 }" J" d! b8 p  s, S
1.png
(图:瀑布与迭代的区别)$ |9 r- z, x# ^3 p) e1 F2 O
$ [$ E; k+ Q3 V: m% j
1.png
(图:瀑布的特点)

3 |& v2 J4 s  ?; ?
1.png
(图:迭代的特点)

+ N9 b* \+ M' j7 B* k( J5 j- S
1.png
(图:迭代与敏捷之间的区别)

# ~4 W0 `# V# R" Q6 B
: l2 d1 K* S0 S

+ f, h9 y+ r' f1 S/ W) o! k0 x
2、大家都缺乏敏捷文化
! E% n+ z3 f5 q$ ?

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

% A# ?. c3 b0 H  N- f( h; ~5 s
4 ]7 m+ J8 {) O1 L$ B" p
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。
5 ^4 T0 n% g6 m0 `
1.png
(图文:跨职能产品化的组织结构)

+ \( _( S/ a; H' ~
& l0 K) X6 H. a# k
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

$ W+ B& W0 t# D- H/ Q0 m
( z: d9 \. N3 p$ y" Q
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。
( U  ^0 \% ?" N4 u6 O( s
5 R( S! [2 Q% s! t; l3 z4 V
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。4 E  k# N% \% p4 ]8 E' T% ^

# H3 }" \9 ~' `2 U3 i& X
5 h" ?& X' t$ j, [  ?
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
6 b) `3 R$ J7 F
1.png
(图:网络游戏 - 混世魔王形象照)
( F# @$ u' l8 K* J
( d6 ~% N! c1 \6 j7 ~5 o
7 }0 e; G) n/ E6 u
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);

% u$ |" f3 g6 X8 C6 |; c; E1 V) ^

1 l0 }) |7 E0 h2 M5 p8 X; X3 Q! A
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;
; c3 Y* z, k1 _6 ^; h
+ \. \4 U. G. b% j" @) O
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。

4 c& N7 p% A5 n9 ~( a, q& L6 d2 q
3 h# ?# R/ N4 U$ ?4 c
所谓敏捷文化是个啥?抄袭一张图吧,简单点:
$ y. C1 \' v5 z6 h; x8 y
1.png
(图:敏捷,乃至DevOps所需要的文化)

& r7 d' i- M7 V6 s$ J8 E" E

! b" y7 a0 r2 ]0 C  i
3 |+ X# p) s9 j# o/ W- }
挑战二:配置文件的困惑
7 C5 l  p; F6 r2 U+ i. B
* H" r" ^4 ?1 Y' p! Q
1、没有DevOps之前,配置文件是怎么玩的呢?

8 s0 V6 o8 W5 L' w" j
+ T9 J" n  V9 {5 l2 a( @
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:

( C5 L' ?% y3 K+ b7 N* S# T  {5 s) G( N: P8 Q! t9 f' ]
配置文件位于classpath下

7 o$ q6 R( ~" t6 _0 W
) s6 I$ ?7 \0 t! J' @
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:

/ _; t0 ]* t& }# k6 v
1.png
* h7 F  M' q" K: B
: y/ H5 C) Z  d1 U. }! K

  Z( ~4 }, N1 G! h) w
如果有多个配置文件加载,则:
9 D- U  [8 U9 }4 g$ }! a7 N
1.png

9 N4 U2 g+ ~$ k6 J1 E. r! e5 H+ b
配置文件位于外部目录
" J  j+ _- Q. j! n

$ m8 A4 Y$ a$ g. [9 k' S1 Q6 _

; E0 _! e! N9 ^0 o% F8 }! G, `$ C
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
3 k. _3 x2 r! U+ a) ?% u/ l
1.png
$ s7 n& Z& H( `
( a, l( m- L; z1 V% @9 c

. u6 o* ]7 G: W8 `+ a
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。
  M* i+ Z/ a, l! F, x9 i- f' y

; t' g9 K5 T* s  S, M6 u
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:: ^; I/ c* @* v: F; w+ l6 h1 s, h! p% d
! w0 w. E7 O0 P- z$ U
* V( A* E' F  n# Z( P
  • …………

    4 ~1 I% t0 C5 R
3 i3 T- s- K; r# d1 M- M
* t7 ?/ K2 o; U7 e) }0 p# I& \
  • 配置文件的版本如何与程序版本对应?
    8 o. D3 Z1 `0 c- `8 E
# Y+ D) W8 T0 i* _
  • 配置文件的管理如何更加简便?

    " Z9 \2 O6 p+ s% U, \

' F# U# @1 x" R$ W7 ?

& G' {( N: a; i* D* _: L. V$ U2 M
  • 配置文件的修改该有谁来操作?
    + }; S# g- y) O. {: c: |& O# m
7 e$ J8 l: R- m7 ^  ~+ T
3 q# W' y/ A) J0 u
  • 配置文件的更新是否可以不影响正常服务?

    1 b- x: a  u- g% H  L1 a& u9 I

, f1 ^" V9 O- C- j
  • …………

    , n+ T4 S3 l) k$ ^' W

+ C/ [; T6 y8 H( v7 T! Z; ?
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。
8 w5 }6 V. O7 y% P6 m6 F7 T7 {. e

1 K) h( H& h4 U! ^
撸起袖子,不要怂,咱们搞个配置中心吧。
$ g. J/ P9 @" ?' I" @
& D" K2 K- P7 D3 R3 J
2、有了DevOps之后,配置文件又是怎么玩的呢?
( H- `5 m" a9 Y4 i; |0 V4 s
, @: i$ M& h* L5 x+ [3 v) v8 N
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。

, N8 q1 y3 c) t; E' A3 D

. ?& g# O/ ^- [& H
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;

& U, `& k% {+ S% T' g# f9 w. P% F
$ A% f. D; p0 {1 L& T9 a
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。
2 Y- I- B' c2 I" l( @: w0 V* n: v

% C8 U3 \: \+ u3 [1 ~
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?

. y3 S1 f' S, L
* X0 U% f) H+ c2 G* t
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
# l' b# O2 C/ h& \% T+ u0 ?" v: G5 B* c. s: H. b
2.操作风险:配置修改随意,无操作痕迹,易出错;' r. f" w0 p' E" S  t0 j5 g# N: w( y

$ b5 s2 h7 V& E9 `
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
9 G4 n4 Q0 o. g4 u& n* V+ i) T& m& K; n4 ]5 Z  K/ Y/ V! o
) G, C% |1 h6 k, G6 s. J) B

- e0 y# [  g: Q+ A. g* E0 e& b3 g9 Q' h
1.png
图:配置中心在DevOps快速交付通道中
/ ]0 m) c+ E. o1 W
( q) W- i0 Z6 O, I' `7 p
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。
4 i4 M2 b2 l, x2 D- |- h
3 r* _( V! h; ]; E# l
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?
) ^/ F* U! f/ q; o3 }& T4 {% b

$ e3 m9 E8 j, Y% i/ Q# E9 ?4 Q, k+ D
无法满足我要求的,我不接。
5 N. M! J& @# {. O
; ^1 k* _+ ~, f  l) p- Q* h
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。

  m8 J8 ^2 B' K) U7 g$ x  g
9 a/ X: K  Y* t* C/ _6 I
三种适配器
; n+ O% ?% P& u5 ~
. l* ?' ^. a8 x
1.png
图:适配器Trade,满足原有使用Properites的诸侯们
  S& j* _6 a. h. }: ^. N1 e/ T
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们

$ d* y% }! b3 C- A
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们
* f1 p: P* ?5 M
. q/ {2 R# q% a4 Q; z) p; |' ~

# {+ x; X! t' I+ A7 |
两种推进器
1 v# |  w. o0 J; R

  s/ L3 A: t0 E  R' F6 y
1.png
图:希望采用 “文件被动加载” 的诸侯们

' t4 j& M6 c% x! e6 {
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们

. `$ N# p# F. h6 Z! G! X/ Q  b
) n5 I, k1 F- v; x( a, W
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

' \* v- y; ]& P8 m- n

; o( M3 ~; C: _/ d5 R+ \: J* k% q
有了配置中心,诸侯们的确享受到了福利:
- t- U( {4 j9 D

- w' E( p2 _1 s
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;
  [; N& @& }6 Y- J

% ~# a9 M7 p; Q/ _5 ]2、配置控制台提供鉴权、操作日志等服务;$ Z& L* p: g  }0 E
8 k- C+ |4 |( y, e' w
2 @. c! i9 v8 M$ K# K+ K
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;5 ~* j6 o2 Q5 N7 p* l
7 l( [* v6 Y" a

# _! Q- ^2 u0 d4、配置发布后,实时通知应用端,无须重启即可使用;) }1 @7 h& u# J

2 Z0 I% b. P' z$ a4 V) @5 q2 l* C4 f$ K  U: a7 s
5、配置版本支持一键回滚;
0 C, w9 w) P5 b1 F7 o5 u
, Z" E% [* ?6 g. p6 W6 A8 `
" H0 s* @* e& m7 [! p; Y7 k6、配置控制台实现了整体复制、导出、批量修改等功能;3 R4 o/ S3 m  e9 _9 d2 f" T! [7 v! s3 {
$ m: I0 ?  w, y# o! W) ?' g/ I

2 `1 \! q! w$ f4 c/ W: H! T! z' `

7 T3 U& _4 z$ S* W2 {# J
3、小结
2 {$ K3 S1 x- @- q
, P. _" ], x( ?. t
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
1 M* P9 {8 W! L! e- p+ v3 P' h
9 H% {) S' Q- N% Z1 |$ G" i% M
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

  `: I! a7 O& D3 q

本版积分规则

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

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

Baidu

GMT+8, 2019-3-20 03:45 , Processed in 0.238272 second(s), 38 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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