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

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

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 1019|回复: 0

搞DevOps团队结构该怎么规划?请对号入座,给你安排得明明白白

[复制链接]
发表于 2020-1-22 09:25:57 | 显示全部楼层 |阅读模式
本帖最后由 adminlily 于 2020-1-22 09:36 编辑 ; U3 }1 t) B9 X" [: z/ L& F( N
9 a0 H2 f5 G+ y3 Q
为了实现有效的 Dev 和 Ops 协同,不同的组织可能需要不同的团队结构。本文提出了 DevOps 实践的几种反面模式和一些最佳组织结构,可以参考改进。
/ g! k! n% R2 M  n5 C. N4 H9 t7 Y

, p) m, m& `; ~1 E. E* C; L, k
前言   
组织中任何 DevOps 工作的主要目标都是改进客户和业务的价值交付,而不是降低成本、提升自动化或者通过配置管理驱动一切;这意味着,为了实现有效的 Dev 和 Ops 协同,不同的组织可能需要不同的团队结构。

, P( i5 p  f0 _! S5 D
; S8 s+ ~5 J# D
概述   3 D% `' t# t: u+ ~# ~) W
具体哪种 DevOps 团队结构或拓扑适合组织取决于以下几个方面:

- V6 J  r; Z* |* H$ D
  • 组织的产品集:产品越少协同越简单,就像康威定律预言的那样,自然形成的筒仓就越少;
  • 技术领导者的职责范围、实力和有效性;Dev 和 Ops 是否有共同的目标;
  • 组织是否有能力或意愿变革其 IT 运维部门,使其不再只是“上架硬件”和“配置服务器”,而是成为真正与价值流一致的部门,使运维特性为软件团队所重视;
  • 组织是否有能力或技能主导运维。6 e; ?" N" _: H8 T" y
    6 B6 u* L/ C2 l
! K2 V3 l6 C; \' Z) w
当然,这里列出的主题有些差异;这些拓扑和类型可作为参考指南用于评估某个模式是否恰当。实际上,组合多个模式或将一个模式转换为另一个模式通常是最好的方法。
$ ]) ^( F4 l/ y: c
那么,什么样的团队结构适合采用 DevOps 呢?显然,不存在适合每个组织的神奇结构或团队拓扑。然而,介绍几种不同的团队结构模型是有用处的,其中一些模型比其他模型更适合某些组织。通过探索这些团队结构(或“拓扑”)的优缺点,我们可以确定自己的组织中最适合 DevOps 实践的团队结构,并考虑康威定律。
1 ?" C- H' I* f) _
下面为你一一介绍 DevOps 实践的各种团队结构。

* J' |9 N# R, Z- w

# |  a! ~3 X7 ]0 ?" s
DevOps 的反类型
, R2 }; L/ \+ m5 `/ Y  @" U2 I9 c
了解一些糟糕的做法是有用处的,我们可以叫它们“反类型(anti-types)”(这个叫法源于我们常见的“反模式”)。 反类型 A:Dev 和 Ops 筒仓
反类型 A:Dev 和 Ops 筒仓
这是典型的 Dev 和 Ops“各管一摊”。这意味着可以尽早声明故事点“完工”(意味着“特性完成”,但还没应用到生产中),而软件可操作性受损,因为 Dev 没有足够的有关运维特性的上下文信息,而 Ops 人员没有时间或无意为了软件上线前解决问题而参与开发。

4 f' d( e7 i. D6 q/ r+ ?
我们可能都知道这种拓扑不好,但我认为,还有实际上更糟糕的拓扑;对于反类型 A(Dev 和 Ops 筒仓),我们至少知道这其中寻在问题。
" u8 f; P, t' Q: S6 p. S$ b! R
; k/ W; B$ M6 d* w

! _9 o- R# n# ~6 p; P; }
2 S) ~) L' ]3 Q7 s  G- {
反类型 B:DevOps 团队筒仓
DevOps 团队筒仓(反类型 B)的形成通常是因为经理或主管认定他们“需要一点 DevOps 的东西”并创建了一个“DevOps 团队”(可能其中全是被称为“DevOp”的人)。DevOps 团队的成员迅速形成另一个筒仓,Dev 和 Ops 远比以往任何时候都注意保持距离,因为他们要捍卫自己的老窝、技能和工具集,不被那些“一无所知的 Dev”和“守旧落伍的 Ops”所破坏。
) y1 |; Z* x8 ~  K
一个单独的 DevOps 筒仓只在一种情况下是真正有意义的,就是该团队为临时团队,存在时间不超过 12 或 18 个月,其目的是为了让 Dev 和 Ops 团结起来,而且很明确,过了这段时间,该 DevOps 团队就是多余的了;这是我下文所说的 5 型 DevOps 拓扑。
) L, n4 p& |$ Z+ i  m4 a5 W
5 i, g: O6 W* s; i4 P% M
图片来源:
反类型 C:Dev 不需要 Ops
这种拓扑诞生于开发人员和开发经理的天真和傲慢,特别是当开始新项目或系统时。假设 Ops 现在已经成为过去(“我们现在有云,对吧?”),开发人员严重低估了运维技能和活动的复杂性和重要性,并相信可以没有他们,或者只在空闲时间涉及他们。
5 e6 m/ X1 B5 e! n+ h9 v% Q! x
这种反类型 C 的 DevOps 拓扑可能最终需要下文说到的 3 型(Ops 即 IaaS) 或 4 型 (DevOps 即服务)的拓扑,因为他们的软件变得更加复杂,并且运维活动开始占用“开发”(即编码)时间。要是这样的团队认识到,运维作为一门学科的重要性与软件开发同等重要和有价值,他们就能够避免许多痛苦和不必要的(非常基本的)运维错误。

0 ]5 a# Z% C+ G8 U& N) `

8 b  {  n0 x" l) X/ c2 p
图片来源:
反类型 D:DevOps 作为工具团队
为了“成为 DevOps”而又不影响当前 Dev 团队的速度(或者说功能点交付),创建一个 DevOps 团队致力于部署管道、配置管理、环境管理等所需的工具。同时,运维人员继续孤立工作,而 Dev 团队继续把应用程序从“墙上”扔给他们。

- U6 ^2 b) m2 i5 Z: S/ T0 F4 G
尽管这个专门小组的成果就改进工具链而言可能是有好处的,但其影响很有限。在应用程序开发生命周期中 Ops 人员未能早期参与和协作的基本问题仍然没有改变。

  x! Z: Q2 }0 M" P% l, Q, X3 |

! i4 f1 E9 {3 B# F: B$ D
图片来源:# j! Z# F7 f% s; c( U
反类型 E:换个名的 SysAdmin
这种反类型在工程成熟度较低的组织中很典型。他们想要提高实践并降低成本,然而,他们并没有将 IT 视为业务的核心推动力。因为 DevOps 在行业内取得的成功现在已经显而易见,所以他们想“做 DevOps”。不幸的是,他们没有反思当前的结构和关系存在什么差距就去为 Ops 团队招聘“DevOps 工程师”,这很难达到目的。
8 U+ v* a) w& e/ U
DevOps 只是对以前的 SysAdmin 角色改了个名,没有真正的文化 / 组织变革发生。这种反类型正变得越来越普遍,因为为了招揽人才而无所不为的招聘人员会赶时髦,寻找具有自动化和工具技能的求职者。遗憾的是,人类的沟通技巧可以让 DevOps 在组织中茁壮成长。
5 D6 @# _9 a3 e" w3 }8 ]2 O# ?

* |* `7 e) Q! K4 p% E( p  q
图片来源:
反类型 F:Ops 嵌入到 Dev 团队
组织不希望保留一个单独的运维团队,因此,开发团队会负责基础设施、管理环境、监控等。然而,在项目或产品导向的方式中,这样做意味着这些工作会受到资源限制和优先级重排的影响,导致低于标准的方法和不成熟的解决方案。
% F( A1 [) R$ p/ L0 Q4 x& ^6 c
这种反类型表明,组织对有效 IT 运维的重要性和所需的技能缺乏认识。特别地,开发人员将其视为一种烦恼,Ops 的价值因此被贬低(Ops 是由开发团队的管理者管理的,而开发团队往往有其他的优先级事项)。

- c- D& v3 C9 l8 u+ v7 F: \' h4 D! ]
感谢 Scott Prugh 建议我对反类型 F 与 2 型的区别进行说明。图片来源:
反类型 G:Dev 和 DBA 筒仓
这是 反类型 A (Dev 和 Ops 筒仓) 的一种形式,在中大型公司中非常突出,在这些公司中,多个遗留系统依赖于相同的核心数据集。因为这些数据库对于业务而言非常重要,在 Ops 保护伞下会有一个专门的 DBA 团队,负责它们的维护、性能调优和灾难恢复。这是可以理解的。问题是,当这个团队成为任何数据库变更的守门人时,它实际上就成为频繁的小规模部署(DevOps 和持续交付的核心原则)的障碍。

. E% P  d+ D, M  n4 A5 r. s
此外,就像 反类型 A 中的 Ops,DBA 团队并不参与应用程序的早期开发,因此,在交付周期中会发现数据问题(迁移、性能等)。再加上需要负责多个应用程序的数据库,最终的结果是不断地灭火和越来越大的交付压力。

4 N0 G8 u! b: w* v4 o( T4 g

: |7 a/ L8 A5 ?8 _" V# @
图片来源:
0 G6 [- K! u0 q* B. T
DevOps 团队拓扑与反类型相反,让我们看一些有效的 DevOps 拓扑。
1 型:Dev 与 Ops 协作
这是 DevOps 的“应许之地”:Dev 团队和 Ops 团队之间顺畅协作,各自专注于自己的工作,并在必要的时候互相分担。可能有许多单独的 Dev 团队,每个团队致力于一个独立或半独立的产品栈。
1 I. t* u5 h1 N  p% S& H: w9 l
我的感觉是,这种 1 型模型的建立需要相当大量的组织变革,并且要求技术管理团队的高层具有一定的能力。Dev 和 Ops 必须有一个清晰描述且明显有效的共同目标(提供可靠而频繁的变更,诸如此类)。Ops 人员必须适应与 Dev 人员搭配,掌握测试驱动编码和 Git,而 Dev 人员必须认真对待运维特性,从 Ops 人员那里获得日志实现的输入,等等,所有这些都需要相当大的文化变革。

0 s7 I8 H% E$ W) t$ U

- P6 A! @7 }4 _! ?( v% ^1 ^$ i
图片来源:
; \. L6 w! v2 B0 b6 K: U

% m6 g4 @& Q4 l1 B3 ]+ x  L
6 }( ?& T" R. f4 ]2 B6 {
1 型适用于具有强力技术领导者的组织

3 {: D1 C6 B0 g" Q8 [潜在有效性:高
2 型:完全共担 Ops 职责0 Q% a# C' J5 a% Z% @
运维人员已经被整合到产品开发团队,我们看到了一个 2 型拓扑。Dev 和 Ops 之间几乎密不可分,所有人都高度关注同一个目标,这是一种有争议的 1 型(Dev 和 Ops 协作) 形式,但它有一些自己的特点。

. N- G* ~5 x, `# ]
像 Netflix 和 Facebook 这种实际上只有一种 Web 产品的组织已经实现了这种 2 型拓扑,但我认为,如果不是只关注少量核心产品,这种模式可能不是非常适用,因为在拥有多个产品流的组织中,预算限制和上下文切换很可能会迫使 Dev 和 Ops 进一步分开(比如说回到 1 型模型)。由于没有明显的或可见的运维团队,所以这种拓扑可能也被称为“NoOps”,(尽管 Netflix NoOps 也可以是下文的 3 型(Ops 即 IaaS))。
7 D% [$ v$ p' E1 a- c& }& C: a
图片来源:
2 型适用于具有单一主要 Web 产品或服务的组织
# p$ s! ^& @; f0 t$ C! ?
潜在有效性:高
3 型:Ops 即 IaaS(平台)
; L* N& R4 \; {9 x% S) m( L
对于具有传统 IT 运维部门(不能或不愿做出足够迅速的变更)的组织,以及将所有应用程序运行在公有云(Amazon EC2、Rackspace、Azure 等等)上的组织,这可能有助于将运维视为一个团队,他们只是提供了弹性基础设施供应用程序在上面部署和运行;为此,内部 Ops 团队直接就相当于 Amazon EC2 或“基础设施即服务(IaaS)”。

: a, U4 ~' b4 M" F
然后,Dev 中的一个团队(也许是一个虚拟团队)可以作为运维特性、指标、监控、服务器配置等方面的专家组,可能负责大部分与 IaaS 团队的沟通。然而,这个团队仍然是一个 Dev 团队,遵循 TDD、CI、迭代开发等标准实践。
IaaS 拓扑的潜在效益是实现更容易(不必和 Ops 人员直接协作)完成,可能比尝试 1 型(Dev 和 Ops 协作)拓扑 更快地获得价值,至于 1 型,可以后续再试。
* R2 ?4 {5 `- o. v7 X) a- _2 c6 w7 Q
图片来源:
' {6 @5 P* u/ j4 \5 S

3 U; e' A# L* v9 ?% g& [3 t& k7 `( l
3 型适用于有多个不同的产品和服务以及传统 Ops 部门的组织,或者应用程序全部在公有云上运行的组织

) V) ]4 [, l4 ?2 R" ?/ O& l: U潜在有效性:中
4 型:DevOps 作为外部服务! C* l1 I" g3 [% i, c5 [
有些组织,特别是较小的组织,可能没有财力、经验或人力可以运维其开发的软件。Dev 团队可能会联系服务提供者,如 Rackspace,帮助他们构建测试环境及自动化基础设施和监控,并就他们在软件开发周期中实现何种运维特性提供建议。

+ H6 ?5 O! f8 \
对于小型组织或团队,如果他们想要学习自动化、监控和配置管理,然后随着他们的发展,会有更多的人专注于运维,他们可能发展成 3 型(Ops 即 IaaS) 甚至 1 型(Dev 和 Ops 协作) 模型,那么 DevOps 即服务可能是一个有效而务实的方式。
$ C) E* F7 x- Z# c$ d7 z- |9 l5 }5 E
图片来源:
4 型适用于运维问题相关经验比较有限的小型团队或组织
; f4 c& y# q$ D6 B) R( V' j# z. X
潜在有效性:中
5 型:具有截止日期的 DevOps 团队% G7 H6 D" n) Q
具有截止日期的 DevOps 团队(5 型)看上去非常像 反类型 B(DevOps 团队筒仓),但它的意图和期限有很大的不同。这个临时团队的使命是让 Dev 和 Ops 更紧密地联系在一起,在理想的情况下向 1 型(Dev 和 Ops 协作) 或 2 型(完全共担Ops 职责) 模型转化,并最终会淘汰掉。

) h3 M8 Q& |. e
临时团队的成员将“翻译”Dev 语言和 Ops 语言,引入大胆的想法,像站立会议和运维团队看板,考虑讨人厌的细节,如负载均衡、管理 NIC 以及为 Dev 团队进行 SSL 减负(offloading )。如果有足够多的人开始看到 Dev 和 Ops 一起协作带来的价值,那么临时团队就真正获得了一个达成目标的机会,至关重要的是,部署和生产诊断的长期职责不应该给临时团队,否则它就可能会成为一个 DevOps 团队筒仓(反类型 B)。

& H' s. m+ ~) w) {
图片来源:
5 型是 1 型拓扑 的前身,但要注意 反类型 B 的危险
0 ~1 {2 j1 z2 H
潜在有效性:低到高
6 型:DevOps 布道团队0 P% X3 S0 [. `; [) P
在 Dev 和 Ops 之间存在巨大鸿沟(或者差距有变得很大的趋势)的组织里,它可以有效地“促进”DevOps 团队,保证 Dev 和 Ops 之间的对话。这是 5 型具有截止日期的 DevOps 团队 的一个版本,但这里的 DevOps 团队是一直存在的,其具体职责是促进 Dev 团队和 Ops 团队之间的协作。这个团队的成员有时也被称作“DevOps 布道者”,因为他们帮助宣传 DevOps 实践。

5 e, e( {7 x3 S3 _, n1 G
“DevOps 团队”的目标应该是通过赋能组织的其他部分来让自己脱离业务。

( D: E0 V6 e$ d" m- s5 ^$ x7 j: {7 u# K
! }+ b! v+ g9 Z
图片来源:
( A- e4 X8 F; I( |7 p

/ @( |' E' K2 _+ z. B6 k% t# Y
6 型适用于 Dev 和 Ops 之间有疏远趋势的组织。注意 反类型 B 的危险

  F: B( V. h; Q4 H) g$ M潜在有效性:中到高
7 型:SRE 团队(谷歌模型)
" f* t! B: A! @
DevOps 经常建议 Dev 团队加入值班轮换,但这不是必要的。事实上,有些组织(包括谷歌)运行一个不同的模型,软件由开发团队显式“交接给”运行软件的团队,即网站可靠性工程团队(SRE)。在这个模型中,Dev 团队需要向 SRE 团队提供测试证据(日志、指标等),证明他们的软件已经达到一个 SRE 团队认为足够好的标准。
) ?. t2 G& ^) ?0 M
至关重要的是,SRE 团队可以拒绝不符合运维标准的软件,要求开发人员在投入生产之前改进代码。Dev 和 SRE 之间的协作围绕着运维标准展开,但是,一旦 SRE 团队对代码满意,他们(而不是 Dev 团队)就会在生产环境中提供支持。
& g* H; c& g. `* [
图片来源:
7 型只适用于工程和组织成熟度较高的组织。如果 SRE/Ops 团队被告知进行“JFDI”部署,则要注意不要回到 反类型 A

& i/ A8 c9 j6 D9 F& v潜在有效性:低到高
8 型:容器驱动协作
4 N/ \* \! V0 p) _
容器将应用程序的部署和运行要求封装到了容器中,消除了 Dev 和 Ops 之间的某些协作需求。在这种情况下,容器充当了 Dev 和 Ops 的责任边界。在良好的工程文化中,容器驱动协作模型运转良好,但是,如果 Dev 开始忽视运维注意事项,那么,这个模型就会向敌对的“我们和他们”回归。
; j' o5 R3 W$ p5 E4 D1 Y
图片来源:
2 X9 N1 u# x4 c4 w0 p, ]

, T5 c* h( {/ W' ~! d
8 型适用性:容器可以很好地发挥作用,但要注意 反类型 A,不要期望 Ops 团队运行 Dev 扔给他们的任何东西

9 ~! Y! ?" s/ D: V4 b潜在有效性:中到高
9 型:Dev 和 DBA 协作
! q2 o) |& p, R% l9 @- J: g4 o
为了消除 Dev 和 DBA 之间的鸿沟,有些组织已经尝试使用类似 9 型的模型,DBA 团队的数据库能力与 Dev 团队的数据库能力(或专长)可以很好地互补。这似乎有助于将以 Dev 为中心的数据库视图(基本上就是作为应用程序笨拙的持久性存储)和以 DBA 为中心的数据库视图(智能丰富的业务价值源)之间的转换。

" F) o$ f9 S8 Q% T! K' t! |; q

6 e2 X/ e9 o" m# W$ k2 C* R& }& H4 W' h8 I
9 型只适用于有一个或多个大型中心数据库连接多个应用程序的组织

; ]7 C9 j" n$ K3 V潜在有效性:中
你所在的团队开始采用 DevOps 了吗,采用的怎样的模式呢?欢迎大家在评论区一起谈谈。
# ^6 _: D  _: k0 X0 G
, q; S& N9 _# M) e" o0 q
20190219141858.jpg
20190219141904.jpg
20190219141912.jpg
20190219141919-780x452.jpg
20190219141925-780x452.jpg
20190219141931-780x452.jpg
20190219141938-780x452.jpg
20190219141945.jpg
20190219141951.jpg
20190219141958.jpg
20190219142004.jpg
20190219142009.jpg
20190219142015-780x452.jpg
20190219142022-780x452.jpg
20190219142028-780x452.jpg
20190219142034-780x452.jpg




上一篇:2019 年 DevOps 实践中最有价值的技能
下一篇:Netflix、Oracle、ING、思科、JFrog都如何做DevOps的?

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2020-9-24 05:41 , Processed in 0.178997 second(s), 27 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

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