前面几个章节重点讲述了CICD以及应用上线后我们如何去保证应用的生产问题及时响应度等方面，基本上涵盖了DevOps的绝大部分内容，这些内容也或多或少能过解决IT整个研发交付流中的一些痛点。所以我们在日常的研发交付过程中，可以多去思考在团队中，哪些因素或者节点是真正地影响我们研发交付效率的，然后对这些节点做改善，所以DevOps不光是一个大家都能看到的有形的平台或者系统，其实也是一种指导团队进行研发交付流程的方法论。
另外，结合研发交付传统的各个场景后，我们又通过解决相关领域特定问题的开源产品进一步代入如果实现一个简单的研发交付流可以怎么进行。当然，正常规模稍微大点的企业也会组织相关的研发团队，研究系列领域的开源产品从而落地DevOps，对于规模比较小的公司可以在节省成本提高落地可能性的时候多使用成熟的开源产品，后期再根据自己团队的使用情况逐步去优化迭代。
接下来两篇内容我准备和大家一起来讨论一些比较分散的话题，而这些话题其实也是在落地DevOps的时候可以去进一步思考的问题。
首先，我们来看一下研发效能。 研发效能是近段时间比较火的一块内容，它指导着我们如何深入到研发同学的研发过程，通过一些方法去提升整体的研发速度，为研发线赋能。 我们先看一下传统的研发模式。 我先举一个我经历过的例子。我们知道在实施一个项目的时候，有一个重要的节点就是架构设计，架构设计中就会需要团队去考虑比如使用什么样的技术栈、依赖哪些组件，设计完了之后我们可能需要去对组内的研发同学做技术上的培训，同时架构师也会先去搭一个初步的项目模子。后面假如再有一个项目，架构师不同的话所采用的技术栈等又都不一样。正所谓一千个堵着就有一千个哈姆雷特，同样，一千个架构师也会有一千个技术架构。我们来看下这种方式会有哪些问题。
第一，筒仓效应
我个人觉得此种方式还是传统的瀑布流的研发模式，因为每个团队所负责的业务不同，技术负责人也不同，同时团队与团队之间并没有充分的互动，所以逐步产生筒仓效应，产生筒仓效应的结果就是，各个团队各自建各的，很有可能某两个团队之间有很多可以复用的资源，但是可能就是因为未在顶层去做考虑，所以降低了企业资源的重复利用率。
第二，能力递减
也正是因为形成了大大小小的独立的筒仓，所以企业中的项目的技术形态也是五花八门，走的稍微激进点的，可能会去尝试使用一些目前行业中主流的技术；稍微保守点的或者因为目前单体形态臃肿硕大而暂时无法优化的，可能还是停留在很多年前的架构。所以我经常听到一些研发同学抱怨手头的工作没有积极性，很多技术还是很多年之前的，而目前行业中对于研发同学所掌握的技能要求越来也高。所以如果拿整个行业来对比的话，抱怨的这些同学的能力其实是递减的。
第三，整合困难
突然有一天企业里面需要做一定的资源、系统整合，这个时候发现系统形态和技术形态都是五花八门，可能每个团队所使用的接口形态都不一样。比如有些团队是restful的接口，有些是webservice，还有些是RPC的，所以这就带来的整合的苦难，之前比较火的ESB和SOA其实就是一定程度上解决这些问题。所以我个人觉得此种局面的出现其实就是因为传统研发模式的筒仓化所造成的。 所以，近几年的企业应用微服务化其实有个前提就是能够先做技术栈的统一。 技术栈的统一的好处其实就是解决如上所陈述的系类出现的历史问题。那到底如何才能做到技术栈统一呢？ 解决方式我觉得也是因人而已。如下是我个人的一些观点。 首先，达成技术栈统一是一项全员的工作，而并不是某个团队去驱动的，就是所有研发团队需要有一项基本的认识，本质就是认知的问题； 有了上面统一的认知后，架构师就需要去落地一些统一的技术栈，而这些技术栈肯定是需要充分评估企业内各个团队的研发能力、系统规模和现状以及技术栈后期的运维难度等。近几年其实有很多峰会去介绍一些最佳实战，但是我个人觉得那些最佳实战只能做参考，而不能做全面引用，因为每个公司的情况都不一样，一块技术的投入，是受限于当前企业的资源分配、场景切合度、内部研发能力以及技术投入的可持续性等。另外，统一的技术栈其实也是让各个业务条线研发能够专注于业务的迭代，而减少花太多的时间去调研各项技术； 有了落地的技术栈之后，企业的新应用就可以开始去使用，老的应用就可以去接入或者改造。但是，我们发现其实远远不会那么顺利，虽然统一了技术栈，但是随着人员的变更、技术栈的活跃度、团队之间的活动不足等因素，有些时候还会走偏了。
所以，我就想到了研发效能 。 那什么是研发效能呢？我个人觉得研发效能的思考逻辑就是怎么去思考一个应用的生命周期的问题，而这个生命周期会包括一个应用从代码创建、项目结构生成的这些细节到应用的生产运行治理以及一直到最终的应用的下线消亡，而在这其中会衍生出很多规范、基于规范的工具和脚手架以及乃至平台等，这些衍生出的内容其实都是来保障研发效能的提升。而这些内容我个人觉得也是DevOps乃至企业数字化转型落地的一个关键步骤，对于数字化转型如果单纯只是认为是应用系统或者数据层面转型，我个人觉得理解就有点片面了。 前段时间和国内一家技术型公司交流技术架构，里面对这块双方是有歧义以及是否必要性的争论。后来我思考了一下，真实原因还是双方工作经历的影响。成千上万的企业就会有成千上万的商业运转模式和组织架构模式，所以适合当前企业的才是最合理的。
另外一点，就是花小的篇幅来谈一下DevOps对IT基础架构的影响的个人观点。
前面我们所介绍的内容其实都是偏向于产品线、测试线、研发线和运维线。但是支撑着IT各个应用运转的最重要的一块，也称为衣食父母的一块，其实就是IT基础架构。 IT基础架构其实所包括的内容也非常的多，比如就以自建IDC来说，比如主机服务器的管理、网络的管理、数据库的管理、设施安全管控等等，基本上包括了整个IT的网路流量从外到内的整个管控，所以重要性不言而喻。 那为什么说DevOps对这块也会有影响呢？ 其实这就是一个反向激励的过程，总体来说就是应用层面的敏捷所引起的底层资源的升级。这里我就举两个小的例子。 比如我们申请一个主机用于应用运行，以前往往我们都需要去开单到基础架构团队，基础架构团队评估后会给予我们设施，这样带来的一个问题其实就是效率的下降，与DevOps所推行的敏捷是违背的； 另外，比如我们以前应用系统上线的时候如果涉及到很多的数据库脚本，往往都会提供给DBA，DBA做一个审核后去执行，有些时候DBA有空的话，也会帮忙去审核一下脚本中是否有性能问题； 再比如一个应用上生产的话总会要进行安全的扫描，当然以前的扫描都是人工的，扫描后才会告知产线应用是否能正常上线，而且这个扫描正常都是新系统上线或者年中巡检才会进行； ……
那怎么解决这些问题呢？所以近几年针对于IT基础设施这一块其实也有很多基于DevOps的理念所提供的一些方案，更甚者，基于安全这一块，更提出了DevSecOps的概念；对于主机资源更优的管理，社区中也衍生出很多优秀的方案和产品，比如基于Docker的生态、K8S的生态；比如之前看到互联网公司所推出的一些sql审核的开源平台；比如针对于web安全的Arachini等。这些产品其实都可以融合到整个研发交付流程中，从而进一步解放基础架构这块的生产力。
所以，其实我们可以看到，DevOps是IT中涉及方方面面的事情，而不仅仅只是一个发布平台的问题。那这几年谈的比较火的企业数字化转型，DevOps也仅仅是这个转型进程中的一个关键节点而已。
至此，这一篇所要讨论的内容就结束了。 下一篇是这个专栏的最后一篇，我们再继续讨论下DevOps中的其他一些比较碎片的内容。
—————–EOF——————