其实说起devops，大家应该都不陌生，devops也已经从很多年前的概念中，走进了我们的日常工作中，但是有些时候还是会觉得目前虽然devops体系已经成熟落地，但是依旧会觉得目前已经落地的devops依然有很大的前景。所以在这里也希望和大家分享和探讨，也写一写关于个人对devops的理解和落地的设想。

1、Devops来源

     说起devops的来源，那就不能不提两个重要的开发模型——瀑布模型、敏捷开发

1.1 瀑布模型

     说起瀑布模型，大家应该都不陌生，瀑布模型是软件开发中最早出现的模型之一，整个软件开发流程严格遵循需求、设计、开发、测试、部署、维护几个阶段。在这个流程中，需要等上 一个阶段工作完成后，才会进行下个阶段的工作。就像是瀑布流水一样，因此得名瀑布模型。如下图所示：

        瀑布式开发模式流行于20世纪70年代，是由软件开发大师温斯顿·罗伊斯（Winston Royce）最初提出的软件开发模型，作为最早出现的软件开发模型，它在软件工程中占有重要的地位。

        当然，随着软件行业和互联网行业的快速发展，瀑布模型的的局限性就很明显的展现出来了。因为瀑布模型前一阶段的输出是下一阶段的输入，所以当进行一次软件更新、软件迭代时时间的周期会变的非常长，瀑布模型就会显得尤为笨重，而后一阶段如果出现问题，就会需要回到上一阶段进行修改，这样即使已经进入到了下一阶段，那么上一阶段乃至初始阶段的人员已久不能释放。而且，瀑布模型的周期很长，软件的一次迭代或一次更新可能需要一个月、几个月甚至时间更长。当软件上线后，可能上线的业务功能已经不能符合当前的市场需要了，这不仅仅是对人力资源的浪费，也会严重影响企业的发展进程。此时，大家也已经意识到，瀑布模型已经不能满足大家的需求，一种新的模型诞生了——敏捷开发。

1.2 敏捷开发

        其实敏捷开发并不难，敏捷开发是将瀑布模型中一个大的需求不断拆解，分解成一个个可交付的小目标。之后进行不断的迭代，在一定程度上节约了资源。敏捷开发如下图所示：

        虽然敏捷开发补充了瀑布模型的不足，但是敏捷开发的覆盖范围也仅仅是开发和测试阶段。并不涵盖运维，部署。因此运维部门并没有在这其中得到受益，运维与开发还是会出现互相指责的情况。为化解这个矛盾，就出现了DevOps。

1.3 Devops

        DevOps与敏捷开发最大的不同点就在于，对软件进行多次、频繁的部署来避免软件部署难的问题。DevOps的提出，最开始也确实是为了打破开发和运维之间的对立和隔阂。我们用一张图来对比一下瀑布模型、敏捷开发和Devops。

        DevOps完善了敏捷开发存在的短板，实现了真正的软件交付全流程闭环。在 DevOps 的模式下，开发和运维都不再是“孤立”的团队，两者会在软件的整个生命周期内相互协作，并在工作中得到紧密地配合。而由此带来的效益，则是更加高效的服务交付和质量。Devops流程如下图所示：

2、Devops概念

        Devops是一个结合了开发（Development）和运营（Operations）概念的术语，旨在促进软件开发、技术运营和质量保证（QA）部门之间的沟通、协作和整合。

        Devops强调软件开发人员（Dev）和IT运维技术人员（Ops）之间的合作文化、运动或惯例，其核心实践包括自动化软件交付和基础设施变更流程，以实现软件构建、测试和发布的快速、频繁和可靠，这种整合有助于提高软件质量和可靠性，缩短软件开发和部署周期，并提高组织对市场变化和客户需求的响应速度。

        DevOps还涉及到持续开发、持续测试、持续集成、持续部署和持续监控等多个方面的软件开发方法，它不仅仅是一组工具或平台，而是一种组织文化和运营方式，旨在提高效率和质量，同时减少开发周期中的延迟和障碍。

3、Devops现状

        其实现在已经存在很多很成熟的Devops的平台了。功能也很完备，例如获取git地址，代码扫描，代码编译，打包，制品发送，制品部署等功能。功能已经逐渐完备。对于上线的代码也有了很成熟的监控工具。有以软件形式进行监听的，也有以网络形式进行抓包的。似乎Devops已经被我们诠释的很好了。好像这就是Devops落地，也似乎这就是Devops的全部了。但是总觉得Devops好像被诠释的还不够。

4、Devops的理解

       这里简单的和大家交流一下个人对Devops的一些理解吧。虽然Devops再强调研发和运维的沟通，在强调开发周期的缩减，在减少上线的风险。看似好像Devops的主旨很多，例如持续集成、持续交付等等。但是个人认为Devops的主旨应该只有一个，那就是实际的拉近研发和运维的距离。当然这个距离不应该仅仅局限于人的距离。可以是环境的距离，压力的距离，数据的距离，思想的距离，能力的距离，结果的距离等等。下一节，我会详细讲述一下我对Devops的几种看法。

5、Devops的设想和落地

5.1 Devops的设想

5.1.1 看山是山，看水是水

        起初看Devops，一直都觉得Devops就应该是Dev和Ops，是研发即运维，运维即研发。所以Devops应该是对人的观念。将研发变成运维，或者将运维变成研发。所以Devops的理念应为是围绕着人去阐述的。运维和研发应该具有相同的权限，相同的能力，相同的思想，相同的。。。所以，在最起初接触Devops时，认为Devops应该是对人的要求，即使存在CI/CD，那么对开发和运维的要求也是必不可少的。

5.1.2 看山不是山，看水不是水

        在学习了Devops一段时间后，在使用了Devops的平台一段时间后，渐渐的对Devops也有了一定的改观。认为平台就已经诠释了Devops，但是在平台的功能中诠释的Devops好像又和Devops的理念有些出入，例如代码上传，代码扫描，代码编译，代码制品，代码上传制品库，仿佛好像都是研发测同事的工作，而制品出库、制品部署好像都是运维测同事的工作。所以Devops的理念，在这个平台上到底是如何体现的呢？若没有完整的Devops体现，为何称为Devops平台呢？

5.1.3 看山还是山，看水还是水

        其实这个问题一直困扰着我，Devops究竟应该是什么样子？直到有一天，听到了好朋友在和我诉说他的工作。又一次的思考起了这个问题。Devops应该是一个方法论，一个中心主题，而不是一种固定的做法。Devops的中心思想上面也提到了，其中涵盖了研发、运维、质量等等。其实如果缩减、涵盖的应该就只是研发和运维。研发是运维的基础、运维是研发的反馈。因果关系。所以他才叫Devops。但是如果要实现Devops，就必须拉近研发与运维的距离。这个上面也提到过。但是如何拉进研发和运维的距离呢？当然不是让研发去做运维，让运维去做研发。当然也不是让运维和研发具备相同的能力，相同的水平。那是什么？应该是运维关注什么，研发关注什么。研发怎么做，运维怎么做。实际上不是拉近人和人之间的距离。而是拉近研发和运维处理事情的方式和方法。以达到研发即运维，运维即研发。来实现Devops。

        以上是阐述了想法，可能相对比较模糊，那么在这里可以举例说明一下！我们先从技术层面举例，再从业务层面举例。

技术层面：

1、软件环境的距离：

（1）操作系统环境，这里包含环境和版本，例如用的是windows还是Linux，用的是是不是一个版本，不是一个版本，大版本是否相同，大版本不相同是否和生产的大版本功能相近。

（2）技术中间件的问题，生产与研发环境是否是一个中间件？安装方式是否相同？版本是否相同？配置文件是否相同？等等。

（3）技术语言的问题

（4）持久化的问题，也就是数据库的问题

2、数据的问题：

（1）数据量级的问题，生产的测试环境，研发环境的数据量级是否相同？是否可以按比例即性能贴近量级。

（2）数据意识形态的问题，生产和研发的数据是否完全一致，若不一致，是否可以将数据意识形态变成一致？

技术层面这里就简单的举个例子，不做过多的探讨，因为大家也都比小编厉害很多。

业务层面：

相对于业务层面，可能关注的就会多一些，比如，生产上已经存在明显的业务报错信息，那么运维人员应该如何处理呢？上面其实已经给出答案了，研发怎么做，运维怎么做。简单而言就是把研发阶段的事情平移到生产上，运维不要凭经验查询，而是跟着研发查询。

5.2 Devops设想的落地

        下面我们聊一聊落地，因为研发的日常工作不仅仅有研发，还有配合测试查询问题，解决问题，进行研发后的第一次功能测试等。我们此次先对查询问题，解决问题进行一次讨论。

        假设生产中出现了一种场景，业务提示相对模糊，我们用网购为例，报错订单信息不存在，此处可能会有两个原因，第一代码缺陷，第二业务未成功。我相信在此功能上线之前，研发应该已经配合测试无数次的查询过这个报错的具体原因。也已经有了成熟的解决方案和查询方案。那么研发是否可以将此步骤和方案封装呢？封装后将此方案给到运维同事，在生产上出现此问题时，可以有成熟的方案和操作呢？（当然这里写的方案为自动化方案）。还是刚刚的报错，我们可以列举一下可能性：

（1）由于代码缺陷导致，为生成订单信息或未更新订单信息，但是客户已经扣款成功。

（2）业务实际未成功，但是客户钱款已经扣除，由于第三方原因，钱未及时回到客户账上

（3）业务实际未成功，客户钱款也为扣除，只是客户误以为钱款已扣除

我们是不是可以根据列举出的可能性，对这一个业务进行问题查询，推演的封装来是的运维和研发同事查询问题的根及过程是相同的，从而获得同样的效果。

        相反的，上述描述没有说运维的关注，运维的同事也应该将自己关注的指标，例如系统tps，业务大面积异常等现象及时向研发反馈。当然最好的运维模式应该是预防，而不是出现了反馈，那么运维可不可以在问题还没出现前，通过观察表层现象及指标的波动及时识别风险和研发进行交流共沟通来避免风险的发生呢？当然，这里也应该减轻人工的工作，将此工作列入自动化范畴。

        当然这里仅仅阐述了Devops对于运维和研发之间的关系的落地，Devops在发展过程中，DevOps 也成为一种文化，一种运动，一种实践，凡是有益于软件交付的思想和方法，好像都可以被DevOps吸收，DevOps不再只是敏捷开发的延伸，而是以C（文化）、A（自动化）、L（精益）、M（度量）、S（共享）为原则，旨在提高软件交付效能、团队效能，改善组织效能的重要方法和实践。

         中国信通院也起草了《研发运营一体化（DevOps）成熟度模型》[10]，标准中对DevOps的总体架构描述如下图所示：

        标准中，把DevOps过程分为敏捷开发、持续交付、技术运营三大模块，覆盖软件交付的方方面面，这也很好地证明了当前DevOps覆盖范围相当全面和广泛。

        所以在Devops的运作上是需要有由运营研发组成的领导团队，需要有运营研发组成的支撑团队，领导团队需要总体把握从需求到反馈的整体流程，而支撑团队，包含需求，测试，研发，运维等人员，需按模块划分团队，每个团队负责一个模块的整体流程，由领导团队决策每个团队的运营流程。当然团队里的每个成员应该各司其职，完成团队的工作，使各个节点形成闭环，以达到反馈后调节，调节后优化的∞的Devops。

        所以，长此以往，才能是Devops的概念图，团队的距离才能被拉近。也才能真正达到Devops。