引言

等风来不如追风去，追逐的过程就是人生的意义。

正文

距离上一次写博客已经是10月下旬了，本来想着至少保持着每个月至少一更的频率。结果这次硬是拖到了年底才开始动笔写这篇博客，好在从来没有人对我的博客催更，于是这次就打算水一篇自己的2018年的年度总结。姑且写，也姑且看。

今年十月份的时候，收到了公司的一周年纪念品，感觉挺开心的。收到的时候我自己也挺诧异的，不知不觉的就在酷家乐工作了已经一年多。回顾这一年，我觉得两个字就是幸运，四个字就是比较幸运。

我是一个不大喜欢闲着的人，所以在决定好校招offer以后，我过了十月份的国庆长假就直接去实习报道上班了。所以我对于我入职的第一天的日子10月9号记得一直比较深刻。那个时候上海的研发团队算上我才总共5个人，我参与了一个几何算法图形库的基础组件库的开发和维护。虽然我以前从来没怎么接触过计算机图形学并且一些高中的计算几何知识都忘得差不多了。不过好在大二的时候参与过一年ACM，脑子没算完全荒废掉。凭借着一点小聪明对于Mentor派发下来的任务都能比较顺利的完成。那段时间有一个我比较深刻的事情是我第一次提交merge request。那个时候研发组人少嘛，所以我的merge request就所有人都review了一遍，然后就指出了很多低级错误。让我最为深刻的就是我的那次merge request里居然忘记把调试时的控制台打印语句给删掉了。当时我看到Code Comment里面被人指出代码里不要加入控制条打印语句时简直都要羞愧到爆了。现在我经常给实习生做code review的时候，虽然我也经常会提很多意见，但说实话现在的实习生写的代码比我当实习生时写的代码好多了，也没有很傻的低级错误。诶，都是后话…

年初的时候，Mentor找到我希望交给我一个计算几何的课题让我单独尝试。这个课题非常小众，而且我当时也没任何计算几何的基础。不过当时凭借着一股迷之自信，我就没怎么多想的接了下来。这个问题算是平面计算几何里面一个比较经典的问题，即Nest Algrithm。当时给我的需求是提供一个服务端执行的算法包。当我搞清楚这个问题以后我就意识到这似乎是一个单纯靠我自己无法解决的问题。

好在天无绝人之路，万能的Github上面居然有这一个问题场景的算法Demo，而且效果居然惊人的好。但是最可惜的一点在于这个算法的Demo居然是Javascript写的，而我需要完成的则是一个服务端可跑的算法库。我看了看这个Demo仓库里的issue，不少都提到了希望作者提供一个服务端可以跑的算法库。或者是有人自己搞了一个计划准备做一个服务端版本的算法库，可惜到最后都不了了之了。于是我的难题瞬间就降低了一大部分，即只需要读懂他的算法然后用服务端语言改造即可。

于是自从十二月份开始，我就一开始针对这件事情做封闭式开发。由于作者的算法相较传统的算法使用的是临界多边形结合遗传算法去计算排列顺序的可行性，而对于这两块我又都是零基础，所以只能边啃论文边调试代码。说到这个调试代码也是一脸泪，由于这个算法Demo全程运行在浏览器端并且用javascript完成，所以我只能通过一次又一次的打印控制台里的各项参数来明白整个算法逻辑。

就这样一边啃一边调一边写，差不多到二月底的时候我的第一版服务端排版算法引擎就已经出来了。这当中经历了许许多多、日日夜夜的调试以及各类问题。比如如何在遗传算法中通过多线程并行计算来加快效率，和如何处理浮点数在进行几何计算时的精度误差等等。这些都是在一步步踩坑中，然后对很多地方再推倒重来的解决方案。

最终这个服务端引擎输入了当时原作者使用的测试用例Demo，最终得出了如下的结果。后来我将这些工作成果整理过后开源了出来，同时作为我的本科毕业设计，顺利毕业了。后来七月份还是八月份的时候，李青老师电话找到希望我给这篇论文写一个短篇杂志期刊，为我争取了一个优秀毕业论文。虽然没啥用吧，但是作为我大学期间为数不多的奖项，也算是一个善始善终吧。当然后面在七月份的转正述职上，当我再次提到这个项目时，我将它评价为2018年上半年我个人最满意的作品，没有之一。

在完成了上面的工作中，我就从三月份开始转去了国际站业务组开始后端业务开发之旅了。这个时候我的Mentor也换人了，实习期间的Mentor由我现在的主管@橙子担当，而技术上的指导则有杭州的@磊哥跟我远程联系。磊哥的代码写的非常棒，而且在技术上教了我非常多的工具、方法和思想。让我有一种过去Java后端白学了一样。感觉自己和他写的完全是两种语言。整个三月到五月基本上都是磊哥带着我写后端的代码，我也是慢慢从CRUD开始，然后一点点写复杂的业务逻辑。最终变成了几个服务的Owner。当我完全可以独立的负责这几个后端服务的时候，磊哥的历史任务也就完成了从我们组去了监控组开发了。

四月份的时候，我抽空回了一趟母校，然后在开源社区做了一次分享。比起那时候我大三的时候办开源社区分享活动，今年的开源社区热闹了许多。来了不认识的学弟学妹都过来听，非常开心。

五月份的时候，我开始梳理我们整个项目组的持续集成与持续交付。由于作为一个新的前台业务组，我们当时的情况是每个服务Repo自己控制部署节奏。每个服务自己在gitlab-ci上写好了各个环境的部署脚本以后，Owner负责部署到内网环境，然后在某个特定的时间点由主管将所有服务部署到生产环境。当时我正好接触到了Istio体系中的Service Graph。那个时候我们的业务调用关系还比较简单，可以看做是一个简单的拓扑图结构。当时我看到这个图的第一想法是这个服务间调用的拓扑图不也正代表了部署的部署顺序吗？如果有一个总控制台去每个服务的部署节奏，让每个服务部署时必须要所有先制服务部署完才能部署那该多好。于是凭借这个想法，我通过Gitlab-CI的API，单独完成了我们组的级联部署系统的第一版雏形。

整个六月份，我都在忙于挤毕业论文和处理毕业的各种手续，终于在7月初的时候正式毕业了。同时，我们组也开始紧锣密鼓的筹备校招和实习的事项了。当时来上大做校招的宣讲会之前，由于之前在大摩实习的时候碰到了不少大一大二甚至高中生的实习生。让我意识到其实实习这件事没必要从大三才开始找，所以我特地也去了大一和大二的年级群里做了实习的宣传。最终竟然成功招到了一名大二的学妹来我们这里做前端实习生。另外一方面，因为我一直坚持每个学期都来开源社区做一次分享，我觉得促进我们组来开源社区做技术宣讲的同时吸引更多的学弟学妹们来我们这里实习是一件两全其美的事情。在七月份九月份的时候我分别带了我们后端和前端的负责人都带到开源社区做了一次分享。

在工作上，从六月份开始我开始接触我们的组基础设施平台，Kubernetes与Istio。由于我们的组的所有服务都运行在Kubernetes，而我一开始对这个又毫无概念。所以光是了解Kubernetes我就看了不少的资料和文档，边看官网Demo边尝试性的在内网进行一些简单的操作，才一点一点看明白了K8S的整体架构和如何使用。在我们的文档系统里面，有两个目录专门用来记录我们在Kubernetes与istio上的最佳实践和踩坑经历。现在看下来这些文档我自己一个人这半年来总共块贡献了有三四十篇文档了。从刚开始被K8S一上来大量的概念而感到力不从心，到后面内网或者生产环境出现BUG时自己都跟在大佬后面看他们是怎么解决问题的。到后来出现问题时自己也能慢慢的独立解决。整个六七月份我的工作重心一直铺在国际站的基础设施建设上。慢慢的对K8S和Istio的使用越来越得心应手，我也顺其自然的被大家放心去管理建设整个项目的基础设施与负责生产环境的稳定性。 在那段时间我个人总结了一些管理和运维经验在博客上。

从七月份开始，我成为一个正式员工时，也成为了一个带实习生的mentor。对于带实习生这件事情，我是比较乐意的。因为我个人是一个乐于分享的人，有一个实习生能天天主动或被动的接受我的叨叨我还挺开心的。和实习生合作了三个月不到，从七月份成为mentor到九月份送走实习生回学校。当中的过程总体来说比较开心，但是作为Mentor，我事后回想过后给自己打分大概就是一个及格分。从我开始带实习生起，我给我们俩定位就在于我和实习生一起去完成我工作中的指标。所以为了保证工作能够顺利完成，我会将这些工作拆分成一些比较简单机械的任务交给实习生，然后将一些比较有难度或者比较有风险的事情交给我自己做。另外一方面，为了让工作能更快完成，某些比较困难的事情让实习生做可能需要花一天，我自己做的话可能就十几分钟就搞定了。于是我最终也是选择让我自己做。最终可能因为干的事情大多数都是没有挑战性，所以实习生在干完两个月暑假结束后就选择离开了。前段时间我和我主管One on One的时候，我谈论到了这件事情反思到对自己当时的决策比较后悔。我的主管告诉我其实交给实习生干一些有难度的活或者有些事我做的比较快，实习生做比较慢，但让他去做一样没有问题。只要我们能将任务的风险控制在一个可控的范围内，完全可以不追求效率和成本让团队内的其他人去做一些有难度和深度的事情。这样对于整个团队的成长是最有利的。

九月份的时候，我邀请了我们前端的负责人@影魔来到了上大开源社区来做技术分享。影魔大佬的技术分享说实话我个人认为是我2018年听到的最好的一场分享。在他的分享当中，他特意谈到了他从阿里干了9年以后出来加入我们团队有很大一部分原因就是想要去体验和整个团队共存亡的感觉。这个话给我的感触很深，让我意识到即使是为了我自己，也要开始考虑从如何更快的提升自己转变为如何更快的提升整个团队的战斗力。我觉得这句话是我目前为止从九月份以后加班越来越厉害的罪魁祸首。我会开始主动思考我们的后端服务架构是否合理，我们的部署节奏是否能够灵活支撑频繁的服务更新迭代。当我们业务的服务越来越多，临时用的小工具越来越碎，同时每个Sprint的Story Point越来越多，以及加入了很多新的同事以后。我开始意识到我们业务组从以前的通过某个临时的工具去解决问题的情况需要转变为一个完整的内部管理体系去统一协调。

10月份和11月份的时候分别参与了今年的QCon和KubeCon。QCon这个会议以前还在大学里的时候就已经听说过了，但是一直是以学生的视角走马观花的一样看了几场分享的资料。但是看完听完就完了，并没有留下啥感触。今年参加的这两场分享，第一次以一个已经工作的人视角去参加，这两场会议我都是直接直奔了Kubernetes与Service Mesh相关的主题会议。QCon参加了第一天，我之前也写了自己在QCon上的参会感受。

如果说在QCon上的ServiceMesh产品主角是蚂蚁的SOFA，那么毫无疑问在KubeCon上的ServiceMesh的当家主角则是G家的Istio。可以看得出来，今年整个Kubernetes话题上，大家都对新出来的ServiceMesh概念非常关注，尤其是Google主打的Istio。但同样也有阿里和华为在KubeCon上推荐自家的ServiceMesh产品，这些更多针对的可能是国内用户。值得一提的是，这一年的KubeCon上也有不少公司分享了自己在Istio使用上的探索和经验，以惠普为首。这让我感受到了单兵作战和小组作战的效率差距。不过让我感到遗憾的是，大部分公司仅仅是用了Istio，但并没有说按照Istio提供的工作来真正在生产环境上实现一些互联网的常见需求，这一点我有了一种我上我也行的感(错)觉，不过未来的目标之一确实是希望自己也能作为主讲人参加这种会议吧。

这个十月份同样还参与了ServiceMesher组织，并成功给ServiceMesh投稿Coohom在生产环境中使用Istio的经验和实践。有意思的是，通过这篇文章，我有幸被一些HR和出版社编辑认识，前者经常说要我找过去聊聊，后者则是鼓励我把这些经验时间总结成一本书来出版。 关于出书这个事情我一直在考虑，一方面非常开心有出版社找我写这方面内容，而且serviceMesh这块作为一个比较初期且前景比较明朗的领域的确是越早越好。另外一方面，工作上比较忙，而且说实话我对自己在这一块的深耕也并不自信，觉得自己学到的也只不过是些皮毛，只是起步应用的比较早而已。但是纠结归纠结，明年应该会开始构思在这方面的内容与方向吧，希望自己能做到。

最后是一些工作上的感悟，以前总是觉得一个牛逼的程序员/工程师应该要有自己的拿手绝活，这样才能提高自己的核心竞争力。来到国际站项目组将近10个月以来，从项目刚开始定下到现在已经在北美打出SAAS的市场，经历了一轮又一轮商业模式与目标客户的探索，数据运营与服务治理的搭建，以及敏捷流程与团队成长的建设。我感受到的是，在互联网模式，尤其是作为最前台的业务组，一定要不能将自己局限在某个领域里面，而是需要了解业务和团队从发芽到开花方方面面的思维和工具，不停的消除瓶颈与优化效率。以前的自己有一种程序员的定性思维，总是觉得各种工具或者服务要自己写和自己实现那才是最牛逼的，但其实这些工具明明在开源软件里就有成熟的工具和解决方案却不愿意去用。技术是要为产品服务的，而产品的最终目的就是利益，所以为了产品成功，工程师就应该首先要抛开技本位的思想，从ROI的角度考虑每一个决策，多用不同的思维和视角去看待产品和业务。（可以理解为互联网版的给钱什么都做)

以前在知乎上看到一个关于职场成长的金句，原文我记不大清了，原意是在职场发展中，在技术上成为一个高手固然厉害，但是更厉害的则是可以带出一个都是高手的团队。现在一想，在职场上跟对leader很重要，好的leader会为了团队成长而培养每一个人，最终形成一个有战斗力的团队，那么在业务上的成功也是迟早的。很开心这一年能在国际站团队学到这些。下一次上班又是新的一年，新的工作内容。