摘要：
墨玦，阿里巴巴 iDST 高级技术专家。博士毕业于北京邮电大学，计算机应用专业，目前主要从事语音技术工程化方面的研发。回顾在阿里的三年时光，他感慨良多，写下了这篇总结，与大家共勉。
博士毕业工作以来，最大的乐趣就是学习和深入思考。所以，从来不以工作过程中项目或者业务的简单或者复杂而困惑。对自身的发展，我一直有一个明确的指导方针：一步一个脚印，提升自己解决问题的能力，不给自己设限。我大概在10年前面试一个40岁的大叔的时候，就认真地思考过，结论是：我喜欢写代码，我会为此坚持一辈子。
一、既然这个项目这么重要，我们就干吧
回归正题，总结一下在阿里最近3年的工作。前两年，我主要在御膳房数据引擎团队做猪头小队长，聊两个重点经历的项目。
第一个就是5k+，一个通用大数据平台。刚去一个月就赶上这个集合京杭两地的大项目，确实蛮幸运的。在这个项目中印象深刻的有几个地方吧，一个是立项的时候参与方案的讨论，因为涉及京杭两地、跨部门、跨团队的沟通，各个团队的老大难免在一起相爱相杀，我们一帮小弟在旁边参与讨论。一直相杀到凌晨的时候，在自由发言的阶段，我实在忍不住，跳出来说：既然这个项目这么重要，我觉得我们就干吧。真的是仗着自己在创业公司积累的锐气跳出来说这一句。我觉得大不了就是拼啦。
我说完就意识到这可能给自己的老大带来了巨大的麻烦。很幸运我老大也早就扯烦了，站出来承担责任，一时间各个老大分别出人出枪，一时间群情激奋。最后的责权分配在20分钟内就完成了，甚至一位老阿里都哭了。
感谢那一晚上的感觉，也感谢阿里给我一帮很棒的队友和老大。永远记得，后面996两个月，在京杭两地互换出差的过程中，我负责两个小模块的项目管理，我发挥自己解决问题快的能力，哪里有窟窿我就去哪里堵，当然，整个团队的人都非常强大也非常努力。在最后项目结束评奖的时候，我拿了个最佳救火队员奖，我真喜欢这个奖。
虽然我也是项目的PMO之一，但是除了打酱油，更多的是观摩和学习阿里的项目管理和组织协调。这个项目真的很难，做的过程中经历了各种妥协，项目完工后我们又断断续续还了一年的技术债，但是当时那种拼搏自己和燃烧自己成就BIG ONE的感觉，再难重现。后来也跟一些其他公司的同学沟通关于数据平台构建的事情，发现我们真的走得很远。因为是写自己的感受，就不表扬其他同学了，要不然写一本书都可以啦。
二、这不是我一个人的工作，只是努力使它变得完美
第二个项目也带有我自己的强烈特色，我们一直被业务压得很紧。但是对于引擎层研发来说，团队成员也有自己的诉求，而且，系统要逐步完善和改进。在5K+项目完成后，我们依赖的一个重要模块开始频繁出现问题，随着团队间沟通的深入，我们发现对方团队的不稳定和发展方向不确定导致这个模块未来风险非常高。
我们首先想到的是部署一套新的作为过渡。在过渡阶段，为了完成业务的同时来做这件事，我把团队两位同学的一部分业务工作承接过来，腾出人力开始做这件事。两位同学远赴杭州，出差一个月，把平台基本接过来，保障了我们业务的平稳运行。
随后，我们调研后果断抛弃了这个模块的原有实现，调集团队的技术力量重新规划设计新的模块，除了替换，更重要的是为了发展。这一步走出后发现后面很多东西都活了，数据服务开始作为一个重要的点慢慢从整个平台浮现出来，与数据团队产生更深度的互动，进而随着原数据服务的不稳定，催生了新的数据服务平台。
这不是我一个人的工作，我只是努力使它变得完美。当初万分纠结，每一步都步步惊心，现在相信每个参与这个项目的同学，心里都是美好的回忆。而且，我们不仅通过这个项目成就了自己，更成就了兄弟团队，成就了御膳房的发展。说大了。
三、技术挑战是猎物，是机会，是战功
在这三年里，我不认为自己遇到了很大的技术挑战，很多事情提前想到，组织技术专家提前讨论，当和团队在一起的时候，技术挑战是猎物，是机会，是战功。
举一个简单的例子来说明我做一个项目的过程，例如：我们要实现一个限流的服务，就是允许一个租户的QPS最高多少。首先需要界定问题的边界，包括：要不要考虑网络层攻击(可能被其他模块处理掉)、未来一段时间业务的规模，系统稳定性、架构扩展性等。
这些问题确定后，会有一系列的技术方案成为技术选型，那么如何判断采用什么技术方案，当时不是最新最酷的最好的，要考虑将来部署环境，上下游环境。最重要的这是一个分布式需求。简单来说，N台服务器共同维护一个QPS值，这后面的分布式理论，朴素来说就是CAP，在CAP三者不能同时满足的情况下，应该降低那个并保证业务的目标。
为此，我们参考分布式的BASE模型，降低了一致性的需求，采用分区和主体配额池结合的思路解决了大租户的流量控制，而针对长尾租户采用了另一套控制来保证精确限流。
同时考虑第三方模块和非关键模块挂掉或者降级中的应急预案，以及模块部分宕机或者机房断电导致的服务不可用，以及某些服务的单点问题等而设计完整的稳定性方案。当然，最后还要考虑扩展性方案，如果需求规模突然变大，但是整体是有边界的。
总结起来，整个项目要有明确的目标和阶段以及对应的关键指标，做到可观测、可评估、可扩展、可恢复、以及容易交付给其他人继续研发和维护。我不认为自己做得很好，但是当逐步完善一个系统时，真的蛮快乐的。
四、我不认为做到35岁转管理是必要的
现在细想起来，在我的成长道路上，给我提供技术指导的大牛真的很少，更多的时候，我更喜欢向任何一个我遇到的人学习，我学习的目的不是超越别人，而是超越自己。
转岗到iDST团队后，我坐在iDST老大的旁边，有幸耳濡目染研发和管理达人的工作，受益匪浅。我一直觉得，程序员没有人能教会，要的是自己的钻研和用心的学习。包括我原来御膳房团队的同学和现在iDST的同学，在合作和交流中，总能发现那些令你眼前一亮的优点和闪光点，这如何不欣喜？
另外，我觉得保持持续的思考和以开放的态度与其他同学沟通非常重要，互通有无。我觉得我目前最大的技术优势可能还是在工程领域，主要是服务器后端研发以及数据平台建设这边，主要是思考和经验比较多。我会在理论和实践两个方面继续增强自己的能力。与此同时，我一直在储备自己在人工智能方面的知识。得益于我博士论文期间在信息检索方向的深入思考，我很早就发现了这个能让我着迷的领域。
这里稍微聊两句人工智能领域，虽然一些人说这里面也就是所谓的调参、特征工程、训练深度网络等。这些真的是门外汉才会这么说。真正里面需要的是理性的思维，解决这种没有明确的路径可寻的问题需要非常深入的思考、尝试，经历无数次失败可能有一点小收获，然后还要把这种小收获用最精准的数学语言阐述出来，为后续的研发铺平道路。
目前我刚刚读完NLP领域的一本综述——《统计自然语言处理》，正在重新构建自己的概率论和统计学的知识体系，尽量做到基本的概念信手拈来，然后找一个小的领域进行深入的思考和尝试。对于我来说，找一个点建立一个模型，改改参数出一篇论文的诱惑不大，我希望能够研究前人的研究成果，在理论深度有一定的突破。
在这个领域，那些谈35岁就转管理的程序员可能根本就无法明白。当遇到一个可以持续投入精力去钻研，并且越钻研觉得越难的事情的时候，对于我来说，何其幸运。更何况，我不认为做到35岁转管理是必要的。管理并不好做，很多人以为管理就是分配工作，技术人员都是心高气傲之辈，能力低的根本领导不了，只能领导能力更低的。而且真正的管理和写代码一样，也是一门学问，一门理论与实践相结合，需要边探索边实践的学问。人家让你领导，是把自己的发展托付到你的手里，所以是更重的责任。from 朋友虞老板拍摄，当我们吟诵春风不度玉门关的时候，玉门关其实是这个小土坑了。所以要辩证思考那些流传的话，比如35岁前必须转管理。
我主要利用上下班路上的时间来做机器学习的钻研，每天大概3个钟头左右，上班时间主要还是写业务代码，我热爱写码，调通一个功能的感觉真爽！最后想说的是，在阿里，一样经历繁华，经历迷茫，经历失落甚至冷落，最重要的是守住自己的技术之心，与大家共勉。PS:下面给大家分享一份成为高级工程师学习路线，如果想学习Java工程化、高性能及分布式、深入浅出。性能调优、Spring，MyBatis，Netty源码分析的朋友可以加我的Java进阶群：288351179 ，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
