我从未结束的Java之旅

开篇

   简单的做个自我介绍，码龄九年，主要从事java开发，对前端和python略有了解，是一个技术不精湛但是对得起八年码龄的程序员。作为一个码农，我始终对代码保持着一颗敬畏之心，也正是这颗敬畏之星能推动着我在编码的道路上越走越远。这其中有些许的心酸，也有努力过后的欣慰，还有生命中遇到的各种人和事，我打算以流水账的形式记录下来。

毕业

   2013年本科毕业，由于大学专业是计算机科学与技术,学校的生活丰富多彩但又浑浑噩噩，但是也算提前规划，顺利的步入了社会，有幸加入了一家北京的公司，业务是在当地的医疗机构做软件相关工作，由于比较有上进心所以试用期结束后就顺利的开始带领小团队做项目，工作多是一些二次开发及报表开发的工作，大概干了一年半左右的时间，感觉技术和事业都上升到了瓶颈期，跳槽的欲望开始萌生，时间转眼就到了2015年。

第一份工作的结束

   2015年，递交了辞呈，在经过短暂的交接后顺利告别第一家公司，非常感谢这家公司在我毕业后对我的培养，也让我交到了几个非常不错的好朋友，至今还在联系。辞职之后，非常的迷茫，相信我，一定是因为眼界的问题，作为一个从普通家庭出生的孩子，老一辈能给你提供的平台有限，导致你的思维和想法局限性都非常大，这也是和大多数同龄人有着一样困惑的根本原因，辞职之后，我在思考到底什么样的工作适合我，这时刚好有个大学哥们，还有的一同辞职的同事，可能经历相同，阅历也差不多。我们便开始了勇敢的尝试，期间的心酸一言难尽，但是作为一个初入社会的年轻人，我到现在还是认为一切的尝试都是值得的，最起码我们排除了几个不合适的方向，思前想后，决定利用仅有的优势，继续从事技术方向的工作，但是由于三线城市当时技术的落后性，我…做了一个大胆的决定，作为一个从来没出过省的选手，我拍板决定去北京寻求发展，于是我们坐上了飞往北京的航班。

大胆北漂

第一次在北京租房

   2015年5月，落地北京，由于老东家是北京的，加上我人缘还一直不错，我和我哥们就借住在了一个前同事的出租房里，地址位于顺义俸伯附近，熟悉北京的朋友知道那里是多么的远，为了工作便利，我和好兄弟在前同事的推荐下开始了育新的租房之旅，每天从俸伯坐地铁到育新，到处看房子，最后在「我爱我家」房屋中介的帮助下，'顺利’的和另一个黑中介签订了租房合同，在一个环境不错的小区租了一个次卧，大概有十四五平米的样子。一套两居室的房子被中介改造成了四间房子，一共住了8个人，共用厨房和洗手间，租金是1300元/月，对于还没有收入的我们算是一笔不小的开支，不过这已经是我们在附近能找到的性价比最高的房子了，说起这个出租屋，和我好哥们住了三年有余，有道不尽的心酸，也有说不完的难忘回忆。

供应链

新的开始

   来到北京，充满了挑战和自身的兴奋，想要迫切的证明自己的能力，那么对于北京的第一份工作，也是饱含热情，说到这第一份工作，我和我哥们当时一直讨论的是我们是找家大公司好呢还是找家小公司好。但是事实却是有一家瞎了眼的公司能收留你就非常好。这期间我们俩冲刺学习了大概有一个多月，每天没日没夜的在互联网上学习新的技术，终于鼓起勇气投出了北京的第一份简历。当时是海投，加上公开简历（这里要给刚去北漂的小伙伴提醒，简历千万不要公开，不然会有很多外包公司浪费你的时间）。面试邀约电话是络绎不绝，后来面试了多家公司之后才发现大部分是外包公司。面试了可能有两周的时间，拿到了来自北京的第一个offer，9k。位于海淀黄庄。
   这份工作用到的技术栈比较陈旧，后端框架使用的是ssh，不知道大家还有没有印象， struts+spring+hibernate，前端使用的是AngularJS,当时前后端还未分离，所以AngularJS对我来说是一个从未涉及的技术栈。
   由于工作经验的欠缺，以及对技术栈的不熟悉，导致我每天都加班到10点左右，周末也经常加班，即时不加班也需要加速学习新的技术栈和新公司的业务知识，断断续续的持续了有两三个月，终于能熟练的完成各项任务，不得不说在重压之下，进步的速度也是很惊人。通过不断的努力，也很快得到了领导和同事的认可，能够工作中独当一面。对于陌生城市的第一份工作，逐渐适应。

好景不长

   2015年由于种种原因，煤炭钢铁行业经济呈下行趋势，各个公司都是又赢转亏，我任职的这家公司针对的业务恰巧是这个行业，由于无法收到企业结算，导致公司资金链断裂，开始拖欠工资了。一个月、两个月、三个月，压力陡增，三个月没有发工资导致公司内部气氛十分压抑，我的卡里也没钱交房租了。其实大家心里也都明白，作为一个经营了十多年的公司，必然有它的生存之道，拖欠工资是暂时的，后期是会补发的，很多老员工选择了和公司共渡难关，但是由于生活所迫，我不得不又在短短半年时间又登录上了招聘网站。

餐饮

误打误撞

   我是一个爱思考，喜欢做长远计划的人，所以从登上去北京的飞机的那一刻起，我的目标就是学习并不是立足。那么在找工作这一块，可能思考不是那么成熟，我是没有考虑到业务的持续性的，我是想更多的涉猎各种业务领域，学习各种新的技术，尝试各种疑难问题的解决方案。误打误撞的加入了美团，当时我们是独立运营的一个部门，负责连锁餐饮营运相关的业务线,运行的软件系统十分的庞大，涉及餐饮各个领域，多人点餐、外卖、连锁等等。第一次接触saas的我，又一次变成了小白。这次的技术栈更杂一些，又开始了无尽的加班学习中。

线上事故

   互联网公司需要快速抢占市场，所以我们上线很频繁，最多两周就会有一次大的迭代，小迭代那更是随时随地。我当时所负责的业务线叫做总部营运，是餐饮相关业务的基础，所有门店业务、供应链业务、外卖业务等等都会很依赖，当时架构也比较简单，没有使用微服务，仅仅是通过两层nginx完成二级域名代理做了不同的业务服务集群。我们小迭代上线流程是这样的:
开发->测试->代码合并->灰度发布->灰度试用两周并且bug迭代->生产发布。
其实目测这已经是一个非常严谨的流程了，但是作为当时的救火队员之一的我，在一定程度上拥有了大家默许的优先发布权、甚至有时候可以绕过测试😄😄😄😄。当然这都是基于同事和领导对我的信任，已经多次救火的成功案例。同时，这种信任也为此次线上事故埋下了伏笔。
   2016年的一个炎热夏天，产品经理找到了我，告知现在有个临时的问题，需要对我们一张类似字典表进行批量操作，通过sql脚本达到问题解决得效果，由于我们是多租户，需要对生产所有租户数据库进行升级，于是我就开始编写脚本，我发现改动得数据太多，不如直接把数据导出insert语句，然后清理表数据后重新插入呢，于是说干就干，大概在上午11点，我按照我得逻辑开始整理sql，1点整理完毕。我带着产品直接找到了运维同事，说明了问题需要进行大规模得sql脚本升级，并且产品经理已经在客户群进行了沟通，运维同事也没顾得上吃午饭，我们三个就开始对生产环境数据库执行脚本。
清理表数据
sql truncate table xxx
执行sql
batch insert into xxx
过程无比丝滑，犹如香浓德芙，全程无半点卡顿，如行云流水般几分钟操作完毕，小小得成就感油然而生，咱们做技术得不就是图这点成就感么？😁😁😁谁说不是呢。说着还给运维老哥一个电眼，咋样没耽误你午休吧。😜
    等到午饭回来，发现办公室乱起来了，测试同学奔走相告，说供应链得按钮权限全部消失，生产用户无法在页面进行任何操作，供应链组长正在满头大汗得查问题。

事故原因

   皂滑弄人，原本因该出现在代码世界里面得并发问题，让我在实际生活中给操作出来了。原来是在我们上午商量方案得时候，供应链小组也进行了版本迭代，增加了每个租户的按钮权限，并且好巧不巧和我操作的是同一张表，更巧的是，他们更新sql是在我查询数据之后。然后，我清理了表数据，重新执行了我的sql脚本。我来画个示意图。好在，发现的及时，并且供应链小组保留了上线脚本。很快就恢复了。

复盘

   虽然这次生产事故没什么损失，就是招来了一些客户的抱怨，但是事故可大可小，见微知著，因此不能忽视。
其实问题很简单:
1.跨组协调不到位
2.上线太随意
这两个问题造成了这次生产事故，如果上线能梳理一个规范的流程，并且大家都严格按照流程来执行，那么将会避免很多问题，其实现实就是这样，当团队技能成熟到一定阶段以后，那么后续比拼的将会是执行力、规则、默契度。
因此我们团队吸取了教训,经过一个专题会议讨论得出以下规则:
1.每次迭代需要告知相关方，并且由专人进行评估。
2.每次生产环境跑批脚本必须经由DBA审核，再无特权。
3.每次迭代都需要告知相关各方，并且由涉及到的业务线对涉及功能进行冒烟。
   其实生产事故不可怕，只要善于总结，团队总是在进步。好代码是改出来，好团队也是在千锤百炼中磨合出来的，我一直认为做技术，一定需要时间和经历的积淀，不可能一蹴而就。所以从这次事故中，我也逐渐养成了思考问题尽可能全面的习惯，作为一个程序员，代码不可能没有bug，高低之分大抵就在概率了吧。