几年前，许多组织将DevOps视为一项前景广阔的实验，而非软件开发的核心方法。如今，DevOps已成为一套成熟且强大的开发和部署实践及工具，能够加速新产品发布并提高生产力。更重要的是，DevOps的影响旨在促进整体业务增长和盈利能力。
团队 我翻译了其中最有趣的部分。 这份报告由DevOps研究与评估机构（DORA）的专家编写，调查对象涵盖全球31,000名专业人士。让我们来看看2019年行业发生了哪些变化，以及企业如何提高软件交付效率。
行业和公司规模如何影响DevOps的现状
该研究发现，除零售业外，DevOps 的有效性与企业所属行业之间并无相关性，零售业的结果略好一些。这部分是由于零售商需要快速响应需求和客户需求的波动。研究表明，任何公司，包括金融和公共部门，都可以实现高水平的 DevOps。
员工人数超过5000人的公司的DevOps有效性低于员工人数少于5000人的公司。这可能是因为规模较大的组织拥有更庞大的流程、更严格的管控以及更复杂的IT系统架构，从而导致代码开发和部署的延迟。专家认为，公司规模并不会阻碍DevOps的成功构建；在某些情况下，它可能只是需要投入更多精力。
如何评估一家公司的DevOps水平
专家将 DevOps 流程与基准进行比较，并将调查参与者分为四组：最佳、良好、一般和差。
该报告使用了四个关键指标来评估 DevOps 的有效性：软件开发变更提前期、部署频率、故障率和恢复时间。
DevOps 的四个层级——评估贵公司所处的位置：
用于评估公司核心服务和应用程序软件交付效率的指标
表现最佳的团队
表现良好的团队
表现平平的团队
得分低的队伍
部署频率
公司多久会将代码部署到生产环境或发布给最终用户一次？
按需部署，每天多次部署
从每天一次到每周一次
从每周一次到每月一次
每月一次/几个月
完成变更的时间到了
从测试到软件成功投入生产环境运行，需要多长时间？
不到一天
从一天到一周
从一周到一个月
一个月到六个月
服务恢复时间
在发生影响用户的事件或漏洞后，需要多长时间才能恢复服务？
不到一小时
白天
一周以内
从一周到一个月
变更期间的故障频率
有多少百分比的更新或新版本会导致服务性能下降并需要修复？
0-15％
0-15％
0-15％
46-60％
该研究发现以下趋势：高绩效团队的数量几乎增加了两倍，从 2018 年占所有受访者的 7% 增加到 2019 年的 20%。
按绩效水平划分的开发团队分布。
与低绩效团队相比，高绩效 DevOps 团队：
- 代码部署次数增加了 208 倍。
- 代码部署时间减少了106倍。
- 失败次数减少了7倍。
- 故障后软件恢复速度提高了 2,604 倍。
此外，高绩效的 DevOps 团队达到或超过组织绩效指标的可能性是低绩效团队的两倍。
许多专家认为，同时提升所有指标是不可能的，必须做出妥协。例如，一些人认为加快发布速度可能会对软件交付和服务提供的可靠性产生负面影响。然而，研究表明，速度和结果的稳定性并非相互排斥。
DevOps 团队的增长并不令人惊讶；这是自然而然的：DevOps 理念现在很流行，创业公司的数量也在不断增长。
但依我之见，专家们在评估 DevOps 的有效性时，所选择的参数并不完全正确。
以代码部署速度来评判软件性能，至少可以说是不恰当的。这仅适用于初创公司，因为对它们而言，上市速度是关键指标，而且产品通常以原始版本发布。在这种情况下，能够加速开发和交付到生产环境的机制至关重要。但对于成熟的软件，例如金融或医疗软件，故障率可能并非衡量标准——因为故障可能是不可接受的。
服务恢复时间也是如此：对于任何已开发的服务，其恢复时间都应以秒为单位来衡量，而且对于许多服务而言，停机时间是不可接受的。正因如此，无缝部署技术（例如，绿/蓝部署）应运而生。
此外，不要过分依赖代码部署次数——这取决于需求和开发团队的能力。如果部署是为了添加新功能，那是一回事；但如果是为了修复之前部署中出现的错误，那就完全是另一回事了。
Denis Romanenko，Mail.ru Cloud Solutions 的自由专家
如何改进 DevOps 流程
该报告提出了两个可以帮助改进 DevOps 的领域：提高软件开发和交付的效率以及提高员工生产力。
每个方向都包含其自身的组成部分，通过改进这些部分，您可以实现预期的目标。
报告指出，数字化转型的关键在于企业文化。高效的DevOps团队需要信任和心理安全感，对工作成果有清晰的理解，并拥有明确的目标。这样的环境能够让团队成员做出明智的决策，表达自己的观点，并更具创造力。
云技术、持续交付、灾难恢复测试和变更管理也有助于提高软件开发和交付效率。投资易于使用的工具、减少技术债务（即降低低效代码和过时技术的比例）以及建立企业知识库和获取外部解决方案的途径，都可以提高生产力。
我认为DevOps方法论和理念的核心就在于使这些流程独立于外部条件，例如云或原生硬件。云本身只不过是一种工具；它在某些方面会有所帮助，在另一些方面会造成阻碍，或者根本毫无用处。
Denis Romanenko，Mail.ru Cloud Solutions 的自由专家
下面我们将探讨提高 DevOps 团队效率的一些组成部分。
云技术有助于DevOps的成功。
2019年，越来越多的组织选择云解决方案，这显著提高了DevOps团队的生产力。
DevOps团队使用哪些基础设施？
DORA发现80%的受访者发布 然而，只有 29% 的受访者实施了美国国家标准与技术研究院的全部五项云计算核心特征——这是评估 DevOps 中云计算价值的最重要标准。
描述
使用过它的人的百分比
按需自助服务
消费者可以自动配置计算资源
根据需要，无需提供者参与。
57%
（自 2018 年以来增长 11%）
广泛的网络访问
云功能可通过不同的平台获得。
例如手机、平板电脑、笔记本电脑和工作站。
60%
（自 2018 年以来增长 14%）
资源池
提供商资源被整合到一个多租户模型中，其中物理和虚拟资源根据需求动态分配。
58%
（自 2018 年以来增长 15%）
可扩展性和弹性
资源可根据需求进行横向或纵向扩展，几乎是无限的，并且可以随时提供任意数量的资源。
58%
（自 2018 年以来增加 135 人）
透明度
云系统会根据服务类型（数据存储和处理、流量等）自动监控、优化和报告资源使用情况。
活跃用户帐户。
62%
（自 2018 年以来增长 14%）
平台即服务 (PaaS) 正日益向以容器为中心的部署模型发展。云平台简化了软件部署，使团队只需专注于运行应用程序代码本身。扩展、容量规划、管理和基础设施维护也逐渐转移到服务提供商手中。
云服务提供商正在成为提供各种服务的通用标准：虚拟机网络、身份和访问管理 (IAM)、存储和数据库、机器学习、物联网 (IoT)、容器解决方案、安全解决方案等等。
云服务提供商的客户只需为使用的资源付费，从而确保成本透明。这与传统数据中心截然不同，在传统数据中心，开发成本信息难以获取甚至根本无法获取。符合上述云就绪标准的公司受访者估算软件成本的可能性是其他公司的2,6倍，了解哪些应用程序消耗资源最多的可能性是其他公司的两倍，并且能够控制在IT预算范围内的可能性是其他公司的1,65倍。
有时，聘请合格的专家并利用数据中心的专用容量，比支付云计算费用更具成本效益。最佳方案取决于公司的概况和规模，以及内部 IT 专家和专业知识的可用性。例如，对于初创企业或没有内部 IT 部门的公司来说，云计算非常便捷。随着公司规模的扩大，在本地维护全部或部分基础设施可能更具成本效益。
Denis Romanenko，Mail.ru Cloud Solutions 的自由专家
DevOps技术实践
许多希望实施DevOps的组织都在寻找一套指导原则或最佳实践。然而，没有两家公司是完全相同的，因此实践的选择取决于企业的现状和目标。
也就是说，有一些方面可以帮助提高 DevOps 效率：有些方面是在团队层面开发的，而另一些方面则需要组织层面的努力。
2019年DevOps团队有哪些重点增长领域？
在组织层面
- 松耦合架构
- 变更实施
- 代码支持
在团队层面
- 持续集成
- 测试自动化
- 部署自动化
- 监控
- 开发流程
在团队和组织层面
- 使用云服务
- 灾难恢复测试
该研究证实了松耦合架构对 DevOps 效率的积极影响。
松耦合架构允许团队独立地按需测试、部署和更改系统，无需其他团队参与，也无需额外的支持、资源或审批，并且反馈也较少。这提高了效率，但也需要高度的组织和管理。
这种方法仅适用于初创公司，并且需要满足一些特定条件。其他公司的情况可能有所不同。银行/金融科技公司就是一个很好的例子。它们可能完全使用专有解决方案，但也会应用 DevOps 实践。
Denis Romanenko，Mail.ru Cloud Solutions 的自由专家
成功的DevOps团队会将一切自动化。
使您能够以更低的成本和风险将服务和应用程序投入生产，并保持版本发布符合组织的目标。
成功的 CI/CD 还意味着团队可以按需将变更部署到生产环境，立即获得有关部署质量的反馈，并迅速采取行动以改进下一个部署周期。
报告显示，成功的DevOps团队会投资于各种支持流程、实践和工具：
- 92% 使用自动化装配工具；
- 87% 使用自动化单元测试；
- 57% 将自动化扩展到验收测试；
- 72% 的企业实现了测试环境的自动化部署，69% 的企业实现了生产环境的自动化部署；
- 69% 的企业将聊天机器人集成到部署流程中；
- 57% 与监控工具集成。
选择合适的工具和技术至关重要。
在构建复杂系统和管理业务关键型基础设施时，选择合适的技术至关重要：
- 无论是首次连接还是连续运行，都易于使用；
- 有助于实现既定目标。
该报告考察了通过 CI/CD 和测试自动化工具进行软件部署所使用的工具——这些技术构成了 DevOps 的基础。
DevOps团队使用哪些技术？
技术
得分低的队伍
表现平平的团队
表现良好的团队
高绩效团队
专有产品、开源产品和商业盒装产品的组合
30%
34%
32%
33%
主要采用开源和高度定制化的盒装解决方案
17%
8%
7%
10%
主要采用开源和现成的解决方案，只需少量定制。
14%
21%
18%
20%
首先是盒装商业解决方案
8%
12%
8%
4%
公司内部研发成果和专有解决方案
20%
6%
5%
6%
首先，它是开源的，并且具有强大的可定制性。
6%
7%
5%
12%
主要采用开源技术，并进行少量定制。
5%
12%
24%
15%
工具的易用性对团队最大限度地发挥所选技术栈的价值有着显著的影响：使用易用技术的工程师更有可能加入高绩效团队，其可能性是其他工程师的 1,5 倍。
在我看来，这张表格给人一种印象，那就是要想成为一个成功的 DevOps 团队，你需要追随潮流，而不是技术任务。
一位称职的专业人士会根据任务选择合适的工具，而不是反过来。任何问题通常都有多种工具和方法可以解决。具体选择哪种工具取决于：任务的具体情况；员工对工具的熟悉程度（如果工具是新的，入门门槛有多高）；以及是否存在成本因素。
Denis Romanenko，Mail.ru Cloud Solutions 的自由专家
灾后恢复
任何运营依赖于软件运行的组织都必须具备以下条件： 该报告展示了不同公司使用的灾害恢复力测试类型。
企业在灾难恢复过程中会使用哪些类型的测试？
测试类型
得分低的队伍
表现平平的团队
表现良好的团队
高绩效团队
平均
不涉及真实系统的测试
35%
26%
27%
30%
28%
基础设施故障转移（包括数据中心）
27%
43%
34%
38%
38%
应用程序故障测试
25%
46%
41%
49%
43%
模拟涉及测试系统中断的事件
18%
22%
23%
29%
23%
模拟涉及运行系统中断的事件
18%
11%
12%
13%
12%
创造能够打破常规的自动化和系统
生产系统定期、持续运行
9%
8%
7%
9%
8%
仅有 40% 的受访者每年使用上述一种或多种方法进行灾难恢复测试。然而，进行灾难恢复测试的公司拥有更高的服务可用性。报告显示，绩效卓越的 DevOps 团队将灾难恢复测试数据纳入软件开发和部署流程的可能性是其他团队的 1.4 倍。
确保DevOps团队能够访问信息至关重要。
轻松查找信息以解决问题有助于保持 DevOps 团队的生产力。这在当今由复杂系统构成的技术环境中尤为重要。
此类信息的来源可分为两类：
- 内部来源公司内部文档涵盖代码创建和维护、企业知识库、代码库等资源。使用内部知识资源的 DevOps 团队效率提高了 1,73 倍。
- 外部资源搜索引擎和技术栈扩展。外包工作的 DevOps 团队的生产力提高了 1,67 倍。外包能够带来显著的学习和成长优势，尤其是在使用公有云和开源工具的情况下。
对企业而言，减少技术债务至关重要。
技术债务包括：存在已知但未修复错误的代码或系统；测试覆盖率不足；代码或设计质量差；未使用但未移除的工件；团队无法有效维护的实现；过时的技术；以及不完整或过时的文档。
专家发现，技术债务会对DevOps绩效产生负面影响。技术债务高的团队生产力比技术债务低1,6倍。而高绩效团队技术债务低的概率是技术债务低团队的1,4倍。
DevOps现状调查的主要发现
- DevOps团队得分高的比例几乎翻了三倍，达到20%。这表明企业认识到DevOps实践在改进软件开发和交付方面的潜力，并且越来越多的公司正在其IT部门实施DevOps。
- 快速交付应用程序和服务是技术转型和组织绩效的基础。发布速度和一致性能够提高盈利能力和客户满意度。
- 云技术仍然是DevOps团队取得卓越成果的关键。云计算能够以合适的速度交付软件，并确保基础设施的可用性、可扩展性和高性能。
- 通过关注团队成员的生产力、确保舒适的心理氛围以及使用用户友好的工具，可以提高 DevOps 团队的效率。
- 如果操作得当，加快版本发布速度不会影响公司服务和应用程序的稳定性。
来源： habr.com
