视频访谈： 付钱拉郭江林：自动化只能解决90%的问题，剩下的10%要靠沟通

• 下载
• Android app

郭江林： 付钱拉是八立方科技北京公司旗下的一个品牌，是致力于金融科技的服务提供商。现在最主要的核心产品是聚合支付、帐户管理、供应链金融等一系列的金融云解决方案。

3. 您现在在付钱拉主要负责的工作内容请介绍一下。

郭江林： 我在付钱拉主要是负责整个生产到测试以及开发环境的运维，以及自动化的实现，和后来金融的AIops的研究实现落地。

郭江林： 2015年12月付钱拉以支付为切入点，进入了业务的发展期；16年3月转型秒收产品上线；17年9月转型科技服务，有了帐户体系的金融服务。我认为这三个点是比较具有标志性的，因为我们从切入到转型秒收再到转身成为金融云科技服务商。

郭江林： 这个过程中最大的痛点就是改变。之前的传统的团队可能已经运行了N多年的规范，或者说一个团队的习惯，去改变它的习惯是很痛苦的。那我们怎么去解决这个痛点？最好的解决办法就是让团队感觉到这个变化是可以让他们更加便利的，那我们就做好自己的专业，然后用自动化也好，用行动来说话，让各个团队去感知变化，感觉到落地的好处。

郭江林： 比如我们的构建到上线的流程，这个流程其实之前特别曲折，需要分好几个节点去做这个事情。我们采取的方法是，从构建到打包，到镜像打包，到Push到线上，把整个过程用API的方式列出来，拿状态来确认下游的下一步操作是怎么样的一个操作。这个过程做完以后，开发就能感觉到便利和快捷，从而和我们可以展开构建和部署的协作。DevOps也是一样的，是团队的紧密协作这样一个思想在里边。

郭江林： 在每个企业都会有这样的感觉，运维和开发确实关系特别的奇怪，付钱拉也不例外，同样也会遇到这样的问题。比如说我们有一个订单Bug的上线，在上线过程中，提交到运维部署这个过程很快就已经构建上线了，但是上线以后，开发人员发现他提交的代码文件，配置文件是有问题的，因为他可能get到的是一个测试环境，这样交易就会发生问题，那么他就给我们发起了回退指令，然后运维的同事进行回退，但回退的过程中，备份的脚本有问题，可能备份的文件不存在，这时候就只能手动去get一个老版本，这就延长了回退的时间，这可能已经在线上对数百笔订单造成了影响。这件事情上我们可以分析一下，从开发由于做事情不严谨，导致配置文件出错，再到运维回退，触发了自己的备份脚本，又出现了备份失败的问题，整个过程是这样的。那么我想说的是，这个锅谁来背？其实只要记住每个轨迹就可以了，这个锅是谁的，谁自然会去捡起来，自己背上自己的锅。我们需要做的事情是把自己的事情做专业，我相信这样的话，其实也就没有所谓的锅了。

郭江林： DevOps的落地是在互联网业务快速发展的情况下产生的，因为这时候大家对于是否可以按时交付软件都比较在意，就需要各部门紧密的协作，从而产生了DevOps的思想。没有DevOps思想的话，传统的软件构建可能是各部门之间，你干你的，我干我的，到最后上线，不会跨部门深入协作。DevOps是一个方法，是流程实现的新思路，重新定义了怎么去协作，我认为它是一个新包装，因为整个团队的协作原来其实是固化在某个部门的。

9. 请您具体谈谈您是如何在付钱拉落地DevOps的。

郭江林： 付钱拉落地DevOps有几点：第一是我们先去做了一些分析，我们首先要分析DevOps思想是什么样的，主要就是协作，紧密协作，甚至是跨部门深入的协作，但不是融合，只是一种能力的深入输出，我们研究调查完以后，就可以去实施了，首先是挨个部门沟通和协作，我们应该怎么把整个交付链接起来，怎么把整个软件交付做得更快速。所以说Devops的落地不是一个纯技术问题，而是一个沟通的问题，是一个协作的问题。

郭江林： CICD的落地确实是不容易，因为持续集成的每一个阶段、每一个节点都有状态，我们要怎么去判断这个状态，然后去走它的下游。我们在这个过程中也踩了一些坑，我们最早的时候，代码提交上去以后会有标识，然后会触发一个静态的测试，静态测试以后会返回一个状态，再去调用构建的过程，构建以后到测试环境进行测试，测试的过程中会生成测试报告，测试报告的状态很重要，这个状态反馈了接下来你是否可以去部署，还有要部署的环境是什么样的，这个Tag一定要打好。在这个过程中最大的问题就是状态欺骗，也就说一个不真实的状态会导致不真实的测试，而不真实的测试又会导致不真实的部署，那最后部署可能是中断或者是无效的，或者是到线上会出问题的交付。所以我们最大的痛点就是状态的欺骗。

11. 那自动化运维有踩过什么坑吗？

郭江林： 自动化运维还好，因为自动化运维是自己团队的实现，没有太多跨部门的东西，它的实现痛点就是能不能实现多维度的数据收集。多维度的数据收集关系到最后是否能实现自动化运维。如果我们能够收集到多维度数据，比如说磁盘信息、流量信息，还有交易的信息，能够多纬度地把这些数据都收集起来，进而分析或者计算某个资源是不是要扩容，是不是要缩容，那就可以实现自动化运维了。所以自动化运维最重要的就是数据收集，而且必须是多维度的数据收集。

郭江林： 多维度收集，我们采取的是从硬件层、OS层到软件层，再深入到业务的交易日志层，还有查询数据库层，我们在这几层上都做了一个类似Agent的采集器，采集器将数据收集到我们的核心系统以后，再进行数据的清洗，数据清洗以后将我们需要的数据用筛选器进行分析。大致实现是这么实现的。

郭江林： 我把容器的镜像分为三层，分别是OS镜像、基础镜像和应用镜像，那么分这三层有什么意义呢？这主要涉及到环境的打包，这样可以把所需要的环境从OS层的配置标准，到所需的基础应用层，比如我需要的基础应用包，JDK、Tomcat、Web容器等，都在你打包的时候固定化了，就是直接可用的，同时再加上应用层，这就是一个完整的依赖环境。容器可以将整个依赖全部打包，这是第一。第二就是资源强隔离，资源强隔离能够在一个物理机上跑N多的容器，从而充分利用资源，有多少用多少，需要多少用多少。而不是说，拿着资源却不用。如果是虚拟机，可能分多少就是多少，即使不用也还是放在虚拟机里边的，其他人也占用不了，但容器就可以标配，用多少就是多少，不用的可以释放。

郭江林： 金融云服务其实最好的办法就是跳出自己的部门，你站在服务之上去考 虑这个问题。站在服务之上考虑这个问题，就会去分析服务经历了哪些阶段，从开发到构建、到部署，再到提供给客户使用，这整个过程经历了哪些部门，那我们就可以去看这些部门都在干什么，把整个体系给链起来，有状态有轨迹地去进行生命周期的管理。

郭江林： 首先肯定会有一个比较初级的阶段，然后是整合阶段，到最后还有交付阶段。第一个阶段可能每个企业都会经历，就是企业刚刚开始快速发展，这个阶段企业的生命周期是一站式的，非常简单。可能做完就上线，因为应用很少，不需要做很庞大的一个管理系统去进行管理，总共就两个应用，不可能写一个平台去做这两个应用的生命周期管理，这是初级阶段。第二个阶段其实就是融合，这时候应用服务已经很多了，公司的业务也已经很大了，那这时候就需要生命周期管理了，因为数量一多，单个管就管不过来了，而且也不容易看出生命周期哪个阶段需要进行优化。这时候就需要去进行各部门能力的聚合。

郭江林： 我觉得提升组织的效能，90%是自动化可以解决的，但是自动化只能解决90%，剩下的10%还是源于协作。如果整个部门是隔离的，那效率就会很低，因为整个流程走下来，需要找各部门谈判，以前传统的部门和部门之间隔阂比较大，会有一些争执，所以每次可能需要耗费几天甚至一周时间，第二周还要大领导再开会撮合一下，你们再相互去融合和解决问题。所以我觉得最重要的一个是沟通，另一个是自动化。

InfoQ： 我的采访问题就到这里，非常感谢老师接受我们采访。