当今，DevOps能显著提升企业的商业敏捷与能力，因此在企业中广受欢迎。然而，对于大多数企业来讲，DevOps变革并非一帆风顺，此过程中会面临各种各样的挑战。为了提高DevOps变革成功的可能性，企业领导者亟需识别或者理解DevOps变革失败的常见原因，并采取一定的措施来避免。

经过不断发展，DevOps逐渐演变为一种方法框架，使能企业综合运用人员（People）、流程（Processes）与技术（Technologies）等，从而将价值持续交付给最终客户与用户。基于DevOps的价值观（Value）、原则（Principles）与实践（Practices），华为云DevCloud分析了许多企业的DevOps落地案例，DevOps变革会存在6大常见的主要原因，称之为六大“焦油坑”：

无的放矢、乌合之众、各自为政、一蹴而就、好高骛远、沙上建塔。

无的放矢：未从客户价值出发

在DevOps热潮下，许多组织通常为了赶潮流而快速启动DevOps变革，常常为了DevOps而做DevOps（Doing DevOps for DevOps），而没有充分考虑DevOps的真正目标或者目的。员工只会关注为组织带来的价值，而不会单纯与DevOps术语、方法以及支撑工具产生联系。因此对DevOps变革，无论变革启动时，还是变革过程中，都需要将为客户带来的商业价值作为目标，以便不断调整DevOps变革内容。这也与多数组织“以客户为中心”的理念相吻合，然而却经常被忽视甚至忘却，导致无的放矢或者向不正确的靶子放矢。

为了使DevOps变革立足于客户价值、充分识别谁是客户、他们需要的价值是什么，组织应该经常思考如下问题：

·现有或者潜在的客户是谁

·客户看重或想实现的商业价值是什么

·企业能提供哪些服务，仍有哪些差距

·客户期望的时间点

·企业能够多快进行发布

·客户前进的方向是什么，如何升级企业的服务

·如何让客户了解到企业提供了什么

企业组织在DevOps实施过程中，必须以客户为中心，持续地提高对客户商业价值的理解，来作出相应的改变，并提升自身能力。

乌合之众：未有效地管理组织变革

在DevOps变革中，企业组织应该认识到人或团队是DevOps变革的最大的挑战，因而应该充分重视组织变革的重要性，而不是将重心聚焦在工具上。企业应该从理解客户商业价值来发起组织变革，领导层必须清楚DevOps以及相应的组织变革是不可或缺的，员工必须认识到变革正在发生。在DevOps变革中，领导层应该理解，为了提升商业敏捷性，决策需要在信息产生的地方进行，并应该去身体力行此种决策理念。

因此，领导层需要组建团队，并让团队自己决策应该做什么以及如何做。这就要求在组织内识别潜在的候选人，且候选人应该具有以下价值观：

团队合作：确保候选人乐于团队合作，并且在团队内工作效率高；

值得信赖：信任是DevOps的CAMLS理念中文化的基本要素之一，因此候选人必须可靠、可信；

干劲十足：候选人必须能主动积极地追求目标；

有责任心：对工作过程、工作产出能负起责任，而不是推三阻四；

足够聪明：能理解必须完成的工作，并可以决定如何开展；

经验丰富：经验可以使团队成员成长，当然不一定对DevOps有经验；

有效沟通：及时准确地口头或者书面传递信息与知识；

风险管理：与团队其他成员（例如PO）协同工作懂得如何管理风险；

终身学习：DevOps并非一成不变，因此更重要的是，发现有正确态度的人并培训技术技能，而不是过分强调技术技能而忽略错误的行为。

领导者应具备相应的技能与态度来激励员工，进行授权并提升他们的责任感。当然，对于拒不改变的员工，必须毫不迟疑地将他们安排到不会动摇变革的岗位上。

各自为政：未充分地合作

在DevOps变革过程中，比较现实的情况是单个职能领域（例如IT部门）来发起此变革，因此导致DevOps实施局限于单个职能领域，无形中增加了变革失败的可能性。

因此即使单个职能领域发起DevOps变革，组织必须意识到成功的DevOps实施需要所有干系人共同合作以更全面地理解并系统地解决问题。为了加快价值实现时间，DevOps团队必须与其他团队及关系人合作。DevOps需要人们共同工作实现解决方案，打破障碍，并能像小型团队一样运作。因此，合作是至上的，团队的大小并没有绝对的限制，虽然业界有所谓两个比萨（Two-pizza）团队的说法。

更为重要的是，企业级别的合作需要管理层的支持。在一开始，就应该获得管理层的支持与拥护。DevOps的拥趸必须相信DevOps的价值，并平衡组织内不同团队的激励方式，例如开发团队被鼓励快速变更和开发新特性，而运维被鼓励维持可靠性和稳定性，这样就难以形成合作。

一蹴而就：未采用迭代方法

全面的一揽子的DevOps变革，对于大多数企业组织来说，是非常有诱惑力的。然而，历史经验却无情地告诉我们，这种传统变革失败率非常高。DevOps要在一个大型IT组织中成功，涉及太多因素，并且组织越大越困难。

因此，增量迭代方法成为组织的必然选择，一方面此方法使组织聚焦于持续改进，另一方面避免了传统方法的巨大风险。在进行DevOps变革时，组织聚焦于单一价值流，通过迭代与持续学习来持续改进，来得到合适的因素维持可接受的变革。迭代增量节奏也使组织确保团队分享与合作，并建立实践社区。这样，在此价值流学到的知识可以传递到下一个价值流，逐渐在组织中规模化DevOps。

组织在每个迭代中需要仔细识别目标机会，并确保每个迭代满足以下3个关键条件：

政策友好性：干系人愿意给予DevOps公正的试验环境，在错误发生时，从中学习经验而不是责备；

可接受的价值：每个迭代产生足够的客户价值，来建立信任与获取支持；

可接受的风险：即使DevOps宣称具有显著降低风险的能力，然而人们更乐于看到实际效果，而不是简单听理论。

好高骛远：疏于管理期望值

俗话说，期望越高，失望越大。对于DevOps，许多组织的期望与它能够交付的内容存在脱节。与其讲企业组织将更敏捷或者快速，不如明确组织现在在哪儿以及需要到哪儿，然后迭代地实现目标。DevOps不是一次性投入，而是需要不断地尝试。因此组织需要达成一致的目标与度量指标来有效地管理期望。DevOps的度量指标非常多，建议可以从以下4个角度建立进度平衡视图：

市场目标：例如销售量、客户留存率等；

交付周期：价值实现的平均时间；

风险管理：宕机时间、业务恢复时间等；

客户满意度：满意度水平等；

需要指出的是，并非所有的不切实际的期望都来自于商业客户。例如，IT部门会认为工具链是免费的，实际上工具链需要持续的资源与投入。总体上，组织需要围绕客户价值、成本与风险来权衡建立合适的期望。

沙上建塔：未清晰地管理需求与代码

由于受到DevOps成功案例以及CAMLS理念中自动化的影响，企业通常寄希望于自动化等技术与工具手段来加速产品上市周期，然而经常因诸多基础性工作没有做扎实导致DevOps实施效果未达到预期。

在诸多基础性工作中，最为关键的两点是需求的探索分析与分解、源代码的版本与分支管理。从DevOps的发展历史来看，DevOps继承了敏捷方法的诸多实践与理念，原则上默认DevOps团队较充分地掌握了敏捷方法与实践，也致DevOps组织忽略需求的重要性。因此无论如何强调需求的重要性都不为过。DevOps团队必须清晰地管理需求，使需求以及Story满足SMART要求，在迭代周期内可以按时保质交付最小可行产品（MVP）。

代码版本管理的重要性是不言而喻的，更需要关注的是良好的分支管理模式是持续集成与持续部署的基础。企业可以使用华为云DevCloud进行需求与代码的管理。

最后，

DevOps变革是一个系统工程，涉及到组织、文化、人员、流程、工具、方法等方方面面。对于企业来讲，应该从客户商业价值出发，选择合适的团队，合理地管理期望，并以增量迭代的方法，初始聚焦于单一价值流，夯实基础，逐渐扩展到其它价值，实现DevOps规模化，最终实现企业的商业敏捷。