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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 356|回复: 0

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

[复制链接]
来自- 湖南

参加活动:0

组织活动:0

发表于 2018-9-6 15:54:19 | 显示全部楼层 |阅读模式 来自- 湖南
本帖最后由 adminlily 于 2018-9-6 16:09 编辑 7 ?' ^. E! y- }5 e* y9 m; Y& E5 d' i
4 Y) [4 {; \* i+ R  v8 @

& p1 n# n1 }3 f6 }
  现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。而从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”。
/ ]& q! k* @6 g6 a& Z4 T' m
+ l8 V5 q0 I1 x

; c" ?# `4 s5 s1 G% a, X1 n
挑战一:敏捷文化
- s3 s+ \! x/ B: S% H* j
  U& ~; M  g7 e4 p) Z3 U: P
1、切换敏捷之前的过渡区

! J+ N6 o" l% y
8 b4 Z; U& H+ x+ v- C
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射地会说 “能快呀”、“不用写文档啦” 。
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

" C. Z4 L% O( T# `2 `& L2 p3 _

- D) N8 R2 ~- J+ ^, I
行,就按照你说的做,我写个需求规格说明书给你
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下……
4 |7 c: a; ~* e+ F4 a

/ ?) @4 {0 U- n& E  q
开发结束啦,已经提测了,你问问测试吧……

7 S& k* c) ~- Z$ R: M
/ D* y3 R! T/ B/ ]. f% L
问问测试吧,什么时候可以发布仿真环境……
) V( h* g6 B, _

! x* m; z2 l( ~( d& v
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发……
- W" ]; U7 s# N8 E& u2 s( d6 C
/ M* X; u! s1 {, R; |" v! d
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难。
1.png
(图:职能化筒仓式组织结构)

' X' Q5 }) J( }# R
# W2 X' f7 g8 C9 |; i7 `/ @# q
先用迭代让业务快起来,敏不敏捷不着急
2 \  p) _" f6 q4 y: X: C
* ^0 S4 g; o) U2 p
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心。
( _- I) c' F# m
6 X$ a1 n5 B+ k1 s! Y+ C
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车、自行车、摩托车、汽车。
1.png
(图:正确理解迭代的方式)
8 C5 C9 h/ [4 g4 r# i4 V0 e
9 u# K+ }0 U- a+ O  V" y$ \4 W
$ f) V- z( g) g0 h1 l1 W( ~
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?

# S+ b6 h' J3 x7 E7 I* Q& U2 q7 I# M
1.png
(图:瀑布与迭代的区别)
' e: Q$ p& i+ ?2 N- M2 h- B* X
, [/ D8 T( v: P  L1 d" j
1.png
(图:瀑布的特点)

1 b1 w& a. t& l/ O9 ^1 b
1.png
(图:迭代的特点)

. [5 p- w. t) Y8 o+ X6 j8 T& n
1.png
(图:迭代与敏捷之间的区别)
' w( ]5 M8 Y$ ]3 \! n% F2 n$ T

! M+ b& k, H+ e1 y
2 k* m+ |3 @9 f, `* Y6 X
2、大家都缺乏敏捷文化
+ ]$ _5 h  V$ L" d8 |9 \
% i3 b/ V0 c8 Q
从某种角度来讲,目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的,开发和运维部门经常会坐在一起探讨,就运维流程如何改变、自动化能力如何建设等,然而自始至终无法突破的终极问题就是:无论我们如何改变,如果万一生产环境出了问题,谁承担责任?因为DevOps能力的建设需要一个过程,开发团队不敢承诺完全承担责任;而运维因为弱化审批和控制力,也认为不该为其承担责任。最终不了了之。

( x( a% n( ?# N2 q

" F) }5 y: q' D( D; @. _8 ^
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。
* M, G4 I  ~2 Q
1.png
(图文:跨职能产品化的组织结构)

5 x( V5 E8 n3 C9 |: ^, @3 X

% d3 k6 i8 y; z
 现代关于“系统论”的研究已经在很多著作中强调,一个组织就是一个由人构成的复杂系统,组织中每一个人所能获得的信息是有限的(包括最高管理者也是),每个人或团队都只能基于自己有限的经验、有限的信息做出决策和行动。

7 X* g1 u& a+ M/ w5 x) Y% J* |

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

: J: e3 c- {5 |( r, t# F) M
2 M4 M! @) n5 V4 q' O8 P. E
这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
& |3 E- |! ]4 d
& Q" D4 }" |5 E( I1 [

' a! I' O7 G* {" z3 S6 r
再举个例子,在「讲个‘理论型’高可用架构的故事给你听」我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;
9 u5 R6 \; |* _3 y# A' W; E- E% r7 N
1.png
(图:网络游戏 - 混世魔王形象照)

" C1 Z; O. a. g+ \# D, k9 e, J( i

  U4 z1 }6 b1 w5 W3 h

# J9 u! a* u* ?9 F6 @8 q( A4 m; H
有趣的是被指定优先使用的团队口头全力支持,但实践起来却迟迟延误,当然大家都比较忙,这也是可以理解的。不过我们可以设想下,如果没有这个“魔王”,大家可以给领导讲自己的系统很稳定(只要没出问题);
* ~- W, s4 d: ^% L9 W3 t8 Q
2 Z7 u, e: Q! H! U0 Q! X" ?* C
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

& N: j+ O+ c) C7 Y+ j) S. U
& i, Y( q6 Y" S
这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。
# {# @8 ~" a; @1 V# P3 c4 l* g/ b. j
, s; v9 S, ]6 x4 ~# q' i
所谓敏捷文化是个啥?抄袭一张图吧,简单点:
9 \; k* B* ?0 E
1.png
(图:敏捷,乃至DevOps所需要的文化)

& |# r2 D! l# U0 i& u& Z4 e  J

& n; k9 b: d) V0 o& d4 C  q" \0 d( J

9 _' u: b- Q0 e
挑战二:配置文件的困惑

3 j4 E- a, P/ m8 _4 q/ E3 M

. W" e+ g5 j6 A. T
1、没有DevOps之前,配置文件是怎么玩的呢?

  O( u& k5 v' }/ D# X+ J) B! H
" G8 d" I/ \6 n  H. B7 m
在「群雄割据」的时代里,通常一个Jar或一个War就可以打天下,以Spring+properties为例,对配置文件的适用场景基本可分为两种类型:
1 a% O9 M* T; o  V: S
% [6 h3 X7 j6 _  k6 E# K
配置文件位于classpath下
! _( u. j' s' c0 s1 [" i5 v# K

, h+ }7 O  {" c) o9 A! C) S
使用spring的org.springframework.beans.factory.config.PropertyPlaceholderConfigurer类加载Properties配置文件,通过源码可以知道,默认加载的是classpath下的文件,配置如下:
/ t' B, f7 o/ r3 ^6 T
1.png

8 [8 m$ g& F% D! \

; ^1 @' ~! a, u9 m1 k0 d% Z. L
6 e7 X5 A/ c9 C; P
如果有多个配置文件加载,则:
- T* Z: s% l: l. H" c& u
1.png
1 Z2 E* H7 }5 b2 l, V) `
配置文件位于外部目录
4 U+ P3 `  u7 l* N+ L5 [

- U- }# s3 ^( r( W* H, {
3 l& e' M( ~1 C. s  z$ v1 A) o
但是对于外部目录的配置文件,使用org.springframework.beans.factory.config.PropertyPlaceholderConfigurer也是可以加载的,不过要修改他的路径配置方式,如下:

1 n' {. E4 }' j
1.png
* E% E" R. Q( v

- _( Y1 E3 B6 \% y& e" v+ }: r

0 }; {- _0 A4 B8 g- \  T
这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。
9 E& C# T, n- [% x" S1 C3 N3 e2 S

% Z; A! F. R  J1 z- s4 n
当我们从「群雄割据」来到「天下一统」的时期后,虽然DevOps提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:
3 N' w) E+ S. g% @
) Q# d' j5 d3 `6 m

' ]) {5 N% ~4 D; Y
  • …………

    $ Z; {6 D" c' G7 P

# p* f9 T6 @' P" c2 p5 t, i8 T
+ Z6 l5 ?3 v  l6 p) @6 M6 j0 b! e
  • 配置文件的版本如何与程序版本对应?

    3 K8 f7 L9 L1 z5 b
6 T2 _! W+ L3 p& A% x/ [
  • 配置文件的管理如何更加简便?
    1 G/ N2 L2 Q; `

7 M' j, ?) \  l, H" j7 l4 @) ]# O

% w, }' @, r( `/ r
  • 配置文件的修改该有谁来操作?

    $ A  |" m! ~/ F! @$ Y
" P+ J; M9 s; y7 t+ n+ ~

+ x( Z% D+ H8 a  o5 J
  • 配置文件的更新是否可以不影响正常服务?
    : n" y6 F4 n. H7 E* m/ d

* a' a- [/ c' G- z5 [. M% [
  • …………

    3 |; q( q8 n% Y; r8 O4 n  f8 o
5 n- ?8 Q! t9 Y1 N' a( s7 n$ x0 `
无论哪一项污染,只会与DevOps扯上关系,都是让人头痛不已。

' }% d$ m3 w( U8 F
/ ?5 R  K& _; c& V
撸起袖子,不要怂,咱们搞个配置中心吧。
0 V/ x! m4 t5 b: w( G, Z1 z
& B# X1 H( \; ?' d7 q% \5 u
2、有了DevOps之后,配置文件又是怎么玩的呢?
3 ~+ E0 B  `- x8 v) d; P
: L- n3 j5 u2 J5 Y" K+ f! k' E5 J
其实想通过DevOps获得业务收益,无论从哪个环节启动,都将是一场持久战。
& i: N: J7 B, m% y) f2 `
2 P% x. |5 ~& L: h! C: o
随着系统产品化的改造,通过DevOps流水线的快速交付通道,任何一个交付版本都可以通过CI与CD环节后,利用自动化部署工具轻松地完成升级或发布;

" |, a$ k3 Y6 K; K
( U4 P4 p/ A% ~  W0 W" D" q: K
这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。

: {: h8 f1 i; S! `. E$ Y$ J- K/ D' X7 j# e
如果不将配置信息外移至配置中心,在DevOps中会出现哪些问题呢?
7 A9 P/ E5 K# P- O; `0 m$ a4 j
5 L+ {+ E  H5 r( ^2 }3 y
1.维护成本:系统拆分了更细了,增添CI与CD环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;& R  e6 S  ^% _4 O/ H6 _

* `$ w3 U6 r6 t& F7 F. K9 F6 [
2.操作风险:配置修改随意,无操作痕迹,易出错;
( {3 l4 t4 p( o6 ?5 F0 \1 T1 ?# X2 X) {3 y
3.版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?
  y' G, G7 @0 N3 t
4 g7 j# O! W& i8 e6 W

7 V  C- T6 V- c9 S9 n

1 ?. y; y# w% d! x. M/ j
1.png
图:配置中心在DevOps快速交付通道中
! Q3 A) {6 i  i1 d1 b
$ g6 R7 [* X4 h3 S# _5 X$ D
你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧。

' ]  h. I$ B* {  @, k

: {" I/ W/ f+ c) ~
的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?

7 W0 @; g0 R3 {+ q9 Z3 y3 Z6 S% T$ Y2 v
无法满足我要求的,我不接。
/ z) _' F+ B$ C! e: j0 F# w) f

% J4 u9 B; H; h- `+ \( c* u
这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。
# k/ _( N9 n  G- _
. u0 B0 v9 B5 @
三种适配器

- A9 S, E: \: O+ }  n
+ [  t: p# F5 @$ C% L
1.png
图:适配器Trade,满足原有使用Properites的诸侯们
  O5 a9 D. }- U# P& o1 {1 C+ p
1.png
图3:适配器Native,满足已使用过自研独立配置服务的诸侯们
, b1 v$ ~, d. h4 t2 k/ O/ @) p2 v; n
1.png
图4:适配器Ccms,满足使用Key/Value的诸侯们

, w5 k' g/ u  k( L5 Z4 A
( |9 `+ m" ]1 H/ U5 o
+ i; r6 o5 Z+ ]+ `) G6 c! F8 _# }0 N
两种推进器

1 r3 S  l5 V; W, U# V0 y

* Y: r( |- W8 H3 e
1.png
图:希望采用 “文件被动加载” 的诸侯们

  f& e3 Q  M/ a% i
1.png
图:希望采用 “Key/Value实时推送” 的诸侯们
# @1 Q; n9 k- W3 D. G- Z% B4 ?1 t

+ _  q* d, p. U' C3 q9 A8 ?( d5 I/ p
从某种角度来说,就算没有配置中心的存在,我相信DevOps的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险。

9 E, n5 f, e* z! \
8 ~6 n9 ^/ E/ K2 _# P7 T
有了配置中心,诸侯们的确享受到了福利:

7 [( b" K5 h2 w
7 U- i) x% f' J2 o: N9 ^" r; _
1、配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;

& i+ v9 P7 _2 F2 _* X+ e

2 h9 R: b# j# i4 T2 v; p2、配置控制台提供鉴权、操作日志等服务;
4 e" ]5 j4 y! S0 `0 W/ \( C* H9 Y1 y$ d# \, @% l

/ V- q+ r% ?/ O. M3、配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;
# _4 e! k, Z$ X
! u1 i  `: v2 _8 I) C* T  _0 ~4 M. ?% U" Q5 u5 b9 m6 Q
4、配置发布后,实时通知应用端,无须重启即可使用;5 f. _* g' N& Y# Q$ \- a. Y. G4 {
" l9 H% I, k, H% L$ |
5 t9 m$ m- Y8 V: R) M6 X
5、配置版本支持一键回滚;: n8 D' z7 H9 n# ]$ s. x5 v
: {' E. `- m$ H, z

& u4 O$ J2 s4 r6、配置控制台实现了整体复制、导出、批量修改等功能;
% x, O3 I" M( G
+ d0 a  M; o! }, k9 B0 h

. L0 u( j% F2 e/ Z( [

$ b9 {2 ^) V7 Y5 l) o0 e; _* s
3、小结

) o; \( t6 p/ y' m, S6 j, I; U

( H' E8 X0 K& z% C% }+ `
本章主要讲述围绕配置信息管理和使用在DevOps过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。
) g4 F# B) g# j5 `9 Q0 P
$ L5 {7 q% T# C) U( H% `
王晔倞,现任职好买财富平台架构部技术总监,负责好买中间件及平台化的研发及运营,团队管理和实施重大技术决策。参与了整个公司应用和技术架构变迁、系统建设,辗转过不同的业务团队,对技术与业务都有一定的深入了解。DevOps 的倡导者与实践者

6 K* r! \4 K5 H5 A/ @

本版积分规则

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

Baidu

GMT+8, 2019-7-17 05:27 , Processed in 0.220004 second(s), 30 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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