当今，DevOps能显著提升企业的商业敏捷与能力，因此在业界广受欢迎。然而，对于大多数企业来讲，DevOps变革并非一帆风顺，此过程中会面临各种各样的挑战。为了提高DevOps变革成功的可能性，我们亟需识别或者理解DevOps变革失败的常见原因，并采取一定的措施来避免。
基于DevOps的价值观（Value）、原则（Principles）与实践（Practices），分析DevOps落地案例，会发现DevOps变革存在4个常见问题，称之为四大"焦油坑"：
1. 乌合之众 - 未有效地管理组织变革
2. 各自为政 - 未充分地合作
3. 一蹴而就 - 未采用迭代方法
4. 沙上建塔 - 未清晰地管理需求
乌合之众：未有效地管理组织变革
在DevOps变革中，企业组织应该认识到人或团队是DevOps变革的最大的挑战，因而应该充分重视组织变革的重要性，而不是将重心聚焦在工具上。企业应该从理解客户商业价值来发起组织变革，领导层必须清楚DevOps以及相应的组织变革是不可或缺的，员工必须认识到变革正在发生。在DevOps变革中，领导层应该理解，为了提升商业敏捷性，决策需要在信息产生的地方进行，并应该去身体力行此种决策理念。
因此，领导层需要组建团队，并让团队自己决策应该做什么以及如何做。领导者应具备相应的技能与态度来激励员工，进行授权并提升他们的责任感。
各自为政：未充分地合作
在DevOps变革过程中，比较现实的情况是单个职能领域（例如IT部门）来发起此变革，因此导致DevOps实施局限于单个职能领域，无形中增加了变革失败的可能性。
因此即使单个职能领域发起DevOps变革，组织必须意识到成功的DevOps实施需要所有干系人共同合作以更全面地理解并系统地解决问题。为了加快价值实现时间，DevOps团队必须与其他团队及关系人合作。DevOps需要人们共同工作实现解决方案，打破障碍，并能像小型团队一样运作。因此，合作是至上的，团队的大小并没有绝对的限制，虽然业界有所谓两个比萨（Two-pizza）团队的说法。
更为重要的是，企业级别的合作需要管理层的支持。在一开始，就应该获得管理层的支持与拥护。DevOps的拥趸必须相信DevOps的价值，并平衡组织内不同团队的激励方式，例如开发团队被鼓励快速变更和开发新特性，而运维被鼓励维持可靠性和稳定性，这样就难以形成合作。
一蹴而就：未采用迭代方法
全面的一揽子的DevOps变革，对于大多数企业组织来说，是非常有诱惑力的。然而，历史经验却无情地告诉我们，这种传统变革失败率非常高。DevOps要在一个大型IT组织中成功，涉及太多因素，并且组织越大越困难。
因此，增量迭代方法成为组织的必然选择，一方面此方法使组织聚焦于持续改进，另一方面避免了传统方法的巨大风险。在进行DevOps变革时，组织聚焦于单一价值流，通过迭代与持续学习来持续改进，来得到合适的因素维持可接受的变革。迭代增量节奏也使组织确保团队分享与合作，并建立实践社区。这样，在此价值流学到的知识可以传递到下一个价值流，逐渐在组织中规模化DevOps。
沙上建塔：未清晰地管理需求
于受到DevOps成功案例以及CAMLS理念中自动化的影响，企业通常寄希望于自动化等技术与工具手段来加速产品上市周期，然而经常因诸多基础性工作没有做扎实导致DevOps实施效果未达到预期。
在诸多基础性工作中，最为关键的是需求的探索、分析与分解。从DevOps的发展历史来看，DevOps继承了敏捷方法的诸多实践与理念，原则上默认DevOps团队较充分地掌握了敏捷方法与实践，也致使DevOps组织忽略需求的重要性。因此无论如何强调需求的重要性都不为过。DevOps团队必须清晰地管理需求，使需求以及Story满足SMART要求，在迭代周期内可以按时保质交付最小可行产品（MVP）。
DevOps变革是一个系统工程，涉及到组织、文化、人员、流程、工具、方法等方方面面。对于企业来讲，应该从客户商业价值出发，选择合适的团队，合理地管理期望，并以增量迭代的方法，初始聚焦于单一价值流，夯实基础，逐渐扩展到其它价值，实现DevOps规模化，最终实现企业的商业敏捷。
【凡本网注明来源非中国IDC圈的作品，均转载自其它媒体，目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。】
延伸阅读：
- 寻找中国顶级物联网系统集成商
- 开放Linux“任意门” 红帽企业Linux 8面世
- 2019数字中国创新大赛总决赛在榕圆满举办