好买基金DevOps实践的痛和快

于济萌

作者 | 叶赫华
编辑 | 济萌

作者简介

叶赫华（原名：张振兴）
好买财富股份有限公司 质量总监

从2000年初进入IT行业以来，长期从事软件开发、测试服务、质量管理、过程改进、敏捷教练等，先后服务于IBM CSDL、51testing从事专职培训师、美国B2B电商公司从事测试架构师、英国金融IT公司从事研发运营经理；目前为好买财富股份有限公司质量管理部总监，负责公司互联网测试体系建设、平台化设计与质量过程改进，并主导公司研发中心的敏捷化、DevOps的探索与实践工作。

序言

实施DevOps有什么前提条件？大型分布式互联网系统从何处入手启用DevOps？互联网金融平台，本身测试就复杂度大，究竟如何迎合快速交付的要求？企业要不要做自研的DevOps平台？人员紧张、经验有限的团队如何持续锻造战斗力？文化，一个绕不开的话题，对IT技术革新有哪些影响？

本文的五个部分：

1. Devops对Fintech公司的价值；
2. 选着Devops是否是一条不归路；
3. 好买实践Devops的阵痛与成就；
4. 好买对Devops平台的未来构想；
5. 总结：解放思想 实事求是；

(一)Devops对Fintech公司的价值；

我们好买基金是一个典型的互联网金融公司。可能有同行朋友不了解，好买是卖基金的，但是好买基金不是基金公司，属于第三方销售基金的公司，目前在公募私募领域，我们对接了全部的基金产品，只要市场上有的，我们就卖，总体销量基本上是全国第二名的样子。

现在大的市场行情不够好，因为基金对股票行情的依赖比较大，受行情波动比较大，所以我们一直说是互联网金融的冬天，大家都在过冬。好买财富是一家专注为个人提供专业理财服务的公司，腾讯和联想旗下的君联资本都是好买的战略股东。

1.1.互联网金融系统的特性

作为一个互联网金融公司（在上海基本上90%的科技公司都会有金融业务，或者跟金融相关），其实做金融产品的开发和测试是非常痛苦，总结出几条规律：金融系统业务流程非常复杂，不管是开发还是测试成本非常大。所以咱们日常招聘，或者跟同行交流的时候发现，比如你做纯粹电商的，或者其它消费类的，它的业务流可能非常简单，至多是半个小时、十分钟二十分钟可以把完整的业务流跑完。

但是金融系统就没这么简单了，比如刚才招行的美女也讲到，像银行系统涉及大量的跑批，金融系统就叫跑批，就是每天下午三点钟股市收市，日终要进行大量的批处理作业。我们要完成一个测试业务流可能要跑三个批，五个批，最多的时候到七个批，如果按照自然时间来说跑一个业务流要花七天。

当然实际情况会有技术手段处理没那么长。因此，做金融系统的测试实际上非常复杂，有大量的业务属性在。当然开发它、运营它也都是非常的复杂，系统结构也变得非常复杂。

好买现在的系统规模给大家看一下，我们公司600多人，跟前面嘉宾来自平安、谷歌、招行这些公司都比不了，我们的开发人员有100多人，我们做的东西是什么规模呢？8个产品线，50个子系统，280多个应用，800多个接口，光dubbo体系就800多个接口，加上其它的有1000多个接口，而我们只有130个IT技术人员，包括70多个开发，20来个测试人员，当然我这边还有配管，还有测试平台开发的，10来个人，加上运维，我们IT就这么多人。

但是我们的体系绝对在互联网金融圈已经做的非常到位的。为什么这么说？好买所有的IT系统全部都是自己研发的，可以说是唯一的，因为绝大多数基金公司、第三方公司的基金后台系统都是外购的，而好买130多个人研发并运营这么个东西，非常的庞大，非常的复杂，这也是一个典型的互联网金融系统的现状，只要咱们在座的各位测过金融体系，开发过金融系统的深有体会。

1.2.好买选着Devops的背景

好买选择DevOps的背景，其实我们自己在公司都不谈DevOps，就是一种自然而然的往这方面演进，为什么会演进？我上面罗列的现状，就是2016年三四季度的现状，需求变更多，各阶段均有不同程度的变更，开发、测试怨气很大。开发联调相当复杂，甚至存在虚假的测试结果。

开发提测后质量差，冒烟测试经常持续2到3天。这个稍微给大家解释一下，可能做非金融体系的人想象不到冒烟测试会花好几天，可能觉得一两个小时跑一个脚本就完了，但是金融体系不一样，我们真的需要几天。并行开发的分支多，我们最多的时候有20多个分支并行开发，非常的复杂。各系统交互频繁，版本合并质量差。配置项管理混乱，十几种风格。环境部署复杂度极大，时间也较长。测试对技术方案了解靠后，测试点存在盲目性。

然后产线也经常出事，开发紧急上线多，但只要解决了就好，大概是这种情况。玩互联网金融的都是和钱打交道，大家能理解我们这种东西是个高度敏感的产品。

举个例子，比如你预计明天股市会涨，然后想在今天3点之前下单买股票型基金，如果我们系统正好这时候有问题，造成你两点半到三点下不了单，第二天真的涨了，你会不要要求好买赔偿你的损失呢？或者相反，你预计明天跌，今天3点前想赎回，但系统挂了你赎回失败，结果第二天真的跌了，你是不是要狠狠的投诉好买？不过我们好买一直人品比较好，从来没发生过这些情况；虽然产线很多问题，但都是些非核心功能的bug，咱们的老百姓用户其实也感受不到。

1.3.好买变革的头脑风暴

去年大概4季度的时候，因为正好是做2017年规划，我们好买的管理风格就是联想的一套方法论，定战略，带团队，建班子，柳传志的三个东西。因为联想和腾讯是我们的两个干爹，两个投资方，所以经常用他们的管理理念。

所以我们有CTO的领导班子，我就是CTO领导班子的成员，我们就要谈2017年的规划，就是去年年底做的事，大家就谈诉求，或者谈自己明年需要干什么，从整个好买IT中心来说，对2017年的规划其实就是解决刚才的那些问题，那些问题不是我一个人写的，是各个总监梳理出来的，我列的还是比较常见的，还有一些其他特定的问题。

我们做了好几次头脑风暴，谈规划。至少今天参会的人对这些关键词很容易理解，想解决上述问题，有人谈敏捷，我们是偏传统的，像我刚去好买的时候就是按照CMMI的5级模型建立OSSP体系，是偏瀑布式的，大家说是不是该改革了，我们该向敏捷化靠近了，该做过程改进，要不要成立一个过程改进小组，然后怎么改？然后早期产品太烂，好买系统十年了，这些技术债不是我们留下的，而是前人造成的，要不要做重构，这些话题当时都排上日程。

还有让开发人员做测试，做单元测试，单元测试刚才也说了在国内基本上就是扯淡的，10%以内都得不到的。然后业务方瞎提需求，他不懂IT的，你跟他谈什么敏捷这些东西全扯的，这些人在金融圈很难了解IT体系，所以对不了话，没法交流。要不要上各种中间件，我们还有架构师团队，专门负责应用研发底层的中间件研发，比如日志、缓存、调度、消息等。

1.4.Devops对公司的价值

经过了差不多三五轮头脑风暴，大家就摸索出要改进的方向。然后我们CTO大笔一挥，提出几个大字，就是12个大字：持续集成、持续交付、持续部署。

后来我说这不就是DevOps嘛！其实devops这种东西目前在国内，主要还是一线的公司在玩，BAT、平安、饿了么这些非常顶尖的，像我们第二梯队的公司，刚刚开始引入，我们算是引入的早，大家应该知道还有90%以上的第二梯队、第三梯队的公司还压根没搞，甚至不知道这个理念呢！所以创始人萧老师搞这个联盟还是很有价值的，随着行业的发展，devops有一天会想agile、scrum一样变得非常普及，人所共知！

所以呢，我们好买就是这么过来的，就是因为有太多现实的技术问题，还有业务方面的问题，搞不定，扯不清。从一个企业的管理角度来说定个什么样的战略，怎么解决这个问题，用什么样的指导思想，所以油然而生形成这么一个路子，所以对于好买基金来说，deveops理念在去年冬天发起的时候，就是个非常自然的过程。

(二)选着Devops是否是一条不归路；

2.1.如何看待Devops

选择DevOps是不是一条不归路？今年春天我们公司邀请外部培训机构来讲解DevOps，这名咨询师现在就在现场哈！他曾经给我们说过一句话，我记得和清楚：企业转型devops只有一次机会！成功了就成功了，失败了就很难再做了！为什么呢？因为人性的反弹！

DevOps我怎么来看待它的？当时大家都没搞过，也是摸着石头过河，我是认为DevOps是目前IT行业先进生产力的代表，一个企业衡量这个公司的IT研发能力，IT治理体系能力的代表，或者你去一个公司面试，你问你们公司是怎么运营的，是怎么运作IT体系的？他说瀑布式的，你说过时了，说敏捷的，你说也有点过时了，但是你说DevOps，那牛！

2.2.四象限模式

基于我们折腾这半年多，我总结出来下面几条，究竟实践devops会对一个企业有什么变化？第一个是团队结构，以前我们偏向瀑布式的，或者是偏敏捷的都是一样的，还是那种矩阵是管理，或者是垂直化管理，有什么需求部门、开发部门、测试部门、运维部门，这种横向的。

而DevOps模式将会发生变化，就是从传统的人力资源池向FT演变，把业务方，做需求的人，开发、设计、测试、运维可能都打通成一个团队，我们现在也经历变革，就是最近的事。

另外，就是对人员的要求，从专长人才向混合型人才的转变。以前做测试做开发的，都是有单一技能，非常讲职业技能的深度性，但是现在越来越讲究人才的混合型，一个箩卜一个坑的时代已经过去了。如果你只能干一件活，你迟早会失业的，现在这个时代呢，就是讲究混合型人才！

咱们做软件开发的，三五年淘汰一批，离开上海回老家的太多了，这个行业的生命周期非常短，如果你到了30来岁岗位晋升上去了，也就下不来，而30来岁还没有上去，可能就永远没机会上去了，然后就被迫离开了北上广！那么多数人是没办法获得很大的职业晋升的，而又不能离开IT行业，怎么办呢？那就是横向发展，打造自己多维度的职业技能，力争做互联网技术领域的混合型人才。

其次，是组织模式。矩阵管理向大平台小团队转变，为了偏向这种快速交付的目标，一定是需要多面手，虽然人是第一要素，但是企业一定要有大平台的支撑，有了大平台才能构建好小团队。现在我在好买已经不带测试团队了，已经给我转岗转成产品总监了，专门做好买的devops平台的研发和运营工作，而且就是最近发生的事情。一定是专门有人构建这种大平台，这样才能配合服务好小团队。

最后，则是文化氛围，从强管理向自主式管理模式转变。平安今年裁了很多外包人员，然后有些人来我这里面试了，招进来之后有一次聊天，咱们做测试的职业很多人希望你的上游给你铺路，希望需求写的清楚一点，这样就有标准了，每个人总是希望你的上游给你铺好路，我以前也这么想的，我总跟开发总监说你们要给测试人员铺路，给测试人员说给运维人员铺路。

但是这是反人性的，当你坐在你岗位的时候谁都不会给下游铺路的，这是什么道理？现在企业治理也是一样的，越来越很难用那种非常官僚的、标准化的、工厂化的作业方式去管理一个公司，尤其是管理现在90后95后的IT员工，现在就是偏向于自由化的时代，所以要从强管理向自主式转变。如果一个feature team自己管理自己，具有共同的目标，他们会具有很大的热情，可以齐心协力克服持续交付中的各种问题，这难道不是好事吗？

(三)好买实践Devops的阵痛与成就；

3.1.做好DevOps的三个关键

我提出来做DevOps怎么做好三个关键词：

• 愿景包括：自动化、平台化、敏捷化；
• 策略；
• 行动；

3.2.四个成就

• 第一个成就：
  
  做测试一定先从解放自己的生产力，解放自己的手工工作量开始。我怎么搞的呢？从测试工作作为突破口，大力实施自动化测试。基于Selenium构建web自动化测试框架。构建基于Dubbo接口的自动化测试框架。我上一家公司虽然在外企，我一直想做一个能把自己15年的测试体会融入一个平台里，所以好买给我这个机会。去年10月份的时候我就开始搞，只不过后来搞大了，现在搞成好买的DevOps平台了，原本就是做各种测试的封装，结果现在发展成好买devops平台的核心了！

  然后以开发、测试交互点为突破口，尝试持续集成策略。基于开发团队自建的Sonar、Jenkins封装CI通道，先从非核心产品线进行试点，尝试自动编译打包这个过程。

• 第二个成就：
  
  第二个成就是搞项目管理。我去好买最初就是建立了一个横向的虚拟组织SEPG小组，定义了好买的项目管理体系OSSP，后来做平台就是基于这个体系，从线下搬到线上，还是比较简单的。基于项目管理工具，然后重构敏捷工作流。通过SEPG渠道横向讨论，确立工作流程。对工具进行二次开发，设计工作流。对各条产品线频繁宣讲，并建立SQA审计机制。

• 第三个成就：
  
  第三个成就，正式启动“魔戒”计划。魔戒是我们自己起的名字，就是我们现在好买DevOps平台的产品名称。我们不喜欢大张旗鼓的搞各种大改革，至少不会大张旗鼓的去宣传它，然后就暗中做了，都是非常低调的IT男，没有办法。1.0我们做了将API自动化测试模块实现，用了1.5个月。1.5版本是将web自动化测试模块实现。2.0是项目管理模块上线。3.0是将接口测试纳入CI通道，实现自动化。3.5是通用mock框架的实现。现在我们正在建立4.0，就是有点技术含量，整个策略环境全自动化部署，这是我们4季度的目标，所以一点一点在演进。

  大家可以会问：你们好买就这么点人，究竟怎么搞的呢？我告诉大家：魔戒平台开发组5个人，这5个人还是去年冬天我们招的，然后开始折腾这个魔戒平台；我任产品经理，一名开发经理，一名前端开发，一名资深开发，二名初级开发。今天这五个人都来了，而且都是买票来的哦！魔戒计划真正启动至今9个月，共上线13个版本，除了平台开发，我们还负责各条线的接入。

  我们自己负责策划、推广等等，各个业务产品线都搞定，公司规模不大，所以只能是一人多角，所以做事还是挺难的，想在我们这种中型公司做。其实每一次发一个版本都还是很有成就感的。当时主办方找我的时候我就说，我们好买搞devops还不到半年，当时搞了一个多季度就分享是不是太仓促？我们没取得什么辉煌的业绩，他说没事，你来！所以我就来了。

• 第四个成就：
  
  第四个成就是接口测试。至今好买全部Dubbo接口自动化测试已经接入，并在某些产品线已纳入CI环节，涉及600余接口的增量开发迭代。Web测试，至今好买全部web系统的核心场景全部实现自动化，分布式运行耗时10小时左右，覆盖200余用例量。持续集成是至今好买200余应用有20余个已经接入。不给大家念了。

3.3.好买的痛点

开源的东西是bug很多的，一定要有经验的人去做。我们的平台用到的很多框架其实都是从网上下的，然后改一改，其实你越做越多，量越大，运维的压力越大。其实做测试平台一样的，不是什么东西都是从零开始搞的，你会依赖大量第三方的框架，有的时候你还试错了。像标准的自动化测试还好一些。

比如你招来这个人擅长这个，然后他就定这个了，然后你就被忽悠了，即使团队再大也不允许有浪费，所以这种开源实在太多了。有的人认为这个东西好，他能搞定，但是对后期有风险。总有一天好买的DevOps平台会把业务方纳入进来，他们提需求也会从这上面走，甚至跟下游的运维监控平台打通，我们有一套独立的产品线专门做运维的，就是跟平安的嘉宾讲的类似，我们是分开的。

但是这块最郁闷的是什么？那就是人才！咱们现在做测试的从业人员，会这方面技能的人实在太少了，刚才招行的美女也讲了，做测试总感觉自己地位低，或者先天职业的悲情主义，我毕业到现在十五六年了，我也没有感觉地位有多高，但是问开发，他们也觉得地位不怎么样。

其实早期测试就是纯手工的，行业发展大现在，2014年左右行业大洗牌，洗掉一些淘汰出局的，现在剩下来做互联网IT这方面的人都是主力军，但这里面仍然百分之八九十是以开发工作为主，很多技术比较好的怎么做测试呢？那更别提运维了，运维其实更缺人才。做devops平台这些东西其实都是纯开发工作的，这方面的人才是极稀缺的，稍微有点开发能力的人员占了话语权，但是是非常片面的，要价还很高，要三万四万，其实一点都不值，所以一定要找这种偏平台开发的人才，但是很少，开发的人很少关注这个东西。但是非常有幸的是我招到了！

另外一个方面，是其他同事的认同感。比如业务开发人员对什么DevOps这种东西是不敏感的，大多数开发人员对这个事情不能说排斥，至少是比较冷漠的，开发人员的成就感是我做了什么东西，至于谁用怎么用我不管，他更不会对方法论、敏捷、精益感兴趣，来的是想做提升的，或者是作为管理者，大部分工程师对这些方法论是不感冒的，非常沉醉自己，打打游戏，一个月二三万的收入，非常悠哉的生活。高速运转的互联网公司DEV是没时间离你什么工程效能提高的。

凡事要找个突破口，招到合适的开发经理去合作，否则会碰一鼻子灰。你做一个平台，尤其在公司没有形成那种强硬的绩效目标（比如CTO说你这条产品线必须要切入CI、CD），所以我们都是非常友好的去和开发经理商讨：你这条线可以尝试的接入一下呀？技术难点不是自己瞎搞的，不会借力用力，整合资源、情商低的管理者别搞DevOps这种东西，否则就是找死。其实都是改变企业的治理体系，是碰根本的，有些人会下岗的，所以是比较敏感的。

如果你是那种硬来的一定会搞不好的，一定是稳中求进，甚至走两步退一步，有可能会退两步，就是相当于什么没干，因为做不了没有人用，一堆的吐槽，要允许这种情况存在，所以搞DevOps体系建设一定是情商比较高的，尤其是咱们IT男情商还是有待考究的。给业务方那些只懂基金涨跌的人讲解软件工程，agile这种东西就是对牛弹琴啊，傻瓜教程一定要做到位，而且要漂亮！我们提出我们这个魔戒平台也是要用产品的视角来设计它，要做到美观，按纽要清晰，关键的按纽要用红色，辅助的按纽用灰色，让用户感到简单。

构建一个DevOps平台研发团队是多么难的事情？要有擎天柱一样的领袖魅力。想构建一个什么平台，建一个什么体系非常容易。你要招人，你要设计，甚至Bug该怎么定义，落实到每个点都是非常难的，这种就是要搞DevOps体系的人员就是要有个人魅力。

一个能够强力支持你的CTO是多么重要，打通任督二脉的团队才能展开这种技术革新的事情，否则就是粗滚的节奏。我想表达的意思就是你会很多的事情会有内心挣扎，会不想干了，就是不想干了，搞这玩意啥意思。这个时候你敲开CTO的办公室，他安慰安慰你，获得一点鼓励，他一定是支持你的。最后也是送给自己，一定要有强大的内心，尤其是男人。

(四)好买对Devops平台的未来构想；

故事讲了这么多，给大家看一下我们好买的DevOps平台是什么样的。集成这么多功能，这图就是我自己画的，因为这些功能就已经满足我们的要求了，我们规模不一样，你们几万人，我们就几百人。未来就要建构成这样的，这里一半多的功能都实现了，满足我们自身需要的，你可以说这是轻量级DevOps平台，但是我们公司规模没那么大，这些功能足够用啦！

这是对刚才那个图的衍生了，绿色实现的，红色没实现，黄色需要优化的。

这个是技术栈，只列举了几个关键部分，其实有四五十个呢，没有都列，解决问题需要不同的框架，需要不同的工具。

(五)总结：解放思想 实事求是；

最后，来做一下总结。思路就是解决思想，实事求是。谁说的？邓大人！当下这个时代在中型互联网公司搞devops这种东西真的挺难的！搞这么多年IT，会发现咱们在IT圈虽然是高投入高回报，但是压力很大的。做传统金融的已经被互联网金融逼的不行，互联网金融之间也在竞争，阿里出了一个东西，然后一堆的公司去抄，你抄慢了都不行。

然后大家都有自己核心的工作职责，会造成一些相关边缘性的职责非常难开展工作，因为压力大，加上人员从业的视野，这种狭隘的价值观是比较强烈的，所以在IT公司大多数公司招人，99.99%的岗位都是招工程师。

但是其实企业真正缺的人是这些真正做中高层管理的人。为什么缺？就是因为大多数人不具备这个能力，所以管理者什么技能？就是这种比较宏观的、体系性的系统性的思维，有战略性的思维去解决企业互联网公司实际的问题。其实真正缺的是这样的人，但是这样的人非常少，各个公司都招工程师，其实真正缺的是这样的人。

就是因为现状都是这样的，大多数IT人的狭隘价值观，拥抱变化的思想还是有冲突的，大家都谈拥抱变化，其实很多人是不愿意变化的。还是那句话，不是排斥，他就是无感，无感是让你感觉很痛苦的一件事，你做了这么多东西跟我有什么关系，或者你企业要不要跟我有什么关系。

其实我们还不错，我们9个多月已经做到这个程度已经很不错了，我相信可能我自己换个公司，给我同样的团队，同样的环境去搞，可能就搞不起来，这一点是好买的企业文化气息还是不错的地方，但我可以肯定的是大多数公司是不具备这种文化土壤的，根本不让你搞，或者你搞不定失败了滚蛋。

然后，保持热血激情心态是作用革新领航人物的必备神器。一定是要保持激情满满的。像我们这边一个技术总监，他更是激情满满，他解决的是比我更尖端的技术性问题，高可用的问题，架构的问题，每天跑步，每天跑步10公里，天天吃素，激情满满，到处做演讲。我们是好哥们，经常互相交流各种体会。

想把事儿做成，除了韧性，还需讲究天时地利人和。你要在恰当的时机跟恰当的人谈去做啥。我在2010年左右就想做一个属于自己的平台，但是直到2016年才有机会做，为什么？很简单：天时地利人和的条件不具备！

实事求是，无论什么方法论，最重要的是解决企业实际问题。尊重企业实际情况，运维或测试发启DevOps皆可。大多数IT的开发人员其实对过程改进，或者技术革新这些方法论是不感冒的，反倒推行DevOps，或者实施DevOps比较适合的角色，真的就是测试人员、或者是运维人员。因为开发对这个是无感的，无感的还算好，有的公司是反感，那就恶心了。我说这块是给大家创造一个新的职业发展机会，大家可以记住：测试或运维在企业从事DevOps工作，还是挺合适的。