上两篇我们分析了在整个研发交付过程中所涉及到的研发、测试两个节点会遇到的影响整个研发交付流的问题，以及我们可以依据哪些方法论去相对地解决这些问题从而提升我们的效率。
这一篇我们继续分析我们的需求在进行正式交付的时候又会遇到会影响交付效率的问题，以及我们如何去弱化这些问题。
传统的稍有规模的企业对整个生产交付都会有很严格的流程，以我所经历的为例，会包含如下流程： 首先，在封版本之前，研发同学会走一个流程或者邮件告知运维同学某天晚上会进行升级，运维同学受到邮件之后，会要求研发同学提前提供当天升级所需要的包和脚本； 接着，升级当天运维同学会拿研发同学所提供的包和脚本进行升级操作，传统的升级方式都是以人工操作脚本的方式进行，这些脚本都会通过日常的积累进行模板化； 升级完成后，进行正式的通知。后期生产问题的处理，在一些企业，也会由运维同学统一报送，比如依赖ITIL机制以及系列问题报送平台，这个属于每个企业对运维方式以及SLA等指标的建立的理解，在此不作介绍。
我们看下传统的研发线到运维线会遇到哪些问题。 站在运维同学的立场上来分析，会出现如下的问题：
1、工作串行化以及被扰性比较严重
在升级的过程中，运维同学在走脚本的时候其实是不能去干其他事情的，因为要确保是否升级启动成功；如果在升级的过程中，某一个已经启动成功的机器有问题，运维同学肯定会被打扰，要去进行排查以及提供日志给研发线。
2、机器的多寡决定运维同学的工作量的多少
这个很好理解，因为传统的上线操作基本还是通过人工裸脚本的方式进行，所以机器越多，运维同学的工作量越大，所以在传统模式下，研发同学还是要多理解运维同学当天升级的压力。
3、上帝的归上帝，凯撒的归凯撒
这是什么意思呢？其实传统的研发交付模式下，因为研发和运维双方职责分明，所以如果在生产交付的过程中出现问题，运维同学需要及时将生产报错日志提供给研发线进行分析，那么一来一去，对效率的影响自然就免不了。 站在研发同学的立场上来看：
1、日志的获取速度较慢，影响问题解决
因为传统模式下系列与研发运维有关的基础平台建设的因素以及生产机器的安全保障，所以研发线生产日志的获取还是需要从运维同学这获取，有些时候可能会夜里要求运维同学拿取日志；
2、问题的解决还是以研发线为主
因为凯撒上帝的职责分工，所出现的问题其实还是研发同学去解决，所以往往研发同学自己也会觉得效率降低，但是又因为生产流程等因素短期很难改变。 所以，我一直觉得，传统研发交付模式下，研发线和运维线之间就像隔着个防火墙一样，就像如下图展示的这样：
我们可能会去思考，为什么研发线和运维线之间会有一个隐形的『防火墙』呢？我个人觉得有如下几个因素： ####1、生产环境。生产环境影响着公司的业务，必须用最严格的规范，最少的人参与，保障最高的安全； ####2、日志获取。因为生产环境和基础平台建设的原因，日志的获取暂时不得不通过人工的方式给到研发线； ####3、发布流程。不以规矩不能成方圆，适合当前研发现状的流程才是最好的流程。 所以，我们整体分析下来发现，生产机器的安全保障其实影响着方方面面。 但是，存在的就是合理的，因为一个企业流程机制的建立会由各种因素所决定，比如人的规模、研发能力、当时的技术水平等，所以我们对待传统的交付流程不仅要以一种肯定而非批判的态度，更要从传统的交付流程中挖掘出优点去补充指导DevOps的践行。
那我们如何去解决如上所出现的这些会影响整个研发交付效率的问题呢？ 我们先看下如何适当去解放运维同学的生产力。 我们知道，在生产交付的时候，运维同学最主要的一块工作在于应用包的获取、部署和启动，而且机器越多，工作量越大，所以我们可以去思考怎么去解放运维同学这部分的生产力。 那么我们就会去畅想能不能也通过『别人』这个途径去帮着解决呢？比如，我通过平台去统一进行包和脚本的管理，提供统一的发布工具进行应用的一键部署与启动运行。如下图所示：
这样我们就能去相对地释放运维同学的部分生产力，运维同学就会从传统的裸脚本进化到通过界面一键操作的方式，确实是一个进步。 然而我们还会发现一个问题，就是这个时期整个发布工作还是由运维同学去进行，并且研发同学还是要配合运维同学去进行生产的交付，但其实这个时期的生产资源对于研发同学来说已经产生了隔离。 所以，我把以上的流程定义为『一代运维同学生产力解放』。
那么怎么去设计二代的呢？ 在一代的时候，生产资源通过系列技术平台已经与研发和运维产生了隔离，那么我们就可以再去考虑，怎么解决应用在部署运行过程中所产生的效率问题。
我们可以在一代的基础上做如下几件事情： 将传统模式的下的人工上线流程通过技术的方式去定制化到平台中，将整个研发交付流所涉及的各个岗位角色贯穿到整个交付过程中，那么就可以实现一定的交付流程线上化。 同时，我们将传统的交付日志提供与查看方式通过系列工具进行统一并提供开发入口给到研发线，那么又进一步地解放了运维同学的生产力，削薄了研发和运维线之间的防火墙。 当然，还会涉及到很多资源管理，比如网络、裸机、虚拟机等，这个话题也比较大，我们留着后面再进行分析。 至此我们就会发现，传统模式下会影响交付效率的一些问题得到了一定的解决，所以我把它成为『二代研发和运维同学生产力解放』。
那么，到了二代就真的已经结束了吗？其实远远还没有……. 在整个的DevOps的践行过程中会涉及到企业IT全流程中每个节点的变更，而需求或者产品交付只是其实一个影响业务迭代的主流程，但还会有比如基础架构与设施、研发协作、产品迭代管理等各项内容，所以二代仅仅是一个部分的生产力解决，我也会在这10篇文章中不断地去涉及以及谈谈我的一些实践观点。 我们回到上一篇中所引入的程序员身上的三座隐形大山的问题，那么现在我们就可以去解决了。
我们可以将比如自动化测试、单元测试覆盖率检测、代码质量检测三个节点定制到交付流程中，通过灵活的阈值设定去相对地减轻三座大山的重力。不过这里还是要说下，这里并不会彻底解决，只是相对地减轻以及提供质量保障，正如我们上篇也聊过，比如检测下来的技术债务、单元测试覆盖率的提升其实也是会影响研发交付效率的，所以这块还是要根据每个企业的现状去进行定义。
至此，我们就完成了这一篇所要讨论的内容，也有了一个初步的新的研发交付体系，但是我们还会碰到哪些会影响整个流的问题呢？我们下一篇再继续探讨。
—————–EOF——————