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

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

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 467|回复: 0

深度好文:如何摸清一个 DevOps 团队的当前状况?

[复制链接]
发表于 2022-5-26 16:24:51 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-5-26 16:25 编辑
6 Z0 u$ m7 G- ]
& e/ S2 L2 S1 o% Q一、我们要解决什么问题

伟大领袖毛主席教导我们:“没有调查就没有发言权。”其实做 DevOps 也是一样,如果不了解具体企业、具体团队、具体项目的 DevOps 情况,就开始指指点点搞规划,那是没有什么好效果的,因为没有抓住它的痛点。

/ [! r- I6 h" z' k3 j# G

不论你是工具团队负责人,还是过程改进团队负责人,或者是 DevOps 教练,不论你想从工具角度做改进,或者从流程角度做改进,当你帮助一个团队做改进时,你总得先摸清楚当前 DevOps 的落地情况是怎样的。


8 r% M$ s  W2 Y9 S! S

所以我们就来看一下摸底工作到底怎么做?这个摸底的方法也是我们这些咨询师,这几年在为几十个项目做DevOps咨询的时候逐步探索出来的。


( ], r3 t& I' {" K+ b

在开始之前,我们还是先说明一下我们这里说的 DevOps 是指啥。近几年 DevOps 是一个很火的词汇,搞得好像什么都是 DevOps 了,而今天重点讨论的是 Dev 之后,Ops 之前的部分,就是从你写完一行代码到把它发布上线这期间要考虑的部分。

8 [# Y. U; W( i8 \5 n9 @$ H, |

那这部分里面发生了什么事情呢?


5 I0 t- C4 Q6 Q# ], z7 t0 x

粘贴上传202205261621392010..png

第一,生成转换。我们会看到程序的形态从源代码形态通过构建生成了安装包形态,再进一步被部署到线上运行起来,变成运行中的程序。程序的形态发生转换,从源代码最终生成转换为运行中的程序。

第二,配套支持。程序要想运行起来,需要相应的运行环境(测试环境、生产环境)支持,数据库表结构变更需要管理,不同环境有不同的配置,所有这些都是需要提供支持的。因为要想程序运行起来,需要一系列配套的东西在一起。

第三,累积汇聚。发布上线的时候,其实并不是只上线一行源代码改动,而是上线了一系列改动,这些改动是在软件交付过程中不断汇聚、累积起来的。如果你一个人写源代码就是不断累积,但一次发布的东西可能不止是一个人的改动,不同人写不同的用户故事,这实际是大家工作汇聚的过程。

第四,质量提升。最重要的是,这个过程当中会不断提升软件质量,直到达到可以发布的程度。这包括了静态测试和动态测试。

从这个过程来看,DevOps 包括了这四类活动,来实现从改动一行源代码到最后发布上线的事情。我们今天说的DevOps,就是这期间发生的事情。我们也可以把这个过程称作软件交付过程。


% }' v7 k! u4 w9 \1 H

粘贴上传202205261621575266..png

2 G6 [" d0 c3 K) Q, S& p

下面我们看一下我们这里讲的 DevOps 或者说软件交付,在软件开发全过程中的位置。

+ e: o) @2 b7 r$ H

软件开发包括了哪些内容?总体上,大致划分为定义侧、实现侧,一起构成了软件开发。定义侧就是关于确定该研发什么,该把这个产品做成什么样子,产品的定义和业务定义是什么样的。产品经理,CEO 等都在这一侧,他们要定义产品是什么东西。


  \5 f) [8 N  L

而咱们在座所有人都是在实现侧,把定义的东西实现出来。实现侧大体上包括了设计编码、交付、运维三个部分。设计编码是 Dev、运维是 Ops,这两者中间是交付过程,也就是我们这里说的 DevOps,某种意义上,它可以说是既属于 Dev,又属于 Ops,是两者的交集。

. V2 R* D$ C. I+ _* c

好,我们搞清楚了概念,下面就开始介绍如何做调研。

1 s( M# F$ ?6 ]' t1 C, i

二、了解项目和团队总体情况
! {4 a7 M2 I- V" T2 i- @
粘贴上传202205261622211424..png
7 o: \* m" i0 [7 ^. H$ u% a  A

做调研,总得先了解一下总体情况吧。先看一下业务和系统的主要特征。8 p7 J6 I2 \* u% X/ V


( ~. g  M9 M; P- H

  • 业务:这里说的业务是指,产品是做什么的。进而要了解产品是企业内部用户使用,还是企业外部用户使用,等等。
  • 形态:这里指软件的形态。比如淘宝,它首先有服务端,成千上万台服务器。然后是客户端,手机淘宝。你要仔细分析服务端和客户端长什么样子。服务端可能全球只部署一套,所有人都访问这里。也有可能服务端是部署在各个企业内部,即私有云。服务端的不一样的情况会影响到 DevOps 的流程,如企业内部部署需要同时维护提供给不同企业的多个版本。客户端指的是用浏览器访问还是通过移动端 App 访问,还可能是嵌入式设备。只有分别考察客户端和服务端,才知道这个软件是什么形态,这个形态会决定后面调研什么。比如说客户端是浏览器,那考察的时候既要看服务端的后端模块也要看前端模块。而如果服务端是一个后端系统,供别的系统通过 API 和它打交道,这时候再看整个 DevOps 方案的时候就不关心前端的事情了,也不关心自动化UI测试,只需要关注自动化接口测试。
  • 规模:规模决定了软件开发的难度,也会影响到软件的交付过程。
    4 x( v; S" D0 |4 O
    • 软件规模是指有多少行源代码。研发团队规模是指由多少人在上面工作。因为人越多,协作越困难,需要分更多层级,越需要流程。
    • 还要看用户规模、部署规模。访问量大了,负载就高了,就需要部署更多的机器和节点。访问量大了,对质量的要求也有所提高。
    • 耦合性。耦合性是指如果系统是由一个个松散的单元组成,比如微服务,当你说规模的时候,基本上只需要关注一个微服务的规模就可以了,因为是相对独立的。而如果是一个强耦合的大系统,比如比较古老的一个大型单体应用,这时候不能只看某一个模块的规模了,在看规模的时候就得看系统整体的规模。. k9 J) j% k* Q: Q
  • 质量:一方面是质量要求高不高,另一方面看质量是不是好实现,如果算法特别复杂,逻辑特别复杂,可能就不好实现,如果只是一个简单的转接,就比较容易实现高质量。9 U' o5 M2 h3 @& V, w; k' {

/ s4 X( Z( V) a" d
  P4 a% Z$ f. ?% t, K
粘贴上传202205261622377039..png

3 H3 v3 X5 u2 K- n& P4 i. V

然后我们要大致了解一下管理实践。


8 C; V. K8 J/ o& C& G

首先一个问题是,这个产品管需求条目叫什么?就叫需求,还是用户故事,还是特性,甚至可能是项目。我们要用跟用户一样的语言,所以先要了解用户怎么说。另外需求是分层级的,我们关键是要抓住哪个层级呢?抓住可以独立测试、独立发布的需求,这个层级。因为将来它很可能会映射成一条 Feature 分支。将来统计测试的内容、发布的内容的时候,也说的是有哪些这样的条目。


) `% o  k4 v. z. |% t# T2 M% l5 k

接下来是关于开发的组织方式。典型的,Scrum 这样的迭代方式,或者精益看板墙来管理的精益方式。后者比前者要更好些。


; j- Y  d; ~3 I% U2 B7 E# D

最后落实到要看当前的发布频率。比如可能是每个迭代末发布。当然也有多个迭代才发布一次或者一个迭代发布多次的情况。


( c4 O  p2 }' t! w

粘贴上传202205261623095974..png


* m6 v& J( s) \' m: M' Y

接下来我们顺着生成转换过程了解下,从源代码,然后构建,再到部署运行起来。这些事情一方面是了解情况,比如用没用容器啊,用没用容器编排啊。另一方面和项目团队建立一些共同语言,将来沟通的时候,你说的别人听得懂。

为什么你说的别人听得懂?因为你是用别人的语言来说。比如说,开发环境,在不同的团队里,它的含义就不一样。有时候指的是个人开发环境,还有的时候指的是开发人员共用的一个服务器端的测试联调环境。
" e; s, L- A& z6 U1 q$ z

8 U% k: w+ P, I2 M3 f7 @

粘贴上传202205261623345860..png
" D5 c! ~8 s3 y. o: |3 M" j

最后看一下分支策略。如果想了解流程,那么先看分支策略,因为分支策略是承载了它的流程的。你能看到代码在哪儿 Checkout,在哪儿提交的,在这条分支上怎么被管理的,流程再往下走,提交到新的分支又怎么去管理,你顺着分支就捋下来了,就是一个完整的 DevOps 过程。


  j) V8 G7 D' A* h+ F

1000个项目有1000种分支策略。那你怎么去着手了解呢?有一个小的窍门,就是从这四个角度去了解:

  • 总的分支模式:是基于 GitFlow 模式,还是基于 AoneFlow 模式?跟这样的典型分支模式的差别在哪儿?如果这个事情一上来就弄清楚了,那可就省事儿了。
  • 代表线上最新版本分支:现在常用 master 分支来做这件事,它上面的版本代表了当前最新发布到生产环境的版本。
  • 集成/发布分支:典型的,GitFlow 里的 develop 分支。而 AoneFlow 里就没有一条长期存在的 develop 分支,而是一条一条的 release 分支。过去常提的主线开发模式,主线指的就是集成/发布分支。还有 Hotfix 用的分支,它的本质也是一条发布分支。
  • 特性分支:特性分支不一定需要。如果有的话,就看它叫什么名字,从哪里拉出来的,合并到哪里,合并之前要满足哪些质量上的要求等等。

    % F: l, j# i/ S
三、沿价值流进行梳理( O3 C5 [9 E% `. }/ j2 ]$ ~
9 @# O$ F  I5 ]/ g

6 H$ U/ t" _: {4 I4 ~! d解完总体情况,下面我们来梳理价值流。这是精益里面的一个方法,沿着软件交付的流程进行梳理,从写下一行代码开始,是怎么一步一步最后发布上线的。通过梳理找到要改进的地方。5 L2 h) s% O0 X' {9 S. _+ R
4 |( L2 D0 f! q$ F/ M
- C0 F3 d$ x3 Y: ^
粘贴上传202205261623485385..png
! b: q/ X- W. E

既然是沿价值流进行梳理,那我们就解释一下软件交付过程的6个阶段。

/ x; H/ y& @+ I

  • 代码改动累积。代码改动累积就是在本地开发环境里没有做 git push 之前的事,随着不断地开发、不断地写代码,你要不断进行测试。这包括了静态代码扫描,也包括了本地的人工自测试、单元测试等等。关于自测试,还要详细考察,它是端到端的,还是只测一个微服务,其他都 mock 了。后者其实还是挺不够的,因为还有很多问题没有测到。理想情况下,尽管微服务是在个人开发环境里跑起来的,但是可以连通到整体测试环境和整体系统,于是可以做端到端的测试,这时候会发现更多的问题,将来遗漏给测试人员让他遇到的麻烦更少。代码改动累积阶段应该被重视。
  • 代码改动提交。看看在 Push 之前有没有进一步的质量确认步骤。另外还要考察,多久提交一次。以前常说每天都提交,这可不是说,每天下班前必须要提交一次,是大概频率就好。
  • 特性改动累积。如果你使用了特性分支,那就有这个阶段。为每一个用户故事、每一个需求拉出特性分支,在这个分支上面,为这个特性不断开发和 git push。在特性分支上,改动不断累积。并且可能每次 Push 都触发了流水线,做构建、单元测试、代码扫描。
  • 特性改动提交。特性改动完成了,把特性分支合并到集成分支。这经常是一个 Merge Request 或者 Pull Request。
  • 集成。它是指在集成分支上,不断收到新的特性或者新的代码改动,不断累积,在累积过程当中不断给你质量上的反馈,比如说提交触发流水线。进而做持续测试,不要等着所有功能开发后再测试,即使人工测试也不要这么等。每当有一两个 Feature 做完了,合并到集成分支上了,测试人员又有空闲,那就去做测试。
  • 发布。这个阶段指什么呢?是指当所有的打算发布的功能都做完了,都提交到集成分支了,于是开始这个阶段。这个时候进行进一步的测试,如果测试特别顺利,全都通过了,那我就发布了。不像集成的时候,即便测试通过了也不会发布,因为还没攒够一拨呢。所以发布阶段就是最后一哆嗦。这里最重要的策略就是把发布阶段里干的事情尽量往前挪,挪到集成阶段,甚至再往前挪。我们要尽量避免在发布阶段做很多事情,这样我们才能比较频繁地发布。
    ) ]; ~1 r' h* w5 b
6 _2 i; T! R9 P+ f
, q' x3 C1 M# z$ L

所以看起来就是,首先是代码改动的不断累积不断测试,然后 piu,提交上去。接下来是特性分支上改动不断累积不断测试,然后 piu,合并到集成分支。最后是集成分支上代码不断累积不断测试,最后 piu,发布出去。你用这个框架去调研项目实际的交付流程,会让你思路特别的清晰。

3 I0 E+ G) L1 z* ?8 f

四、了解各个具体活动% E" ]/ _$ G0 B; z! A8 G' a! u

我们沿价值流进行了梳理,了解了在流程上,何时发生了什么,各个具体的活动是在什么时候发生的。但是对具体的活动本身,还需要更深入细致的了解。一个活动一个活动地细致深入地了解。


( |- ]( T' W" u4 s6 {' C

我们把所有的活动分一下类,然后看一下每个分类里面有哪些活动。


+ ~  Q- ]& `2 O

粘贴上传202205261624121743..png

/ y- z% c/ a3 X+ K8 r0 U

左边是非测试的活动。上面是源代码版本控制、构建、构建环境管理、制品管理等,总之是从源代码到构建,再把构建生成的制品储存起来。


# v7 [7 R9 f7 O

下面是部署运行方面的事情,也就是怎么让制品变成运行中的程序,并为它提供环境上的支持。

* t, q! i' E7 l: _

右边是测试相关的活动。上面是静态测试,也就是靠分析源代码就进行的测试。包括人工的评审,也包括自动的代码扫描和制品分析。

: q. f8 |# |! H8 Q+ w, l0 O

下面是动态测试,也就是让程序跑起来进行的测试。从最简单的单元测试开始,一直到在生产环境下做的测试,比如全链路压测什么的。(转自董越)


' x, H" g: g( [# F
/ S4 C/ S, q  v  F7 h& i+ [4 I




上一篇:DevOps赋能软件定义汽车
下一篇:运维必备的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, 2023-1-28 02:18 , Processed in 0.101797 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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