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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 358|回复: 0

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

[复制链接]
发表于 2021-12-21 14:05:30 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-24 23:19 编辑
7 s; c, @- c; a# }2 p: g. Y& ^6 K& w; |
今天我跟大家分享的话题是 “DevOps落地的关键要素”,分为三部分。
3 A# J. G2 y( _; v一、你的 DevOps 是什么样?
; k: ?- w, u1 t5 K1 Q4 q& H9 f* X9 |8 T! P0 r7 `9 }  z0 d5 w  Z
场景一、形式主义
6 S( R. j" ]/ o$ N4 Z! D

/ G7 m2 A! ?  X之前我们在做 KPI 或 OKR 的时候,是不是经常会看到这样的字眼:我完成了多少需求、推进了多少业务线,虽说它也达到了量化,但这样做是否合理需要进一步的考量?其实在上线了多少个需求后,最终“解决了多少问题”才是最终的价值体现,而不是上线了多少需求。但这个结果,在整个绩效考核当中是没有人负责的,这是比较常见的场景。我们后续回到公司的时候,可以看看是否存在这样的问题,考虑一下要出于什么角度定 OKR 或 KPI。9 ]+ Y4 K0 n# p/ Z

) _$ P( K6 R8 ^! K场景二、心急火燎
- W/ Z8 Z, F; z( ^; w. U# l7 l/ _4 n4 ~& s% I: }
我们在做整个 DevOps 实施或转型落地的时候,可能会定一个非常庞大的计划,声势造得特别大,但这不是 DevOps 真正要做的事情。我们可以把 DevOps 做一个不恰当的比喻,把它比喻成癌症的癌细胞,它要不断扩散。也就是说,从点到面,然后要成就面,这是 DevOps 本身的发展路径。而不是一上来就做一个宏观庞大的,一是见效速度非常慢,二是推广成本比较大。所以我们尽量做到,当前哪个点有问题,就优先解决哪个点的问题。) O, d6 s" S* ]/ H
1 y3 U( D7 l* Y# K1 c6 H
场景三、百家争鸣
! ]( n2 J1 m: W0 ^
& b- x! v4 i5 S7 Z' M这个问题我之前也遇到过,一个企业里有多个 DevOps 平台。什么原因产生的?比如一个比较狼性的企业,最开始说我们每个团队都可以做,谁做得好用谁的,到最后却变成了各玩各的。“有开始,没结束”开始的方向错了,导致一系列的问题产生,这也是 DevOps 里常见的问题。
" W7 \: S3 W& s% b; D5 r  W3 T- k% x& H" H& F$ ]5 j; @/ p& Q
场景四、混乱之墙
; e- r4 P/ Q0 m1 q! @
- T* n' c5 g/ \) J! A3 n* k; w
# W; F/ _) w2 r- G% O& I
粘贴上传202112242316369580..png

% k4 T. l6 c2 W* j! F4 G9 J/ y/ ~# @6 t
在企业内部,肯定有一些合作不顺畅的点。产生不顺畅的原因有很多,包括目标不一致性,例如开发跟运维,他们的目标完全是不一致的,一个要变,一个要稳,两方领导的做事方式不一样,目标不一样,想达成的结果也不一样。

, ~  ?6 \( L9 t# ?
场景五、盲目跟风
2 A0 B3 z5 P7 |1 z" S# G; r! D" z8 H
不是说别人做 DevOps,我们也跟着做。这个场景可能导致一个问题,荒废了很多人力,最终根本落不了地。总结一条我个人的建议:DevOps 的根基是什么?一定是出于解决某个问题的角度出发,而不是出于规划。DevOps 本身萌发的萌芽,就是你要解决企业内部的一个问题。
2 a; _/ ?+ V. a9 O/ _
粘贴上传202112242317014715..png

; R( Z( q& e& U
. H  w& z0 L1 t) S1 Z
二、DevOps 落地要素
# ~& ~: j* s/ t) S$ B3 F6 a  ~
整体来说,落地要素就是组织结构、企业文化、人员能力、技术、工具平台等等,我挑出来了几个比较主要的因素,跟大家进行交流。
7 c8 s- S/ t' ?9 j$ V
, D0 P! D3 c6 ^6 d& k5 i
粘贴上传202112242317348205..png

( X# [- x- I" x
2.1 企业文化

# z3 E' x' _/ \6 D9 y; k
企业文化到底是如何影响员工的?我经过很长时间的发现和总结,得出了一个结论:不同的行为影响产生不同的行为结果。在企业内部,你周边的人往往是对你影响最大的人,包括你的同事和领导。你的同事做事风格如果是好的、积极向上的,你大概率会跟他一样。如果你的同事比较闭塞,是合作不太顺畅的人,久而久之你也会受到影响,这是定律。
4 Z2 K; e& h) e3 ~" n) x  j7 x
企业文化传承的有效途径,主要来自于“近亲”。企业文化的传承主要依靠主管的影响力,而不是全员都在做企业文化的宣传。这是我自己对企业文化的理解,比较小众。

% L9 Q9 t2 _, n6 j
: q1 N+ Q2 G8 X9 N; m8 P: {9 k
粘贴上传202112242318116620..png

9 T) Z( j8 N! D$ Z( f* O" }+ a' S* L( J4 x1 A8 p
2.2 工具建设
: E4 c. Q. S1 t! K5 U1 C( N8 C2 u: F7 |, m
这是整个 DevOps 落地的关键节点。之前我听有人说过,工具建设不重要,企业文化更重要,组织结构更重要。DevOps领域里,没有什么东西是谁比谁更重要的,它们都同等重要。你把每一项都做好,你的DevOps结果就会很好。
  B2 t- y2 v1 U: y
DevOps 工具,有一个核心环节(CD过程),上线流程的每一块,都需要很细的点,不知道大家在内部的 DevOps 平台里做到什么样的方式,你们有定义过多少个规则?我见过的 DevOps 平台里的规则,比功能点还要多,整个标准化达到了非常高的程度,所以系统不需要做到那么复杂的程度,系统就是一个流程。

9 `2 P2 J3 f- s# B! N5 i
1、Plan。工具层面的计划挺简单的,需求管理跟最终的上线有一一对应的过程。相信现在大家都有电子看板的能力,电子看板有一个很有意思的点,可以松,可以紧,就看我们用到什么程度。当你做后续度量的时候,比较宽泛的看板能力可能满足不了你的度量要求,因为你规范不了用户的行为习惯。如果有企业在做类似于看板的系统,需要想想后续的度量要怎么做,有可能你要先做度量指标,再考虑看板,这是一种方式,这样可以规范看板里的功能点。可视化和可量化,就是整个需求管理的内容。
# _4 \# ^8 K: W( p
2、Code。代码管理是比较重要的,你说它简单,也很简单。说它复杂,也很复杂。说它简单,就是给用户开一个类似自由编译的入口,让他自己做编译就可以了,包括现在云厂商提供的工具,也是类似的概念。因为是通用型产品,所以提供的是通用型功能。

. H% O$ x% m" ]4 M3 ^' s8 s. s" V0 I: W
但是我们在企业内部做这个事情的时候,往往不会那么简单,我们需要在这个环节里加上一定的控制条件,保证代码的质量或者自动化程度能够进一步的提升。这里边的限制条件包括整个代码结构有没有做做规范性,比如某某文件应该做在哪、另外一点比如是否定义与业务匹配的分支模型等等。在我们内部的 DevOps 平台里,大部分都不会线上化管理分支,都是线下依靠开发人员遵守分支模型做线下规范性约束。4 i* H4 H: J+ v
) O# D5 G# G% ?9 w) K! ], X9 C2 g3 n
相关命名规范也很重要,这是自动化的前提,比如代码库名称、分支名称,都要有一个规则,规则有了才能在系统上自动化。
& C3 x- z  O4 J6 _+ q% q+ f8 l/ R7 x. k
完善的校验机制,这个也很重要,不知道多少人在做代码编译之前会做一系列的检查?包括代码结构的检查,包括配置文件的检查,大家可以考虑一下,在编译前要做哪些合规性的校验检查。
/ I$ I) F& M* U
$ \5 W& R8 s8 G8 B1 _1 W
粘贴上传202112242318286350..png
. l8 [4 j! _( ^$ c  q
0 C- f, I9 f9 z. ?, z( X( @
3、Build。
统一编译环境,对 DevOps 一体化成熟度模型熟悉的同学都知道,“标准8”有一个系统工具的要求,对构建环境需要有一个统一要求。为什么要统一?环境不统一容易产生很多问题,修改的东西没办法控制。统一编译脚本,需要在前面标准化的前提下进行统一。咱们在座的同学里,有哪些企业能做到编译脚本是统一的,不需要开发人员自己写,编译的时候调一个脚本,就能直接编译。
7 J: p; D$ B# a8 @' E
其实我想强调的内容是,尽量让开发人员做本身和业务相关的事情,而不是在这个过程中,又需要让他写很多他不懂的内容,让他弄他能懂、能接受的东西。
4、Test。除了持续集成、持续部署、持续交付,还有持续测试。持续测试的目的,反馈回路比较短。前天我跟一个同学一起讨论问题,自动化测试能更好的减少反馈回路,代码提交之后出结果,很快进行自动化测试,所以在整个交付过程里,持续测试非常重要,但现在在很多企业它是薄弱环节。能做到的点我们尽量做到,单测我们还是鼓励做的,投入产出比很高。其次,我们常用的是接口测试,这个也是投入产出比比较高的自动化测试。UI测试在整个测试的能力模型里,处于比较上级。可视化反馈,这个跟度量类似,要有好的方式呈现给这次测试的结果。
6 ~: k; m  i- p, ~; h( _
5、Release。制品这块有几个关键点,尤其是制品安全,有一些商用软件提供了非常好的功能,当然我们也可以自己用一些插件做安全扫描。但是我们往往会忽视管理制品版本和元数据,现在有多少企业会把制品元数据记录下来?比如制品对应的代码的commitID是什么、提交人是谁、什么时间生成的?这是后续做自动化的先决条件。
9 q% W. X: I, i$ @& Y: F) T: u
5 D& X. D' x6 d% f3 ?# k5 U
我列了一些重要的制品元数据(推送者、推送时间、制品大小、MD5、版本号、commitid、源码地址等)尽量要跟制品进行绑定,比如通过哪个代码过来,单元测试覆盖率达到百分之多少,这些要全部记录下来,单元测试覆盖率达到80%才能自动晋级,否则要系统人工卡点,没法做到自动化,所以能做到极致的东西,我们就尽量做到极致。
+ o7 a/ c2 t( Y
7 a4 e( q+ x/ J) R2 {* B9 s
6、Deploy。整个配置分离、应用中心的概念。估计大部分企业现在都做到了这种程度,因为这不是最近才兴起的话题。生产环境不允许接入,基本也能做到,容器化之后这一点控制得比较好。中台的目标,就是代码跟环境统一发布,我们是以这样的思路做这个事的,但是在环节来说,里边有一些比较重要的点,不见得好做,回想一下之前我提到的问题,你要找其中能做的一个点,而不是把所有东西全部做出来。比如现在的自动化测试做得不好,不好的原因在哪?理想状态应该是什么样的?需要谁协助?比如这个自动化测试我做不了,原因是什么?代码架构的问题,可能需要整个架构层面一起考虑这个事情该怎么做。
" _( i2 N% r! @# \3 F
3.3 度量驱动
& e; K* H: Z# B* X4 j* Q) N8 [

# |' }, G1 _8 e: N( G  s  V
粘贴上传202112242318498939..png

8 W* u+ v) G2 W, n  v9 C) w  L; I% M/ q$ m4 A# Z1 H
这一点我有比较深的体会,大家在做度量的时候,往往会跑偏。之前我在一家企业问有没有做度量,他们说做了,给了我一个报告,拿出来一两百个度量指标。需要那么多度量指标吗?当然,有度量指标的比没有的要好,但某种程度上,不一定要展示出来,可以作为数据积累。
6 _, ^" i1 j7 V1 b$ n5 ~! E, P9 Y. Q
9 Y! H9 C. U8 `8 v6 o, R4 h
我列了一些好的度量指标和不好的度量指标,大家可以参考一下,什么样的是好的度量指标,什么样是不好的度量指标?度量要以什么为导向?/ L( W; P5 }, ]# `
  u4 Q# @. x) e5 ~' p& L- D. T. K% X
这是给大家的度量建议,整个企业在度量的时候需要走的路径是什么样的?1.现状与目标。比如阿里的“211”,两周内交付多少,一周内开发多少,一小时提交代码发布。首先要考虑你能不能做到,其次考虑这个东西是否适合你,这不是完全拷贝的过程,要明白自己现状跟目标,再做后面其他的事情。2.策划指标。3.查缺补漏。4.可视化。5.推送预警。6.提供决策。这一点很重要。: M; x8 y! m# w4 o
* j8 M- F1 Q/ z( v
粘贴上传202112242319116925..png
% D* S  T$ v: N  n7 D5 [
在度量这块,你要抛弃过多的无意义指标,因为你做了那些指标,会陷入更糟糕的环境,比如数据造假,衡量这个没意义,反倒影响人的行为习惯,对 DevOps 的整个进展会有很大的影响。  g' M- P* }% `5 m

; C6 B& V. Q7 p& @6 B; m其次,结果导向指标>过程导向指标,我要衡量的是最终结果的指标,而不是过程的指标。度量的最终结果,不是可视化视图,最终出来的应该是一个带着问题清单和解决的方案,这才是度量的意义。
' ]/ W2 p& G$ L' S+ _2 t  w
3 R! m. Z/ m2 H! J3 O5 F也就是说,人、工具、度量,这是反馈环节的东西,比较重要,当然这里面还有其他 DevOps 的相关要素,比如组织结构,我没有提,但是从我个人的角度来说,组织结构没有这几点重要,人是最重要的,人的行为影响,其实是 DevOps 进展是否顺利的条件。后面的工具建设,我们都是科技企业,技术能力不是问题,都能做到,加上自己的业务特点,总结一些实践放进去,不是什么大的问题。
' P0 u5 y7 L- N" Y; l+ e
9 x- C  F* N$ g/ {4 Q/ F三、小结% |8 P& v6 C. b# ~" U. L$ m) k! k* a

2 z( R( w2 A' p  Q8 k第一,基于问题定目标* j" T6 A5 D* L" L

! O) t2 Y/ K: T. M0 D4 p
粘贴上传202112242319295274..png
2 b% `, R& p- r: B! D: E# V0 }
( G$ C; W4 f+ \+ o6 D5 X3 F! a

6 u" s: Y( M8 |4 D" X, e我是谁、我要到哪里去、会到哪里去、需要谁协助?把这个事情列清楚了,这个事我们就成功了一大部分。所以不要盲目做 DevOps。$ _6 r$ ^$ h+ S/ ^- @

7 s) ^" Z( H- \6 Q第二,做正确的事情
1 w( j- J3 I9 K9 R! L
  y7 z- B7 S5 `, l4 D' C, p要了解现状,定义自己的规范,再考虑做到系统工具里,这是一个过程,不是一次性就能做好的。当然我们可以先做工具,解决当前我们能解决的问题,陆续把规范往工具里嵌入。最后的反馈环节除了度量以外,还有自动化测试、运维监控,都是反馈闭环的过程,有很多种方式可以做。
6 E9 R: i* w# H/ C. C" b# q0 p4 q: n1 O6 V' Y# z4 |( H
第三,尽量将反馈回路做到极致1 t5 b& X7 `: _( `/ V* Y+ U
4 n$ L, Q2 c, g1 S: w  |. _0 b9 ]0 ~0 ~9 t
维基百科以及其他指南,对 DevOps 有很多定义。但我个人理解,无论从文化、组织、工具、度量方向来说,DevOps 是努力将结果的反馈回路缩短到极致,这就是 DevOps 的核心理念。+ M" V8 b# s, ]. J' c  L" H7 q

0 h# z# f# E5 L; w4 Y$ q不知道大家有没有产生共鸣,其实你做什么事情,它都是在缩短/左移的过程。我们强调的就是左移,开发开始做单测就是左移,自动化测试也是左移,安全也是左移,左移的过程就是缩短反馈回路的过程,我们把反馈回路缩短到极致,DevOps的整个闭环就可以做得非常好。(转自韩洪雷)
; P4 |7 {" D$ W* [- J  _2 \
; b: b+ L2 p0 P- p, k; D$ @, n8 L- L  e

$ K! S1 N5 {; ^. r# o
, i# s; k: x2 a$ ^1 i
) n( Q* J& r: k3 u3 N. G4 z5 P2 x7 B( ^, g& Y. e/ V/ S! O
4 z* D4 Y+ i: z4 F5 _9 v0 ^
粘贴上传202112242317123767..png




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

GMT+8, 2022-7-5 13:46 , Processed in 0.128232 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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