谈DevOps推行困难原因(200616)

今天不谈DevOps和云原生架构对企业带来的价值和收益，而是分析下DevOps实践在企业内部推行困难的原因，这里的DevOps包含了微服务，中台，DevOps和容器云各方面内容。对于DevOps实际上我们可以看到几个关键方面内容，其一是团队文化的改进，其二是项目管理和敏捷方法论，其三才是技术层面的类似微服务架构，持续集成，容器云部署方面的改进。

因此要分析DevOps实践在团队推行困难的原因还是需要从以上这些方面进行分析。

推动力不足，优化还是变革？

对于DevOps实践，特别是配合微服务和容器云的时候，我们可以看到对企业传统的IT架构是一次具体的变革而不是简单的架构优化。任何大架构的调整一定有推动力，那么站在CIO角度推动力在哪里？

这里面就存在技术驱动和业务驱动两个关键概念了。技术驱动简单来来说技术发展趋势是这样的，我们要早点变革做长远打算。一个是业务驱动，即业务发展需要IT变革，否则性能，敏捷性都无法跟上业务发展需要。

现在真正驱动力一定是当前的IT系统本身通过简单的优化已经无法应对业务需求，这才是关键驱动力。否则当前IT系统本身运转良好，为了新技术发展趋势或远期规划而需要大量前期IT预算投入，估计CIO也没有这个能力申请到足够的预算。

其次，传统稳定架构转变为新架构一定带来一定的不稳定期和阵痛期，大部分CIO并不愿意承担风险。

因此没有明确的业务驱动力，再加上企业IT部门和大部分CIO都很难强势，这些导致了DevOps推行困难度增加。IT投入预算更多的是先解决业务问题和痛点，其次才是解决IT本身治理管控问题。

企业内部IT团队管理和技术基础薄弱

要明白，任何新的方法论和技术的推行和实践本身就是一个循序渐进的过程。这和小孩爬都没有学会就要学跑是一个道理，企业IT也很难进行跳跃式发展，而是必须一步步的逐步演进式发展提升企业IT成熟度。这里面的薄弱实际上可以总结为几个方面

其一是软件工程和研发管理基础薄弱，比如企业是否有标准的软件研发管理，或者实施过类似CMMI软件过程改进，实施过敏捷项目管理，有最基本的研发管理过程规范和技术标准。如果这些都没有做过，你会发现进入到DevOps后你的研发过程管理能力跟不上，因为在敏捷状态下需要更加可视化，更加高频和可量化。

其二是研发技术基础积累薄弱，比如企业原来本身没有接触过微服务架构，容器技术等，如果企业要从头开始学习和实践这些，那么就需要一个长周期的学习时间，而且关键是自己摸索很大地方还无法彻底做到融会贯通。另外一个技术基础就是我们常说的持续集成，企业原来是否实施过类似持续集成，如果你原来实施过持续集成，冒烟测试，自动构建，自动化测试等，那么你会发现过渡到DevOps就相对容易。

团队文化影响，持续改进的意愿

最后一点，个人认为也是最关键一点就是你当前的团队文化究竟是如何的？团队文化是一种安于现状，乐于重复，拒绝变化，喜欢藏着掖着的文化，还是一种开放，透明和拥抱变化的文化。在各种敏捷方法论的推行过程中，我们始终会看到首先就会强调团队文化，敏捷文化。而敏捷文化就是一种开放，包容，乐于接受变化，可视化，对结果负责的文化。而这些正式推行敏捷方法论和DevOps的基础。

在推行DevOps后我们可以看到会让每个团队成员每天的输出成果，和输出质量更加可视化，完全暴露在整个团队，你自己想藏着掖着都不行。可想而知，对于原来一些本身自律性就差，喜欢耍小聪明和偷懒，对产出质量不重视，责任心不足的团队成员来说绝对是坏事。

这些人往往更加期望一种传统的非透明的管理方式，这种方式下他们可以更多的划水或得过且过。

而对于原来就高度自律负责，产出质量高的成员来说往往就更加喜欢这种敏捷和DevOps的方式，这种方式反而是进一步体现和量化对比了他们自己的价值。

在敏捷方法论里面我强调日事日毕，每天都能够反馈和总结，就这一点估计很多人就无法做到，也不愿意去做到。不是所有的程序员都热衷于新技术，更多的人还是希望是不太动脑的重复劳动。

预算和成本，投入产出比

最后我再谈一点就是推行DevOps的投入产出比的问题，要知道DevOps特别是微服务架构的实践往往是对原有架构一次大的变革，那么自然需要投入更多的研发资源，或者还包括外部技术产品和咨询服务的采购，这些都是需要大量的成本投入。

而这些成本投入在刚开始你往往看不到带来的具体收益。

举个简单的例子的，当前需要开发一个新的业务系统，用传统的架构方式可能成本在30万，但是采用微服务架构并实践DevOps后可能总体成本在100万。这个多投入成本在短期并没有价值，真正的价值是在后期运维，在需求变更的快速响应，在后期系统的弹性扩展上。那么多少人又愿意为了长远的打算提前做出成倍的投入。