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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1210|回复: 0

你知道这些简单的DevOps价值观

[复制链接]
发表于 2018-8-23 11:38:18 | 显示全部楼层 |阅读模式
本帖最后由 monicazhang 于 2018-8-23 14:34 编辑
! V8 w& c9 ]7 M/ C7 Q9 ]* [5 j. B1 X9 b. G
前言' l; @1 Z6 R$ s9 E9 Y5 Q: `# M& b
# ^+ R( ~# |4 L2 p7 j$ b
Nicole Forsgren博士在DOES上的演讲,对里面的一句话Architecture matters...Technology doesn’t,很有感触。
1 _% q9 L1 @% P
4 I# I2 W9 \. B  ]+ b5 `. E
群里有同学也问到,初创公司,业务方向不明确的情况下,如何拆分微服务,我说“架构是服务于业务的,太过超前的架构是浪费”,由此想到架构与业务其实也有相似的关系。

7 F1 i. @7 G* A% o7 R

3 @  P& ~3 z( f% o2 B7 b 1.png
& v1 a' f( W) V) T. a. y
% Z; o& e! L" |: T
参考Nicole的句式,从ITILxf.com" target="_blank" class="relatedlink">DevOps涉及到的几个维度出发:业务、架构与技术;人、流程与工具;原则,方法与实践,于是便有了如下的几句话:
( X1 q% U! m5 l
  • Business matters...Architecture doesn’t
  • Architecture matters...Technology doesn’t
      h% \- d  U+ h
$ C, g' Q9 f1 z9 w; H. y
  • People matters...Process doesn’t
  • Process matters...Tool doesn’t

    " s9 \( \1 z" @9 j0 N7 q

! }0 _, g8 `3 u0 Z. M# X
  • Principle matters...Method doesn’t
  • Method matters...Practice doesn’t

    ( v7 f8 S3 M; P: {
9 n: h. w% ~4 C# f3 N
我称之为朴素的DevOps价值观。之所以朴素,是因为这只是我的一个比较原始的想法,并未仔细推敲与提炼;称之为价值观是因为具有相当的普适性;同时我也希望,如果有幸真的可以逐渐形成价值观,它也应该是简单质朴的。

3 h) Y8 |% X' x- W5 s
! j" h! y" u, m0 P2 W: A! D% w
2.png
业务、架构与技术( T2 r6 ?1 I2 W8 V) B# x& }
* O: R/ f$ c" v2 y6 e
8 x1 F, P  o( I, ?8 j) y7 @
业务Business,架构Architecture,技术Technology,缩写为BAT 🙂
) f  Q) I. \5 J9 ]) Y- c
  • Business matters...Architecture doesn’t
  • 7 M, S* @/ ]( I
架构是服务于业务的,关于初创公司,新型的业务,是否需要采纳微服务,回答当然是视情况而定的,但通常建议从单体应用开始。
( @6 X- ^7 L' c0 I
微服务的价值与挑战一样明显,所以Martin Fowler有如下的一幅图。
3.png
2 Q$ M$ |+ G/ ?# o: v

& G8 a$ p. n! w( l1 O
  U* ^, T. h- \5 K9 p* N
初创公司,业务方向还在不断探索,服务的边界是模糊的,即使对微服务的技术储备足够,也不建议此时就搞微服务架构,用最简单直接的方法搞定快速变化的业务诉求。
. s5 T# B2 x( \; K/ [
用贷款买房来类比架构投入,自己出的首付款就像是前期在架构上的投入,贷款就好比是减少一定的架构投入,所需承担的技术债务:

1 s5 x% g0 m4 e7 |( z1 W1 ~
  • 贷款买房,预期的是未来的房产的增值,贷款的利息相较起来是可以接受的;创业期也是同样,此时承担一定的技术债务是明智合理的选择。
  • 一味追求全款买房,就会错过买房的最佳时间窗口;业务的时间窗口更短,需要不断的快速试错,期望在架构层面一步就位是不现实的。
  • 不能贷款过多,否则无法承担月供;架构可以一开始简单些,原始一些,但基本的质量和NFR还是需要满足的;而一旦找对业务方向,又需要快速展开,所以架构在初期具备一定的扩展能力还是需要的。
  • 要定期清理债务,房贷车贷过多,即使是有力偿还,生活质量也会下降,脱离了原始购房改善生活质量的初衷;技术债务也需要定期偿还,定期清理,不能让因为技术债务产生的额外时间成本,大于承担技术债务所带来的机会成本。
  • 这其实是一个经济杠杆,用短期或长期的负债,来换取时间成本和机会成本。

    " \; n% q3 L1 s+ v7 s: `. }
3 ^7 K: c5 m" S( |) b
所以做架构也好,做DevOps也好,需要有经济的头脑。SAFe第一条原则Take an economic view,也有这层含义。
这是一个平衡,一场与时间的赛跑,但总而言之,业务诉求高于一切。

+ X5 Q- `7 p' ~2 H, I

# R* j2 e1 X1 ~3 f) G/ ~
以上所说的都是因为业务战略需要,主动有意识的承担技术债务;如果是无意识的负债,那个叫做奢侈浪费,原本就应该消除。

$ T( W% b) g* j& s" n' n
  • Architecture matters...Technology doesn’t
    / q! U* q- \( g) ~& a9 K9 ?; g
4.png
巴别塔:《圣经·旧约·创世记》第11章记载,当时人类语言相通,同心协力,联合起来兴建希望能通往天堂的高塔,“来吧,我们要建造一座城,和一座塔,塔顶通天,为要传扬我们的名,免得我们分散在全地上”。此举惊动了上帝,为了阻止人类的计划,于是他悄悄地离开天国来到人间,改变并区别开了人类的语言,使他们因为语言不通而分散在各处,那座塔于是半途而废了。

" B2 Q# ^3 _& y' U1 R- p
) K6 B1 P+ s! `( y3 @; q; y" w
架构如此重要,所以一旦业务相对清晰一些,就要根据业务需要,考虑逐渐切换到微服务架构,才不至于堆积太多技术债务,对于可扩展性、可规模化、可部署性等也都至关重要。

  \3 _& Q6 Z/ M* t4 \5 c7 R4 t) N

2 v9 F+ ^2 R6 ~8 v! o' J$ x4 u, t
优雅的良好的架构更加重要,不要让微服务成为另一座巴别塔。理论上微服务可以最大化利用各种语言的优势,但如果没有好的服务切分与架构设计,微服务只会变成更大的灾难,只会是碎片化而不是去中心化。微服务的目的是更灵活的协同,如果服务之间缺少沟通,就背离了微服务设计的初衷。
5 {7 z9 ?3 B- J2 _
' @$ f" J( ~) b9 u. v) `  q
Google内部有开发三大语言C/C++,Python,Java,分别是官方编译语言,官方脚本语言,和官方UI语言。坚持三大语言意味着内部沟通的顺畅。没有使用最新的技术和语言,并不影响,反而有助于Google快速成为世界顶级的公司。
. n" F* A$ V0 u# `: a4 |) V

6 o5 n  H$ l8 W: e( o
团队效率高于个人效率,统一技术栈带来的收益,往往大于使用最新技术栈带来额外的维护和沟通成本。

5 ~( b' g; [: z+ `2 g

1 n# ~: e) N- a3 O1 {
Etsy在2010年,决定大量减少生产环境中的技术,统一标准化到LAMP栈,“与其说这是一个技术决策,不如说是一个哲学决策”,这让所有人,包括开发和韵味,都能理解整个技术栈。
2 r0 \' j" \' K
2 w- c) y- m) F% f+ s4 y
另一个例子,Etsy在2010年引入MongoDB,结果是“无模式数据库的所有优势都被它们引发的运维问题抵消了”,最终Etsy还是选择放弃了MongoDB,迁移到MySQL。

7 f7 w% [+ A' Q' I+ i) [
: M! Z; _# ^# p7 y3 X, H
DevOps也并非只有Web应用、SaaS或是开放平台才适用,我们听到太多传统银行的转型案例,主机开发的案例,技术并非DevOps的绝对先决条件,虽然开放平台可供选择的工具会多一些,后面我们还会就工具进行讨论。

$ E0 o1 q& Z: w: C
0 N) @) V! ?# B: U6 K
技术圈总是喜欢追逐潮流,总是存在各种鄙视链。就像前一段看到的PHP与其他各种语言的互喷群;还有类似于容器编排技术,大家一窝蜂的从Swarm、Mesos向K8s迁移。技术永远不是第一位的,最新的未必是最合适的,永远追逐最新的技术,往往丧失了自我的思考和技术的积累。

. L, q) y% Y; e
5.png
6.png

1 ?# {1 l' Z& ]  C! j# a# w0 h人、流程与工具
6 R* }, m/ e, l8 t
人People, 流程Process, 工具Tool,传说中的PPT模型 🙂
6 S- W" ?. ?! V2 Y& C
  • People matters...Process doesn’t
  • / p/ C8 ~, B! i; W
最近敏捷微信群里沸沸扬扬的CMMI之争,不去论述谁是谁非。我早先也参加过公司的CMMI 2/3级评估,CMMI应该是团队做到一定程度,拿来对自身进行现状评估,用以指导下一步改进的参照。CMMI模型的初衷是好的,设置也还算合理,模型事实上也是在演进的,只是被不合理的使用了。
$ ]+ O' D, g; O' H/ B3 p1 o

$ X* X/ [6 w) @& ^4 c  U: @" n
所以模型也好,流程也好,使用它们的人,以及用法,才是最重要的。

, n* O% a  B% \3 g; I% p+ [

  H+ a: B! P. N; [: d& p0 t0 w# c
这就好比聚贤庄一站,乔峰用一套太祖长拳,打败天下英雄。太祖长拳,号称三岁孩童都会的拳法,为何可以在乔峰手里发挥如此巨大的威力?
( o3 m4 F" G* B/ s# Z) a

- I$ G+ l( a4 L& E4 @, A
具体的武功招式,方法流程,并不重要,重要的是看谁来用,如何用。
  L# s4 E* g2 b! E
7.png

) e& F8 q+ q, {$ K# \# ^, P! D8 N# n( Z5 y' o" H

4 e7 s& ~) n7 F% r7 c6 M9 }
关于流程的另一个问题:如果流程是最重要的,那么到底是流程要求的多好,还是流程要求的少好?

9 }; |* y: Q0 {

1 a1 K9 R% H0 r! `+ \" I% y
正如上图,Henrik Kniberg在《Kanban vs/with Scrum》里,对RUP、SCRUM、KANBAN等方法的约束给出了最直观的感觉:RUP有120多个要求,XP有13个,SCRUM是9个,而KANBAN只有3个。RUP是最重视流程和方法的,而KANBAN是最不重视的,孰优孰劣?很难讲,我并不觉得RUP就一定不如KANBAN,RUP在实际采纳时需要裁剪,只是因为裁剪的过程对人的能力要求太高;Henrik说,“Scrum和RUP的主要区别在于,RUP给你的东西太多了,你得自己把不需要的东西去掉;而Scrum给你的东西太少了,你得自己把需要的东西加进来。看板的约束比Scrum少,这样一来,你就得要考虑更多因素”。
% }2 ?+ M) E8 F$ k; u
" M5 I! b! Q& k& B4 u
一边是需要裁剪,另一边是需要增加,所以执行到最后,成熟的团队的研发流程,大抵都能找到很多相似之处。

2 {3 L) I2 {( [8 K0 P
  • Process matters...Tool doesn’t

    . k" v4 ~( a+ j1 N3 Z: Y
现在一提到DevOps,大家谈的比较多的,是如何用工具搭建流水线,如何用工具搭建容器化开发平台,持续集成应该用什么工具,自动化测试应该用什么工具,诸如此类。
+ p7 v$ u- y( L) D  H8 n: J, f
& G& ^# B8 p/ d6 d* r2 P1 |, @
我们常见的持续交付工具图谱,里面有太多是5年前、10年前甚至更早就推出的工具。如果工具是实施DevOps的关键,那么十年前就有这些工具,理论上当时我们就应该成功实施了DevOps,实际上我们又做的如何呢?
9 n" u: {6 r; i; ?5 ~# a7 {; q
8.png

+ [7 j2 Z3 a6 T) s
/ K3 a& a/ k! y
工具当然是重要的,没有工具是万万不能的。
; o7 L3 i* s. v! m4 u; Z2 F
) f+ L* E, ^1 Q& I- V' n$ h
但工具不是万能的,比工具更重要的是使用工具的方法和流程,当然比流程更重要的,是执行流程和使用工具的人。

* s" R" T+ i8 s$ o$ v7 C
" |8 N" g' I! P/ b
简单如SVN,复杂如Clearcase,我都看到过在此基础上,实施持续集成非常成功的企业。2 o* m: o( [% J' G: q4 e

7 G" {+ U! U  D3 _& K8 w
- O. [8 U$ r: V& O# h/ r
Martin Fowler对CI的定义和建议,从2006年至今,居然未曾修改过:
( {, e5 j, d7 ~, @6 p. S. r' D
- ]2 s+ ~0 ^/ w7 H5 o+ ^* [- f  D* b
即使到现在,又有几个人敢拍着胸脯说,真正能把CI这些实践做到的?
, Z4 j: R7 q! f
7 C$ {3 Q% w  {1 b
9.png

8 O. C3 D" F3 @
所以流程也好,工具也罢,最重要的是执行的人,而对人而言,关键的是思维模式Mindset,用今年的热词,我称之为原则Principle。
# m) h. k1 t* r+ q( `- h
原则、方法与实践
10.png
原则Principle,方法Method,实践Practice,缩写为PMP 🙂

! p  b7 ?0 V/ \  w. f: J" m  m$ A
  • Principle matters...Method doesn’t

    . X+ @0 G: J6 x$ {# y
敏捷的方法有很多,讲了很多年也还任重道远;丰田TPS被各大车企学习了30年,没有哪家能学到真经的;

2 z$ ]# |& C- m
有人说,丰田生产模式,最重要的是背后的KATA,即丰田套路,如何使得改善和提高适应性成为组织日常工作的一部分,而KATA的书出版到现在也快10年了,好像依然没有多大改观。
- X/ e5 q5 v! S6 `7 V& P; J

. W% l9 I+ D, Q2 h9 k9 }& `7 o
敏捷的方法有很多,SCRUM,精益看板等,SAFe是大规模的敏捷,DevOps也有很多种模型。

3 j% P$ Z" ?" l8 A0 K

; S  o6 `' `3 B/ b" {1 u
比模型更重要的是背后的原则,虽然这些模型从表象上相差甚远,但其背后的原则却十分相似,比如敏捷宣言的十二条原则,SAFe的九大原则,以及DevOps的CALMS原则。

6 h* T3 K' k- F: }  G8 P* M

* `$ G; _9 W7 l9 z
方法论的表现形式有很多,具体落地执行又根据不同企业千变万化,但不变的,相通的,是背后的原则。

; P& d- |, V- \% U( A3 ~: T
: ?2 z( Q- K! P1 n. u6 S9 s
好比张三丰教张无忌自己新创的太极剑,张三丰教的快,每次的招式还都不同,张无忌学的快,忘的更快,“不坏,不坏!忘的真快”,武功招式始终是下乘的,心法精髓才是上乘,守住了心法,招式就可以随时创新,不必拘泥。
  ^, p0 S& `% b4 N- r4 v; ~( Q- c
  • Method matters...Practice doesn’t
    1 \. f/ R3 Q1 U% _' q( b
《雷神3》里的桥段,奥丁的女儿海拉轻易的就捏爆了雷神之锤,索尔灵魂出窍,一时仿佛看到他已故的父亲奥丁。他向他的父亲求助。奥丁:索尔,你是锤子之神吗?那锤子,是为了让你控制你的力量,让你更专注,它不是你的力量的来源,你才是。
+ `, b$ l9 x5 w
6 ~' ?$ a% Y$ ~: L, s; }+ K
我们经常会得到锤子,锤子很重要,它是个开始。锤子又不重要,当你能够控制你的力量的时候。
(部分截取自欧兰辉朋友圈的一段话)

, v+ G+ _6 y3 w: U

$ H8 N4 V4 x0 n  m+ P: E5 \' q* E
DevOps原本就是偏实践层面的,有很多实践归纳,比如下图的Gartner的DevOps模式和实践图,还有DevOps地铁图。
! p/ g8 g7 B/ E5 g
但这些实践都只见树木不见森林,缺少彼此之间的关联和依赖,需要方法将其串起来。
1 d0 M2 K4 \/ D7 m0 O

; h# c) n' M, p: D/ I3 B9 a2 m1 `
这也是为什么一套辟邪剑法的剑招,缺了葵花宝典的心法,就稀疏平常沦为三流一样。
8 L5 Q5 w, v& Y0 ]+ A  j% U& ~7 {
+ C1 d. S5 B& E8 Q7 z3 @$ o3 w
11.png
  A( c; F% |& J) u2 X( c$ i) ^
从Practice,到Method,到Principle;也是从Doing,到Thinking,到Being的过程。
6 P& Z* v: j* L8 E
Being DevOps并非一蹴而就的事情,需要从实践做起,心里要有方法论,过程中始终严守原则。
+ s* a  b$ G6 ?  L& F$ F
又不能固守着那把实体的锤子,方法也好,实践也好,都只是达成目标的途径,而原则才是指南针。
7 ]5 u! s$ ^4 v: y. f$ r% S1 J" j, ]
小结
12.png
我的朴素的DevOps价值观
  • 首先,业务、架构、技术,人、流程、工具,原则、方法、实践,这九大元素不能孤立的来看,原本就是相辅相成,密切相关的。
      E+ S/ m7 e" R: {3 ^( r6 b# D% L
Principle背后,其实是人的Mindset思维模式,而一堆人遵循同样的Principle,就演化成了文化Culture。
% T/ k5 W* M7 q  r) U4 t( U
方法Method也好,流程Process也好,最终都由实践Practice通过工具Tool落地。

% I  N% X- _* o. v/ L' M' C$ ?
DevOps、微服务和容器的三剑客,也是方法、架构与技术与工具的极佳结合。
, Z* h) e+ {! G3 {" X
  • 其次,所有这些元素都重要,缺一不可;但不要舍本逐末,需要了解什么是根因,什么是手段。

    7 V3 `/ d) X% E3 Z
技术、工具、实践,都是服务于方法和流程的,需要遵循核心的原则,最终的目的是为了商业的诉求,为了快速的价值交付。
方法、实践、工具,都是形;原则、Mindset、人,才是根。
DevOps
; m1 ~+ D! z. W6 g8 V; ^4 @( U" L% i
  • 最后,我的DevOps朴素价值观
  • $ o/ C; ]; a% g& B! P7 f7 Z0 g
殊途同归,不管是CALM/CALMS,还是SAFe的CALMR,或者是Nicole Forsgren/Jez Humble/Gene Kim的新书Accelerate中的能力成长模型,都只是对同样问题的不同解读。
& H- C8 _) ~3 ?6 ?3 {( h; V+ O1 F
本文是我原始的对于DevOps思想的解读;DevOps是什么,DevOps有很多面,每个人心中都有自己的DevOps,我的所谓朴素的价值观,只是个人的一种解读。如果你也认同,十分感谢;如果你不认同,也欢迎一起探讨。

7 l4 ]* W& n1 K6 R: |, X4 S7 M

; _7 l/ ^* \* {) P' [原创:姚冬
0 x: K. {& s, T- a  W2 n' D3 {5 u  a8 ~1 s/ q

- E- T3 X/ K$ A9 C




上一篇:DevOps时代,微软都在干什么?
下一篇: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:47 , Processed in 0.170884 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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