2017年DevOps使用状态报告

xiaowei

本帖最后由 adminlily 于 2018-9-25 16:42 编辑

1 摘要

• 在过去6年里收到27000个调查反馈

• 涉及盈利型和非盈利组织，结果显示DevOps都能更好的帮助完成组织使命

• 在DevOps旅程上效能高低不同的组织之间，自动化是最大的差异点

6个主要结论

1 改革型领导者有5大共性

• 有愿景

• 沟通鼓舞人心

• 激发智力

• 支持型领导

• 个人认同

2 高效能团队能够鱼和熊掌兼得-更快的吞吐量和更好的稳定性

3 自动化对所有组织而言好处是巨大的

4 DevOps适用于所有类型的组织

• 交付物

•COTS-商务现货供应软件（如Office2017）

•Microservice-微服务业务系统

•传统业务

• 高绩效者2倍的完成目标

• 财务指标

• 非财务指标

5 持续交付效果的2个重要影响因素

• 松耦合架构

• 松耦合团队

6 精益产品管理驱动着更高的组织绩效

• 更快交付特性

• 更快的交付周期

2 受访对象

• 人数：3200

• 来自DevOps团队的人数增加迅猛

• 2014：16%

• 2017：27%

• 3年增长了11%

• 人数统计

• 性别

• 男性：91%

• 女性：6

• 其它：3

• 不具备代表性（New调查项）

• NO：77%

• YES：12%

• NA：11%

• 部门

• IT运维或基础架构：28%

• DevOps团队：27%

• 开发或工程：25%

• 地区

• 北美：54%

• 欧洲：27%

• 亚洲：10%

• 行业

• 技术 34%

• 金融服务 14%

• 零售 7%

• 通讯 6%

• 教育 6%

• 员工数

• 1万以上 25%

• 100~499 20%

• 500~1999 15%

• 20~99 14%

• 服务器数

• 100~499 20%

• <99 20%

• 500~1999 18%

• DevOps教练的总结

• DevOps能否正式提到台面上成为主流是很重要的考察点

• 绝大多数人都认为DevOps已经是不能被忽视的了

• 其它统计数据主要看前三强

• 参考自己的组织的位置

3. 改革型领导者

• 很重要（重复三遍）

• 来源于： Gartner的预测——>到2020年还不转型的会被组织的数字化领导层团队直接拉黑。参考来源下载： [ /binaries/content/assets/events/keywords/infrastructure-operations-management/iome5/gartner-predicts-for-it-infrastructure-and-operations.pdf]binaries/ ... -and-operations.pdf[/url]

• 重要性（敲黑板了）

• 建立和支持创意和高度信赖的文化规范

• 实施能够提高开发人员生产力的技术和流程，减少代码部署的前置时间，并支持更多可靠的基础设施

• 支持团队实验和创新，更快地创建和实施更好的产品

• 跨组织孤岛实现战略协调

• 5大特征

1 有愿景

• 理解组织的方向

• 理解团队的方向

• 理解团队5年的长期规划

2 沟通鼓舞人心

• 激发自豪感

• 说积极的方面

• 激发热情和主动性，鼓励人们把改变视为机会

3 激发智力

• 挑战现状

• 持续问新问题

• 挑战工作的基础假设

4 支持型领导

• 三思而后行，考虑他人感受

• 体贴地照顾到个人需求

• 关照个体的兴趣

5 个人认同

• 表扬优于平均水平的工作

• 认可工作质量的改进

• 对个体优秀的工作进行个人致谢

• 作用

• 员工体验好

• 愉悦

• 忠诚

• 投入

• 企业的NPS分数高

这个领导特质出处是精益产品管理

• DevOps教练的总结

• 本章大篇幅的定义了改革型领导的各个方面

• 提出了DevOps自上而下变革的基调

• 给了保守的领导者一定的提示

• 和前几年的报告相比，政治高度一下高了许多

• 对管理者的这种需求的一个来源是精益产品管理

4. IT效能

• 高效和低效者对比

• 吞吐量

• 部署频率高46倍以上：按需部署，一天多次

• 变更前置时间快440倍以上：小于一小时

• 稳定性

• 故障恢复时间快96倍：小于一小时

• 变更失败率低于5倍以下（大约是五分之一）： 0~15%

• 和2016年相比：前三个指标倍数降低的多

• 原因

• 高效能者已经不需要那么快了

• 他们已做到在流程里内建质量了

• 大量的低效能组织在过去一年里也成长了不少

• 高效能者不需要高分，他们的收益已经足够了

• 最后一个指标变化不大

• 自动化

• 来由

•去年分析计划外工作和返工的工作时间发现到自动化是效能高低这的巨大差异

• 应用场景

• 配置管理

• 测试

• 部署

• 变更审批流程

• 分析了绩效高中低者在这方面的差异

• DevOps教练的总结

• 四个指标的最后一列是高绩效者的表现，对高中低的分类，见报告的方法论部分

• 自动化这个指标是今年新加入进来的

• 在各个方面的技术债还是要偿还的

5. 组织的绩效

• DevOps不仅适用于独角兽型的互联网企业，逐渐被更多企业应用，对非盈利企业和政府影响不大

• 各种类型的组织对DevOps能高效和精确地交付软件能达成一致

• IT的效能影响到组织的目标的实现

• DevOps可以帮助任何类型的企业完成它的使命，不管它在那个行业和领域

• DevOps教练的总结

• 在探索IT组织以外，DevOps能产生的更大范围的影响

• 这些应该是DevOps产生的间接效果

• 其实是最高层的最关键的驱动力

6. 技术实践

• 持续交付

• 效果

• 按需部署到生产环境

• 对系统的可部署性和质量快速反馈

• 正面因素

• 测试自动化

• 部署自动化

• 在软件交付工作中集成信息安全

• 持续集成和主干开发

• 强大的版本控制

• 架构

• 倡导松耦合架构和团队

• 2个新的研究假设

• 让团队自行决定用什么工具能交付的更好

• 更松耦合的架构驱动IT效能

• 总结了6个影响持续交付的和架构有关的因素

• 主干开发

• 高效能团队的特点

• 每天合并代码到主干一次

• 也做分支，使用一般不会超过一天

• 代码没有封锁期

• 集成的差异

• 高效能团队

• 集成时间和分支寿命是最短的

• 分支寿命和集成通常按小时计时

• 低效能团队

• 集成时间和分支寿命都很长

• 按几天来计时

• 数据分析结果显示差异是显而易见的

7. 精益产品管理

• 把工作化大为小，工作在小批量作业上

• 收集、广播和实施客户的反馈

• 新增：给开发团队更多权限，让他们能新建和变更开发规格

8. DevOps和COTS

• COTS：标准盒装商业软件

• 一个误区：DevOps不适用于运行标准商业盒装软件的环境

• 辟谣：DevOps实践当然适用于COTS

• Martin Fowler的解释

• COTS是工具性软件

• 企业软件是战略性软件

• 二者没有本质区别

• DevOps教练的总结

• 留下的不做DevOps的理由已经越来越少了

9. 方法论

• 使用Cluster analysis来确定高中低IT效能

• 目标人数和采样方法

• 建立潜在的构造

• 统计学分析方法

• Cluster analysis 群集分析

• Measurement model 度量模型

• 回归分析

• 结构方程建模

• 研究设计

10. 致谢

• 度量架构

• Neal Ford

• Martin Fowler

• Mik Kersten

• Sam New Man

• Rebecca Parsons

• 团队实验

• Amy Jo Kim

• Mary Poppendieck

• 编辑

• Aliza Earnshaw

11. 作者

• Dr. Nicole Forsgren

• Jez Hummble

• Gene Kim

• Alanna Brown

• Nigel Kersten

12.公司简介

• Puppet - 出品报告的公司

• DevOps Research and Assessment --承接报告调差、分析和整理工作的公司

原创： Martin Liu

上一篇：一起探索ITIL和DevOps的边界
下一篇：DevOps的四种核心能力是什么？

2017年DevOps使用状态报告

评论