点这里👇星标关注，获取最新资讯！
不得不说，这看着很美好，听着也很美好的DevOps，宣传时各方也都给与高度评价，纷纷表示其要解决的问题正是他们平时工作中所深恶痛绝的。但在实际推进过程中，却是横拢地拉车——一步一个坎，各种非技术问题的接踵而至，让你陷入不断地自我怀疑 —— 这么费心费力地，我他喵到底图个啥？
作为一种流程管理思想，DevOps的落地必须结合所在公司的实际情况来对症下药，必须先深刻理解团队当前的状态，然后才能因地制宜地，将DevOps中的各类思想和操作一点点引入进去。本篇文章分为两部分，第一部分介绍DevOps的落地的十个重要实践，第二部分介绍落地DevOps的工作方法。
DevOps的落地的十个重要实践
实践
基础设施即代码
不可变基础设施
只生成一次制品
对不同环境采用同一种部署方式
内建质量
一切皆版本控制(配置管理)
唯一可信任源
工具的连通性
随时可发布
元数据
这一条指导思想要求我们将应用正常运行所需要的环境，其搭建过程用代码的方式描述到配置文件中，之后将由专门的工具通过读取该配置文件来实现应用环境的构建。
以上看似增加了额外工作量的最佳实践，将让我们获得如下好处：
环境的搭建过程不再依赖于人，人的经验和责任心并不会影响最终搭建出来的应用运行环境，做到环境的完全独立，进而缩小了系统出现错误时候的排错范围。
有助于形成完整，规范的安装目录结构，大幅降低沟通成本。因为整个部署过程在一开始的时候就进行了约束并持久化，因此我们很容易就联想到形成默认安装目录结构的团队契约，这在降低沟通成本的同时，也使得基础架构部门在进行重复性工作消除的时候，能够基于共识进行更为激进的封装。
2. 不可变基础设施
对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不在进行更改。
这一点很重要，但又隐藏地很深，就笔者过往的工作经历而言，一套基础环境经过一系列人工操作配置完成之后，基本陷入两种角色的反复切换：
“生怕磕着碰着的宝贝疙瘩”。我他喵费了九牛二虎之力才整出个可正常运行的系统，谁要是把这环境破坏了，我跟谁拼命！
“任劳任怨的老黄牛”。哎呀，这套系统的基础部署环境搭建起来太费劲了，咱们不是已经有了一套可正常的运行的吗？我这开发的新功能就在那套环境下测试下得了，你看你这人咋这么不近人情呢，又不会给你搞坏了。
“这种模式中，任何基础设施的实例（包括服务器、容器等各种软硬件）一旦创建之后便成为一种只读状态，不可对其进行任何更改。如果需要修改或升级某些实例，唯一的方式就是创建一批新的实例来替换它。
为什么我会说，不可变基础设施的思想对持续交付的影响非常深远呢？因为不可变的思想正是解决了持续交付一直没有解决的一个难题，即环境、顺序、配置这些基础设施在测试环节和生产环节的不一致性所带来的问题。” — 《极客时间 - 持续交付36讲》
3. 只生成一次制品
只生成一次制品，这是《持续交付》中提到的一个非常重要的实践。
对于同样一份代码，理论上来说，不同的时间段编译打包出来的制品，其所提供的服务应该是完全一致。
但是正如上面所强调的，这都是"理论上的"，在这个现实的世界里，你需要面对各类违反常识的现象，因此针对制品生成这一块，为了杜绝相关的不一致问题，根本性地解决方案就是：针对某个时间节点的源代码，只生成一次制品，不同环境下应用的表现不一致的需求，应该交给外部的配置文件来控制，而不是交给源代码的编译过程。
4. 对不同环境采用同一种部署方式
对不同环境采用同一种部署方式，这也是《持续交付》中提到的另一个非常重要的实践。
实现这一步并不简单，因为要实现将同一制品部署到不同的环境，就必须做到制品与配置的分离。
只有实现了"制品与配置的分离"，我们才能实现无人工介入前提下的，可追溯的部署流程。
"制品与配置的分离"实现之后，我们可以针对每类不同的环境来准备一份包含完整配置信息的，只对应相应环境的配置，这样在之后的部署环境，整个部署过程将转变为由自动化流程根据用户所指派的环境，抓取同一份制品包，以及与指定环境相匹配的配置文件包，合并之后部署到对应的环境上。
5. 内建质量
"内建质量"的底层逻辑是“你想要有一个好的结果，那你必须得先存在一个好的过程”。
"内建质量"要求我们在研发流程的过程中，能够将问题尽早暴露出来，最好在错误发生的地点将错误发现并解决。
为了实现上述目标，我们需要一系列诸如" 测试左移"，“质量门禁”的指导思想，以及一系列相应的措施来保证"内建质量"的实现。
需求评审阶段，我们需要对需求的描述格式，需求优先级等进行一系列检查，确保从源头掐灭一些低级错误。
代码研发阶段，我们需要从最基本的代码质量检查，团队内部代码规范，单元测试覆盖率等等各个维度将代码低级错误消灭在这个阶段。
测试阶段，我们需要从测试用例格式，测试代码质量，测试代码业务场景等等多个角度来进行检查。
部署运维阶段，我们应该指定严格完善的上线/回滚流程，并针对多个维度搭建完善的监控系统，确保系统线上环境的稳定，以及问题的及时发现，系统回滚的快捷。
本小节所描述的"内建质量"，作为核心的"内建"说明了这其中的大部分检查工作都应该被自动化流程所完成，确保不能满足基本质量要求的阶段性产物无法流动到下一阶段。
内建质量的两大原则：
问题发现得越早，修复成本就越低；
质量是每个人的责任，而不是质量团队的责任。
6. 一切皆版本控制(配置管理)
“一切皆版本控制”的同义词就是我们经常听到的"配置管理"。
在《持续交付》（2011-10）的第二章配置管理的小结里说到：“配置管理是本书其他内容的基础。没有配置管理，根本谈不上持续集成、发布管理以及部署流水线。它对交付团队内部的协作也会起到巨大的促进作用”。
"一切皆版本控制"这句话里的"一切"已经很说明问题了，对于软件开发整个流程捋下来，从最开始的可行性分析文档开始，我们就应该将其进行版本控制，例如上传SVN，或者用专门的WIKI等。
我们进行版本管理的目的不是为了找个地方把东西存起来，也不是为了未来某一天不小心发生误删或审查需要时候，有所底气；更不是因为别人都做了，所以我们也要做。以上这些都不是做版本控制的主要目的。
我们做版本控制是为了能够精确控制软件开发的整个流程，让整个流程既能够按照实践顺序按部就班地向前迭代，也能够在问题发生或者某些需要的时候，能够稳步地将时光倒流，退回我们期望的那个时间点。
既然是"一切皆版本控制"，让我们尝试列举下需要版本管理的：需求，代码，制品，部署脚本，数据库，应用环境相关的安装软件包等等。
7. 唯一可信任源
关于这一点，其实用一句话就能解释：“我们只对从这里拿到的包负责，不要从那些犄角旮旯踅摸个包告诉我们有问题，我们深受其害，我们以后不想再受伤害”。
"唯一可信任源"隐含了要求将发包权限回收，放到专人手上；其二就是建立双方的契约，断开提供者和实现者的直接接触，通过引入"唯一可信任源"规范化制品的管理。
8. 工具的连通性
对于持续交付工具链体系来说，工具的连通性是核心要素。
相较于争论为了完成某个任务，是使用现有的工具A，还是新引入更为强力的B，在单个工具上反复拉锯论证，如何在现有研发流程工具集基础上，在最短时间内拉通各个软件，实现研发数据信息的快速流动，才是应该被首先考虑的。
借用政府作部门协同信息化文件中的一句话：“我们要让数据多跑路，群众少跑路”。工具的高效连通能够显著降低研发流程中各部门协作的停滞感，促进价值流的高效流动。
9. 随时可发布
你的软件必须处于随时可发布状态。
这一最佳实践要求软件开发团队至少能够随时提供软件的两类最新版本：
经过完整测试通过的，能够部署在生产环境下的版本，该版本内拥有所有测试通过的新特性。
未经过完整测试，可提供给测试人员进行测试的，或者产品/售前部门进行软件演示的，包含了当前最新开发进度成果的。
这一最佳实践展示出来的是对于软件开发流程的最终要求，看似简单的一句话需求背后所隐含的要求却并不简单：
你的软件要时刻处于等待测试和展示的状态。这要求软件从设计阶段开始，之后的每次状态变更都要经过一些基础的检测， 这样才能将尽量多的问题留在原地，而不是积累到最后需要演示/部署时候才解决。
你的软件版本管理得规范，你得明确知道当前软件的最新版本号，以及各个版本号对应的需求完成和BUG修复情况。
你的软件流程得尽量自动化，"随时"的要求决定了我们不可能指望依靠人工来完整这一要求。
10. 元数据
关于元数据的名词解释这里就不多做描述了，作为"关于数据的数据"，元数据的特点决定了其主要作用是对过程和结果进行描述和记录，以方便对相关过程和结果进行反向追溯。
在DevOps流程中，因为大量的工作被机器所取代，增加了效率的同时，也让人增加了对于过程不可控的担忧（当然了这只是出于感性上的直观感觉，其实从理性出发，自动化反而增强了过程的可控性），因此为了能够对过程进行回溯，自动化流程需要在搭建的过程中，在流程的每个阶段尾声，写入关于本阶段的一些元数据作为备份，这样既能够为之后的阶段提供信息参考，也能够可能的问题排查提供追诉依据。
额外提一句的是，其实人工操作也是应该有元数据的，只是人工操作本来工作量就大，你再给加个增加元数据的活，造反和阳奉阴违就并不是什么值得惊讶的事情了。
落地DevOps的工作方法
落地
DevOps落地的三个要素
DevOps的落地思路
DevOps落地三步工作法
由国家工业和信息化部教育与考试中心颁发的职业技术证书，也是国内首个《研发效能（DevOps）工程师 职业技术证书》。课程内容涵盖【组织与协作】、【产品与运营】、【开发与交付】、【测试与安全】、【运维与监控】五大研发关键环节逐一讲解，1000页学习教材+2000分钟的课程内容讲解+400个技术知识点，助你成为研发效能(DevOps)专业人才。
1、DevOps落地的三个要素
从DevOps定义里我们可以看到，DevOps的整个落地分为三个要素：平台，流程和人；其中流程是搭建平台的基础，在开始搭建DevOps平台之前要先梳理清楚各部门项目/迭代研发的端到端流程，抽取流程中共性的东西，使之标准化，在基于标准化的流程上，构建适合公司流程规范的DevOps平台。
📢流程落地：
流程落地遵循2个原则：
1、自动化一切能自动化的流程
2、减少不必要的中间环节，特别是需要人为沟通的环节
下面我给大家举两个例子，分别说明：
自动化一切能自动化的流程，比如申请测试环境的流程， 流程中有以下几个节点：
1、申请主机资源
2、环境初始化：操作系统，数据库，中间件搭建
3、安全扫描
如果这几个节点都是通过人工去推进的，那么当研发团队很小，假设处理这几个节点的同学没有并发任务的情况下，效率还算可以，但是一旦团队足够大，测试环境的申请并发量大于1的时候，必然会造成资源的等待，导致测试周期的拉长，而这些等待最终都会体现在团队的交付效率上。
减少非必要的中间环节，比如我上家公司处理客户反馈的线上故障的流程：
1、客服先受理
2、协调组成员复核问题
3、技术经理复核问题
4、开发修复问题
5、测试验证后上线
在这个流程里，第2步和第3步只是为了解决这个故障转给谁处理的问题，真正起作用的就是第4步和第5步，如果我们把每个产品对应的联系人做成一个表格，告诉给客服人员，让客服人员生成故障单后直接流转给对应的开发负责人，就可以减少这个故障单的流转节点，提高线上问题处理的效率
一个公司的流程梳理和标准化要远比我上面举的例子复杂的多，这需要DevOps的推进者充分的熟悉各部门各产品的流程特性，另外在梳理流程的时候，要把梳理重点放在研发流程中最痛的地方，因为这些最痛的地方，改进之后的效果最明显，也最容易得人心，当研发同学感受到DevOps流程是在帮助他们提升效率的时候，再推进其他流程梳理的时候
📢平台落地：
所谓平台就是一个能贯穿软件需求—编码—测试—交付—运维全生命周期的一个软件系统，在这个平台上要能实现需求，代码，测试，交付的自动化管理，还要能实现度量数据的自动化收集，为团队的持续改进提供准确的数据支撑，目前市面上比较有影响力的devops平台如阿里的云效，华为的devCloud，腾讯的织云，这些平台的能力大致可分为如下几块：
1.项目管理能力：包括需求，任务，用例，缺陷的管理能力，对应的项目管理的开源工具有：jira
2.代码管理的能力：代码提交，分支合并等能力，对应的开源工具有：git
3.持续构建&持续交付的能力：包括环境管理，自动化构建，自动化部署，自动化测试等能力，对应的开源工具有k8s, jenkins,junit
4.数据度量的能力：
5.制品管理的能力：主要是对制品进行版本化，分层化的管理，开源的工具有：nexus
在平台选择上，建议根据团队的实际情况优先考虑自研的产品，因为自研的产品流程是最贴切本公司实际情况的，其次考虑具备端到端管理能力的产品，因为只有端到端能力的平台，在数据度量上面才会更全面，更能够为团队的持续改进提供准确的数据支撑。
📢人：
关于人这块，主要是指人的观念改变，不要只关注自己所负责的一亩三分地，不是说一个团队搭建了一个统一的研发管理平台，这个团队就实现了devops，要站在整个交付链的效率和质量的角度去考虑问题，才是团队能否实现devops，能否持续改进的灵魂所在。
在传统的瀑布模式中，测试同学就是负责测试，开发同学就是负责写代码，修改缺陷，运维同学就是管环境，管线上发布，有明确的职责边界，但在devops流程中，为了追求更高的交付效率和更好的交付质量，我们提倡打破这些职责边界，通过协作的方式，来实现质量内建，测试提前，自助交付。
如何更好的实施质量内建和测试提前呢？在这个环节里，开发同学的作用尤其重要，让测试同学为开发赋能，测试同学给开发同学提供测试场景，测试数据，测试工具，让开发同学在代码完成之后就可以立即开展质量验证的工作，而测试同学可以聚焦于复杂场景的验证，减少代码交付，缺陷沟通过程中的资源浪费，既缩短了交付周期，也提高了交付质量，还有助于开发同学养成良好的测试驱动开发的习惯。
本培训课程致力于打造一支既懂技术又懂管理的复合型研发效能团队，为企业的发展提供强有力的支持，助力企业在数字化转型道路上稳步前行。
2、DevOps的落地思路
除非有高层领导的铁腕支持，否则在现有团队中推进DevOps，你最好是抓住DevOps的神，而不要在形上过于纠结。
这里有四条指导思想：
1、先减负，再加正。
不要一上来就试图在团队原本已经紧张的工作压力上，再加上几条新措施，这只会遭受激烈的反抗，你要通过观察团队的当下工作协作流程， 采取DevOps思想评估当下他们流程里的痛点，找出那些改进ROI最高的点，推进这些措施降低他们当下的工作压力，进而赢得他们的信任，然后再将DevOps流程里那些对当下流程影响较大，需要作出改变较多的措施按照实际情况编排后的顺序逐一推到台前。
2、完成比完美重要，且重要得多。
重点是让流程执行起来，将整个团队赶到流程上来，之后改良的需求会自己主动跳到面前，而且那个时候的改良，更具体，也更实际。
3、从大处着眼
究其根本，DevOps目的是提升业务交付能力：
如何快速的交付想法？
如何让客户进行尝试（从而获取反馈）？
如何快速响应客户反馈？
DevOps不应该只是IT内部的几个部门玩的游戏。必须跳出IT的角度，端到端（业务端到客户端）分析，才能弄清公司需要依靠IT的哪些工作来支撑业务目标，支撑企业战略 ，从而实现更完整、真正的DevOps。需要将IT变成一种能力，融入公司的日常运作中，融入业务活动中。在快鱼吃慢鱼的时代，需要快速试错，不断整合来自市场的反馈。
所以最终，DevOps是一个端到端的问题，是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作、共同支持。DevOps尝试建立一个业务价值交付管道，业务规划、需求梳理、计划、开发、构建、测试、部署、运维、监控 ，在此交付过程中涉及到的部门/团队、过程、系统、方法都归属于DevOps关心的内容。
4、从小处下手
理解了DevOps是一个端到端的过程，我们就会发现整个交付链条涉及太多的领域，导致问题也层出不穷，无从下嘴。因此在实际操作中，我们需要有一个切入点。
DevOps的思想以精益与敏捷为核心，通过暴露问题、解决问题，从而实现持续改进。从精益的角度看，在代码投产之前，实际上未产生任何价值，都只是半成品。要限制半成品，即在制品（WIP）数量，让其尽快流过生产线，让投入产生交付价值。
DevOps是一个复杂问题，我们却希望可以把一个复杂的问题简单化：正如装修时通过加压检查管道是否泄露，是否有阻塞，我们也通过加压的方式来暴露软件交付管道的问题。那么如何加压？以终为始，我们选择业务价值交付的那个点，也就是部署与发布来对整个交付管道进行加压。团队可以简单的问自己一个问题：“能不能一天部署10次？”如果没有办法？那么原因何在？流程不规范？自动化不够？沟通导致效率低下？过程无法复用？环境差异导致回归出错？逐一的暴露问题，解决问题，交付能力自然提升。
需要注意的是，根据《凤凰项目》中提到的TOC约束理论（Theory of Constraints），在瓶颈之外的任何地方做出的改进都是假象，在瓶颈之后做的任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来，而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。所以如何识别真正的瓶颈变得尤为重要，在发现问题之后多问几个为什么，力求找到根源原因。
3、DevOps落地三步工作法
目前行业中通常采用三步工作法以实现DevOps：
第一工作法：建立从开发到IT运维的快速工作流，支持DevOps从左向右的快速流动。
通过工作可视化，限制在制品数量，并注入一系列的工程实践，加速从开发到运营的流动过程，实现低风险的发布；
从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化，需要小的批量规模和工作间隔，绝不让缺陷流向下游工作重心，并且不断为了整体目标（相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标）进行优化。
从左向右的流动即是DevOps从左向右的流动原则。也就是有效地把项目开发工作从开发侧到运维侧的稳定快速流动，减少从需求到用户获得新产品真正体验的前置时间(Lead Time)。
在快速流程的同时也需考虑不要因为软件的快速交付导致产品的质量问题或品质的不稳定，更不能因为快速的交付导致生产环境不正常和客户服务的中断。
即产品交付过程中的内建质量(Build In Quality), 通过DevOps工具链打造的持续部署流水线是这种内在的质量基本保障。
必要的做法是：看板、持续构建、集成以及部署，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。
第二工作法：建立快速反馈环路，从而在源头解决质量问题。
建立快速反馈能力，使问题第一时间暴露，用户和运营数据第一时间展示，从而提升组织的响应能力；
价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防治问题再次发生，或者更快的发现和修复问题。这样我们就能在所需支出获取或潜入知识，从源头上保证质量。即时的反馈机制的建立可以从源头上保证软件研发的的质量，尽早发现和修复问题。反馈在生产环境还表现为自动化的运维监控。
必要的做法是：
在部署管道中的构建和测试失败时“停止生产线”。
日复一日的持续改进日常工作。
创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态。
在开发和IT运维之间建立共同的目标和共同解决问题的机制。
建立普遍的产品遥测技术，让每个人都知道，代码和环境是否在按照设定运行，以及是否达到了客户的目标。
第三工作法：建立组织文化，支持持续学习与试验，既鼓励探索，从失败中吸取教训，又能理解反复的时间是精通工作的先决条件。
通过团队激励学习分享，将持续改进注入日常工作，使组织不断进步。
DevOps的落地实施是一个全新的文化锻造的实践，而文化的打造不是一朝一夕可以完成的，需要做到不断的自我迭代。不断尝试可能触发组织改进的实践，并勇于承担失败的风险，并从成功和失败中吸取经验教训。
DevOps需要打造不同团队能够逐步实现价值交付的共同目标上来，持续让开发、测试和运维团队紧密合作，久而久之就形成了稳固的DevOps团队。
DevOps的持续学习和改进的工作要求是打造学习型组织的关键。DevOps的持续不断的反馈和可视化管理实现了组织内部不同部门的高度信任和高效的跨部门合作。DevOps的从左到右的流动方法是打造持续交付能力的理论源泉。DevOps就是要实现从技术交付能力到行为方式的一次深刻的组织文化变革。
一个常见的陷阱是一味关注技术，而不是文化要素。开发运维注重各个技术和运营团队之间的信任和合作；工具和技术其实是为实现这个目标而服务的。
大多数技术团队认为，工具可以解决所有问题。虽然工具对开发运维转型来说绝对很重要，但是除非辅以实际而重大的文化变化，否则它们毫无帮助。认真考虑你的业务目标，考虑信任和沟通，考虑原因。只有搞清楚了如何开始文化转型，你才可以往技术解决方案投入时间和精力。
IDCF
