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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1653|回复: 0

敏捷文化--我们在实施DevOps时遇到的挑战

[复制链接]
发表于 2018-10-19 10:39:53 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2018-10-19 10:41 编辑   _$ U8 K6 o# [/ b4 X) k  D

2 r, A5 a7 m" E6 W( [" W) s' i
1.png
题图:敏捷看板

; r7 S$ h/ W" R' w- [$ P0 Y: ?

  S* k! B# w9 m2 r( r/ v
现在只要搞开发的人,都在谈微服务,只要搞运维的人,都在谈ITILxf.com" target="_blank" class="relatedlink">DevOps,但对于大部小伙伴来说几乎没什么经验,对于大部分企业来说也只处于尝试阶段,虽说如此,可感觉大家在制定目标时,都不太喜欢给自己留余地,把规划写得很大,功能很全,甚至恨不得一夜之间所有问题都会通过微服务与DevOps的设想凭空消失。

& D( `1 g3 C3 W2 [- F) T
% N, l) Y9 ^+ ]; V5 h. ~$ w8 g
早在上半年,我曾向大家介绍过好买在这几年中实施DevOps的一些经验与教训,但绝大多数内容偏向于技术,对于其他方面说的太少,从本文起,我将通过一个系列向与大家聊一聊 “我们在实施DevOps时遇到的挑战”

9 M4 N& P1 r/ Z5 k3 k# m
8 ~% c9 @# I' E( H' h8 f' s: D# T
切换敏捷之前的过渡区
1 k; v% a5 U7 C2 n
/ l1 ^0 i$ r/ E% O( B! I
对于许多草根程序员来说,提到敏捷所能带来的收益,条件反射的会说 “能快呀”、“不用写文档啦”

; R! L9 p+ s/ r2 P- k5 @
* s8 o( I8 M; ]) `* \, [8 q/ L
不能说这种说法有问题,只是不够专业,在实际的工作中,我们是否经常会听到这样的对话?

, }, C2 T. n3 q3 f

" n( L% j9 S9 |  X9 x
行,就按照你说的做,我写个需求规格说明书给你

0 B$ j0 V% i6 r+ H) ?
1 C" K* r! D1 S( Z" J
好的,写完别忘记给领导审批,然后我按照需求做个设计给你看下
……

! X8 Q; Z% v  X( C

6 L  p8 p$ i7 }9 R& _5 W% [
开发结束啦,已经提测了,你问问测试吧
……
7 H$ l) y9 ^& Q: V9 `! \5 g
- @$ u- m9 O: v3 y  f% @9 f
问问测试吧,什么时候可以发布仿真环境
……

7 |, K' m8 j, q  @- \- }

6 b  p: U. y7 G1 c, d
又改需求了?别忘记先改需求规格说明书,要不然代码和文档对不上了,改完我再开发
……
/ z: x6 l" d3 i3 m4 p. E0 Q
7 a) Q0 D' w7 v1 O( Y& ?% E. F
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说,直接切换至敏捷模式,无论对业务、技术及架构都是非常具有挑战的,这种挑战多半来自于业务场景与公司文化的限制,甚至是组织结构的局限性,不但不能快起来,甚至会带来一些意想不到的灾难
# a/ y) L$ M# u- l" y: }6 g4 H
1.png
(图文:职能化筒仓式组织结构)

0 A9 H( Q& m, }) W

1 Y0 z& v: \3 L1 p+ c
先用迭代让业务快起来,敏不敏捷不着急

/ }2 r1 f& r# M$ ~; H9 e4 l; ]

0 M5 i0 W6 I3 P6 D* }) G
对于金融类企业来说,多半是业务驱动模式,业务关心的是 “快上线” 、 “别出事”,至于技术是用什么实现,敏捷也好,糊上墙也罢,他们其实并不关心
+ a! m9 W( K% t: `+ J. t
3 o$ p( S& N" L7 e) J1 L0 w
为了快速让业务获得收益,在采用敏捷之前我们选择迭代进行过度
9 n% H% X) z4 u; u
- R1 r: M. |- s/ z
举例说明下迭代给业务带来的价值:要计划制造一辆汽车,它最核心的功能是可以在路上跑,所以我们可以先制造一个踏板车,依次迭代为滑板车,自行车,摩托车,汽车
1.png
(图文:正确理解迭代的方式)

: \- B- Y9 R* Q3 |' d$ X: C$ N
% _4 ~5 j9 W+ k& v; N1 G
瀑布 - 迭代 - 敏捷,三者的差异是啥呢?
1.png
(图文:瀑布与迭代的区别)2 u: n3 h: K; ~, J+ ^
1.png
(图文:瀑布的特点)
1.png
(图文:迭代的特点)
1.png
(图文:迭代与敏捷之间的区别)

9 [$ _2 P$ S" h; b  j

# m3 G1 `# o" ~4 r

6 F6 [  K+ C7 y- o# @5 ^
大家都缺乏敏捷文化

! F0 s* o3 v4 e2 w" q* J

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

8 J- B9 i' W% s* X  J
1 d$ W* H: \2 c
其实,使用迭代过度也只是权宜之计,真正的问题出在文化上,旧有的组织治理模式产生了各扫门前雪的官僚文化,没有责任共担,以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维,可能源自组织的绩效考评和激励制度。
1.png
(图文:跨职能产品化的组织结构)

6 q' C9 ]1 T8 j. D" f


& ~6 j. [. M# K% Z" o% f! C

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

" f' G" C% |  M- x


1 F1 c6 D9 m" W: t9 s! D

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

3 d8 ^( C9 H' K1 i, G! E$ @


8 G9 h+ u, m  x1 R

这是ThoughtWorks在一篇DevOps文章中所提到的,我觉得一针见血,不过对于大部分企业,尤其是金融类企业,实践落地所付出的周期与成本可能会更大一些。
2 @/ T- g. [! m6 O2 L& y

& q; w' e* j- f/ k9 Q" \


8 m8 x3 p' u3 Q2 J- v

再举个例子,我曾经说过,我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”,英文名叫“ChaosDevil”,这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭,以此来测试生产环境的快速恢复能力,促使各团队提升系统的稳定性;

1.png

(图文:网络游戏 - 混世魔王形象照)

8 l, L2 \2 M7 c- s, ?


, E9 s- D- h4 z; Q  W, @

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


, `. f- L& f2 ?% z


0 a7 H" f" f% P$ w/ m0 L4 S

然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定,会降低自己在上级心目中的“有能力”印象,随之而来的可能就是问责、惩罚;

) m2 c; g7 A$ x# p4 y


7 f5 t, S# [# c% i

这样的文化下,大家真正关心的是如何给领导“表现”,而不是在真正的系统稳定性上追求卓越。


) s7 X! y2 Q: u9 d/ O% E


# ?+ C' [& ]# W" s$ ^

所谓敏捷文化是个啥?


2 u4 P8 H, `) A


+ d$ K$ W* ]8 e4 U, z; u

抄袭一张图吧,简单点
1.png
(图文:敏捷,乃至DevOps所需要的文化)

/ h+ J, }. V) U; W4 N* E3 a: O
原创: 王晔倞




上一篇:攻克痛点:DevOps线上部署的最后一公里
下一篇:Capital One (美国第一资本金融公司)的DevOps案例
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 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 03:25 , Processed in 0.116097 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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