风控这半年

2015年10月18日

认识自己

1. 为什么来到风控?

毕业第一份工作是在 Hulu,在这里感受到了外企的工作方式和氛围,总体的工作氛围可以用轻松、和谐来概括。 公司没有指定针对每个人的 KPI, 大多数的工作都没有太多的压力, 更多的时候是靠自己的规划和主动性。 这样的氛围下每个人都有一些时间和机会去接触自己想要做的事情,但是刚开始工作可能并没有体会到这种模式的太多好处, 反而很多时候觉得可以做的事情不够多,成长不够。在工作 Hulu 工作的这两年之中,经历了一些公司的变故, 很多大牛们都离开了, 在觉得做事情都驾轻熟路之后, 想应该出去看看了, 当时主要的想法是去国内的互联网公司。 在经过一些面试和选择之后,选择了目前这个公司的风控团队, 一方面是这边有熟人, 不太容易踏空, 另一方面是因为面试的时候感觉还不错。 放弃了一些风险更高的创业公司, 主要是觉得自己的水平还不够想再磨练一番。

2. 在风控做了什么

a) 适应节奏

刚来到这个团队的时候, 感觉和之前的工作方式和模式都有了很大的区别, 第一次体验到了传说中的 KPI, 觉得大家的工作节奏都比较快, 之前在 Hulu 的时候一周上线两次都觉得是不是有点多,在这边基本上一天上线十几二十次的节奏(当然是糙快猛的上线, 没有特别严格的测试和流程, 大家也就上了)。 另一方面由于公司阶段的原因, 觉得很多事情都不太正规, 感觉整体的代码写的都比较糟糕, 坑比较多也没有太多流程上的保证, 所以刚开始的时候每次都特别紧张, 因为代码上去之后是什么样自己完全没有把握, 也出过几次问题。曾经一度觉得非常沮丧, 感觉环境太糟糕(内心是不是有点太脆弱了)。要么走要么改变,后来下定决心决定尽力去改变这种状况, 在做 code review 的时候下了更多的精力, 记得有一次一个同事的 review 添加了几十条 comments, 来来回回改了好多次, 同时和她面对面的沟通了好几次, 把代码的好与不好都跟她自己进行了分析。 这样几次之后,代码质量慢慢就开始有了提升,另一方面自己也慢慢适应了这种工作状态和节奏。

b) 性能

招我进来的主要目的是为了做工程这边的工作, 最紧要的是要优化主服务性能, 当时主服务的性能正在变得越来越差, 而且服务及其不稳定, 响应时间经常飙升到几秒左右。同时服务的容灾能力也特别差, 依赖了大约 20-30 个外部服务, 某一服务出现问题的时候, 我们的服务就面临崩溃的危险。这是我第一次碰到这种状况, 依赖的外部服务太多了,在之前的公司做推荐服务的时候仅仅只依赖了几个外部服务, 怎么来管理和组织这些外部服务的关系成为了一个棘手的问题。 最开始的时候并没有什么思路, 第一步要做的就是添加完备的监控, 查看我们服务的各个环节的监控数据。 根据监控的信息进行了针对性的优化, 简单来说就是看看那个步骤或者环节比较慢, 然后进行针对性的优化工作。 在做完几个外部服务的针对性优化之后, 发现每一次响应时间都会有所下降, 但是发现我们服务的总体响应式时间却在慢慢增加, 这是因为我们的服务迭代太快,有越来越多的功能或者服务被引入, 也就是说优化的速度还赶不上“造”的速度, 这一度也让我很沮丧(再次沮丧了)。 通过思考之后觉得针对性的优化并不能起到太大的作用了,要想一个一劳永逸的方法, 新添加的功能和外部服务不会使得响应时间越来越长, 所以我们需要一个统一的管理外部依赖的方式, 同时为了尽量降低响应时间, 决定引入并行化。并行化是我最不愿意看到的,因为并行化之后整个编码的难度将会提高, 这不利于我们的开发和迭代, 会给开发同学们在开发的时候带来更多的心智负担。 好在通过一段时间的思考,想到了一种统一管理的方式, 同时隐藏了开发同学在开发功能代码时候需要考虑的并行化问题。 之后的主要工作就是推广该方案, 同时迁移老的代码, 大家对于性能问题都感同身受, 所以都很配合相关的工作, 我们以比较快的速度迁到了新的方案, 同时也认同新的方案更利于开发工作, 代码和外部依赖的统一的管理下, 减少了很多坑。 最后也收到比较好的效果, 响应时间的 upper90 从 150ms 降低到了 50ms 以下。同时添加新的功能和代码, 一般情况下自动和之前的并行, 总体的响应时间不会变的越来越差(了解业务和流程, 才能更好的找到解决问题的方法)。

c) 测试

在做性能优化的同时进行了另一部分工作就是推广测试和搭建集成测试平台。 因为很多同学之前的工作都没有做过太多的测试,所以测试的意识不足, 第一步就是普及大家的测试意识,很多同学都被需求追着跑,所以大家很少写单元测试,在这推广的过程中也遇到了一些困难。至于集成测试,我这边目前也只是完成了集成测试的整个流程, 但是鲜少有人去添加集成测试的 case, 测试这块是这段时间觉得做的不够好的一部分工作。 感想就是测试要早推, 要尽早培养测试的意识,同时代码和模块要易于测试。

4. 考虑离开

由于来的时候把我的工作划分工程这一块, 所谓工程的工作可能主要是分为代码质量, 测试,性能和工具这些, 但是在来了一段时间和做了一些工作之后, 慢慢的觉得很多工作都比较零碎, 很难形成一套整体的东西(工程就是由一些零碎的构成一整个体系, 所以可能就是这样的 :) )。另一方面觉得工程的东西越做越少, 因为性能优化好了不可能再优化一遍, 一些工具和流程建立好了不能再建立一遍。所以和老大进行了多次沟通,想问问有没有别的事情可以做,觉得有点闲了,但是经过了几次探讨之后都没有找到比较合适的事情。所以我想是不是可以去看看其他的机会, 转一个组或者换一个公司, 当时的想法就是不要闲着, 继续追求一点技术的东西,暂时也没有带人的想法(想法可能并不够成熟)。

5. 收获了哪些

这段时间的收获还是挺多的, 主要是看到了国内正在迅猛发展互联网公司的工作氛围和工作方式, 相对之前在外企的工作更加接地气了。看到了同事们加积极乐观的工作和生活态度, 积极健身和积极看书学习方面让我感触颇深, 以至于我启用了我落灰一年多的 kindle。自己的眼光放的更开了一些, 不在局限了一个两个具体的技术,而是更多专注于如果做好一件事情。公司的 wiki 资源很丰富, 通过阅读了很多的 wiki 学习到了很多科学文化知识。了解了在线风控的一些基本业务知识, 同时也见识了黄牛党有多么犀利。

6. 未来的思考

第一件觉得想的比较明白的事情是工作中自己感兴趣或者很技术的东西是可遇而不可求的, 可以将业余的时间做一些自己比较感兴趣的事情。不管之后在哪里都要有比较强大的内心,要有更强的适应环境的能力, 踏实的做一些事情,多总结多观察, 少一些胡思乱想。:)