全球大约有3200人参与了今年的调查（Puppet Labs每年都会进行一次），包括高管、开发人员和IT专家。认为自己在DevOps团队工作的受访者数量在过去三年里已经从16%增加到27%，这表明DevOps的应用增加。大多数受访者来自有100-499、500-1999和10k+员工的组织，而且他们中大多数都属于DevOps、IT Ops/基础设施和开发/工程分类。不过，性别比例仍然不均衡，女性和其他少数群体占比分别只有6%和3%。来自北美的受访者最多，占54%，来自欧洲和俄罗斯的占27%，亚洲的占10%。和去年一样，科技公司仍然占比最高（34%），然后是金融服务业（14%），接下来依次是教育、零售、电信和政府机构，占比在6%和8%之间。
这份报告区分了高效团队和低效团队，列举了两者之间的效率差异。和去年类似，他们度量了以下效率指标：
部署频率——生产环境多久部署一次；变更提前期——新变更多快可以推送到生产环境；平均恢复时间（MTTR）——从故障（电力中断）恢复的平均耗时；变更故障率——变更导致部署管道失败的频率。与去年相比，高效团队的所有指标值都有所提高。他们的代码部署频次多了46次，MTTR时间缩短为原来的1/96。平均来说，与去年相比，低效团队也有多个指标值提高了。
自动化实践显著增长，尤其是在高效团队中——配置管理自动化增加了28%，而部署自动化增加了26%。
组织的持续交付（CD）能力通过两个要素来度量——按需部署到生产环境的能力和面向所有团队成员的快速反馈循环。全面的版本控制、CI、基于主干的部署（包括软件交付过程安全、测试和部署自动化），这两个要素为这些成果的取得作出了巨大的贡献。服务和团队的松耦合是促成持续交付的架构要素。服务之间的耦合则是通过服务测试是否需要集成环境以及服务是否可以单独部署来度量的。
实现高效DevOps的非技术因素包括精益产品管理。该报告将其描述为三种能力——将工作分解成小批量及实现工作流程可视化，收集、传播及落实用户反馈，赋予开发团队自主权，让他们可以在开发过程中创建或修改规范，而不需要获得批准。
领导力本身不足以达成高阶DevOps成果。它还有赖于合适的架构和良好的技术实践。该报告的作者使用“结构方程式（Structured Equation Model，SEM）”作为预测模型来度量软件交付中相关概念之间的关系。
图中的箭头表示统计学关系。
本文转自d1net（转载）
相关资源：DevOps on the Microsoft Stack(Apress,2016)