DevOps落地难度主要源于它不仅仅是技术上的改变，更是文化和流程的转变。DevOps旨在通过自动化工具和跨职能团队的紧密协作，提高软件开发和交付的速度和质量。然而，这需要打破传统的组织结构和工作流程，克服团队间的隔阂，建立新的合作文化。同时，员工需要学习新的技能和工具，而这通常需要时间和资源的投入。因此，DevOps的实施不仅涉及技术层面的挑战，还面临着组织文化和流程改革的挑战，这使得DevOps的落地变得相对困难。
DevOps难落地的原因有很多，不同的企业都有自身的困难，以企业内部各角色的角度看，总会陷入角色代入的公司内部具体细节中。
我们在学习研究的过程中，大家都在说成功的案例，很少有人讲失败的案例。
我担心这会产生一种误导：不管什么企业，什么组织结构，什么技术能力，什么基础设施平台，都可以轻松落地DevOps。个人非常喜欢查理·芒格的逆向思维方式，既然大家都在讲成功的案例，我给大家泼泼冷水，讲讲我所理解和了解的真实情况。
作为DevOps的学习和布道者，对DevOps本身没有任何诋毁质疑，只是希望从反面让大家更全面的了解DevOps，不要在错误的时间，以错误的方式，错误地尝试了一下，然后做出了DevOps无用的判断。
一、什么是Devops
要谈落地Devops，先来看看什么是Devops。先看下 “官方”解释：
- DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
- 它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
- DevOps不能简单认为是工具、方法、技能或组织结构，DevOps的框架结合所有这一切元素，去建立一个流水线的过程，使业务更快的运营并且更快地应对变化。
看完之后是不是一头雾水？这可能是刚接触到DevOps的第一反应（或者说是我当年的第一反应吧）。2009年，Patrick Debois（DevOps之父）在提出Dev和Ops概念时的主要目的是如何在运维工作中应用 Scrum 和其它敏捷实践，为的是促成开发运维合作（打破开发和运维之间的部门墙）。
为什么会有部门墙？参考康威定律：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。
我们来看一个图，更好的理解一下Dev和Ops部门墙产生的原因。
传统的Dev 和 Ops 的关注点不同，Dev的关注点是如何开发测试交付新的功能，Ops的关注点是保证站点的稳定和高性能。导致直接的矛盾点表现在以下两方面：
（一）在价值流下游的Ops 评审认为价值链上游的 Dev 软件非功能质量不满足要求，因此阻止变更。
（二）在价值流上游的 Dev 无法获得价值链下游的 Ops 的真实运行环境，因此无法提升交付质量。于是，逐渐陷入了“无法提升质量”和“ 非功能质量不满足要求 ”的死循环中。
这么看，问题是不是清晰了，但是有人又会说，这墙也不是一天两天垒起来的，为什么现在要砸墙了？软件工程方法论从瀑布到敏捷，到目前的DevOps，都不是凭空演进出来的。敏捷的目的是为了打破产品和开发团队之间的部门墙，但是市场变化越来越快，需要更快的交付和反馈，所以只打破产品和开发部门部门墙还不够，现在需要将开发和运维运营也打通。
2010 年The Agile Admin 博客发表“ What is DevOps ”。在 DevOpsDays 之后，DevOps 被越来越多的人所熟知并迅速得到了大多数人的认可。2010年，《持续交付》的作者 Jez Humble 参加了第二届的 DevOpsDays 并做了 “持续交付”的演讲。从本质上说《持续交付》中所提到的实践给 Patrick 和 Andrew 最初所遇到的问题给出了最佳实践。
理解了DevOps的产生历史和目的，再来看看DevOps具体是什么。DevOps落地由于涉及的内容非常多，所以不同的角色以不同的视角看，基本就是横看成岭侧成峰，远近高低各不同。我们从不同角度和层面来看看什么是DevOps？
1.从人员管理层面看Devops
从上图可以看出，DevOps落地后，人员管理的组织结构会有变化。目前大多数传统IT企业的开发和运维部门的运作模式是共享的运维团队，开发完成后的交付物，交给运维团队负责部署、发布和运维。DevOps推荐的多功能团队类似于图中虚拟运维组的形式，每个开发团队都有自己的运维人员（运维人员少的也要有共享的运维联络人）。这里的运维人员指的是一种角色，有些团队也有全栈工程师，开发测试兼运维。对于中大型的公司，还经常会有基础设施运维团队，提供基础设施即代码等平台化能力。未来随着云原生服务的发展，运维的角色会有更大的转变（打破部门墙的最高境界，干掉运维部门，一切运维服务都是云原生服务）。
2.从技术架构层面看Devops
看完组织结构的变化，再来看技术架构的演进。从技术架构层面看（以Java Web应用为例）：随着IT技术的不断发展，应用系统的建设经过单体应用、SOA应用、逐步走向微服务应用。微服务的实施必然要具备需求管理、代码版本管理、质量管理、构建管理、测试管理、部署管理、环境管理等全流程自动化工具链，以及开发部门与运维部门的深度协作。因此，DevOps是微服务实施的充分必要条件。
3.从信息流转层面看Devops
从信息流转来看，DevOps包含了从需求管理到需求开发、代码管理、基础设施管理、持续集成、自动化测试、持续部署、持续发布和应用运维管理全流程。每个过程都需要DevOps方法和工具的支撑。比如我们需要Git来管理代码，需要根据企业的实际情况寻找合适的分支管理方法；我们需要Jenkins来做持续集成；使用selenium来做自动化测试；需要使用ansible来自动化部署；使用chef或者puppet来管理基础环境等等。
理解了Dev和Ops部门墙，然后从人员管理、技术架构、信息流转多个角度看完DevOps，现在我们应该对“什么是DevOps”，“DevOps具体要做什么”有了初步的理解。（对这块感兴趣的，后续会专题介绍。）广义的DevOps涉及的内容极广，理解之后，我们才能更好的分析DevOps难落地的原因。
二、DevOps难落地的原因
DevOps难落地的原因有很多，不同的企业都有自身的困难，以企业内部各角色的角度看，总会陷入角色代入的公司内部具体细节中。由于工作经历的原因，在DevOps布道和推广过程中，接触了大量不同类型的企业。本次从DevOps自身的技术复杂度和企业自身情况复杂度两个维度，来分析下不同类型企业DevOps落地困境。
1.DevOps为企业带来的收益
企业对于组织变革和技术变革最重要的两个关注点：收益、成本。
先来看收益。
DevOps的直接效果是缩短交付时间、加快交付速度、提高交付质量、提升客户和团队的满意度等，其根本目的是为了更好的支撑业务的快速更新迭代，满足市场的快速变化。通过市场的快速反馈，交付更多的价值，帮助企业实现商业目的。
案例：Netflix 是欧美地区最大的网络视频提供商，超过了 Youtube，与Facebook、亚马逊、苹果、谷歌一起并称五大科技巨头“FAANG”。全球每天有超过190个国家，一亿多会员在 Netflix 上观看1.2亿小时的电影，电视剧和纪录片等等。为了应对巨大的并发流量，Netflix 用了7年时间，网站架构从传统巨石应用演进成为业界超前的微服务架构。目前，Netflix 的云平台上运行了500个微服务，每天会有1000次的变更部署到线上环境。为全球用户提供稳定的网络视频服务。
这里只关注Netflix每天500+微服务，1000+变更部署的Devops交付能力，对具体案例感兴趣的可以参考《DevOps案例研究：进取到让自己毛骨悚然，Netflix公司的简介和文化》。
收益看起来非常明显，也非常诱人，还有什么理由不行动，燥起来吧骚年。
冷静冷静，我们再来看下成本。
2.DevOps实施的成本
不论企业规模，企业进行技术变革的最终目的都是为了实现商业目标，所以都会考虑投入产出比（ROI）。只不过有些企业目光长远一点，有些企业更关注短期效益而已。
如果上述收益分析算做DevOps落地的产出，那么DevOps的变革投入就是成本。这里的成本主要包括两方面，一是企业投入学习和实践的人力成本，二是变革过程中的项目延期以及组织变革导致人员流失等风险成本。
广义DevOps体系复杂，涉及到公司文化、组织结构、项目情况等多个方面。即使以上都符合，DevOps落地时候需要学习和改变的技术体系也比较复杂，涉及代码管理、持续集成、持续部署和交付、自动化测试、基础设施环境、技术架构等多个方面。
DevOps实施可以大概分三个阶段，包括持续交付、协同方式、丰田方式。
《DevOps实践指南》中的三步工作法基本匹配了以上三个阶段。第一步流动实践完成后，基本完成了持续交付阶段的目标。第二部反馈完成后，可以做到部门间良好的协同工作。第三部持续学习和试验完成后，算是接近丰田精益的管理模式。（丰田模式也有先决条件，不是所有企业都可以完全做到的，具体可以参考《目标》-高德拉特和《丰田生产方式》-大野耐一）
通常企业devops实践都是以三步工作法中第一步作为尝试，即完成持续交付能力，保证业务价值快速流动起来。那么我们来看看《持续交付》中Jez Humble对持续交付内容的定义。
对于持续交付内容的多个维度，在落地过程中都需要使用相应的工具和平台，常用的如JIRA、Git、Jenkins、Ansible、Chef、Docker、Kubernetes等等。
无论是持续交付内容，还是各种技术工具，学习成本和维护成本都不低。想实现第一阶段目标-持续交付，需要做的工作已经让我们应接不暇。想要达到Netflix的成果或者丰田的模式，需要部门间的协同以及整体组织结构和文化的变革，更是难上加难（大野耐一在丰田内部推广精益流程用了10多年）。
上述成本分析是基于DevOps方法体系和技术实践的复杂度来分析的，不同类型和规模的企业，组织文化、资金规模、技术能力、基础设施水平都不一样，企业DevOps实施的难度和成本也都不同。看完了收益和成本，在具体看看各类型企业对DevOps实施的态度。
之前说过，DevOps最根本目标是通过又快又好的交付价值，帮助企业实现商业目标，所以对于市场变化敏感度高的企业，对DevOps落地的诉求更强烈。
通过上述模型，将企业大致分为4类：
企业规模大、对市场变化敏感度高的企业（成本低，收益高）
这类型企业资金规模雄厚，对新技术有强烈的尝试意愿，愿意在早期投入以占领先机，应对复杂的市场变化，占领住领先的市场地位。如华为、阿里、腾讯、京东、百度、字节跳动等公司，以及招行、农行、建行等金融科技公司（这类企业案例和相关材料网上都能找到，不过多举例）。除了有意愿投入，这类企业技术实力雄厚，基础设施水平高，落地较快（也有部分企业部门墙厚重，推进相对缓慢）。
企业规模大、对市场变化敏感度低的企业。（成本低，收益低）
这类企业大多对DevOps持观望怀疑态度，对于DevOps变革可能对当前业务的影响有比较大顾虑，尝试意愿不强烈。客户案例：上市公司A，1000人以上规模的软件公司，传统行业业务，行业渗透率高，业务稳定,市场变化和竞争不激烈。公司内部组建了5-10人的DevOps和容器平台研究团队，三年换好几波人，迟迟也没有落地。这里边原因很多，但是落地推动艰难是问题之一。
企业规模小、对市场变化敏感度高的企业。（成本高、收益高）
这类企业对于市场敏感度高，愿意尝试和落地DevOps，但是自身技术能力和资金能力有限，DevOps落地困难较大，企业在尝试和困难中犹豫和徘徊，在一段时间内看不到收益和效果，容易放弃。这类企业我接触较多，企业大多尝试过，但是少数坚持下去，收获了明显的提升和收益，最终落地成功，而大多数企业在尝试后放弃。
企业规模小、对市场变化敏感度低的企业。（成本高、收益低）
这类企业，有些是企业自身项目或产品所属的领域对市场敏感度低，有些是领导和团队没有意识到产品快速迭代交付可能对市场竞争力的提升。此类企业我举个有意思的案例：A企业，研发团队10人左右，传统行业项目研发，老板很实在，和我说，我这小公司，有尝试新技术的时间和成本，不如我出去喝两顿酒，多接几个项目。对于此类型企业，他的瓶颈不是价值交付的速度，是提升市场销售能力。
解释一下，这里四种类型企业标注的成本和收益的高低，是相对企业自身能力来说的，比如：假设我们需要100万的人力作为尝试成本，对大企业来就是毛毛雨，但是对小企业来说就难以承受。上述企业类型的划分存在一定模糊的区间，有兴趣的同学可以细化为大中小、高中低的九宫格，继续详细分析一下，我这抛砖引玉。这里以大部分同类型企业的相似性作为分析，即使同行业同规模企业具体情况也不尽相同，不需要拿个别企业来钻牛角尖。
这里主要分析了DevOps落地对企业的收益，以及DevOps落地的成本。每个企业结合自身的情况都会有自己的ROI的分析，并最终导致不同类型企业对DevOps的态度。在众多企业DevOps落地困境的万千表象中，希望可以拨开一丝迷雾，通过冰山一角透到背后的本质。
面对DevOps自身的技术复杂性（门槛高），以及不同企业自身的情况复杂度（技术水平参差不齐，组织文化风格各异），下面我们谈谈：我们的DevOps推广和布道者应该怎么办？作为企业自身的管理者又应该如何选择？
三、面对DevOps自身的技术复杂性企业该如何选择？
评估和确定目标
1、评估企业的敏捷度
（这里的敏捷度是指所属业务场景的复杂度和对市场变化的敏感度，偏管理和商业属性）
《STACEY》矩阵是通过技术的确定性和需求的明确性，来评估适用的项目管理方式。对于需求和技术都不明确的复杂领域，敏捷型项目管理方式能更好的适应市场需求的快速变化。对应的，DevOps落地对于这样的企业和项目收益提升较高，而对于预测型项目相对来说ROI要低一些。
PMI通过文化、团队、项目三个维度来评估敏捷的适用性，也是很好的思路。所有一切敏捷性评估的根本目的都是为了让我们明确收益和成本的关系。DevOps落地对大多数企业来说都会有收益，只是收益大小和落地成本要综合衡量，以确定开始实践的时间和阶段目标。
2.评估企业的DevOps成熟度
（这里的DevOps成熟度是指自身技术的成熟度，偏工程和技术属性）
研发运营一体化（DevOps）能力成熟度模型，是国内第一个DevOps系列标准，由中国信息通信研究院云计算开源产业联盟（OSCAR）联合多个单位行业顶级技术专家100多名共同编写制定。每年会做一次企业DevOps能力成熟度模型调研，并发布报告。感兴趣的可以参加并评估下自身的DevOps能力成熟度。
《2019 State of DevOps Report》中的5个DevOps进化阶段，既可以作为我们评估自身成熟度的标准，也可以了解到我们当前所处的阶段和下一步的阶段目标，推荐大家参考。
评估完企业的敏捷度和DevOps成熟度，然后根据成本收益分析（参考中篇的模型，或者细化9宫格）确定企业是否要转型，什么时间开始尝试转型，以及转型的阶段目标（没有明确指标，别谈改进），我们再来看看落地策略。
落地策略
1、从上到下推行 DevOps 容易，从下到上推行 DevOps 困难
推行DevOps涉及到整体体系的改变，不只是对技术的改进，对组织架构和整个企业文化建设都是有要求的。所以想要落地DevOps，一定需要老板支持，技术负责人和老板沟通清楚目的和目标，在推进过程中会减少很多阻力。
2、寻找外部专家指导或者内部培训转型教练
DevOps落地是一个长期的过程，这块内容在前两篇文章里已经说过了。三步法的三个层次逐步推进，必须要有教练一样的角色长期的指导和跟踪，否则很容易导致进一步退两步直至最后放弃的结果。DevOps落地最难的不是技术，是人。
3、渐进式变革，可视化阶段目标和成果
只要是变革，就避免不了对现有工作流程的冲击。尽量减少冲击，特别是减少对于人员现有工作方式的改变，会减少变革的阻力。通过阶段的收益成果，增加企业继续实施变革的动力，从而引导企业逐步改变工作习惯和流程。特别是对于中小企业来说，企业对于成本投入的预期回报期比较短，如果不能看到阶段的收益，很容易放弃。
4、以“绿地项目”、创新团队为试点，逐步推向其他团队
软件领域有“绿地项目”和“棕地项目”的说法，绿地项目是指那些新开始的项目。DevOps落地最好以有创新意愿和能力的团队的新项目为试点，增加首个案例项目DevOps落地的成功率。以该项目为案例，逐步推广到其他团队。每个团队和项目都要先做分析，不要盲目推广，不适合也硬推，最后可能会成为反面案例素材。
5、精益思想+TOC理论为指导，优秀DevOps工技术实践为参考，探索适合自己的DevOps落地路径
我个人觉得DevOps就是精益思想在软件开发生命周期过程管理领域内的一种良好的工程落地实践。企业需要结合自身实际情况，探索适合自己的DevOps落地路径，最终实现企业的商业愿景。技术落地实践重点推荐两本书《DevOps实践指南》和《持续交付》。
以上几点，是这几年辅导企业转型的过程中的反思和总结，基本都趟过一些坑，所以印象深刻，痛定思痛，推荐给各位参考。后续会继续结合企业落地案例，梳理一些良好的技术实践，特别是一些中小企业的实践案例。希望可以通过这些实践，抽取出同类型企业的通用方案，帮助中小企业更加低成本落地DevOps。
另外，Google 提出的 5 个 DevOps 原则也非常值得我们学习参考。
- 精简组织架构；
- 愿意承担一部分试错带来的损失；
- 分阶段地一小步一小步地进行转型；
- 最大化地利用工具和自动化流程；
- 对所有的过程和结果进行记录和分析。
四、DevOps布道和推广
1.DevOps布道和推广的现状
DevOps理念、技术、方法的布道推广分内部推广和外部推广。内部推广针对的主要是公司内部团队，通过公司内部的SRE或者技术负责人推动的居多。外部推广的有两种：一种是云厂商和SAAS服务商以产品和服务有偿为其他企业提供DevOps赋能和落地服务。一种是技术社区和志愿者出于对技术的热爱和技术推广的热情，对企业和个人开发者进行赋能。
DevOps落地的“道法术器”，除了理念、技术、方法的学习，还需要工具支撑。目前DevOps工具主要分两种，开源自建型和平台产品型。大型企业大多内部自建平台，内部推广，迭代优化，支持内部研发团队。常见的工具方案如JIRA+Gitlab+Jenkins+Ansible+Docker+K8S。众多云厂商也推出一站式云端DevOps平台，如华为DevCloud、阿里云效、腾讯Coding、微软Azure DevOps等。SAAS厂商也在推 DevOps工具平台SAAS服务，如Ones、Gitee、Worktile等。大家有兴趣的，都可以对比试用一下。
2.问题和建议方案
众多厂商的 DevOps平台多以最新技术和内部实践而孵化，更适合团队技术能力强，资金实力雄厚，基础设施水平较高的企业。所以客户大多以大型企业为主，提供定制化解决方案。中小企业问题千奇百怪，以大企业自身经验孵化的产品和解决方案，对中小企业来说经常是美好而不接地气。这部分长尾客户目前仍处于培育期，缺少比较适合的落地方案。
手里拿个锤子，看什么都像钉子。成千上万的企业，一个锤子肯定不够，但是一家一个锤子也不现实。所以第一件事，抽离出目标用户画像。企业众多，情况不尽相同，但是可以通过用户分类和画像筛选，将主要的目标用户确定下来。吴昊老师的《SAAS创业路线图》中将目标客户描述为橄榄型，非常形象。DevOps平台的目标客户也应该是橄榄型，头部和尾部客户少，中间的中型企业众多，是我们的主要目标用户群。
大型企业：定制型锤子（解决方案）是没问题的，毕竟大型企业财力雄厚，企业组织大、问题多，需要专家团队一对一转型辅导。即使平台定制化，成本和收益也是划得来的。
小微型企业：识别哪些是目标客户，哪些暂时不是。非目标客户果断放弃，不要浪费时间精力，容易把你的产品和解决方案拖入混沌的境地。
中型企业：根据行业、规模、场景、流程、组织结构等维度，需要制定对应用户群特性的DevOps落地路径和方案。目前此类方案比较少，也是我后续的努力方向。有很多人会很迷惑，或者非常不认同我的说法。我们已经弄清楚DevOps的阶段以及每个阶段的目标状态，大企业也有很多优秀的实践案例和成果，直接把锤子拿过来用不就行了么？我在初期推广DevOps的思路也是这样的，但是经过几年下来，对各类企业业务流程、组织结构、研发痛点等深入的了解后，发现理想的状态和现实的差距很大。
《精益思想》中有一段关于价值的讨论，大致的意思是美国的企业关注财务指标、德国企业关注技术工艺、日本企业关注生产地，而真正的价值应该由最终客户来决定。目前DevOps布道和推广的厂商和技术大咖更多关注技术的先进性，案例实践以头部互联网和金融科技企业居多，缺少以中小型企业实际情况总结的渐进落地方案，很多企业只能看着大厂的美好，对比自己的基础和能力摇头。
大企业的案例网上不少，但是中小企业的案例比较少，原因可能是中小企业还在探索落地的过程中。另外，企业觉得自身的实践并不规范和完美，不愿意去分享。其实很多中小企业的落地方案更加务实，也更接近于大量同类企业的真实场景，接地气，非常有参考学习的价值。中小企业一样可以探索出适合自己的DevOps落地路径，只是步子要小，成本要低，见效要快，才能持续迭代的改进并最终落地。
3.未来的思考
企业之间都是有差异的，每家都会有自己的特殊情况，很难有所谓的通用产品能适配所有场景、解决所有问题。但是对于提供产品化的企业，必然要努力抽象出目标企业群体（中小型企业）的共性场景问题，才会有成功运营的机会。如果每个企业都只能由解决方案专家一对一提供定制化平台解决方案，那么平台类产品就只有死路一条。即使对于提供解决方案的咨询类企业，每个中小企业都要投入解决方案专家，也必然入不敷出，只能放弃中小企业客户群，专心于大型企业（这也是目前的一个实际情况）。
对于Salesforce的模式可以作为一个很好的参考案例。基于常年累月的行业积累，抽象出通用的领域产品，满足大部分企业场景。对于大客户或者其他比较复杂的场景，也提供基于通用产品定制化开发的解决方案。通过通用产品+定制化的方案，完整覆盖了目标用户群。
文章转载自：华为云CodeArts，作者高荣信
