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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 112|回复: 0

路在何方:DevOps 落地的3个关键要素

[复制链接]
发表于 2021-12-21 14:05:30 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-24 23:19 编辑
) ~& j" M- `8 P' a
( j( ~& Z$ e' x今天我跟大家分享的话题是 “DevOps落地的关键要素”,分为三部分。8 ?4 b- w7 P* Z, J1 P% M! @+ ?
一、你的 DevOps 是什么样?
; X: ]) ~4 W, h! J3 v& _
, ~/ q0 f3 V5 b% O场景一、形式主义
* ~! b9 ?1 {. [) s* v

1 c9 P; R" }, z4 \: g# Q之前我们在做 KPI 或 OKR 的时候,是不是经常会看到这样的字眼:我完成了多少需求、推进了多少业务线,虽说它也达到了量化,但这样做是否合理需要进一步的考量?其实在上线了多少个需求后,最终“解决了多少问题”才是最终的价值体现,而不是上线了多少需求。但这个结果,在整个绩效考核当中是没有人负责的,这是比较常见的场景。我们后续回到公司的时候,可以看看是否存在这样的问题,考虑一下要出于什么角度定 OKR 或 KPI。
9 t  y6 ?# M3 K4 Q$ u) `( F, h. O3 r. W; \. R
场景二、心急火燎# B: y% Y: h3 E0 L+ d
5 e+ Y% g. `* l
我们在做整个 DevOps 实施或转型落地的时候,可能会定一个非常庞大的计划,声势造得特别大,但这不是 DevOps 真正要做的事情。我们可以把 DevOps 做一个不恰当的比喻,把它比喻成癌症的癌细胞,它要不断扩散。也就是说,从点到面,然后要成就面,这是 DevOps 本身的发展路径。而不是一上来就做一个宏观庞大的,一是见效速度非常慢,二是推广成本比较大。所以我们尽量做到,当前哪个点有问题,就优先解决哪个点的问题。
* \9 y0 v/ G. _3 J- P9 m7 ]+ a1 f+ w
场景三、百家争鸣
, b( D0 j/ p! {" ]0 ~/ J! q8 w3 {. Z* q9 A
这个问题我之前也遇到过,一个企业里有多个 DevOps 平台。什么原因产生的?比如一个比较狼性的企业,最开始说我们每个团队都可以做,谁做得好用谁的,到最后却变成了各玩各的。“有开始,没结束”开始的方向错了,导致一系列的问题产生,这也是 DevOps 里常见的问题。+ B# x3 c+ F0 f' a; y, ~
+ v8 T- c3 [9 d! ~9 z4 d. E* c
场景四、混乱之墙  C% M% O9 H" \; \7 ^
7 b- a/ `6 q: ^. m9 f
- h& W5 g; i  t* @* x" s
粘贴上传202112242316369580..png

$ g, q* L, F" V& f3 u, ?9 B* M; x$ g' j. D! D/ F; T9 ~4 T
在企业内部,肯定有一些合作不顺畅的点。产生不顺畅的原因有很多,包括目标不一致性,例如开发跟运维,他们的目标完全是不一致的,一个要变,一个要稳,两方领导的做事方式不一样,目标不一样,想达成的结果也不一样。

* g7 R" C* X8 E5 b9 u8 E# |* u& a
场景五、盲目跟风
5 n4 y* c1 P3 @& O2 u! n$ e, Z3 k8 K
不是说别人做 DevOps,我们也跟着做。这个场景可能导致一个问题,荒废了很多人力,最终根本落不了地。总结一条我个人的建议:DevOps 的根基是什么?一定是出于解决某个问题的角度出发,而不是出于规划。DevOps 本身萌发的萌芽,就是你要解决企业内部的一个问题。

! [' P! e$ c- I
粘贴上传202112242317014715..png

" G6 d" V# Z* s! g6 _0 g% x
$ S, H% U+ I9 m7 B3 c, a
二、DevOps 落地要素
5 I' n0 D- O7 K4 B5 W0 q* I' `5 o* f
整体来说,落地要素就是组织结构、企业文化、人员能力、技术、工具平台等等,我挑出来了几个比较主要的因素,跟大家进行交流。

- {1 _5 A& u( w( Z
7 X, @) x! r9 r
粘贴上传202112242317348205..png
! {: a2 V+ U: G! i, l8 m  }
2.1 企业文化
3 {3 o2 m* |; Q6 \: e: [
企业文化到底是如何影响员工的?我经过很长时间的发现和总结,得出了一个结论:不同的行为影响产生不同的行为结果。在企业内部,你周边的人往往是对你影响最大的人,包括你的同事和领导。你的同事做事风格如果是好的、积极向上的,你大概率会跟他一样。如果你的同事比较闭塞,是合作不太顺畅的人,久而久之你也会受到影响,这是定律。

1 T& y7 ]/ k; N! R4 i企业文化传承的有效途径,主要来自于“近亲”。企业文化的传承主要依靠主管的影响力,而不是全员都在做企业文化的宣传。这是我自己对企业文化的理解,比较小众。
1 `) S2 w0 n9 ]. O& \6 R- F# u
9 ]9 a. L: ]! ^7 |" N1 n0 J
粘贴上传202112242318116620..png
/ o$ ~9 b& ^: A- ]. o  B
* f- J& Q# n1 f# A1 `( `# W4 i3 B& F
2.2 工具建设) E0 C0 s7 q1 Q0 k) `/ c' [$ s
9 [  C/ H+ R3 H1 n9 }
这是整个 DevOps 落地的关键节点。之前我听有人说过,工具建设不重要,企业文化更重要,组织结构更重要。DevOps领域里,没有什么东西是谁比谁更重要的,它们都同等重要。你把每一项都做好,你的DevOps结果就会很好。" E9 m( c1 v0 K7 x; m* k0 R9 }
DevOps 工具,有一个核心环节(CD过程),上线流程的每一块,都需要很细的点,不知道大家在内部的 DevOps 平台里做到什么样的方式,你们有定义过多少个规则?我见过的 DevOps 平台里的规则,比功能点还要多,整个标准化达到了非常高的程度,所以系统不需要做到那么复杂的程度,系统就是一个流程。

5 C4 J: m5 @1 S4 S: M7 o( f
1、Plan。工具层面的计划挺简单的,需求管理跟最终的上线有一一对应的过程。相信现在大家都有电子看板的能力,电子看板有一个很有意思的点,可以松,可以紧,就看我们用到什么程度。当你做后续度量的时候,比较宽泛的看板能力可能满足不了你的度量要求,因为你规范不了用户的行为习惯。如果有企业在做类似于看板的系统,需要想想后续的度量要怎么做,有可能你要先做度量指标,再考虑看板,这是一种方式,这样可以规范看板里的功能点。可视化和可量化,就是整个需求管理的内容。

3 N% O1 X, E' }5 |" R4 l& _0 ?2、Code。代码管理是比较重要的,你说它简单,也很简单。说它复杂,也很复杂。说它简单,就是给用户开一个类似自由编译的入口,让他自己做编译就可以了,包括现在云厂商提供的工具,也是类似的概念。因为是通用型产品,所以提供的是通用型功能。

6 O4 x' p- P) ?, \/ ^" f
8 K) C% ]* M8 }. f! ]2 j但是我们在企业内部做这个事情的时候,往往不会那么简单,我们需要在这个环节里加上一定的控制条件,保证代码的质量或者自动化程度能够进一步的提升。这里边的限制条件包括整个代码结构有没有做做规范性,比如某某文件应该做在哪、另外一点比如是否定义与业务匹配的分支模型等等。在我们内部的 DevOps 平台里,大部分都不会线上化管理分支,都是线下依靠开发人员遵守分支模型做线下规范性约束。
" K) f8 Y; Z# {  f& v
4 }6 B( {/ D/ L: V/ o0 u相关命名规范也很重要,这是自动化的前提,比如代码库名称、分支名称,都要有一个规则,规则有了才能在系统上自动化。/ y: D2 R$ X" J: {% ]

6 V8 _& y  b+ d0 S( f完善的校验机制,这个也很重要,不知道多少人在做代码编译之前会做一系列的检查?包括代码结构的检查,包括配置文件的检查,大家可以考虑一下,在编译前要做哪些合规性的校验检查。5 h! s: e& I! Q: L7 ]* Q/ l

' }8 L0 B% y- R( Z# {2 Z  b/ g
粘贴上传202112242318286350..png

8 `1 V) d5 J, m/ |$ c; f: y8 V- V4 K
0 Z1 d" c6 _; U9 M. }3 ]: K
3、Build。
统一编译环境,对 DevOps 一体化成熟度模型熟悉的同学都知道,“标准8”有一个系统工具的要求,对构建环境需要有一个统一要求。为什么要统一?环境不统一容易产生很多问题,修改的东西没办法控制。统一编译脚本,需要在前面标准化的前提下进行统一。咱们在座的同学里,有哪些企业能做到编译脚本是统一的,不需要开发人员自己写,编译的时候调一个脚本,就能直接编译。
2 e: S/ Q3 q, v, {
其实我想强调的内容是,尽量让开发人员做本身和业务相关的事情,而不是在这个过程中,又需要让他写很多他不懂的内容,让他弄他能懂、能接受的东西。
4、Test。除了持续集成、持续部署、持续交付,还有持续测试。持续测试的目的,反馈回路比较短。前天我跟一个同学一起讨论问题,自动化测试能更好的减少反馈回路,代码提交之后出结果,很快进行自动化测试,所以在整个交付过程里,持续测试非常重要,但现在在很多企业它是薄弱环节。能做到的点我们尽量做到,单测我们还是鼓励做的,投入产出比很高。其次,我们常用的是接口测试,这个也是投入产出比比较高的自动化测试。UI测试在整个测试的能力模型里,处于比较上级。可视化反馈,这个跟度量类似,要有好的方式呈现给这次测试的结果。

( ~4 y0 u1 }, n. X( j: u: R. K( E5、Release。制品这块有几个关键点,尤其是制品安全,有一些商用软件提供了非常好的功能,当然我们也可以自己用一些插件做安全扫描。但是我们往往会忽视管理制品版本和元数据,现在有多少企业会把制品元数据记录下来?比如制品对应的代码的commitID是什么、提交人是谁、什么时间生成的?这是后续做自动化的先决条件。

8 M& z: n6 q0 }
" H3 M; C: W) O- K5 Z我列了一些重要的制品元数据(推送者、推送时间、制品大小、MD5、版本号、commitid、源码地址等)尽量要跟制品进行绑定,比如通过哪个代码过来,单元测试覆盖率达到百分之多少,这些要全部记录下来,单元测试覆盖率达到80%才能自动晋级,否则要系统人工卡点,没法做到自动化,所以能做到极致的东西,我们就尽量做到极致。
( _: a, ^/ q. z+ N: j9 `. w$ T; f, ~4 f
6、Deploy。整个配置分离、应用中心的概念。估计大部分企业现在都做到了这种程度,因为这不是最近才兴起的话题。生产环境不允许接入,基本也能做到,容器化之后这一点控制得比较好。中台的目标,就是代码跟环境统一发布,我们是以这样的思路做这个事的,但是在环节来说,里边有一些比较重要的点,不见得好做,回想一下之前我提到的问题,你要找其中能做的一个点,而不是把所有东西全部做出来。比如现在的自动化测试做得不好,不好的原因在哪?理想状态应该是什么样的?需要谁协助?比如这个自动化测试我做不了,原因是什么?代码架构的问题,可能需要整个架构层面一起考虑这个事情该怎么做。
2 n" n1 |; w3 ]' Y/ A
3.3 度量驱动

3 K8 x3 t. J0 b2 r- a9 \2 c5 B; @. q; s: K, g0 [9 H
粘贴上传202112242318498939..png

( W3 m- M  o) _3 f% B
* d! O8 z' n' V' y/ g这一点我有比较深的体会,大家在做度量的时候,往往会跑偏。之前我在一家企业问有没有做度量,他们说做了,给了我一个报告,拿出来一两百个度量指标。需要那么多度量指标吗?当然,有度量指标的比没有的要好,但某种程度上,不一定要展示出来,可以作为数据积累。
1 m( q( B: R# i9 X: M: ]
) l* E( A0 m3 a" Z- S1 l
我列了一些好的度量指标和不好的度量指标,大家可以参考一下,什么样的是好的度量指标,什么样是不好的度量指标?度量要以什么为导向?$ Q- t* K5 B6 @8 F5 S6 H% O# z

  t- w) K1 f4 b7 ?6 A7 ]这是给大家的度量建议,整个企业在度量的时候需要走的路径是什么样的?1.现状与目标。比如阿里的“211”,两周内交付多少,一周内开发多少,一小时提交代码发布。首先要考虑你能不能做到,其次考虑这个东西是否适合你,这不是完全拷贝的过程,要明白自己现状跟目标,再做后面其他的事情。2.策划指标。3.查缺补漏。4.可视化。5.推送预警。6.提供决策。这一点很重要。
/ @7 a7 C9 X. T, @) g9 V  E. Q- o- _( h# W
粘贴上传202112242319116925..png

7 U$ B2 [% a* g在度量这块,你要抛弃过多的无意义指标,因为你做了那些指标,会陷入更糟糕的环境,比如数据造假,衡量这个没意义,反倒影响人的行为习惯,对 DevOps 的整个进展会有很大的影响。8 X; a- g. _( F* f
5 ]6 h; t7 E! W" G  i
其次,结果导向指标>过程导向指标,我要衡量的是最终结果的指标,而不是过程的指标。度量的最终结果,不是可视化视图,最终出来的应该是一个带着问题清单和解决的方案,这才是度量的意义。
# y, i, j7 D+ _, S$ G2 S
/ g8 i* D: _5 L" d也就是说,人、工具、度量,这是反馈环节的东西,比较重要,当然这里面还有其他 DevOps 的相关要素,比如组织结构,我没有提,但是从我个人的角度来说,组织结构没有这几点重要,人是最重要的,人的行为影响,其实是 DevOps 进展是否顺利的条件。后面的工具建设,我们都是科技企业,技术能力不是问题,都能做到,加上自己的业务特点,总结一些实践放进去,不是什么大的问题。( K% Q$ A) c, N5 }/ j# B" q# p
: n1 z( W$ I1 [  Z# g5 G4 ~; l
三、小结+ ?( y9 n+ R2 t% D; `% i* N  T9 Z
! x' h9 \  n5 [/ D1 t+ b
第一,基于问题定目标! t# V, E! c2 i7 O$ ~

( p: U% b  A4 L+ {* ~
粘贴上传202112242319295274..png

& \; o' A" i7 P/ B4 r9 {5 m
' W' S. W# l2 N) x: o  I+ R7 J' l
2 Q% B" J: C. C, @; H7 H2 E
我是谁、我要到哪里去、会到哪里去、需要谁协助?把这个事情列清楚了,这个事我们就成功了一大部分。所以不要盲目做 DevOps。: D1 T" {+ h+ g6 y5 m4 X  r

+ ~# q3 k, O: e: ?; T% Z% q5 f- ^第二,做正确的事情
: b# \- h/ B& S
: c9 P! b8 r& Y3 ?# r1 L2 A要了解现状,定义自己的规范,再考虑做到系统工具里,这是一个过程,不是一次性就能做好的。当然我们可以先做工具,解决当前我们能解决的问题,陆续把规范往工具里嵌入。最后的反馈环节除了度量以外,还有自动化测试、运维监控,都是反馈闭环的过程,有很多种方式可以做。2 \, D. o' i4 f9 `8 ~2 ~1 |

9 Q; m4 g" H0 |9 d. K& v- E第三,尽量将反馈回路做到极致$ a5 x' `% P6 P) Q: i; B
! G8 {" K; V1 I$ s: w
维基百科以及其他指南,对 DevOps 有很多定义。但我个人理解,无论从文化、组织、工具、度量方向来说,DevOps 是努力将结果的反馈回路缩短到极致,这就是 DevOps 的核心理念。3 H2 A; @5 {6 P: f. |8 W  G0 R

5 b4 r$ h8 G! c: L# o" x. \$ W" T不知道大家有没有产生共鸣,其实你做什么事情,它都是在缩短/左移的过程。我们强调的就是左移,开发开始做单测就是左移,自动化测试也是左移,安全也是左移,左移的过程就是缩短反馈回路的过程,我们把反馈回路缩短到极致,DevOps的整个闭环就可以做得非常好。(转自韩洪雷)% P& w3 M3 t5 T. S
2 u/ T# J7 ]6 Z* Y4 M

: G: D3 i1 N. [" f+ W7 }7 P! q/ A; a5 `1 f( B* f
4 ^- j5 P7 }# d/ s6 c

' [. P8 N' X4 f
% l8 E/ t% U7 J1 c. c- c0 T* R+ _
粘贴上传202112242317123767..png




上一篇:提升 DevOps 能力的5个技巧
下一篇:DevOps 进行时之最佳实践分享:代码合规检查配置
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、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-1-20 18:16 , Processed in 0.110321 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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