State of Devops 分析报告

部门

2016年到2017年有比较明显的变化，而从2017年到2018年 devops 所占的比例变化不大。

image.png

行业

从2016年开始到2019年，一直都是技术行业更多一些。

image.png

SDO performance 衡量软件交付和运营性能（software delivery and operational performance）

SDO performance能够带来的一些优势，这些包括提高盈利能力，生产率，市场份额，客户满意度以及实现组织的使命目标能力。

SDO performance 四个指标

在DevOps现状报告中，证明了组织绩效和软件交付效能之间存在直接关联。只需要四个关键指标就能区分低绩效、中绩效和高绩效人员：前置时间、部署频率、平均修复时间(MTTR)和变更失败率。通过这四个指标的分析，可帮助领导和团队改进重要的环节。实施构建流水线可以帮助可视化四个关键指标(Four key metrics)，使得软件交付价值流可见。
这四个指标在20期的技术雷达中也有体现，技术维度-采纳level。

速度方面：

• 部署频率 ：代码部署到线上的频率。
  性能最高的每年1,460个部署（4/天x 365天）到性能低的每年7个部署。最高的是最低的208倍。

  
  
  image.png

• lead time：代码从提交到release所花的时间。
  最快的24小时内，而最慢的为2555小时， 之间差距106倍。和往年对比，差距变小的原因可能是因为lead time从不到一个小时增加到一个小时到一天之间。( 近年来越来越流行的重量级代码审查和批准过程)

  
  
  image.png

稳定性方面：

• 恢复时间Mean time to restore（从检测到事故到纠正事故所花费的时间）
  最快的恢复时间少于一小时，而慢的在一周至一个月之间。统计下来相差2604倍。
  只有40％的受访者至少每年使用所列一种或多种方法执行灾难恢复测试。进行灾难恢复测试的组织更有可能具有更高级别的服务可用性，即技术团队和组织具有对所运行的软件产品或服务作出并保持承诺和主张的能力。

  
  
  image.png

• 更改失败率（即发布过程质量的度量，包含hotfix,rollback等等的频率）
  最低的变更失败率为0％至15％，而高的可达46％至60％。变更失败率表现好的比差的好七倍。

  
  
  image.png
  
  

  从2016年到2019年，performance好的比不好的差距如下：
  可以看出lead time的差距减小很多，但是恢复时间的差距依旧很大。

  
  
  image.png

Devops一些实践

image.png

报告中显示高效团队更多的工作量在于新需求的开发，而不是在计划外的工作和返工、补救安全问题、处理最终用户发现的缺陷、客户支持等工作上。
如何提高效能呢？
从基础开始：基本自动化（例如版本控制、自动化测试），Monitor，明确的变更批准流程以及培养良好的文化。 然后确定约束条件来规划前进的道路， 将资源集中在当前的block，然后进行迭代（确定约束条件并选择下一个目标）。
以下是一些用来提升性能的关键技术实践：

platform as a service （PaaS）

PaaS指的是消费者不管理或控制底层云基础架构，包括网络，服务器，操作系统或存储，但可以控制已部署的应用程序以及应用程序托管环境的配置设置。
PaaS公司在网上提供各种开发和分发应用的解决方案，包括网页应用管理，应用设计，应用虚拟主机，存储，安全以及应用开发协作工具等。
PaaS的例子有Heroku，RedHat OpenShift，Azure App Service，Google App Engine， AWS Elastic Beanstalk和Cloud Foundry

cloud-native design practices

云原生应用：应用系统应该与底层物理基础设施解耦；应用必须能满足扩展性需求，垂直扩展（向上和向下）或水平扩展（跨节点服务器），也就是说云原生应用程序必须能够动态响应工作负载的变化（即弹性），并且易于按需部署和管理。

infrastructure as code来管理其云部署

通过版本控制来自动复制或更改环境状态，而不是手动配置基础结构。这种工作方式适用于云基础架构，在云基础架构中可以通过API设置和配置资源。

Continuous Testing

连续测试包括这些实践，并添加了一些重要的补充：
•不断审查和改进测试套件，以更好地发现缺陷并控制复杂性和成本
•允许测试人员在软件开发和交付过程中与开发人员一起工作
•在整个交付过程中执行手动测试活动，例如探索性测试，可用性测试和验收测试
•让开发人员通过在编写针对代码库的所有更改的生产代码之前编写单元测试来练习TDD。
•能够在不到十分钟的时间内从本地工作站和CI服务器上获得自动化测试的反馈。
2019年报告中多了 Disaster recovery testing。

Managing Database Changes

数据库更改通常是执行部署时带来风险和延迟的主要来源。管理数据库的更改可以避免部署出现问题。

Loosely coupled architecture，松耦合架构对CD的积极影响。

松耦合架构是指交付团队可以根据需要独立测试，部署和更改其系统，而无需依赖其他团队以获得额外的支持，服务，资源或批准，来回通信较少。 这使团队可以快速交付价值，但需要更高级别的编排。

Clear change process

Code maintainability代码可维护性

Continuous integration

Automated testing自动化测试对CI的积极影响，CI提高了CD

Deployment automation

Monitoring

Trunk-based development

云平台的使用

如何实施云基础架构至关重要。云提高了软件交付性能，利用所有云计算的基本特征的团队成为高性能企业的可能性要高23倍。

2018年云平台的使用情况：

image.png

随着业务性质的发展，越来越多的组织正在选择multi-cloud 多云和hybrid cloud混合云解决方案。 这是因为这些解决方案除了可以提高性能之外，还提供了灵活性，控制能力和可用性。2019的报告对比2018年，对多云和混合云的使用有所增加，但是还不知道这个现象的意义是什么。

image.png

云计算的五个基本特征

使用云计算显然是按需扩展。利用动态扩展的团队可以使服务背后的基础架构灵活地响应用户的需求。团队可以监视其服务并根据需要自动扩展其基础架构。

• 按需增长On-demand self-service
  消费者可以根据需要自动配置计算资源，而无需提供者进行人工干预。
• 广泛的网络访问Broad network access
  通过不同的平台都可以访问到。例如phones, 平板电脑, laptops, and workstations。
• 资源池Resource pooling
  提供者资源在多租户模型中池化，物理和虚拟资源按需动态分配。客户可以指定更高抽象级别的位置，例如国家/地区，州或数据中心。
• 快速弹性Rapid elasticity
  可以弹性配置和释放功能，以根据需要快速向外或向内扩展，这似乎是无限的，并且可以随时以任何数量进行分配。
• 实测服务Measured service
  云系统会根据服务类型（例如存储，处理，带宽和活动用户帐户）自动控制，优化和报告资源使用情况。

提高生产率

生产率是指以最小的干扰来完成复杂，耗时的任务的能力。

image.png

文化相关

高绩效团队具备的文化：信任和心理安全感，有意义的工作和清晰的角色、计划和目标认知。这种团队环境使成员能够承担有计划的和适度的风险，敢于发表想法并更具创造力。

技术债管理

技术债包含脚本、配置管理，基础设施管理。可以通过不断的重构来减少技术债。
为了减少技术债就可以思考如何增加code 可维护性，如何构建松耦合架构，如何做Monitor等。

工具

在效能低下的企业中，有着更多的专有软件，定制化程度高，但是维护成本大。而高效能团队使用的工具都是开源的，相对集中的商业现货（COTS）软件，很少进行定制。

高效能团队几乎在所有维度上都将工具自动化并更频繁地集成到其工具链中。 自动化build、自动化单元测试、自动化验收测试、自动化性能测试、自动化安全测试、自动配置并部署到测试环境、自动部署到生产环境、集成chatbots / Slack、生产监控和观察性工具等等。尽管自动化可能被认为实施起来过于昂贵，但自动化确实是一项明智的投资。它可以使工程师花费更少的时间 从事手工工作，从而腾出时间来进行其他重要活动，如新开发，重构，设计工作和文档编制。 它还使工程师对工具链更有信心，从而减轻了推动变更的压力。

内部搜索和外部搜索

内部搜索：构建企业内部的知识库，共享知识可以帮助大家更快的找到问题的答案。
外部搜索：为学习和成长提供了强大的社区，也为公共云和开源工具提供支持

组织相关

跨职能团队的重要性

跨职能的团队具有完成工作所需的全部能力，而无需依赖团队以外的其他人

精益产品管理

精益产品管理功能对软件交付性能，组织文化和组织绩效产生积极影响。

• 团队将产品和功能切成小批量可以完成的程度，在不到一周的时间内发布并频繁发布，包括使用最低限度可行的产品（MVP）
• 组织是否定期积极地寻求客户反馈，并将此反馈纳入其产品设计中
• 开发团队是否有权在不经批准的情况下创建和更改规范，并将其作为开发过程的一部分

报告：
state-of-devops-2019
state-of-devops-2018
state-of-devops-2017
state-of-devops-2016