【华为敏捷/DevOps实践】5. 如何避免DevOps变革的六大“焦油坑”

原创

华为云开发者联盟 2021-05-25 09:31:03 ©著作权

©著作权归作者所有：来自51CTO博客作者华为云开发者联盟的原创作品，请联系作者获取转载授权，否则将追究法律责任

文/华为云DevCloud 伦语春秋

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

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

§ 无的放矢

§ 乌合之众

§ 各自为政

§ 一蹴而就

§ 好高骛远

§ 沙上建塔

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

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

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

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

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

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

· 客户期望的时间点

· 企业能够多快进行发布

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

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

企业组织在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个关键条件：

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

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

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

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

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

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

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

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

4. 客户满意度；

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

六、沙上建塔：未清晰地管理需求

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

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