2年来,从码农到技术总监,我在一家金融科技公司经历了什么?

背景:我就职于一家金融科技公司,主要是做大数据风控业务。刚开始加入这个团队的时候我是第一个写代码的人,到今天需要管理一支近40人的技术团队,这个过程无论以后什么时候回想起来必定都是终身难忘的,所以希望今天借此机会复盘,和大家分享一下一路走来踩过的一些坑和从中学习到的教训或经验。

团队成长

业务研发

首先给大家分享下我们在业务技术上面的一些变化,前面1年多的时间我们都主要以spring+spring mvc+mybatis作为业务系统研发的基础框架,后来因为微服务架构的迁移,我们从去年年底开始有部分新增业务系统直接在以spring boot为基础的框架下进行开发,保证后期微服务架构脚手架等等全部ready后能够直接迁移过去。同时我强烈推荐spring boot作为基础服务构建的框架,真的可以算得上是一个非常轻量级的框架,习惯优于配置的设计使得我们可以非常快速的启动一个应用,提供了各种常见第三方组件的starter,避免时间花在造轮子上。在业务框架、语言的选择上面我觉得我们还是比较主流的,主要以java作为后台开发语言,前端则经历了angular–>vue的一个变化过程,令人比较头疼的大概是因为前期开发不够规范造成的一些接口管理问题,有一些为了临时业务需求加出来的接口,后期需要花费不少时间让客户替换到统一接口,当然这样的变化也很正常,毕竟不是所有的内容都能在一开始就设计好,最关键的是要定期复盘,及时还债,不然到最后可能发现接口数量极多,而且很多接口可能都不怎么使用(这个是我在其他团队能够明显看见的情况)。此外我也真诚的建议刚从学校毕业不久的同学认认真真的多看一些开源项目的代码,看一些大牛的博客。首先学习别人的设计方法和尽可能多的去了解一些好的轮子,在实际项目中实践总结慢慢形成自己的体系。在一开始还没好好学习一下牛人的设计思路时就按自己的想法去做一些设计很容易事倍功半,对你在一开始的成长非常不利(当然如果你觉得自己特别牛当我没说),还是要学会站在巨人的肩膀上前行。

  • 组件
    • 爬虫:
      • 语言与框架:我们的爬虫主要还是用python开发的。有直接用scrapy做的,也有通过对请求的分析直接用requests完成的。
      • 代理ip:网上有不少卖代理ip的服务,一般来讲是自己养了一堆机器做的池,质量说实在的不是很好,用的客户多,效果就差。核算成本后完全可以考虑自己建(如果对ip分布要求不高,前期不用太多机器就能满足需求,可以在x宝买adsl,自己做拨号机制换ip)
      • 反爬虫进阶: 对一些反爬虫机制做的特别强的,会用到selenium(本身用于自动化测试的,运行在浏览器中则像真正的用户操作一样)+phantomjs(一个基于webkit的无头浏览器)。
    • 规则引擎:推荐下drools,一款基于java的开源规则引擎,可以将复杂多变的规则从硬编码中解放出来,以规则脚本的形式存放在drl文件中,规则的变更不需要修改代码重启机器就可以马上在生产环境中生效。对于一些有规则配置的业务来说,在这个平台上做二次开发是一个不错的选择。

架构

  • 单体架构时期。在实践微服务架构之前,我们就是一个独立的业务系统一个war包,有很多重复的模块是难以避免的,早期我们两个针对不同对象的征信系统都有自己的第三方数据请求的模块,后来拆分出来做了一个数据中心。
  • 微服务架构迁移期。这是我们现阶段的一个状态,有一些业务已经改造在微服务体系下跑了很长一段时间了(算是做尝试、测试)。然后有一些业务才开始做一些拆分,改造,逐步融入到微服务架构体系中。

大数据

我们是一家大数据风控公司,自然就是一家拥有很多数据的公司。在我们起量之前就有相关的储备,搭建了基于hadoop的大数据平台。一开始是解决历史数据存储的问题,在起量后我们的一些分析和模型训练也需要这样一个平台来提供基于全量数据的批量计算能力和实时计算的能力。

测试&运维

  • 自动化:自动化是我们测试运维团队一直以来建设的目标,把人工操作尽可能自动化是建设的核心。没有ci/cd/自动化测试等支撑在服务拆分细致、服务数量成倍增长的情况下对于运维测试人员的工作量是成倍增长。
  • 平台化:建设运维测试平台将有益于将部分运维测试工作转移给研发团队,逐渐到devops,他们需要的就是学会的使用这些工具,而原有的测试和运维团队可以更加专注于在工具、平台的建设上。现在我们主要的工作是基于gitlab+jenkins+harbor+rancher构建ci/cd流程,同时配套自己在逐步完善的自动化测试平台,作为测试钩子外链。此外充分利用了云平台提供的sdk,建设弹性扩充方案。

自我成长

沟通与组织能力

锻炼沟通和组织能力的方式非常多,尤其在你做了一个tech lead后,组织会议,分配任务、组织大家完成一个产品阶段性目标都是日常工作。做到一个开发经理后就会开始负责一个项目的技术部分,估算工作量、分配工作、协调前后端开发这些事情都是锻炼自己这方面能力的绝佳机会。作为某个技术方向的head,结合中长期的一些目标给自己或者自己带的团队做规划也是锻炼组织能力的一种方式。此外不管是项目管理还是团队技术性目标在实施过程中及时回顾更新管理措施对于刚转岗管理的人非常重要,可能学习了很多管理的方法,但是未必适用,没有银弹,实践出真知。

产品能力

研发管理

  • 框架选型:我们经历了从spring到spring boot作为基础服务构建框架的过程。在这里我特别想分享的一点就是对于小团队,如非必要,一些脚手架里面需要的组件因尽可能使用一些可靠第三方的轮子,不要选择自己造,严格到可以作为产品在生产环境使用需要大量的测试投入,如此反复打磨一个轮子需要投入的成本太高。比如很多稍微大一点的厂对于微服务架构相关的脚手架基本都是以自研为主,但是对于我们这种前期就那么2、3个人投身于组件和敏捷设施研究的团队根本不现实,选择spring cloud,投入研究后适当根据团队、业务需求去进行一些二次开发比较实在。
  • 招聘人才:对于像我们这样小型的技术团队,我觉得作为团队的技术负责人,一定一定是需要参与到每一次招聘过程中的。你看的不是技术,更重要的我觉得是要看这个人的学习能力。在it行业,技术的变化,说实在的,挺快的。比如前端是一个技术变化非常快的方向,angular这个框架从1-2有很大的改动。对学习的态度,对工作的热情,他的三观是否和你的团队match这些我觉得大家作为head面都会充分考察。此外我还想补充一点,我最近的招聘中,一直不忘的一件事情就是了解候选人想要在加入我的团队之后收获的成果(不管是技术能力、业务知识还是平台),我会思考我和我的团队能否提供给他,并且会跟他之间达到一个充分的共识,保证在他的任期里他能够从我的团队中收获到他想要的东西同时他会尽全力的为团队、公司提供服务,做贡献。我觉得现在的时代不一样,不像我们的父母那个年代,我的妈妈从工作开始到退休就只在一家企业,双方都非常“忠诚”。现在的人才市场很活跃,今天还在腾讯,明天也许就去了阿里,与其彼此相互揣测心意,在离职后才去了解别人为什么要走,不如透明做一对盟友,共同进步,在不能达到双方预期的情况下好聚好散。
  • 挖掘高潜人才:我们是一支一开始几乎以校招为主的团队,说的直白点,就是白纸比较多,他们需要时间成长,也需要有人带带方向。一开始招进来的岗位全当作为一个参考(也许感兴趣、也许只是恰好知道得多一点),对于手下有这样的同事作为tech lead最重要的就是多观察,多给一些锻炼,挖掘出高潜人才,重点进行培养,鼓励他们多接触开源信息,多分享,多展示自己,当然你需要做的就是尽可能的给他们提供平台。同样地,对于我手下直接带的同事,我也会定期花时间了解他们的想法,尽可能提供帮助,这个时候我们要做的就是更大程度地去倾听,帮助他发现问题并解决。人生路很长,不管是否还在一个团队,都是一段缘分,结交的一位朋友。
  • 业务管理:作为总体负责人实在很难有时间管控到每一个项目的细节,也不建议这样做,否则你下面带的人没法独立,你也没法把精力花在其他需要你的地方,因为这实在太碎太碎。同时也不能完全撒手不管,对于一个新的project tech lead,在系统的总体设计上一定要做review,和保证一定时间的跟踪,确保方向上没有太大的问题,在表设计上应该要求dba对一些通用字段有固定命名,字段命名上也应该有一套规范,保证在当应用系统变得越来越多,独立系统开发团队越来越多的情况下,数据集中后还能够不通过任何映射关联基本信息,就需要有一套针对人/企业的基本信息命名字典和其他字典的基本命名准则。
  • 基础运维管理:
    • 建立完善的线上故障的监控与处理机制:要从整个访问架构上做充分的分析和准备,具体大致分为区域性故障(有做多可用区备份,目前我们是2地3中心,由于成本问题还是单活,感兴趣可以下来交流)、lb故障、反向代理故障、基础组件故障、应用层故障、数据层故障等。
    • 建立监控指标的分析反馈机制:平时的监控数据采集下来之后,通过对各项指标在时间线上的变化,能够帮助我们发现潜在问题。如果是因为业务极速增长带来的变化可以及时扩容,而如果是在某个时间点后突然出现的上升,应该反馈给业务开发进行排查,看看是不是某个版本发布后带来的问题,这样就能够提前解决可能发生的问题。目前我会组织运维相关的人员每周进行这样一次深度分析,主要是从主机的指标,访问分布、曲线,SQL慢查询日志等方面去分析每个业务系统的情况。

技术学习与交流

  • 保持对技术的敏锐: 作为tech lead一定要保证自己每天有固定的时间去看一些技术文章和开源资讯,摄入足够多的信息保证自己在技术上的敏锐度,同时在和产品迭代不冲突的情况下及时组织团队偿还技术债、引入一些更好的解决方案保持团队的技术活力。近一年里我养成了一个习惯,每天早上转发开源中国的早报到我们信息技术部的群里,无论是自己了解还是试图用知识唤醒同事(也许有人从来不看-_-),都不失为一个办法。
  • 持续分享与交流:可能对我稍微熟悉一点的朋友,会发现我今年一年来还是较为频繁的出现在一些会议上。不论是参与不同主题的会议学习别人的经验也好,分享风控产品相关的、微服务架构的技术也好,都可以逼着我自己不断的去学习、消化、输出一些内容。同时也可以和技术圈的一些牛人近距离接触、交流,从他们身上学习宝贵的经验,帮助自己快速成长,同时也能结交到不少朋友,扩展自己的人脉和见识。

今天在这儿写一篇两周年纪念文也是一种分享方式^_^。由于内容较多,篇幅有限,欢迎大家在评论区交流,也希望大家多多支持关注我。

后记:也许在很多熟悉我的朋友眼里,2年前我选择这家金融科技公司是一个很难以理解的决定,但我一直觉得这未必就比选择出国留学能够带来的收获少,今天这篇文章也许算是一份quiz答卷,我想至少是及格甚至能够称得上良好的。当然因为没有办法把我变成2个我,从而可以做一组对照实验来科学比较,所以这个事情真不好说,就像谁能想到10年前的网瘾少女如今成了一个科技公司的技术总监? 由此希望看到这篇文章的朋友,不要因为过去取得的成就而沾沾自喜,也不要因为此刻的落魄而对自己的未来感到迷茫举步不前,人生是一场长跑,比的是耐力,短暂的爆发并不能决定最后谁能先到终点,与君共勉。