这个全球DevOps市场早在2023年就会达到94亿美元。然而，78%的组织都没能做好。为什么？
DevOps在2018年庆祝了其成立10周年。在科技行业，这是一辈子的事！尽管相对成熟，DevOps的哲学仍然在回避即使是最杰出和最足智多谋的组织。一份令人震惊的高德纳报告显示75%的DevOps项目失败来达到他们的目标。
为什么DevOps的故障率这么高？组织在实施DevOps理念时面临的共同挑战是什么？如何克服这些挑战？
我们将解决这些问题，并为企业提供可复制的策略，以提高其DevOps项目的成功率。
DevOps的挑战可以大致分为人员、过程和技术挑战。没有一套组织范围内的政策可以让企业采用并保证项目的成功.每个组织都必须制定与组织文化、业务目标和客户需求相一致的DevOps策略。然而，以下是所有企业面临的一些共同挑战，以及如何克服这些挑战。
1.不正常的资源分配
资源分配是DevOps面临的一大挑战。仅仅集成开发和运营团队将不会产生一个高功能的DevOps团队。数量惊人的DevOps团队缺乏主题专家，这严重影响了团队履行DevOps承诺的能力。
首先，一个致力于应用程序开发、优化和监控的不同技术的通才，不会像专家那样高效高效。这浪费了宝贵的时间，最终减缓了DevOps的交付速度。
此外，DevOps团队在最小化计划外的工作时工作得最好。没有专门的资源致力于利基DevOps问题，DevOps团队被迫将复杂的问题分配给非主题专家。这给他们计划中的工作日程带来了麻烦，使整个团队效率低下。更重要的是，这些人才的工作量不断增加，会导致员工精疲力竭，并有破坏整个DevOps计划的风险。
只有当有专门的人才在解决问题时，DevOps才能加速特性的发布、更新和上市时间。因此，企业必须确定关键的应用程序技术和开发过程，可以简化与DevOps，并指派专门的，熟练的人才到这些特定的领域。
最佳资源分配对于DevOps计划的成功至关重要。
“没有意识到DevOps是任何IT转型业务的关键基础的高管不应该从事领导IT的业务。“阿纳夫杜拉尼，副工程副总裁，格兰杰。
2.责任错位
DevOps将目标迥异的团队聚集在一起，在一个“不稳定”的环境中工作。开发人员主要关注创新，运营团队具有稳定性，QA团队具有完美的性能，等等。当然，这些团队之间必然会发生摩擦和冲突。
更糟糕的是，高层管理人员并不总是明确定义DevOps团队的目标、责任和优先级。这给模棱两可的问题留下了很大的空间。习惯于在筒仓中工作而不担心依赖关系的团队可以回到原来的方式，从而否定了实现无缝协作的所有努力。
让团队摆脱他们的筒仓心态是变革领导者面临的最大挑战。因此，当团队由跨学科资源组成时，DevOps的工作效果最好。具有操作思维的开发人员，他们不回避经常走出他们的舒适区域，是领导DevOps计划取得成功所必需的。
组织通常通过明确划分DevOps的目标、优先事项和责任来克服这些挑战。更重要的是，他们为DevOps任务的成功指定了综合责任。每个团队成员都要对DevOps任务的成功负责。当团队的整体成功来衡量他们的个人表现时，筒仓会自动崩溃，协作也会迅速增加。
3.分散的进程
并不是很多DevOps的领导者意识到，或者至少理解到，DevOps是深深的支离破碎的。尽管它已经成熟，但DevOps并不是中小型企业软件开发和交付模式的选择。长期以来，DevOps主要是一个大型企业项目。出于这个原因，参与DevOps项目的中小型企业发现自己陷入了水深火热的境地。
DevOps通过自动化软件开发生命周期中涉及的大部分任务来工作。然而，没有一个工具、过程或资源可以实现这一点。DevOps团队必须使用不同的工具来自动化其操作的不同方面。有很好的工具可以自动化各个组件，如持续集成、基础设施配置、测试、源代码管理等等。然而，这些工具并不相互交流。
让这些不同的工具相互交流需要大量的资源，而大多数组织都无法或愿意分配这些资源。由于这个原因，DevOps团队常常被迫以有限的自动化能力工作，这是DevOps的对立面。
有效的DevOps团队将他们的时间分配给执行他们的任务和自动化这些任务。没有后者，前者会逐渐增加，导致员工精疲力竭、流程延迟、反应恶化和交付质量下降。
企业可以通过开发清晰的DevOps策略来避免这些问题，该策略指定了组织的DevOps目标，确定了可以自动化的流程，并部署了实现这些目标的资源。这些目标应该与资源分配相匹配，这种解决碎片整理问题的现实方法将有助于企业精简和自动化对他们重要的流程。
4.缺乏适当的计量标准
缺乏适当的度量既是过程的挑战，也是人的挑战。KPI和度量在传递DevOps团队、组织的优先级和期望方面起着很大的作用。如前所述，在DevOps团队中，稳定和部署时间继续处于永久冲突状态。他们是否应该以稳定为代价仓促交货，反之亦然？他们如何开始将一个目标优先于另一个目标？
度量为团队确定不同目标的轻重缓急提供了明确和准确的指导。尽管这些度量的价值可能在不同的业务之间发生变化，但是度量本身对于所有的DevOps团队都是普遍相关的。以下是企业在向团队传递DevOps目标时必须定义的一些指标：
- 部署频率。
- 部署时间。
- 改变故障率。
- 自动测试合格率。
- 每次交付后出现的错误数。
- 缺陷逃逸率
- 是时候侦查了。
- 功能使用。
- 最终用户体验。
- 商业影响。
- 部署失败。
5.文化变革
抵抗变革将成为DevOps转变的最大障碍。DevOps寻求将控制从被隔离的团队和他们的领导转移到组织内单一的多部门机构。当然，这样的尝试可以被解释为是对决策权的侵蚀。
而且，这不全是关于控制的。与传统的IT角色相比，DevOps的领导角色有很大不同。一般而言，IT领导必须具备指导、支持和建议员工掌握各种技术的专门知识。在DevOps环境中，情况并非如此。DevOps的员工在一个动荡和快速发展的环境中工作。错误是常见的，这些错误的后果可能是灾难性的。不难理解为什么员工可能对DevOps过程感到担忧。
因此，领导的首要作用是创造培养条件，给予雇员更高的自由，并保护他们免受快速试验带来的挫折。此外，领导者的工作必须集中在识别DevOps成功模式并复制它们，以扩大整个组织的转换。
一种自上而下的方法，试图重新定义领导的角色，赋予DevOps团队更多的实验自由，并确保他们的稳定性，这对于克服文化惰性至关重要。
“无力实施文化变革–整个组织的利益相关者都必须一致支持成功采用DevOps所需的必要文化变革。它包括各集团的行政人员和领导人。这不仅仅是一种技术上的采纳。为了取得成功，业务、运营、IT、金融和其他方面必须作出承诺并建立信任。“伊恩威洛比，副总裁云解决方案和首席建筑师，第二观察。
6.无法扩大DevOps的规模
很多时候，早期DevOps计划的成功变成了失败。表现最好的DevOps团队充斥着更多的项目，他们很快就成了项目交付的瓶颈。更别提随之而来的压力增加和生产力下降了。
解决这个问题的一个显而易见的方法是扩展DevOps团队。然而，说起来容易做起来难。DevOps的专家需要一个与开发人员或工程师截然不同的技能集，因此，雇用他们是困难的，也是昂贵的。
一些组织通过在每个开发团队中嵌入一个DevOps专家来克服这一挑战。他们的作用是精简各自小组的交付链，同时与其他部门的DevOps专家进行协调。然而，这种方法常常导致团队之间的不一致和协作问题。解决这些新问题的一种方法是采用一种内部来源的方法，这种方法借鉴了开源知识。
团队必须获得强大的协作工具的授权，这些工具允许他们从世界上任何地方编码、发布和协作。最后，一个健壮的分散的、“以产品为中心”的交付模式必须取代传统的“以项目为中心”的方法。
“由DevOps驱动的变化首先需要有一个可以相信的目标。然后，要成功地扩展更改，需要在整个组织中进行沟通、协作和承诺。“卡西姆·汗，副总裁-美国银行商业信息官。
7.无法纳入安全
从表面上看，DevOps和安全似乎是完全冲突的。DevOps是所有的速度和持续交付，而安全强调广泛的测试和傻瓜防伪。然而，各组织正在慢慢认识到，与安全集成的DevOps可以帮助他们修补漏洞，发布更新，并比以往任何时候都更快地应对网络威胁。
目前，DevOps在将安全性集成到其过程中面临三个障碍–缓慢的开发进度、详尽的安全标准和对威胁的可见性。
谢天谢地，有办法应对这些挑战。安全自动化工具与DevOps工作流兼容，可以帮助大大改进安全检查、漏洞检测和修补。同样的工具可以用于在整个开发过程中自动化安全标准。当然，这将要求组织放弃大部分安全标准，只保留DevOps的核心安全标准。
最后，通过向所有团队成员提供安全数据并使他们更容易报告，可以提高威胁可见性。根据每个团队成员的角色和职责定制的Siem仪表板可以大大提高DevOps团队的威胁可见性。为了使其有效，可以建立一个基于共享绩效目标的奖励制度。
“安全性的价值主张是DevOps目标的同义词–更快可靠地构建、测试和发布软件。我们有能力在开发过程中解决安全问题，但正是我们的后续行动使组织与众不同。人员和流程是最重要的考虑因素–培训团队在开发过程中解决安全问题。“Joe Burkard，安全顾问，前CISO, 普罗蒂维蒂。
每个组织的DevOps计划都会遇到复杂的障碍，这些障碍对该组织来说是独一无二的。然而，强调团队成员的协作和稳定可以减少内部阻力，并将潜在的惯性源转化为变革领袖，从而确保成功。
