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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 562|回复: 0

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

[复制链接]
发表于 2021-12-21 14:05:30 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2021-12-24 23:19 编辑 ( r. x4 b9 r, ]  R
* Y4 z8 A# o6 T' N: d+ Z
今天我跟大家分享的话题是 “DevOps落地的关键要素”,分为三部分。7 O5 F0 ?* c: L3 ~0 p
一、你的 DevOps 是什么样?
7 B- c# E2 g- F- e1 i
2 k0 \* `. ^  r3 l" E: Q场景一、形式主义; k- J" N6 n1 u, j& T* e, I& J

! l* d' h7 F6 d! R- R之前我们在做 KPI 或 OKR 的时候,是不是经常会看到这样的字眼:我完成了多少需求、推进了多少业务线,虽说它也达到了量化,但这样做是否合理需要进一步的考量?其实在上线了多少个需求后,最终“解决了多少问题”才是最终的价值体现,而不是上线了多少需求。但这个结果,在整个绩效考核当中是没有人负责的,这是比较常见的场景。我们后续回到公司的时候,可以看看是否存在这样的问题,考虑一下要出于什么角度定 OKR 或 KPI。
5 Y. @: K) W. F, F& |- U0 Y; r2 Y! u3 l7 O/ d
场景二、心急火燎0 U8 ^7 X. l9 Q  x2 r9 _' X/ L0 `- n
5 H6 p* G" P' k" V
我们在做整个 DevOps 实施或转型落地的时候,可能会定一个非常庞大的计划,声势造得特别大,但这不是 DevOps 真正要做的事情。我们可以把 DevOps 做一个不恰当的比喻,把它比喻成癌症的癌细胞,它要不断扩散。也就是说,从点到面,然后要成就面,这是 DevOps 本身的发展路径。而不是一上来就做一个宏观庞大的,一是见效速度非常慢,二是推广成本比较大。所以我们尽量做到,当前哪个点有问题,就优先解决哪个点的问题。) I/ ]" U/ s2 r& |; Y) t, j) C7 l

: O- v3 ^* C6 `+ f/ `3 h场景三、百家争鸣3 F6 u7 e/ S% Z  k8 j
# Q6 z2 e# U( W; X9 A, I
这个问题我之前也遇到过,一个企业里有多个 DevOps 平台。什么原因产生的?比如一个比较狼性的企业,最开始说我们每个团队都可以做,谁做得好用谁的,到最后却变成了各玩各的。“有开始,没结束”开始的方向错了,导致一系列的问题产生,这也是 DevOps 里常见的问题。* ]! e! ]) |3 [
! O0 m1 X% j9 r1 J
场景四、混乱之墙
8 R2 }7 o/ u2 d5 s
! ^8 ^. Z" t- A, T* i( l
0 P2 n; {8 l1 J* \
粘贴上传202112242316369580..png
# _( \) g3 q8 ?6 K2 B( U! O

+ r) J1 k8 O1 u2 l, q$ |( d1 h
在企业内部,肯定有一些合作不顺畅的点。产生不顺畅的原因有很多,包括目标不一致性,例如开发跟运维,他们的目标完全是不一致的,一个要变,一个要稳,两方领导的做事方式不一样,目标不一样,想达成的结果也不一样。
2 M- ~& ?! k! \: j0 |. ]
场景五、盲目跟风

' c) ~7 }9 ]- ~0 i
不是说别人做 DevOps,我们也跟着做。这个场景可能导致一个问题,荒废了很多人力,最终根本落不了地。总结一条我个人的建议:DevOps 的根基是什么?一定是出于解决某个问题的角度出发,而不是出于规划。DevOps 本身萌发的萌芽,就是你要解决企业内部的一个问题。
8 {: i2 l1 D! M7 d0 |5 |7 x2 O& }
粘贴上传202112242317014715..png
9 Z" y5 s/ X5 p! j1 F
: T5 F4 T! |- @0 k% K1 p, b% i
二、DevOps 落地要素
4 i( o3 A& b. L3 u! {& C5 r
整体来说,落地要素就是组织结构、企业文化、人员能力、技术、工具平台等等,我挑出来了几个比较主要的因素,跟大家进行交流。
' G- ?+ p) k- U

; K* j) m2 Q- A: q
粘贴上传202112242317348205..png
! k1 n3 X- ~9 y$ v* S
2.1 企业文化
  r6 a: e4 u, I5 H
企业文化到底是如何影响员工的?我经过很长时间的发现和总结,得出了一个结论:不同的行为影响产生不同的行为结果。在企业内部,你周边的人往往是对你影响最大的人,包括你的同事和领导。你的同事做事风格如果是好的、积极向上的,你大概率会跟他一样。如果你的同事比较闭塞,是合作不太顺畅的人,久而久之你也会受到影响,这是定律。

& i; B# r  e0 L5 e* J企业文化传承的有效途径,主要来自于“近亲”。企业文化的传承主要依靠主管的影响力,而不是全员都在做企业文化的宣传。这是我自己对企业文化的理解,比较小众。
* `2 G! h% C/ Z

& s! t3 ?& P# V! Y- s# G+ M' Q: F5 Q
粘贴上传202112242318116620..png

. j1 S3 s- A& d4 G$ q( L, h
0 U6 {0 Z# O, V/ R6 w, x) E* @2.2 工具建设, Q6 N1 \: u$ T; j9 l

, X( n% I5 Z( ^/ ]这是整个 DevOps 落地的关键节点。之前我听有人说过,工具建设不重要,企业文化更重要,组织结构更重要。DevOps领域里,没有什么东西是谁比谁更重要的,它们都同等重要。你把每一项都做好,你的DevOps结果就会很好。
- J' [' i. v& H! P$ t6 {
DevOps 工具,有一个核心环节(CD过程),上线流程的每一块,都需要很细的点,不知道大家在内部的 DevOps 平台里做到什么样的方式,你们有定义过多少个规则?我见过的 DevOps 平台里的规则,比功能点还要多,整个标准化达到了非常高的程度,所以系统不需要做到那么复杂的程度,系统就是一个流程。
' O4 E. i" |8 a/ f3 i
1、Plan。工具层面的计划挺简单的,需求管理跟最终的上线有一一对应的过程。相信现在大家都有电子看板的能力,电子看板有一个很有意思的点,可以松,可以紧,就看我们用到什么程度。当你做后续度量的时候,比较宽泛的看板能力可能满足不了你的度量要求,因为你规范不了用户的行为习惯。如果有企业在做类似于看板的系统,需要想想后续的度量要怎么做,有可能你要先做度量指标,再考虑看板,这是一种方式,这样可以规范看板里的功能点。可视化和可量化,就是整个需求管理的内容。

2 g- M. p. Q( O2 k5 ~: p2、Code。代码管理是比较重要的,你说它简单,也很简单。说它复杂,也很复杂。说它简单,就是给用户开一个类似自由编译的入口,让他自己做编译就可以了,包括现在云厂商提供的工具,也是类似的概念。因为是通用型产品,所以提供的是通用型功能。

" {; ~5 n& M, W+ F/ X
: b, ?# N6 L% W但是我们在企业内部做这个事情的时候,往往不会那么简单,我们需要在这个环节里加上一定的控制条件,保证代码的质量或者自动化程度能够进一步的提升。这里边的限制条件包括整个代码结构有没有做做规范性,比如某某文件应该做在哪、另外一点比如是否定义与业务匹配的分支模型等等。在我们内部的 DevOps 平台里,大部分都不会线上化管理分支,都是线下依靠开发人员遵守分支模型做线下规范性约束。
- g9 X" N1 n% |) O  Y$ ?
0 a: Y- s. F: V' J# Q0 G相关命名规范也很重要,这是自动化的前提,比如代码库名称、分支名称,都要有一个规则,规则有了才能在系统上自动化。! A' N$ v6 |( I3 F4 e( A8 e

5 f8 J' ]6 U% f) t) O  k9 N- d完善的校验机制,这个也很重要,不知道多少人在做代码编译之前会做一系列的检查?包括代码结构的检查,包括配置文件的检查,大家可以考虑一下,在编译前要做哪些合规性的校验检查。
# q! O9 x' i, H9 c! T2 [, C" j* [  w% J) e: R
粘贴上传202112242318286350..png
$ [$ G2 M0 z" x. I6 m0 H

% B; D  P) g! T* \5 T
3、Build。
统一编译环境,对 DevOps 一体化成熟度模型熟悉的同学都知道,“标准8”有一个系统工具的要求,对构建环境需要有一个统一要求。为什么要统一?环境不统一容易产生很多问题,修改的东西没办法控制。统一编译脚本,需要在前面标准化的前提下进行统一。咱们在座的同学里,有哪些企业能做到编译脚本是统一的,不需要开发人员自己写,编译的时候调一个脚本,就能直接编译。

7 b$ U0 ?$ j+ T2 y其实我想强调的内容是,尽量让开发人员做本身和业务相关的事情,而不是在这个过程中,又需要让他写很多他不懂的内容,让他弄他能懂、能接受的东西。
4、Test。除了持续集成、持续部署、持续交付,还有持续测试。持续测试的目的,反馈回路比较短。前天我跟一个同学一起讨论问题,自动化测试能更好的减少反馈回路,代码提交之后出结果,很快进行自动化测试,所以在整个交付过程里,持续测试非常重要,但现在在很多企业它是薄弱环节。能做到的点我们尽量做到,单测我们还是鼓励做的,投入产出比很高。其次,我们常用的是接口测试,这个也是投入产出比比较高的自动化测试。UI测试在整个测试的能力模型里,处于比较上级。可视化反馈,这个跟度量类似,要有好的方式呈现给这次测试的结果。
1 z$ C! S; F5 u2 C$ R
5、Release。制品这块有几个关键点,尤其是制品安全,有一些商用软件提供了非常好的功能,当然我们也可以自己用一些插件做安全扫描。但是我们往往会忽视管理制品版本和元数据,现在有多少企业会把制品元数据记录下来?比如制品对应的代码的commitID是什么、提交人是谁、什么时间生成的?这是后续做自动化的先决条件。
  B. T9 q2 I0 r( b
! @3 j) o% K7 C) ^9 |
我列了一些重要的制品元数据(推送者、推送时间、制品大小、MD5、版本号、commitid、源码地址等)尽量要跟制品进行绑定,比如通过哪个代码过来,单元测试覆盖率达到百分之多少,这些要全部记录下来,单元测试覆盖率达到80%才能自动晋级,否则要系统人工卡点,没法做到自动化,所以能做到极致的东西,我们就尽量做到极致。
6 i# Z. |# c1 O, U8 F. J
! H6 p% Q/ G( l: e2 }
6、Deploy。整个配置分离、应用中心的概念。估计大部分企业现在都做到了这种程度,因为这不是最近才兴起的话题。生产环境不允许接入,基本也能做到,容器化之后这一点控制得比较好。中台的目标,就是代码跟环境统一发布,我们是以这样的思路做这个事的,但是在环节来说,里边有一些比较重要的点,不见得好做,回想一下之前我提到的问题,你要找其中能做的一个点,而不是把所有东西全部做出来。比如现在的自动化测试做得不好,不好的原因在哪?理想状态应该是什么样的?需要谁协助?比如这个自动化测试我做不了,原因是什么?代码架构的问题,可能需要整个架构层面一起考虑这个事情该怎么做。

. K( a* I8 {/ U, W8 `3.3 度量驱动

* j1 v- d( M, c! ]5 u4 S) |/ p0 l; b% ]9 s! L" o
粘贴上传202112242318498939..png
7 k9 s8 _# E0 u; \+ V5 V% r% \8 w

* L' @/ s0 f8 p+ G这一点我有比较深的体会,大家在做度量的时候,往往会跑偏。之前我在一家企业问有没有做度量,他们说做了,给了我一个报告,拿出来一两百个度量指标。需要那么多度量指标吗?当然,有度量指标的比没有的要好,但某种程度上,不一定要展示出来,可以作为数据积累。

" J3 M; m7 T' Q. b9 {3 j! d' G4 w5 E' V# K6 [) p  Z- R  ?
我列了一些好的度量指标和不好的度量指标,大家可以参考一下,什么样的是好的度量指标,什么样是不好的度量指标?度量要以什么为导向?
4 I  p2 L$ u6 M) \6 f5 n& }8 m/ z1 {! N, S0 s% O; K5 a
这是给大家的度量建议,整个企业在度量的时候需要走的路径是什么样的?1.现状与目标。比如阿里的“211”,两周内交付多少,一周内开发多少,一小时提交代码发布。首先要考虑你能不能做到,其次考虑这个东西是否适合你,这不是完全拷贝的过程,要明白自己现状跟目标,再做后面其他的事情。2.策划指标。3.查缺补漏。4.可视化。5.推送预警。6.提供决策。这一点很重要。7 I3 u4 W' {" [

! ?4 p, f! H2 _$ x, g! i
粘贴上传202112242319116925..png

: u* _- U- z8 J, A9 v在度量这块,你要抛弃过多的无意义指标,因为你做了那些指标,会陷入更糟糕的环境,比如数据造假,衡量这个没意义,反倒影响人的行为习惯,对 DevOps 的整个进展会有很大的影响。
- p- n3 p$ k2 f- k# S( D6 }/ \8 X& k) z& u; U& k; i& t
其次,结果导向指标>过程导向指标,我要衡量的是最终结果的指标,而不是过程的指标。度量的最终结果,不是可视化视图,最终出来的应该是一个带着问题清单和解决的方案,这才是度量的意义。
+ y9 O, J& Y7 w( }$ n. z, X( |1 ?& R2 s  L3 R- C  M* M% ^
也就是说,人、工具、度量,这是反馈环节的东西,比较重要,当然这里面还有其他 DevOps 的相关要素,比如组织结构,我没有提,但是从我个人的角度来说,组织结构没有这几点重要,人是最重要的,人的行为影响,其实是 DevOps 进展是否顺利的条件。后面的工具建设,我们都是科技企业,技术能力不是问题,都能做到,加上自己的业务特点,总结一些实践放进去,不是什么大的问题。
$ j5 ?# l( P  n9 C; _5 n5 J) }
. q. L, O4 c7 b) L: D& X$ G( F. `0 h三、小结
* i/ ]5 U/ G, Y
; D2 y2 O8 k# Z% B第一,基于问题定目标
1 ^4 _& b  `  T0 z2 j5 e) e) V: G- w% n
粘贴上传202112242319295274..png

; B' t* N$ q1 f1 p) k
7 B' [$ V9 I  m& ^9 E

& P  H+ R/ W3 J% K; ]+ L4 {' q4 e我是谁、我要到哪里去、会到哪里去、需要谁协助?把这个事情列清楚了,这个事我们就成功了一大部分。所以不要盲目做 DevOps。" c- u$ J) N3 F  V) C' \/ p' X: A

1 ?* X, O( c, Y第二,做正确的事情
3 n% N) Q1 W+ E- O
0 M% j: Y/ Q3 r, k$ A要了解现状,定义自己的规范,再考虑做到系统工具里,这是一个过程,不是一次性就能做好的。当然我们可以先做工具,解决当前我们能解决的问题,陆续把规范往工具里嵌入。最后的反馈环节除了度量以外,还有自动化测试、运维监控,都是反馈闭环的过程,有很多种方式可以做。; p7 x  l4 k* S2 {7 I! u, U2 F
1 T2 H0 Z1 [* o! D  ^
第三,尽量将反馈回路做到极致+ }  ~( }4 R( i2 U! r; n

( d$ C/ k4 x6 ]8 }维基百科以及其他指南,对 DevOps 有很多定义。但我个人理解,无论从文化、组织、工具、度量方向来说,DevOps 是努力将结果的反馈回路缩短到极致,这就是 DevOps 的核心理念。3 ?4 m& x" @7 v2 B: c
) F$ n& P0 M6 Y2 g
不知道大家有没有产生共鸣,其实你做什么事情,它都是在缩短/左移的过程。我们强调的就是左移,开发开始做单测就是左移,自动化测试也是左移,安全也是左移,左移的过程就是缩短反馈回路的过程,我们把反馈回路缩短到极致,DevOps的整个闭环就可以做得非常好。(转自韩洪雷)4 ^6 L. A$ `1 N( c

5 m: n0 R. l% G5 P9 s; l
. C1 x- `2 v9 Y
1 B* m, ~0 ^9 q- T
! j% \8 t$ F& W

5 r9 l# {5 b8 n0 W" O
$ y9 \9 e) {% R* [% Q
粘贴上传202112242317123767..png




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

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2022-12-7 17:11 , Processed in 0.100286 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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