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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

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

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑
  o$ i  o/ o  F
3 ]6 b9 V" k3 L& [2 ?& E- B
6 ?  n% W. ~2 b
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。

. L1 @) W+ G7 J! }

; v9 G4 C( r" q! w( O% J
* U7 z9 E9 G9 O# }0 r( H6 P
挑战一:敏捷文化
% ?0 k0 o& }# T6 K  `5 ~/ J2 }

8 G! E2 P4 b0 X$ C% O) e7 J
1、切换敏捷之前的过渡区
. |) f2 ]$ y3 R7 N2 F2 r8 C2 X' p

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

5 ^; R& l8 f2 a
7 P8 N2 x! }( u& Y7 Y
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……
& @# L; [0 s( E9 B  M
) b. c8 g) R2 Y) i$ F- _# g
开发结束啦,已经提测了,你问问测试吧……

  D) `/ ~; f+ ^' W$ @. o

, V. ?/ H- q( C+ @, t
问问测试吧,什么时候可以发布仿真环境……
- i, i/ m; Q; S5 L6 N5 a
. i5 k3 G; D/ `) Q4 k/ Z  e
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……

' B: F( Y& L! A! p
' c. b/ @7 d6 W$ z: d
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)

# |) S; Z6 H- h3 K9 I& R8 V7 e
先用迭代让业务快起来,敏不敏捷不着急
" G& c$ M* V9 Z( f. m8 z4 q
# j$ M' r+ W* R" l: s
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
/ ?' k2 n7 z4 }/ Q& {. V$ B* T
% d1 C0 [% F' x4 Q
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)
1 I5 {/ u& P3 H& D4 \
+ g. h& e' a7 y, T# c7 C$ ?

; _3 s3 r& n/ |# S& _
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

8 R( u! Y1 y' e! [4 [% `
1.png
(图:瀑布与迭代的区别)* d4 P5 u3 ?$ r0 n! }1 i

. y, ^) o+ i6 G* J3 v* f
1.png
(图:瀑布的特点)

( k7 A+ d7 L4 @4 g
1.png
(图:迭代的特点)

' W3 r; T# @, t( R* R: i. y
1.png
(图:迭代与敏捷之间的区别)

- t1 i8 G0 ]* K5 v9 _

7 O3 _7 e- n% |* |- a8 o( z6 u
3 K& c' l7 s9 U; G4 U$ R
2、大家都缺乏敏捷文化
9 x$ ^) @) \1 a8 L+ p; u

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

: E: E: P* |6 v  P
6 N! N# ^2 Y. E7 n0 S0 A+ f
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。

) M  S  p4 L+ j4 Y7 f) K
1.png
(图文:跨职能产品化的组织结构)
6 `) _) i) X  h/ I7 i1 j8 G% L/ v4 `

3 n0 e! s7 Q0 {- \
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。
2 K4 ~: X/ i5 P, H

4 _% a# P  z" ~7 f
如果系统发生失败,例如生产环境出现问题,这必然是由于系统各个部分相互作用(从想法提出到软件投产各个环节的相互作用、系统与其它系统间的相互作用)产生的结果,对其中任何局部进行惩罚无非是寻找替罪羊,有害而无益。这时候组织真正应该做的,是相信每一个人都已经做出了最大努力,将相关干系人拉到一起对问题的根因进行分析,找到能够有效避免类似问题再次出现的解决方案,并确保该方案得到实施,对其效果进行验证。
" v7 w6 X. d7 y. Z/ d! H' \
  _" B: T6 ~- y% [
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
7 }1 L7 H; X+ B8 @' E3 K0 _4 P

" i) R5 t( _+ Q; Q; Y: L& ^7 G) K
. f: P( K5 [: e% g
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
; `9 w$ I4 l- W# X* I8 H
1.png
(图:网络游戏 - 混世魔王形象照)
' G( T. K2 I1 v$ A) l  k
4 ^: \& P; F! V9 t. z

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

0 u/ [8 E/ t# E9 N+ z" \
) `/ v) X! j% d" S) c# q
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;
% w& d1 o7 F3 {; L) y

3 W8 t6 p1 c/ d6 m4 d6 j
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
3 H3 `- u+ ^5 N* B) t$ o: c2 ~
  o- Y! u  v5 ^* f) @3 z7 x/ D) p
所谓敏捷文化是个啥?抄袭一张图吧,简单点:

# ^# w1 W2 A0 s$ L; E4 f2 q! _2 q
1.png
(图:敏捷,乃至DevOps所需要的文化)

% Z+ h1 `2 n' N7 M9 R% l

% V0 g$ y/ f) j4 v( k+ p+ r

0 c- w5 b$ w$ E: c7 z" G
挑战二:配置文件的困惑

: N' B6 [( v* }7 z, ]

6 V2 ?! \8 M+ t: y
1、没有DevOps之前,配置文件是怎么玩的呢?
- z7 [' `+ [4 M; u: @; x& m5 q% |/ U
3 T2 \& O# w0 W
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
) P- @  o5 U7 A/ j' d/ g2 M
6 W/ d8 l7 ~* s, w% u* `5 F0 P
配置文件位于classpath下
( @( M8 K. Z, `$ e

& g2 h4 j0 {* n* P0 s4 n4 {) |
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
1 T& k1 g. ~+ h; A6 s
1.png

8 S: g1 n8 Z5 y& K8 G" q

, m, O3 i* m: O
* n  K* h! w, M9 j: {
如果有多个配置文件加载,则:
1 [% e/ s# f5 ^  u) B
1.png

% K$ e) b4 d  k2 x! a
配置文件位于外部目录

- E5 f. `! x- z4 d* b

9 a; ^6 r% h/ l

; T( t4 F9 L/ T1 E
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:
) n% o+ j; @. y% F7 c& X
1.png
. s1 C! A( y6 [8 |7 T6 q

( f6 M& I2 k/ r7 a) Y
! L9 r- V/ ?4 i# ?1 G; H( |
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。

9 f: d3 c# {) M/ ~/ ?, [) u$ z! x
1 d# H3 P6 r/ u& l6 r1 R
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
, z* w* j5 q) e# |8 l& H" t+ _
" m' j: d" C( W& F9 ]

1 ?" v7 r: C+ f4 ^0 \) g2 d
  • …………
    2 c, k' S, n+ h' t2 z

6 I4 A) ]4 Q8 k8 [1 Z1 u

! T( ~$ ?6 |/ n  @  d
  • 配置文件的版本如何与程序版本对应?

    ' Q8 h# S7 x$ R% f7 P

6 Z/ Y  V/ K- g' J* @
  • 配置文件的管理如何更加简便?
    8 Y3 h% ?1 N" l, e* `) p. ?
0 H. i. O  G) I% j. V  R
2 N* B5 s6 w! d: p, [5 u" `
  • 配置文件的修改该有谁来操作?

    9 h; M6 d! b! N8 t

/ ]# y0 {3 y4 c6 U

1 J  t* p( ]/ y& }/ K" ^6 t6 {
  • 配置文件的更新是否可以不影响正常服务?

    ' L( s1 [. C% h3 a
: Q4 s9 T& _0 T, s- H+ p/ ?
  • …………
    : R+ k4 r* r% d
6 W) G* L7 b  |% r
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。

( f0 [6 ]5 f4 A7 h
0 M! }( v6 j: C8 X4 S
撸起袖子,不要怂,咱们搞个配置中心吧。
0 y  ^, _8 r2 I  h3 Q
7 o2 x! D9 a$ R) I2 \4 U; @1 H6 Q8 o
2、有了DevOps之后,配置文件又是怎么玩的呢?

! e" C! a3 P3 D3 u0 i. U
- C+ m6 ?( r: g3 L
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
+ X+ u; [2 I) E) }( p% @
9 ]2 m# h9 @( n  z
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;
) `- |5 \+ M5 _- F1 v* s
4 R1 S6 X' u- w8 [
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

, j5 M4 J" z) [
9 O3 j9 l( f; u( ]  K* y% G
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
1 {" |- I, g# s' T

* P5 d: M# ^% `, r8 |
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;
+ R. X2 t9 a- X: R7 A4 y7 A# W4 T5 o# v
2.操作风险:配置修改随意,无操作痕迹,易出错;
" M% T8 N- S/ u/ t; ~- k" r
4 O% L1 u- ?$ O& I8 R2 \
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
  {# X& X+ T0 L2 a  w$ `# |" T$ a. L4 J4 j
2 t) M, Q9 r9 Z( S

: |" L) G5 b) ]+ t8 @
1.png
图:配置中心在DevOps快速交付通道中
6 t" `% ]2 J+ v, l
& m+ P: m7 y0 r  M- H! B3 q4 f
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。
3 ?1 B; r( H) F8 O

2 W  o4 O! m9 G1 C$ w( }
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?

( \; L/ h2 U+ ?; O& H6 w: q, Y3 Y8 M: \9 O! V/ V
无法满足我要求的,我不接。
! J4 k. w. z- m7 x4 j0 g5 c& z
, @- I: E; z# E- ]; e
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。
- K$ N: w6 N% z
9 t3 D" {: U" Y: b
三种适配器
; E) t6 [2 G% [& A% l* A

+ p' |- s% F, f! z4 [2 b0 ^- `
1.png
图:适配器Trade,满足原有使用Properites的诸侯们

+ c+ @0 a% ]! Y6 l
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们
7 G+ o  u6 D6 [8 N7 l
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们

3 f. Z2 x# H9 S
# R3 D  L7 c  f6 W0 k% f, U! s: ?- e5 z6 {/ p
两种推进器
. z+ w1 E7 C+ k# ~
/ q# C, }% y' s% o  o+ W
1.png
图:希望采用 “文件被动加载” 的诸侯们

3 y" `% {& z* w1 a+ a
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们

* U! L6 i5 t# `# k4 S% F1 Y
* g3 g+ `8 N/ V8 \
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。
( A, V2 ?3 }( y6 j: W6 h' B

0 G$ Z" Z# P5 D- o' ]+ |5 g
有了配置中心,诸侯们的确享受到了福利:

/ L1 s, C8 `# |/ h
& d( I& v; d/ {6 [% }. d, ]/ W
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;

. O/ r0 O2 T. `
8 _, a# d% v( v' E
2、配置控制台提供鉴权、操作日志等服务;5 e9 M2 x6 \5 ?4 C9 [
8 Y+ c' \) P* s  f" c6 m; u
6 K6 }" t7 G: z# l  {8 z. k' v0 r
3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
/ S  z5 i7 f7 U4 J
9 d  s1 L6 k5 U/ I
& m7 A. ~7 a: t: H+ L1 c4、配置发布后,实时通知应用端,无须重启即可使用;- f% D$ Y4 [6 ?  A

9 d/ v- }' L: G5 _5 C0 `7 b9 K) J
5、配置版本支持一键回滚;
* R4 s4 d: P- W$ H: {6 I6 l; [- }

  G. Z2 K- A3 a" g& @" n) z6、配置控制台实现了整体复制、导出、批量修改等功能;
8 T* S' M) x1 R& W/ R( D

8 n- b5 x, u: X
" u1 _% E6 T) v- |: o' d

2 s: b$ G8 P- X0 ~  r! k0 h
3、小结
! f9 U( i) l4 m4 q
' ?; W6 h0 s% x' }" `( d
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。

% R% [. p, c# F4 I8 A
* O/ t6 z- b1 V  y
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者
  q- A  H& j- _6 s

本版积分规则

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

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

Baidu

GMT+8, 2019-1-23 22:55 , Processed in 0.246906 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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