如何避免DevOps变革的六大“焦油坑”

当今，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规模化，最终实现企业的商业敏捷。