技术发展背后的那个人～～

昨天关于淘宝开放平台技术部分的分享看到有些同学留言说有这样的机会和环境是幸运的，的确在阿里这些年赶上了公司的发展，赶上了互联网技术的发展，是幸运的，但是背后这个普通的人，从进入公司的低级程序员一步一步成长起来到底是怎么走过来的，也许可以让一些正在走的同学有值得思考的地方，我尽量少加一些自己的收获在里面，因为每个人看到这些场景感到了什么那就是什么。


2005年：
毕业4年多在一家通信国企做的顺风顺水（不是自己能力有多突出，是老板经常被挖，所以提升的不错），总感觉有点养老的味道，于是开始在招聘网站投简历，没想到一家叫阿里巴巴的杭州公司联系上我去面试，聊下来是类似于后台运维部门，兴趣不在此，就拒绝了，但其实埋下了伏笔。


2006年：
刚过完年，那家阿里的公司HR又联系我，说这次部门不太一样，去了，然后说了一些关于Work at alibaba的想法，那时觉得互联网要比通信企业更有意思，所以不顾家人和未来老婆的反对（当然其实还是非常支持我任何决定的，只是国企安稳让他们觉得放心），辞职去了这么一家以前都没听说过的企业。进公司以后，一切归零，工作四年后又从底层做起，虽然忙碌，感觉充实。半年后开始觉得有些无聊，该学的都学到了，剩下的就干一点常规的活，啥 work at alibaba 又没影了，只看到很多高P作为架构师进来，心里落差很大。（就和现在很多状况一样，人际关系好，连带推荐进来的都是高P）


2007年：
突然被征召“入伍”，20来号人被拖到老马的福地“湖畔花园”创业去了，我的感觉就是莫名其妙，收购了一家公司（主要做CRM系统框架和模型驱动），然后就开始要搞创业了，不过起码work at alibaba的说法有找落了。一帮子人窝在3室一厅的房子里面，不同业务团队分在不同的小屋子里，测试和架构团队在客厅。没错，“架构团队”，收购来的公司人都是架构团队，我们这些“业务人员”要做的事情就是使用架构团队的框架，然后配置xml来搭建CRM系统，当时salesforce火啊，老大们收购了这家公司打算大干一场。每天早晨7点出门，9点到湖畔花园，晚上11点打车会城东（当时住在钱塘江边上，每天就是横穿杭州城）。这是来阿里的第一年，我开始反思我当年头脑热要丢掉一个安稳又发展不错的工作，来这里找罪受，我更新了招聘网站的简历，周末有空的时候会去投一些公司。老天好像很不给机会我，居然2个月没有一家公司找我（这些年却有些公司看到了我当年的简历，问我是否还在老公司需要换工作#_#！），于是我安心了，每天除了配置xml，偶尔也开始看看架构组的框架代码，架构组人少，需求＋bug已经把他们的队列排到了要执行discard policy了，我开始自学更多javascript和java知识，来帮助他们来修复我们提的bug和需求，虽然我没有主干权限，但本地测试还是可以做的，就这样我修复，他们检查，然后合并到主干，我很充实，他们也很满意。差不多大半个月后，架构组的老大（直到阿里软件解体都是我直属老大）找我谈话，问我是否愿意加入架构组，怎么可能不愿意呢@_@，于是我进了架构组。（此时我非常感谢招聘网站的石沉大海，让我这个年轻气盛的人坚持下来了）事情到这里开始发生变化了，虽然我是个没有背景的小兵，但老大还是给了我足够的机会，我没有去做业务支撑，反而成了团队里面做基础系统的，这里每个人的level都比我高2级，于是我背着“架构师”的名字开始努力奋斗。
到了下半年，基本上我们开始抛弃了以前架构部从老公司带来的代码，开始设计自己的平台，服务化成为新平台的目标，SOA火烧到了老板这边，自然我们也开始响应，SCA，OSGI（也就是学习这个的时候和毕玄同学相识），当时为阿里软件写出了第一版SOA的框架：基于SCA协议实现的服务化框架。当时菲青老大是淘宝新来的首席架构师组织了全集团的架构团队周期性的交流会，感觉分享和收获都不少，对这个框架信心满满。阿里软件技术部门的高P们和老大们也支持大力推广，结果部门大运动，业务团队争相配合完成切换（这种事情放在淘宝基本不靠谱，其他几家公司都有可能），推行后发现稳定性还可以，但是调试，开发成本都很高，带来的好处服务化作用却对团队来说丝毫没有感受到。当时的我总感觉“架构”么，就是要有前瞻性，困难总是有的，业务团队需要自己思考和解决，有问题可以找我帮着搞定，就这样被动的推进着。不久内部还是反弹了，高P们全部反戈说这个不行，我开始吸取教训修改的更易于开发调试。于此同时另一个架构师也写了一套，就用Spring和私有协议来做服务框架的服务化和隔离，框架束缚小了不少（SCA规范还是比较重，WebService所实现的SOA本身就是源于企业化服务框架，当然比不上Spring这种天生互联网开发模式），最后老大拍板，全部换掉。我那个痛苦啊，换掉以后问题其实有所缓解，但最终问题还是一样，团队对服务化的理念和价值完全没有，就好比你一定要让写delphi的人理解MVC一样。不久以后，突然因为要做开放平台了，SCA框架的优势又凸现出来，想要考虑可以拿出来再用，我说，算了，就让它封尘吧～～～这一年我想起了我鄙夷架构师的那段时光，想起了我只不过是丢到一群鸭子里面的一只鸡，我的level还差他们不少，我的底子也不够好，在这里我很幸运，幸运的是能够有机会修练内功，我开始写blog，开始用blog认识更多的人。（回顾起自己的技术发展很多时候还是blog帮助我确定了时间点，大家在看技术发展的时候完全可以对照blog的timeline）


2008年：
菲青老大加盟淘宝，成为淘宝的首席架构师，菲青组织集团所有架构团队的同学定期聚到西湖边上的“淘咖啡”（现在已经没了），相互间交流技术，我这毛头小鬼，托毕玄的福也被拉了进来，也就是这时候知道支付宝在做类似的SOFA，淘宝也准备启动HSF，而阿里软件的ASF已经成过往，我继续研究WebService的安全，效率，通信的内容，虽然不是多大的架构，但非常接地。这个时候，菲青找到阿里架构这边要谈合作，希望阿里软件做开放平台，淘宝将服务从阿里软件开放出去。阿里软件对开放平台的合作有兴趣，但初期也比较看不清楚价值，因此投入我一个人和淘宝半个人（自雪同学）一起来搞这玩意儿，2周时间，出的来继续走，出不来就结束。翻着yahoo的网站，看到了flickr（记得今年年初的时候还谈当年的flickr是最能够成为今天FB的公司，结果给雅虎浪费了）的开放模式，于是照猫画虎，还就搞出了一个看起来还有点摸样的东西。接下来我的主业就放在这块上面了，这一年技术成长很快，因为开放平台是新事物，安全（数字签名，授权，加密），数据处理（xml解析各种基础知识，json的规范），REST代理服务器实现等等，这些都是互联网的产物，都非常扎实落地，充实的日子过的总是很快。


2009年：
阿里集团的不同公司的氛围是完全不同的，阿里软件团队氛围还是那种强调自上而下的管理，加上一些关系纠缠在里面，我这个苦脸coder一直都不入流，因此也想换换环境，加上看到当时HSF的成长中菲青老大能抗的住压力让毕玄最后坚持下去，心里还是酸酸的，但HR和boss的左手大棒（你去哪家公司我们管不了你）右手胡萝卜（晋升名额本来就是你的），我能做什么呢（那些日子的经历让我记忆犹新，也许当时运气太好了吧，在淘宝快3年多了，每个HR都让我觉得受宠若惊）。4月的时候，我和我直属老大说开放平台我做到6版本就封顶了，没法做了，已经快两个季度都是我自己给自己提需求，这个产品从技术角度上支撑1年以后这样的业务都没有问题了，再做一些新功能就是耗时间了。其实说白了，当时阿里软件和淘宝合作的关系已经变弱，一来阿里软件业务与淘宝冲突，二来两个公司合作还是距离太远，对开放平台的需求慢慢的都再往后走，而我也感觉到了自雪同学慢慢的把很多阿里软件开放平台的架构拿过去结合淘宝自身体系开始构件内部的平台。而阿里软件一直还在平台和产品间纠结（到最后一季度一换目标），所以业务都不明确，怎么会顾及到平台。不过还是非常感谢我的直属老大一直给我空间（他在阿里软件解体以后回到成都），如果没有他估计老早被排挤到哪里去都不知道了，当时老大说你想做什么就做什么吧。因为当时Memcached这块做的比较深入，所以考虑给整个阿里软件做全公司的缓存中心，好比今天淘宝的Tair集群管理。但世事难料，年中的时候突然宣布公司解体，就这样我们笑话的说我们把公司搞没了，很多人非常伤感，我却非常开心，因为我有机会去淘宝了。不过另外一个问题出现了，阿里软件业务团队合并到B2B和淘宝，架构团队留下和阿里云团队合并，阿里软件番号给阿里云，这意味着要带着开放平台留在阿里云，这比阿里软件留着开放平台还要危险，因为当年毕竟阿里软件还有部分业务通过开放平台开放，而阿里云当时还没有任何业务。虽然外界对王博士评价不好，但博士本身人还是很平和的，最后我做好了所有的分析和架构设计，给阿里云留了一个后续统一集团开放的方案，然后带着没完成的开放的理想去了淘宝。


2010年：
空降淘宝，虽然新老板对我能力比较认可，但是淘宝的开放平台已经有了一个10个左右的小团队了，如何融入是最迫切的。我缺乏的是业务，了解的是平台，能力在于技术，于是天天帮助团队同学打杂，解决问题，慢慢的也用能力证明自己。一直处于一个团队攻坚和打杂的角色，技术能力还是得到了飞速的提升，因为这一年开放平台正式商业化了，对于基础平台的要求非常高。但这一年也有些不好的评价对我，有些同学觉得我太强势了，对于团队成员的发展会起到反作用，顺风顺水的我依然觉得用技术说话，判断力取决于技术能力。（我用一句话评价过自己：智商还可以，情商比较低）这一年由于平台发展太快了（4千万一下子到了8亿），所以所有的矛盾随着业务的发展被掩盖。


2011年：
经过一年多的基础平台建设，整体平台架构已经比较完善，而我的角色开始显得有些尴尬，叫架构师，但业务管不着，技术管一块，不带人，干活自己做。后来这年有个毛头小伙子听了我的课死活要加入开放平台（技术大学第一届），因此他成了我第一个徒弟式的同学，然后加上我是淘宝第一个做App OPS（原来运维是独立于开发的，后来因为希望给开发更多空间，所以允许有开发有能力的人自己管理系统基础运维和发布，这类人被叫做App OPS），另一个还在实习的愣头小伙子也成了我的徒弟式的同学，就这样我这个架构师有了一点人员资源干点可以干的活。这一年我已经不仅仅满足与技术，因为我又体会到了阿里软件开放平台的感觉，一个季度的需求都是自己提给自己的，我要更多的了解淘宝，了解开放能够支持到淘宝什么，不希望总是告诉我你把稳定搞好，安全搞好就好了，其他你就不要管了。8亿30台虚拟机，19亿还是30台虚拟机，4台虚拟机可以分析19亿的日志，我不想再停留，再安逸的过活。加上平台稳定以后对我个人的需求减弱，因此很多矛盾就慢慢凸现，我个人也有些焦躁不安，希望得到信息能够做更多的贡献，但给我的答覆就是你是架构师，做好稳定，安全就好了，不要管什么业务。这一年的年底，我提出了换个岗位的想法，去哪里我不知道，做什么我不知道，对我来说只要能够有个地方需要我的能力就可以，既然我不能碰业务，我就做好技术。
事情总不按每个人的想象走，最后组织结构调整，开放平台技术部分人员可以让我来管，看我是否能够留下来，我比较坚定的要求就是我要带产品和技术两块，可以想象的是，老大看着一个从来没带过人的P，突然要带人了，还要带产品，那有多忐忑。最后为了风险可控，开放平台技术两个技术核心团队留给我，其他两个团队拆分，给我一个产品经理，其他产品经理还是统一组织管理。我给老大的承诺是：一年，除非老大你炒我，否则我会让你觉得放翁说道做到。


2012年：
事情就这样开篇了，我开始带人了，开始跑业务了，象块海绵一样吸收各种信息，和三淘的各种团队打交道，作技术的久了总以为自己对业务很熟悉，能够分析出产品需求，当你真实的去做了，去落地了，你会发现这个世界在变，淘宝这个甲方的身份在变，开放平台能够承诺的事情落地是多少不容易。半年里面，人变化了很多，因为了解的更多，学会了更多的倾听和学习，学会更多的谦虚，遇到了很多好朋友UED，测试，PD，这些人真的是为了开放平台而不顾我们组织结构调整到天猫继续支持着，很感动。技术上更多的放手，很开心的是团队的每个人都在成长，当年“放翁的分析器”，“放翁的PipeComet”，“放翁的安全”都成为了开放平台的xxx，如果说有一天要离开这个团队，我最不舍得的还是这帮兄弟，因为我有心血付出在这些人身上了。另一方面，因为带人，让我更迫切的去拓展业务，利用技术来落地业务，为技术团队的人员成长创造更多机会。
而这一年正好是开放平台5年了，就和技术发展里面说的，技术是开放平台前5年的驱动力，业务是开放平台后5年的驱动力，技术5年的内容可以通过3个月复制过去，开放一年业务的折腾是三淘如何借势转身的关键，最近有文章关于淘宝开放边界的迷茫，其实迷茫已经过去，只是是否三个公司实施的人最后靠谱的落地这关键的一步棋，做开放平台的人心里清楚就可以帮到团队，也帮到自己。


最初打算写这个内容的时候有很多想写的，但是发现写完了就是一个乱，呵呵，权当看故事吧。总结几句话：技术耐得住寂寞，低谷积累高峰冲刺，主动改变一切，找到自己的特点，没有问题的时候最可怕，不同阶段追求不同的收获，先听再说，永远都要清楚你到底要什么！
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－


下面是自己的一些问答，觉得不靠谱一笑而过，不要纠结，觉得靠谱也不要相信，因为我上个月说的话，下个月可能就改口了：）


怎么看待老板？
老板就像老婆，他能容忍你的个性就是最大的幸福，不要期望他成为你的老妈，对你百般照顾。要换老板的时候看看离开了他是否一样找不到“幸福”，如果是，那么问题在你，“离不离婚”其实不是那么重要。


怎么看待技术重复造轮子？
coder那么多，有时候重复造轮子也不一定是坏事，也许比直接拿别人的东西来用要靠谱，毕竟高P不会分工资给你的兄弟。原则就是对产品负责，对人负责，两句话很简单，作技术老大的自己把控和判断。（做不到只能说明你还处于被技术玩的阶段）


怎么看待开源？
当年写了一个Memcached的客户端，阿里软件一直在用，就一直维护和更新，到了淘宝用Tair了，那个就废弃不更新了。有时候对于国内的公司的开源，我更倾向于叫做“晒代码”，只有自己参与，一旦自己不用就Over了。授之以鱼不如授之以渔，多把设计细节和代码片段分析说明作详细了就好了，至于开源，对于一般的业务或平台团队投入成本太大了（一来自己都保证不了几时内部都不用了，二来开源和晒代码最大的差别就是易用性和文档及长期更新），专职做基础设施的团队可以（操作系统，数据库，存储等）。TOP技术分享月结束以后会把几个核心系统的设计和细节优化代码说明晒出来。


怎么看待晋升？
对晋升的人来说：
1.有时候不多想反而就成了。（因为你脑子只有一个，想多了这个，该想的就没想了）2.挫折未必是坏事。（我唯一一次被一棒子打回来的时候，头晕目眩，现场什么都好，结果就不给理由的说no，但最后老大一句话点醒：如果不能承受这样的结果，你的心胸就还不够那个level）
对Leader来说：
1.给兄弟们创造更好的环境，你不是管人来的，你是来“创收”的，管人谁都会，“创收”才是真本事。2.让兄弟放心的去做事，自己做好各种准备来帮助到他们。（了解晋升真实的考核目标和需求）
一句话：人都要养家糊口，都要付出得到肯定，以心相待。


怎么看待带人？
我告诉自己最多就只能带20个人左右（现在就这个极限了），一个团队必然工作有差异之分，但是让每个人都能够满意和满足就需要让所有人认同这个团队要做的事情，以及每一步的结果都是团队的结果，这个时候个人觉得靠“管”其实不太靠谱，更多的是靠“感染”。“感染”能力随着精力分散到技术和业务中一定是有限的，当然梯队化的感染需要每个梯队环节都能够做到位，那么就牛叉了。
一句话：先让自己相信，别人才会相信，每个人都相信了，人就不是“管”出来的。（理想很美好，现实很骨干，有时候自己就说服不了自己）


怎么看待技术兼顾业务？
我第一个小软件也是修改了flash文件将操作光驱的代码植入，然后调研了各种业务场景，最后成功的传播出去并操纵了一把，那时我就默默的感到传播才是关键。今天也是如此，我和每个程序员包括我老板一样担心我自己分心到业务上是否会废了自己的“武功”，其实取决于：1.你到底code了多少代码？（你会因为一个月用叉子吃饭忘记怎么用筷子么）2.你到底是喜欢写代码做技术，还是为了生活所迫？（后者无论你写多少代码还是一个没内功的人）3.写了10年代码以后你留下的只有那些代码和技术入门文档，还是有更多的设计理解。（你用了hadoop除了会配置，会修改部分性能代码，对他适用场景的理解，整个流程的瓶颈点设计，所有分布式都纠结的问题是否有感知）这么多年了，为什么只有那些paper不断的给人启示去做更多的工程化内容，因为用筷子吃面和叉子吃面没那么大的区别。（关键是吃的人怎么理解面难吃的原因）
所以，前面1,2,3都是你在coder时候做到了，那对业务的理解只会让你如虎添翼（重要的是更多去学习和倾听，放空自己的程序员经历，做个用户）


怎么缓解PD和开发的矛盾？
开发角色：
1.开发要把PD的客户作为客户，而不是把PD作为客户，就和走棋一样，你会比他更能主动的把控下一招的变化，不会纠结于PD不断的变化。2.量化！如果产品无法量化结果，无非就是需求不明确，所以追问。
PD角色：
1.数字是基础但不是全部。2.多一点兴趣爱好，多一点思考。blog当年如果没有浏览量这个数字会怎么样？微博为啥要搞个双向关注才可以评论的设置？音乐播放器如何在用户不点击like反向收到用户喜好行为？


怎么看待平台产品？
先要活下来，服务好一个产品线，如果没有任何其他产品线过来，那么就不要在乎平台的称呼，留好口子就可以了。当有多个产品接入，同样要活下来，因为脱离单一业务线为了更好的平衡个体需求和平台发展，但重要的是要找到自己有群聚价值（也就是只有集成在一个平台上，多个业务得到的平台功能才会最大化），这样就业务方就不会独自建立平台来快速响应需求。最后如果业务非常繁荣，那么更多的考虑为业务方挖掘业务价值，而不要聚焦于平台，帮助别人就是帮助自己。（这是平台永远都正确的说法）


如何学习技术？
不用急着什么都学，珍惜每一次不同工作的机会，挖深做细，几年以后回过头来原来自己积攒了那么多！xml解析分成几种模式，各种解析的优劣？http 1.1协议中的Header中的缓存设置，返回头里面的trunked什么用途？分布式计算关键问题是什么（调度，协同，数据交互）？应用压力测试瓶颈如何评定，导致瓶颈的代码所属操作可能分成哪几类? …… 要留下更多疑问背后的答案，而不仅仅是那一点代码，那一些入门文档。


太累了～～～


coder活下来很容易，活的好不容易，好像各行各业都是这样，所以coder和其他行业的人一样，技能仅仅是一方面，更重要的是人的素质和能力，你要活的被动，那么生活就会赶着你走，你要活的主动，那么你就可以走走看看。


题外话：今天上午爬山回家，公交车上看到一对夫妻都是盲人，心里一阵感慨，如果自己看不到，还有活着的勇气么，因为我们今天那么脆弱的抱怨很多事情，当你看不见的时候那是怎么能够抗得住的打击。