几年前，许多组织将 DevOps 视为一项有前途的实验，而不是软件开发的主流方法。 DevOps 现在是一套经过验证且功能强大的开发和部署实践和工具，可以加快新产品发布并提高生产力。 更重要的是，DevOps 的影响是对整体业务增长和盈利能力的提高。
团队 最有趣的翻译自 ，由 DevOps 研究与评估 (DORA) 专家编写。 这项研究涉及来自世界各地的 31 名专家。 我们来看看000年行业发生了哪些变化，企业如何提高软件交付效率。
行业和公司规模如何影响 DevOps 的状态
该研究发现 DevOps 绩效与组织所在行业之间没有相关性，但零售业除外，零售业的表现稍好一些。 这尤其是因为零售商需要快速响应需求和客户需求的波动。 研究表明，任何公司都可以实现高水平的 DevOps，包括金融部门和公共部门。
员工人数超过 5000 人的公司的 DevOps 绩效低于员工人数少于 5000 人的公司。 这很可能是因为大型组织拥有更大的流程、更严格的控制和更复杂的 IT 系统架构，这在开发和推出代码的过程中引入了延迟。 同时，专家认为，公司规模并不妨碍构建DevOps的成功，只是在某些情况下可能需要付出更多努力。
如何评估一个公司的DevOps水平
专家将 DevOps 流程与基准进行了比较，将调查受访者分为四组：表现最佳、良好、一般和较差。
在该报告中，我们采用了四个关键指标来评估 DevOps 的有效性：完成软件开发变更的时间、部署频率、故障率和恢复时间。
DevOps 的四个级别 - 评估您的公司所处的位置：
用于评估公司主要服务和应用软件交付有效性的指标
拥有最佳战绩的球队
表现良好的团队
平均团队
低绩效团队
部署频率
公司将代码部署到生产环境或将其发布给最终用户的频率。
根据要求，每天多次部署
从每天一次到每周一次
从每周一次到每月一次
每月一次/几个月
更改执行时间
从测试到软件在生产中成功运行需要多长时间？
不到一天的时间
从一天到一周
从一周到一个月
从一个月到六个月
服务恢复时间
发生影响用户的事件或错误后需要多长时间才能恢复服务。
不到一个小时
白天
一周以内
从一周到一个月
改变失败率
有多少百分比的更新或新版本会导致服务降级并需要修复？
0，15％
0，15％
0，15％
46，60％
该研究揭示了以下趋势：高绩效团队的数量几乎增加了两倍，从 7 年占所有受访者的 2018% 增加到 20 年的 2019%。
开发团队按绩效级别的分布。
与低绩效团队相比，高绩效 DevOps 团队：
- 执行的代码部署量增加了 208 倍。
- 代码部署时间减少了 106 倍。
- 我们遇到的失败频率减少了 7 倍。
- 出现故障后软件的恢复速度提高了 2,604 倍。
此外，高绩效的 DevOps 团队达到或超过其组织绩效指标的可能性是低绩效团队的两倍。
很多专家认为，不可能同时实现所有指标的增长，必须做出妥协。 因此，一些人认为，提高发布速度会对软件交付过程和服务提供的可靠性产生负面影响。 然而，研究表明，速度和结果的一致性并不是相互排斥的。
我并不认为 DevOps 团队数量的增长有什么令人惊讶的；这是很自然的：DevOps 理念现在很流行，初创公司的数量也在增长。
但是，在我看来，专家们选择的参数来评估 DevOps 的有效性并不完全正确。
至少可以说，根据代码推出的速度来评估它是很奇怪的。 这仅适用于初创公司，其中关键参数是将产品推向市场的速度，并且产品通常以其原始形式推出。 在这种情况下，加速开发和交付生产的机制至关重要。 但对于已建立的软件，例如金融或医疗软件，故障率参数可能不存在——故障可能是不可接受的。
服务恢复时间也是如此：对于任何已开发的服务来说，它应该以秒为单位计算，但对于许多服务来说，停机是不可接受的；为此，发明了无缝部署技术（例如绿色/蓝色）。
此外，您不应该关注代码部署的数量 - 这取决于开发团队的需求和能力。 如果部署涉及添加新功能，这是一回事，但如果涉及纠正以前部署期间发生的错误，那就完全不同了。
Denis Romanenko，Mail.ru 云解决方案的自由专家
如何改进 DevOps 流程
该报告提出了两个有助于改进 DevOps 的领域：提高软件开发和交付的效率以及提高工人的生产力。
每个领域都包含其自己的组成部分，通过改进这些组成部分，您可以实现预期的目标。
报告认为，数字化转型的关键是企业文化。 高绩效的 DevOps 团队需要一种信任和心理安全的文化、绩效意识和明确的目标。 这种环境使团队成员能够做出明智的决策、发表意见并更具创造力。
云技术、持续交付、灾难恢复测试和变更管理也将有助于提高软件开发和交付的效率。 通过投资易于使用的工具、减少技术债务（即减少无效代码和过时技术的百分比）、组织企业知识库和访问外部解决方案，可以提高生产力。
我认为DevOps的方法论和思想恰恰是这些过程不依赖于外部条件，比如云或者你自己的硬件。 云本身只不过是一种工具；在某些地方它会有所帮助，在另一些地方它会阻碍或不会被需要。
Denis Romanenko，Mail.ru 云解决方案的自由专家
下面我们将看看提高 DevOps 团队效率的一些组成部分。
云技术使 DevOps 取得成功
2019 年，越来越多的组织选择能够显着提高 DevOps 团队生产力的云解决方案。
DevOps 团队使用哪些基础设施？
DORA 发现 80% 的受访者认为 。 然而，只有 29% 的受访者实施了美国国家标准技术研究院的全部五个核心云特性——这是评估 DevOps 中云价值的最重要标准。
描述
用户百分比
按需自助服务
消费者可以自动配置计算资源
根据需要，无需提供商的参与。
57%
（自 11 年以来增长 2018%）
广泛的网络访问
云功能可通过不同平台获得，
例如手机、平板电脑、笔记本电脑和工作站。
60%
（自 14 年以来增长 2018%）
资源池
提供商的资源被组合成多租户模型，其中物理和虚拟资源根据需要动态分配。
58%
（自 15 年以来增长 2018%）
可扩展性和弹性
资源可按需水平或垂直扩展，几乎无限，可以随时发行任意数量。
58%
（自 135 年以来增加 2018）
透明度
云系统根据服务类型自动监控、优化和报告资源使用情况：数据存储和处理、流量、
活跃用户帐户。
62%
（自 14 年以来增长 2018%）
平台即服务 (PaaS) 正日益转向以容器为中心的部署模型。 云平台使软件部署变得更加容易，因此团队只需担心运行应用程序代码本身。 扩展、资源规划、管理和基础设施维护也转移给提供商。
对于云提供商来说，提供各种服务正在成为通用标准：虚拟机网络、身份和访问管理（IAM）、存储和数据库、机器学习、物联网（IoT）、容器解决方案、安全解决方案等。
云提供商的客户只需为他们使用的资源付费，这提供了成本透明度，这与很难或不可能获得开发成本信息的传统数据中心不同。 满足上述云特征的公司的受访者准确估计运行软件成本的可能性高出 2,6 倍，了解哪些应用程序需要更多资源的可能性高出 2 倍，保持在 IT 预算之内的可能性高出 1,65 倍。
有时事实证明，雇用一位有能力的专家并占用数据中心的分配容量比购买云更有利可图。 哪种选择更好取决于公司的概况和规模、其 IT 专家员工和专业知识的可用性。 例如，在创业或公司没有自己的IT部门时，使用云很方便。 扩展时，在本地维护全部或部分基础设施可能更具成本效益。
Denis Romanenko，Mail.ru 云解决方案的自由专家
DevOps 技术实践
许多希望实施 DevOps 的组织都在寻找一套指南或最佳实践。 然而，没有两家公司是相同的，因此选择哪种做法取决于企业的当前状况及其目标。
话虽这么说，有一些一般领域可以帮助提高 DevOps 绩效：一些是在团队级别开发的，另一些则需要在组织级别做出努力。
2019 年 DevOps 团队重点关注哪些增长领域：
在组织层面
- 松耦合架构
- 实施变更
- 代码支持
在团队层面
- 持续集成
- 测试自动化
- 部署自动化
- 监控
- 开发管线
在团队和组织层面
- 使用云服务
- 灾难恢复测试
该研究证实了松散耦合架构对 DevOps 性能的积极影响。
松耦合架构是指团队可以根据需要独立测试、部署和更改系统，独立于其他团队，无需额外的支持、资源、批准，并且反馈较少。 这可以让你的工作更有效率，但需要高水平的组织和管理。
这种方法只适用于初创公司并有一些保留。 其他公司的情况可能有所不同。 一个很好的例子：银行/金融科技。 那里可能会使用专有的解决方案，但将应用 DevOps 实践。
Denis Romanenko，Mail.ru 云解决方案的自由专家
成功的 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 云解决方案的自由专家
灾难恢复
每个其运作依赖于软件运作的组织都必须具备 。 该报告显示了不同公司使用哪些类型的灾难恢复测试。
公司使用哪些类型的测试来进行灾难恢复？
测试类型
低绩效团队
平均团队
表现良好的团队
高绩效团队
平均
不影响真实系统的测试
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%。 这意味着企业了解改进软件开发和交付的实践承诺，并且公司正在其 IT 部门更积极地实施 DevOps。
- 快速交付应用程序和服务是技术和组织转型的核心。 发布的速度和一致性可以提高利润和客户满意度。
- 云技术仍然是 DevOps 团队实现卓越的关键。 使用云可以让您以所需的速度组织软件交付，确保基础设施的可用性、可扩展性和性能。
- 通过关注团队成员的生产力、提供舒适的心理氛围以及使用便捷的工具，可以提高DevOps团队的效率。
- 通过正确的方法提高发布版本的速度不会影响公司服务和应用程序的稳定性。
来源： habr.com