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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 534|回复: 0

新鲜出炉2017年的 DevOps 报告

[复制链接]
来自- 巴西

参加活动:0

组织活动:0

发表于 2018-9-21 17:33:25 | 显示全部楼层 |阅读模式 来自- 巴西
本帖最后由 adminlily 于 2018-9-21 17:38 编辑
3 B9 y1 Z5 u- u8 }- R
+ `6 t: T+ Q/ z$ ^
1.png

3 n8 y& o6 s* o; u5 T, o% i
8 O5 m$ N9 P0 R2 [: e% N/ ?0 W

3 v  k3 r  C- K" ^3 V' x, W
又是一年年中时:由 Puppet 与 DevOps 研究与评估(简称 DORA)协会共同发布的最新《DevOps 现状调查报告(State of DevOps)》再度出炉。作为本轮的核心议题,双方分析了“高效领导者如何影响技术实践与流程改进,从而带来更为理想的 IT 与组织运作成效,同时确认称自动化水平已然成为不同企业之间的核心区别所在。”
. y* M% f2 q6 J+ s' ^
) W- ]7 t6 v: k
今年,双方对 3200 名 IT 专业人士、开发人员以及高层管理者进行了调查,并发现每一年 DevOps 团队的人员规模都保持着持续上涨。三年之前,只有 16% 的受访者身为 DevOps 团队成员,但如今这一比例几乎翻了一番(达到 27%)。先来三张图解释这次报告    # _/ D0 S, c* A* ~. ^8 }
& v! X- k- i0 u) s) g
9 T/ t8 ]0 ?" z8 M1 m$ m
  受访者图像5 B3 F, Z) c8 g1 M/ W

3 M( p' ]& W" c: V5 ~, ]
! C. ?3 c, k  A2 T
7 l1 O" x3 n9 B3 A: I
今年 Puppet 对全球范围约 3200 人进行的一次调查,包括高管,开发人员和 IT 专业人士。 最多的受访者来自拥有 100-499,500-1999 和 10k + 员工规模的组织,其中大多数来自 DevOps,IT Ops / 基础设施和开发 / 工程类别。
! E) M; T$ r3 s6 S3 Y0 c
0 z% `" n" y) U2 ?
然而,性别比例偏差依然很大,女性和其他人分别占 6%和 3%。 北美的受访者人数最多(54%),欧洲和俄罗斯为 27%,亚洲为 10%。 科技公司去年仍然领先(34%),其次是金融服务(14%),其次是教育、零售、电信和政府机构,达到 6-8%。

) z. B. u6 x7 y9 f0 e, M1 f
: A, G  I6 H4 C& h' f6 R
调查中发现在 DevOps 团队工作的受访者人数在过去三年中从 16%上升到 27%,表明 DevOps 采用率有所上升。
$ ^; G3 {5 O  z0 k0 r! a
' @+ {4 Y9 Y/ O: _( [  M; V
1.png  
   0 D" v5 l( F% K" N. Q7 E* {+ Y
- F5 j- E# @4 s1 Z3 d2 l
  h- W+ i# g7 q8 a; `# u) k+ b) H
高绩效 vs 低绩效团队的对比
. @. C5 g  ?7 V4 ]+ Y2 A
" d- ~% F* ^3 k+ b' }5 Q5 I, M& L
# V3 w; j, z( V3 ]/ I( |" x
该报告区分了高绩效和低绩效的团队,并阐述了他们之间的差异。 与去年类似,绩效指标如下:
& ]# L( |% P5 o1 n8 T/ I+ O# d. }
: M/ V0 T' {1 ?: g' p4 b5 V# W
  • 部署频率 - 部署到生产的频率

    # b% s: \' D  P) k" _$ ^5 B
7 G/ j% U( l. y$ P8 Y% n+ C% F
. t$ @8 d* Y3 \: n0 u" `8 Z
  • 改变的交付时间 - 如何快速地将新的变化推向生产

    ; ?+ H& l' m: x' d* t
/ K/ `- n7 `, W5 e/ Q7 Z
  • 平均恢复时间(MTTR) - 从故障中恢复的平均时间(中断)

    ' r( u3 j7 f4 o& ]8 j4 E2 m" t: f

+ y# k* ?  \+ O
  • 更改故障率 - 更改导致部署管道故障的频率

    3 ]* I5 j" r, W6 Y* D0 S: ]
$ E4 i1 G" H- G( X* J$ o

# Y% Z, A* o- c% R" Q9 N3 y. p
  • 0 I9 V4 q7 Z7 Q" Y8 I  L- U
与上一年相比,高绩效者在所有指标上有所改善。 它们的代码部署频繁 46 倍,MTTR 快 96 倍。 不过,与上一年相比,表现较差的人员在多项指标方面也有所改善。
# L* d+ P. d/ s8 b

: K+ [0 O0 `7 N! h: g( [) N! C
自动化实践显着上升,特别是在高绩效团队中,28%的配置管理和 26%的部署已被自动化。
1.png
- g; h) h3 z: u7 R
& |. B6 n: I% ~
此份报告显示,高成效 DevOps 团队在代码生成量与稳定性方面优于低成效团队。根据结论,高成效 DevOps 团队拥有:

" s8 e' ^6 H  h# L/ ]* p! Q

# v0 o5 @! w8 W
  • 46 倍于低成效团队的代码部署频率
    2 H% J6 _+ ?( R, u  c

# F+ ~( t, Z, S% F

7 p; E7 s% o# `# x7 A, _$ ]3 x6 u
  • 440 倍于低成效团队的代码提交至代码部署实施速度

    ' M$ A$ ^4 y+ y# U+ M

+ S- w# C# ^; F( z2 P+ |
  • 96 倍于低成效团队的停机后平均恢复速度

    5 b2 U2 Z9 ?( t; c' {; t6 L; l$ a4 o) |1 [0 O
% ]# y( Y- |: v) D
  • 变更故障率仅为低成效团队的五分之一(即二者变更故障比率为 1 比 5)
    5 y+ {; ^0 B8 v. B! V
$ \/ @3 |7 r+ h  K1 s! \$ B' U8 W
通过与 2016 年的调查结果进行比较,Puppet 报告发现高成效团队与低成效团队在代码生成量(包括部署频率与变更速度)方面的差距有所缩小,但稳定性(平均恢复时长与变更故障率)则进一步扩大。
$ A, V( A8 v8 \( v0 v

7 j2 a7 P9 Z+ E0 q6 ^! B# X: K
    关注连续能力3 ?: Q* @0 X1 |( [8 V6 q' m7 y1 r. P
1 v2 Y8 C, L, F
! P; p4 P" c$ F
组织做连续交付(CD)的能力是通过两个因素衡量的:从需求到生产的部署能力,并快速响应团队中的每名成员。

6 n) y* M* f4 g. ]' M

' Y0 {' u: N  i1 p4 W
为实现这些成果,需要顾及的因素包括综合版本控制、CI、基于中继的部署,包括软件交付过程中的安全性,测试和部署自动化。架构层面的服务和团队的松散耦合。服务之间的耦合性的衡量是从人们是否可以在不需要集成环境的情况下进行测试,以及这些服务是否可以独立于其他服务部署。

* F  `+ @) b+ {- @4 h

) U* s4 I3 c0 H$ a
实现高性能 DevOps 的非技术方面包括精益产品管理。该报告将此定义为三个功能 - 将工作分成小批量,使工作流程可视化,收集,广播和实施客户反馈,并使开发团队有权在开发过程中创建或更改规范,而无需批准。
$ K; E% r/ m/ A" x

% F" ~# S9 K0 K/ T- d. Q$ I% L$ V
团队的领导本身还不足于决定高质量的 DevOps 落地,还要取决于是否有合适的架构和良好的技术实践。报告作者使用结构方程模型(SEM)作为衡量与软件交付相关的预测模型。
1.png

! n. B0 A9 i. d! g5 D: D
# ^9 m  I1 F2 C6 N
当企业决定采用 DevOps 理念时,其亦面临着众多前所未有的新问题,包括“如何吸引工程师的参与”以及“如何吸引领导者的参与”。

9 i3 C$ |; p4 h  M, A

2 J5 `* c* J1 E# X: p
根据 Puppet 公司在报告中所言

. `+ N) N; c3 K4 s% ?
% X9 @, ?4 n% s' n) q& x) \
“每个人都意识到杰出的领导者在成功实现 DevOps 转型工作当中的重要意义。”
. l6 C6 a& R& B, _' ~/ o
3 {! Y7 @* X% m7 a$ X
“仅具备变革性特质的领导者并不足以带来理想的 DevOps 成果。”

- N9 m; n) o+ f/ ?' t

3 `! r6 I3 e9 X, `* ~) F8 S6 e
这是因为领导者无法单凭一己之力实现 DevOps 转型成效。DevOps 能否成功亦取决于架构是否合适、技术实践是否良好、精益管理原则的使用方式以及我们多年来在研究中囊括的其它重要影响因素。

2 ~7 H+ S8 u' B) Z2 G7 w" E0 E3 G8 u/ x; R) Q, c" }& ~6 Z4 m
成功 DevOps 团队的普适性实践      重点在于持续交付; s# Y( X# f& j1 v/ [

1 D6 p& _5 E+ t# b, a5 B. {* E! n5 D
5 X8 E. R2 W9 T( I8 ^" `" H- m* d
今年的报告归纳出以下将对持续交付带来积极影响的关键性因素:

1 v- a. H: A9 ~" z: D, D
; Q4 n' ^: R% M9 K# X5 t
  • 全面采用版本控制机制;

    + X5 Z+ f8 u8 j
5 f1 `+ Q, I; L; ]
  • 持续集成与主干开发;
    , I' G$ N1 m% Q& C$ _9 t  g, ?9 W

* s5 w0 o- Z  H, p
  • 将安全性保障整合至软件交付工作当中;
    7 Q+ T5 V. \' L9 L5 [+ ?( `% {
* U# K! }* I6 _0 M" p6 {+ {/ s
  • 采用测试与部署自动化方案。
    1 P$ E* j. y/ B; q' y/ Z

5 Y7 b' |" A' g5 T
在以上因素当中,测试自动化的的贡献效果最为突出。

2 X/ S/ H" ~& F0 ]5 @
( }( x& R% M( `# o% W5 i5 a
    团队层面的具体举措3 e( e+ c7 Q2 k/ P( {% T' O

4 Q# y+ g; U5 D$ d
( k7 j2 Y  r- ?  s
另外,以下团队整体层面的具体举措能够将持续交付成效提升至新的高度:

  P, f' F8 p5 ^& a; W/ G5 R1 S! ^

' V, n  @$ v0 q3 \7 I- v# T
  • 无需从团队外人士处获取批准即可对系统设计进行大规模变更。

    ' J4 W% e6 u) u- ^- N4 O$ ^

4 n4 S: ^3 y5 a  ^$ z
  • 无需其它团队变更自有系统或者承担大量相关配合工作,即可对系统设计进行大规模变更。

    ( f9 I0 \! T( X" {# G

- z4 U( ?# l9 I; G8 Z  y9 F

8 d- q+ k7 V3 H/ R% v9 C
  • 无需与团队外人士进行细化沟通及协调即可完成工作。例如无需经历多次预约及交流以获取反馈意见。
    ' L* C8 H) V; M2 f# L, h2 l  p
1 }2 q# ]! V5 ]) Y1 X
  • 根据需求实现产品或服务的部署与服务,且相关工作不依赖于其它服务。
    * t* h. Z( a3 J/ `9 D

, N' z) S* u) G' d+ ?
  • 无需使用集成化测试环境即可根据需要完成大部分测试任务。
    " K' B) o$ E8 k- I
; |, G# ]$ e4 ]1 w8 Q- L, G" `+ r. I
  • 在正常营业时间内执行部署,且停机时长可以忽略不计。
    8 n, s6 @) @  S- [

9 e7 I5 |4 w7 h- J6 V+ O    赋权为成功之母
& J1 m6 q6 d+ {: ~0 u& }4 J- i9 M6 a: m8 t% U( o$ J8 `
# \: s# D3 |( ^6 H/ J7 y
这份报告指出,“众多号称实施敏捷化原则的团队仍然要求开发团队必须遵守由多个不同部门制定的具体规则。这种限制可能引发一系列实际问题,导致产品无法真正吸引客户或者受到客户青睐,亦无法提供与预期相符的业务成果。”

6 Q+ a& R# p6 I' y

& k* K% i' S) s" C  E
研究结果表明,各团队在开发过程当中能否切实尝试新鲜思路并对规范进行建立与更新(无需团队之外人士的批准),已然成为决定盈利能力、生产效率以及市场份额等核心团队成效指标的一大重要因素。

1 h6 I4 M9 K* T0 r

( q( O1 G  n8 \3 {8 R3 l
尽管报告作者并不建议开发人员完全依照个人思路处理工作内容,但其仍强调称“组织应将赋权的重要意义与以下能力衡量因素加以同等重视:分批工作 ; 在工作流中确保交付流程对每位成员保持透明 ; 并将客户反馈纳入产品设计当中。”
1 f# Y% u8 v8 F! U3 ]* I% g. [1 D& X* t

  p- q$ F1 K/ C% P. ~: V# S& @
DevOps 现状解析:核心要点  8 r" T) Q, I% A* ^* |% e
# }" a7 B; w" S+ V

8 T6 z' E+ a" F+ e0 a9 ]( ~
1.变革型领导者拥有五大共通性特质——制定愿景、鼓舞人心的沟通能力、脑力激荡、支持型领导风格以及个人认同感,这一切能够显著塑造团队的文化与实践方针,从而带来更高成效。
3 v0 e8 G6 l3 ^1 K0 h8 `
" S. A( b" X5 j/ \. n% {8 A7 I- t, ]6 N9 u! R
2.高成效团队仍然保持着成果产出与稳定性优势。
! e4 o9 N6 Q6 u4 C6 D0 b! J  i' l3 B2 j0 W* ?- ~! w2 n. ^
4 m) X7 m! @/ r  P! Y  D- @- t; B
3.自动化成为企业竞争当中的核心优势。" C, L, J$ H) u' k& C6 Z' A
. |: u& x, v- z" l! a6 b( ?

; v- _( H! f# @5 l- l8 Z4.DevOps 适用于一切组织机构。0 \3 Q, ?" x2 v; L/ ?. H0 z) u
. M6 p) M3 S& z3 F, |4 D8 s# P

+ M! {; s! i2 K5.松散耦合结构与团队是实现持续交付的重要前提。* [5 o# q# u7 S4 B$ T5 r9 p
' s$ }3 U8 }; V1 y
6 b5 a% s5 F& W" W6 e+ r
精益产品管理有助于提升组织绩效。
) p, F* Q4 ]4 T# t) P5 o# }* T3 Y. L# u) B! b- ?
5 ?8 ]0 b4 d2 y0 C6 |- F, D
这份报告最终给出结论
+ m( m% O; n7 _- q
2 w4 ]- ?( G4 y' i+ H
“由于几乎每一家企业皆依赖于软件方案,因此 IT 成效水平对于当前的各类企业皆拥有重要意义。IT 成效水平受到多种不同因素的影响,具体包括领导力、工具、自动化以及持续学习与改进型文化方针等等。”

7 T& I& H' k3 l; r3 O& d

% x! I0 `; v, V% ^3 G
写在最后的解读  
: K( X5 W; B0 A  }
1 ^, m" j- {. }1 j' |( q+ v% X
5 A9 m9 O& ?* a+ V
一项值得注意的趋势是,2017 年年内最高成效团队与最低成效团队间的差距正有所减小——目前最高部署量仅为最低部署量的 46 倍,而同一指标在 2016 年的比值则高达 200 倍。另外,最高成效团队的代码部署频率与最低成效团队间的差异亦由 2016 年的 2555 倍缩小至 2017 年的 440 倍。
" t, }* j& u" P- C: G, ^& Q

/ d( U9 R) l  g2 x
在另一方面,2017 年最高成效团队的平均恢复时间则要远快于最低成效团队(由去年的 24 倍提升至今年的 96 倍),二者之间的变更失败率则由去年的 1 比 3 降低至今年的 1 比 5。Puppet 公司推测,之所以出现上述状况,主要是由于低成效团队的行动速度有所提升,但却仍未能将开发时间投入真正运用于质量保障之上——这意味着此类低成效团队会遭遇更多失败,并需要更多时间以解决问题。

0 Y2 g1 Q& n/ Q- e* U

7 I  N0 k& I( I7 M
研究人员们亦在报告中写道:
# i/ N, O0 ~+ a& w% g2 a5 [/ f5 Y
1 [4 ~  K" W0 X
“高成效团队很清楚,他们并不需要为了稳定性而牺牲速度——反之亦然,因为他们在工作当中充分保证质量水平,从而同时满足这两项需求。”

% h5 U6 H" H: [
* }2 X' u+ h. F, b/ F) s, [
原创:InfoQ

% \7 q$ v! x' M6 X! Q. P. o

& e: P& a; j& ?) \' \
1 r/ K4 O+ f+ c6 L. D1 l% U) X% m

本版积分规则

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

Baidu

GMT+8, 2019-6-17 23:07 , Processed in 0.217362 second(s), 32 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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