3.2.2　开发能力差距分析

回到2018年，我们从整个研发生期来看自如当时的研发生产过程，如图3-3所示。

图3-3　研发过程图

·需求阶段：需求的管理曾经是杂乱无章的，需求由业务方录入Jira，但是对于业务人员而言，Jira的使用略微复杂，进而造成Jira上的数据正确率很低，往往没有完整的需求池。

·产品阶段：产品设计阶段一般作为对接开发的直接上层阶段，会有多轮的PRD（Product Requirement Document，产品需求文档）评审，梳理清楚产品需求，产品评审通过，测试工程师进行测试用例的编写，开发工程师进入架构设计阶段。这个环节当时并没有统一的工具和平台进行管理。

·开发阶段：开发阶段是整个需求交付生命周期中最长也是最重要的环节，这个阶段开发工程师会申请代码环境、机器资源（域名、服务器地址、数据库地址、中间件信息等）、权限，然后进行编码开发。这里与运维工程师的交互较多。

·测试阶段：开发完毕后会进入第二个重要阶段——测试阶段。这个阶段会进行多轮Bug修复与重新提测。通过测试环境验证后，还有一个准生产环境，开发工程师会手动合并代码到主干并进入待发布状态，准生产环境的代码对应主干的代码。很显然，这个过程极易造成手工错误。

·发布阶段：发布阶段会进入生产环境，进入生产环境阶段前需要测试工程师进行签发，签发后运维工程师操作工具从GitLab的主干分支拉取代码到打包机进行编译，打包机编译后的代码由SVN管理，生产环境再从SVN拉取class文件并重启发布。

从现在的视角来看，图3-3的发布和部署过程中的“低效点”非常多，我们来分析几个典型的差距。

·需求产品管理混乱：没有统一的工具和流程进行标准化的BRD、PRD管理，导致上游需求可能非常易变和不透明。

·人工交互过多，自动化程度低：申请资源、申请权限、提测、签发都要有人工交互，上线发布的过程更多地转移到了线下，效率不高，沟通成本很大。同时，代码的合并、资源的配置都是线下开发工程师手工操作，出问题的概率极大。

·工具薄弱：分支管理、环境管理混乱，GitLab和SVN两种代码协同工具并存，定位不清，流程冗长，导致运维成本急剧上升。

·系统脆弱性大：整个交付链路过长，环节层层相扣，一旦出现一个脆弱环节，就很容易导致整个流程阻滞。

系统和流程层面的问题其实都是冰山上面可见的部分，冰山底下的差距是人的差距。人的差距反映在两个层面：能力和思维。

（1）员工能力层面

大部分开发人员都只聚焦于业务开发，虽然对常用的开发技术栈很熟悉，但是对于技术背后的原理探索甚少，对于底层用到的基础设施和技术平台背后的知识接触得就更少了。有些工程师对于DNS（Domain Name System，域名系统）、Nginx毫无经验，甚至有些开发人员连Host都不会配置。

开发人员能力不足主要有两方面的原因：一是接触的场景太少，以JVM知识为例，我们面试时经常会问底层的垃圾回收算法、内存的分代、垃圾收集器、常用的定位JVM问题的命令等，但是实际上，在生产环境中能够接触这些场景，真正定位问题的机会极其稀少；二是主动性不足，一个开发工程师能力的高低，很大程度上取决于他愿不愿意去提升自己的能力。意愿和态度比能力现状更重要，这也是我们要讲的第二个层面——思维。

（2）员工思维层面

无论是开发工程师、测试工程师还是运维工程师，岗位名称有时候限制了大家的思维方式，思维方式被限制之后，对应的行动就会有所制约。开发工程师会把与服务器操作的工作留给运维工程师，运维工程师会把开发的工作留给开发工程师，双方分工明确。相反，如果我们的思维是成长性思维，是积极主动的，当我们搞不明白CDN和DNS的区别时，就会去查域名解析后的完整交互路径。大公司一般都有成熟的技术论坛、线上学习资源，但是一个只知道做业务的员工和一个不给自己设限的员工两者之间的差异是巨大的。

自如当时的研发团队和运维团队也是同样的情况，各人自扫门前雪，对于边界不清晰的工作，往往会有说不清、扯皮多的问题。开发工程师和运维工程师的能力水平与二线互联网公司也有巨大的差距，运维工作尤甚，大家还是以比较传统的手工运维为主，加班成为常态，整个团队疲于应对各种低端、重复的故障。

基于以上几个问题的剖析，我们开始重设方向，决心打造DevOps体系，帮助自如的产品研发流程走向一个新的阶段。如何改变这些差距呢，我分析了研发效能的效率飞轮，如图3-4所示。

图3-4　效率飞轮图

研发（运维）人员能力变强，才能构建更加成熟、健壮的工具和平台；工具和平台更加健壮，能够大大提升研发人员响应问题、处理问题的效率；快速处理完问题，能够使研发人员有更多的时间去学习和迭代新的技能。研发人员的能力越来越强，整个研发组织的效率会螺旋式上升，这样研发效能的效率飞轮就飞速转了起来。