我一直觉得人应该要有长远的目标，哪怕这个目标暂时看起来比较遥远，但只要一个目标在那里，人生就不容易迷失了方向。
我从第一份工作开始，就给定了一个小目标，一定要自己去做一些事情，这个事情可大可小，哪怕这个事情只挣一点钱。
但它是完全由我主导的，由我来创造的…
就像我的生活一样，不论过得好或坏、悲或喜，那都是我的选择，那才是我真正想要的！
我用了10年完成了这个小目标！
1、写在前面
我将用系列文章，回顾十年程序生涯，一方面是对职场生涯的阶段性总结，另一方面希望这些经历，对大家往后职场生涯有所启发。
一只站在树上的鸟儿，从来不会害怕树枝断裂，因为它相信的不是树枝，而是它自己的翅膀。
十年系列文章：
2.毕业即失业，找工作找到怀疑人生-2009（已被删，查看此文公号内回复关键字：毕业）
4.富士康14跳被我赶上了，流水线车间真的没有梦想-2009
如果想从另外一个角度了解我的 10 年经历，可以看看这个漫画：《“失败”的北漂十年经历》，这里有我的一段故事。
2、新平台
“新平台必须在10月上线，董事长已经下了死命令！”
2017年，我刚回到支付公司的时候就听到了这句话，新平台是公司重新整的一套平台，要完全替换到4年前引进的技术体系。
再来之前我就了解到，新平台使用的技术是 Spring Boot/Cloud 相关技术栈 ，和我在上家公司使用的技术体系完全一致。
支付公司的交易量在百万以上，之前给领导打过一个比喻，相当于车在高速路上行驶，并同时换掉轮子，车还要不颠簸。
我之所以重新回到支付公司，就是想参与到这个大工程，主要负责新平台的大数据建设，职位：架构师。
也就是相当于降职从上一家公司回到支付公司，为的就是能在大项目中历练，带一个小团队负责大数据平台建设。
但我还是低估了这件事的难度，团队差点被压垮！
3、大数据平台
996当时对我们来讲是最舒服的，刚去公司就开始全封闭开发，一个月的时间完全没有任何周六周天，天天加班赶进度！
大概给大家讲一下我们当时面临的问题，微服务架构之后平台有上百个库上千张表，每个微服务对应1-N个数据库。
和之前传统的集中存储差异极大，各项业务数据散落到上百张表，但是对于业务部分来讲，就是要查全部数据。
所以要将着数据清洗整合，将 Mysql 数据实时同步到大数据平台，在数据清洗之后给业务部门使用。
一个组合表往往高达上百个字段，几百亿的数据，查询字段高达几十个，要求必须在几十秒内返回。
我们几乎用了大数据所有相关技术，分了三条线路来满足不同场景的需求，比如业务查询、报表整理、数据挖掘。
当我和兄弟们正干得火热时，突然领导找我安排一个事情！
4、研发副总
还是再说一下，我特别感谢我曾经的两位领导，如果不是这两位老大，我在职场确实不可能发展得那么顺利。
能力是一方面，但和你一样有能力的人很多，当机会来临的时候需要果断抓住！
老大说公司需要招聘一位研发副总，配合着领导做整个研发中心的管理，于是想直接提拔我来做这个事情。
坦白来讲，当时还是蛮忐忑的，之前做技术负责人最多管理也就30人左右，这次研发中心有100多人。
于是我问领导，您觉得我能行吗？领导说他觉得没问题。抱着忐忑的心情我决定试一试，做了公司的研发副总。
从金融公司的研发负责人到支付公司的架构师，再从支付公司的架构师连升3级到研发副总，除过忐忑之外，下定决心一定要做好。
我的任务只有一个，尽全力推进新平台尽快投产上线！
5、面临的问题
当时其实很被动，新平台已经上线了一部分，老平台还在继续运行，等于公司有2套系统同时在运转。
运营、风控、客服、财务、结算等业务部分都需要用2套系统，大家都觉得新平台不好用，而且每次切部分业务，多多少少都会有点问题。
业务部门吐槽是正常的，他们需要重新学习新的系统使用，2套系统的设计差异很大，人对于新的事物会本能的抵触。
但领导层对新平台是否上线也没有达成一致，这就导致下面的人做事情很尴尬，天天开各种跨部门会议来沟通。
所以给我的感觉是，全公司都不支持新平台上线，只有研发部门来推动着新平台往前走，这种感觉很难受！
但我们必须往前走，一方面2个系统维护，研发压力也大，往往一个需求需要做2次，新平台一次旧平台一次，什么工作都是2倍。
所以对于当时我来讲，就是要用一切力量推动新平台完全上线，这样大家都痛苦一次，后面就好了。
6、顶着压力上
当时定了一套快速迁移方案，乐观的预告大概半年的时间，就可以完全从旧平台迁移到新平台。
制定完计划之后，就开始按照流程推动，给代理商培训、商户培训、各业务部门提前通知，晚上迁移回测等等。
第一次只切几万的交易量，后面慢慢升级到几十万的交易量，再到几百万的交易量。
随着系统负荷的增长，新平台也发现了不少的问题，一些代理商不熟悉平台或者也有一些bug，直接打电话到董事长那里大骂新平台是个垃圾！
当时研发压力巨大，全公司都在骂新平台，子公司、代理商、业务部门等等，有的代理商甚至要求迁移回去（老平台）。
骂归骂，迁移回去是不可能的，该解决Bug的解决Bug，该加需求继续加需求，反馈问题多的时候暂缓迁移，解决问题之后继续迁移。
终于把老平台中的一个大平台，完全迁移了过来，当我们感觉胜利在望的时候，出现了一次大事故！
7、出现事故
其实随着迁移进展不断往前走，我们开发了一套全自动迁移程序，只需要在页面点击相关按钮。
程序就会自动从老平台迁移代理商或者商户到新平台，其中的所有操作都是自动化的，包含迁移之后的数据核对。
所以我们对迁移这块还是有信心的。
但是问题就是出在最容易忽略的地方，在新平台和老平台最前端有一个路由系统，会根据一定条件选择送交易到老平台还是新平台。
路由系统后面有一个 Nginx 负责服务负载，后面挂了 N 服务器做为轮询，如若有交易处理时间过长， Nginx 会自动触发重试功能。
也就是一个交易被重试了 N 次，但其实交易本身并没有出错，只是超时而已，同一批交易被执行了 N 次。
但谁也不知道这里有这样一个隐患。
谁也不知道 Nginx 超时间是谁来配置的，突然有一天一个业务处理超长，业务部门配置刚好超过限制，问题爆发了…
这个逻辑上有5-6个防范和校验的机制，那天刚刚恰好的都跳过了，导致公司出现了巨大的损失，做为研发管理责无旁贷。
在公司住了整整近一周的时间，处理了相关善后工作之后，就要求辞职了，开启了自己的自由职业。
8、自由之路
一方面确实要为事故负责，另一方面，我确实早有出来的打算，但一直找不到合适的机会。
对于公司还是一直抱有感激之情，就是出现这样的事故，最后也没有处理到研发人员，都是管理层接受处罚。
并且这种类似的问题，本质上肯定是管理存在着漏洞，这个漏洞一直都在，只是看在什么时候爆发而已。
深深的感觉到研发管理是一个系统工程，其中任何的小事有可能在某种情况下成为大事，在996或者超压力负荷下，很多问题都被覆盖或者忽略了。
2019年自由职业之后，就开始了各种各样的尝试，旅游、自驾、读书、尝试各种可能挣钱的商业项目。
不知不觉一年过去了，又有了很多失败的经历，也有一点成功的喜悦，但真的感觉很难再重新回到职场了。
我的10年职场程序生涯告一段落，自由职业的10年却才刚刚开始….
9、最后
到此为止，我的10年程序员生涯就算写完了，中间拖拖拉拉的也快写了一年的时间。
也算是对自己职业生涯的一段总结，分享出来如果对大家有一点点启发的话，我便感觉到很有价值感。
对于职场的程序员们，我也有一点小建议：
1、全力以赴把工作做好，领导真的可以看到见，如果说没有被重视，大概率还是做得不够好！
2、在职场尽可能去帮助同事解决问题，解决问题是成长的最快方式，特别是生产出现问题的时候，重压之下出奇迹。
3、尽量和你认识的最优秀的人一起去工作，哪怕没有挣到很多钱也可以学习到很多知识，对你的成长会有极大的帮助。
最后，保持一颗感恩的心，感谢那些在职场上帮助过你的人！如果有人想拉你一把，请不要先自己拖了后腿！
作者简介：纯洁的微笑，一个有故事的程序员。曾在互联网金融，第三方支付公司工作，现为一名自由职业者，和你一起用技术的角度去看这个世界。我的微信号puresmilea，欢迎大家找我聊天，记录你我的故事。
Post Directory
