企业该如何解决DevOps转型道路上的常见障碍？_导致工作准确度、完成度受到影响

合适的切入点，是DevOps转型成功地关键。数字化时代下，企业需要更快更灵活的交付来支持业务运营，这种迫切地需求促成了DevOps的高速发展，成为企业获得竞争优势的关键。

尽管大家都知道DevOps能推动业务，但DevOps落地过程中极易踩坑，最终导致DevOps转型失败，因此许多企业仍然难以从中获益。

本文介绍了DevOps建设的常见路径，分析各个环节的阻力，挖掘其背后的根源性问题，详解企业在DevOps转型过程中如何结合自身实际情况进行建设规划。

01. DevOps转型常见的建设路径

1. 推行DevOps的两种轨迹

自底而上

在这种模式下，企业内部DevOps的引入和实践一般发起于一个小组或者小团队，他们可能是企业内部DevOps的早期倡导者和实践者，为了解决自己团队内部，或者是和上下游团队交互过程中的问题。一般这类团队规模较小，而且内部相关资源调动起来也相对简单，这种模式比较容易在局部获得效果。

不过，DevOps的核心在于不同团队之间的协作，如果只是一个小团队内部的改进，还不能算是完整的DevOps转型。

如果企业规模较大，很难一次性改变，需要有一些勇敢的人来尝试推动这个过程，一种相对比较合适的方式，就是先在自己团队内部，以及和自己团队所负责的业务范围有强依赖关系的上下游团队之间建立联系，一方面不断扩展自己团队的能力范围，另一方面，逐步模糊上下游团队的边界，由点到面，打造大家共同的DevOps。

如果想让DevOps转型的效果最大化，我们一定要想办法让高层看到我们在局部改进的效果，让高层领导认可这种尝试和实践，最终实现横向扩展，在企业内部逐步铺开。

自顶而下

在这种模式下，企业高层基于自己对于行业趋势发展的把握，以及对团队现状的了解，通过企业战略推行的方式，下达任务目标。在这种情况下，公司领导有足够的意愿来推动DevOps转型，并愿意投入资源给予支持，各个团队也有足够清晰的目标，但是在DevOps的推行过程中，不能只是依靠自顶向下的推广，同时也需要中层的带动和底层的创新。

2. DevOps建设的演进路径

DevOps建设的演进路径一般有三个阶段：

自动化

DevOps的实施，一般先从自动化入手，通过从需求管理到上线部署的工具链平台建设，驱动研发效率、质量、管控的提升，实现通过工具来驱动研发。

数据化

当有了支撑研发交付过程的工具链之后，通过基于研发全过程的数据度量分析，面向不同角色提供关键指标，推进研发全过程的持续改进，实现通过数据驱动持续改进。

一体化

当以数据作为支撑而进行的持续改进，让整个研发过程的效率和质量实现了大幅的提升后，此时通过研发运维一体化与业务进行紧密结合，实现对业务的快速响应，最终不断增强企业的业务在市场上的竞争实力。

02. DevOps转型中的常见障碍

1. 业务部门不关注研发部门如何工作的

由于IT交付最终是面向业务交付的，如果业务部门不关注研发部门是如何工作的，那么很可能会导致IT交付的效果和质量没有保障。

因此，需要让业务部门参与进来，让他们了解在DevOps模式下是如何工作的，和之前有什么不同，可以带来什么样的效果，同时需要业务部门给研发团队提供对需求理解的帮助，帮助研发团队实现更有价值的需求交付。

2. 管理层缺乏对DevOps的深入理解

如果企业的管理层缺乏对DevOps的深入理解，那么DevOps团队很难获得企业高层的支持。

因此可以对高层领导提供DevOps相关的理念和知识培训，最终才能更好的争取领导层的支持。

3. 你说的都对，但是我们没有时间改进

在DevOps推行的过程中，可能些有团队由于手头上的工作内容或者问题比较多，本身就有点手忙脚乱，他们会提出没有时间改进。

因此，这种情况我们可以换个思路，告诉相关成员，其实解决质量问题，提升效率，也是可以创造出时间的。

4. 大家都觉得没有什么需要改进的了

有些团队可能认为当前在交付的过程中一切都还行，没什么大问题，没有什么需要改进的。

这时，可能我们需要通过一些问题现象或者逻辑的沟通论证，证明当前的流程和方式是存在问题的，是有提升效率和质量的空间的。

5. 一开始就把面铺得太广战线拉得太长

在转型初期资源由于投入有限，难以支撑大量任务并行，且团队之间的各种问题慢慢暴露出来也需要时间消化。

因此，可以分阶段设立目标，先在部分部门实施转型，等改进成功后再逐步扩大。

6. 在不改变现有流程下推行DevOps

从组织和文化层面来看，其实DevOps是一种文化和流程的变革，如果直接在现有的流程框架下去推行，不能把相关团队之间的协作调动起来，不将整个过程贯通，最终是无法推行下去的。

因此，实施DevOps转型，不是一个人的事情，是所有人的事情，从思维，技术，流程都需要进行变革。

7. 转型团队缺乏相关的理论和实践经验

DevOps转型的潮流汹涌，但是有些团队可能缺乏相关的理论和实践经验。

这个时候我们可以通过学习一些书籍、参加一些大会、分析一些企业案例来补充相关的知识和经验。

8. 缺乏统一的工具链平台作为支撑

DevOps转型需要工具平台的支撑，有些团队可能更多的成员是被安排在业务开发上，并没有过多的资源在工具平台的研究和开发上，或者有些小团队可能自己零零散散的弄了一些工具。

因此，搭建统一完整的工具链平台来作为支撑，是转型过程中重要的一步。

03. 避免文化、组织、工具中的坑

前面我们梳理了一些DevOps转型过程中常见的障碍，这些障碍总结起来主要涵盖三个方面：

文化的坑：文化不是流程与形式，而是共同的目标与利益

精益和敏捷为DevOps理念提供了很好的理论指导和工具支持，近年来很多公司逐渐开始进行敏捷转型。

例如：项目经理变成了Scrum主管，用户故事替代了以前的需求，开发计划变成了更短的冲刺计划。以前每周一次的会议变成了每日站会，一开始大家都精神满满，久而久之觉得每天的站会太麻烦，录入需求要时间，开站会需要时间，如果此时开发任务繁重、人员不足，这些繁琐的流程就应该尽可能简化，同时应该分析各成员的工作负载，合理的分配任务和资源，把大家当下的共同目标统一并明确起来。

组织的坑：寻求管理层认可和支持是DevOps转型的关键

如果没有管理层的支持，DevOps的转型之路将会困难重重。因为无论在什么时代，变革一直都是一场勇敢者的游戏，对于一家成熟的企业而言，无论是组织架构、团队文化，还是工程能力、协作精神，都是长期沉淀的结果，而不是在一朝一夕间建立起来的。

DevOps在企业内部实施时，要形成以企业高层如：CIO，业务部门和科技部门共同组成的DevOps转型小组，DevOps转型会使得之前的组织结构发生很大的变化，将之前的大部队作战方式，转型为一个一个的小团体进行作战，这样会更加机动灵活。

工具的坑：让需求流动起来才能更大程度发挥工具的价值

DevOps工具链的建设，是实施DevOps转型的第一步，有很多人认为，有了工具就实现了DevOps。

其实，一般的工具都只是满足某一个阶段的需求。比如，用jenkins来做持续集成，用Jira来做项目管理，用gitlab来管理源代码。有了工具并不能说就实现了DevOps，虽然通过工具确实能提高某些阶段的效率，但DevOps最终的目标是为了提高企业整体研发流程的效率和质量。

因此，我们需要让需求流动起来，并通过不断的反馈和持续改进优化，才能最终实现既快速，且高质量的价值交付。

04. 关于DevOps转型之路的思考

1. 经典的DevOps三步工作法

来自《DevOps实践指南》的经典三步工作法：

第一步：流动原则

实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流，需要将工作可视化，减少每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标。

第二步：反馈原则

在从右向左的每个阶段中，应用持续、快速的工作反馈机制。通过反馈机制，防止问题复发，并能缩短问题检测周期，实现快速修复。能够创造出组织学习与改进的机会。

第三步：持续学习和实验原则

建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。通过主动地承担风险，不但能从成功中学习，也能从失败中学习。帮助团队快速并自动适应不断变化的环境，进而帮助企业在市场竞争中脱颖而出。

2. 关于价值流的三个关键要素

来自《DevOps实践指南》的关于价值流的三个关键要素：

前置时间（Lead Time，简称 LT）

前置时间在 DevOps 中是一项非常重要的指标。具体来说，它是指一个需求从提出（典型的就是创建一个需求任务）的时间点开始，一直到最终上线交付给用户为止的时间周期。这部分时间直接体现了软件开发团队的交付速率，并且可以用来计算交付吞吐量。DevOps 的核心使命之一就是优化这段时长。

增值活动时间和不增值活动时间（Value Added Time/Non-Value Added Time，简称 VAT/NVAT）

在精益思想中，最重要的就是消除浪费，也就是说最大化流程中那些增值活动的时长，降低不增值活动的时长。在软件开发行业中，典型的不增值活动有很多，比如无意义的会议、需求的反复变更、开发的缺陷流向下游带来的返工等。

完成度和准确度（% Complete/Accurate，简称 %C/A）

这个指标用来表明工作的质量，也就是有多少工作因为质量不符合要求而被下游打回。这里面蕴含了大量的沟通和返工成本，从精益的视角来看，也是一种浪费。

3. 梳理企业内部的交付价值流

企业内部价值流程梳理会议

对于大型企业而言，开展企业内部价值流梳理会议时，可以选择处于改进中的项目里某个核心的业务模块，同时参加会议的人员需要覆盖软件交付的所有环节。而且，参会人员要尽量是相对资深的，因为他们对自身所负责的业务和上下游都有比较深刻的理解，比较容易识别出问题背后的根本原因。

不过，这种方式的实施成本比较高。毕竟，这么多关键角色能够在同一时间坐在一起本身就比较困难。另外，面对面沟通的时候，为了给对方保留面子，大家多少都会有所保留，这样就会隐藏很多真实的问题。所以，一般情况下，像团队内部的敏捷回顾会，或者是版本发布总结会，都是很合适的机会，只需要邀请部分平常不参会的成员就行了。

内部人员走访

如果第一种方式难以开展，我们可以采用第二种方式。通常来说，企业内部的 DevOps 转型工作都会有牵头人，同时会成立转型小组，那么可以由这个小组中的成员对软件交付的各个环节的团队进行走访。这种方式在时间上是比较灵活的，但对走访人的要求比较高，最好是 DevOps 领域的专家，同时是企业内部的老员工，这样可以跟受访人进行比较深入的交流。

无论采用哪种方式，我们都需要识别出几个关键问题，缩小谈话范围，尽量做到有效沟通，可通过提前建立一个调研问题列表来达到收集关键信息的目的。

通过访谈交流，我们就可以对整个软件交付过程有一个全面的认识，并根据交付中的环节、上下游关系、处理时长、识别出来的等待浪费时长等，最终整理出当前部门的价值流交付图。

4. 寻找DevOps转型合适的切入点

第一步：寻找合适的试点项目

试点项目是企业内部最初引入DevOps实践并实施改进工作的业务对象，一个合适的项目对于企业积累DevOps实践经验是至关重要的，一般一个合适的项目应该具备以下几个特征：

• 贴近核心业务：DevOps要以业务价值为导向，对于核心业务，管理层的关注度足够高，各项业务指标也相对比较完善，如果改进效果可以通过核心业务指标来呈现，会更有说服力。同时，核心业务的资源投入会有长期保障。毕竟，我们肯定都不希望DevOps转型落地项目因为业务调整而半途而废。
• 倾向敏捷业务：敏捷性质的业务需求量和变更都比较频繁，更加容易验证DevOps改造所带来的效果，如果一个业务以稳定为主要诉求，整体处于维护阶段，变更的诉求和意愿都比较低，那么这对于DevOps而言，就不是一个好的选择。
• 改进意愿优先：如果公司内部的团队认为当前状况一切都非常好，完全瞧不上DevOps，觉得自己当前的流程是最完美的，再跟他们费力强调DevOps的价值，结果很可能事倍功半。相反，那些目前绩效一般般的团队都有非常强烈的改进诉求，也更加愿意配合转型工作。这时，团队的精力就可以聚焦于做事本身，而不会浪费在反复无效的沟通上。

第二步：寻找团队痛点

找到合适的团队，有了共同改进和意愿，接下来就需要识别团队的痛点了。所谓痛点，就是当前最影响团队效率的事情，同时也是改进之后可以产生最大效益的事情，至于如何找寻痛点，我们可以参照上面讲的价值流分析活动。

第三步：打造可快速成功的改进点

当我们找到了合适的团队，也通过价值流分析识别出了一大堆需要改进的事项，这个时候，一定要注意不要把面铺得太广，把战线拉得太长，这其实是DevOps转型初期最典型的一个坑。

首先，转型初期一般资源的投入有限，难以支撑大量任务并行。其次，由于团队成员之间还没有完全建立起信任关系，那些所谓的最佳实践很容易水土不服。如果生搬硬套的话，很可能会导致大量摩擦，从而影响改进效果。最后，管理层的耐心也没有想象中那么多，如果迟迟看不到效果，很容易影响后续资源的投入。

所以，最关键的就是识别一个改进点，定义一个目标。比如，测试执行效率，那么就可以定义这样一个指标：测试执行效率提升50%。这样一来，团队的目标会更加明确，方便任务的拆解和细化，可以在几周内见到明显的成果。

第四步：快速展示成果

当我们在转型实施的过程中取得阶段性的成果之后，要及时向管理层汇报，并且在团队内部进行总结，这样，可以增强管理层和团队的信心，逐步加大在DevOps上的资源投入。

第五步：持续优化改进

在DevOps转型过程中，通过及时发现改进过程中的问题，在团队内部形成持续学习的氛围，激发团队成员的积极性，可以从侧面改善团队的文化，更有利于DevOps在企业内部的推行。

以上就是今天关于DevOps转型的过程中的一些常见障碍和企业如何盘点自身情况并选择合适的转型切入点内容分享，DevOps转型的过程虽然很艰难，但我相信只要我们找准了目标和方向，并且朝着这个方向坚持前走，就一定能够逐步的达到我们想要的效果。