《进化——我们在互联网上奋斗的故事》一一1.4 从精兵到强将 —

本节书摘来自异步社区出版社《进化——我们在互联网上奋斗的故事》一书中的第1章，第1.4节，作者：北大首届互联网CIO-CTO班全体同学，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.4 从精兵到强将 ——技术人员的职场发展之路

进化——我们在互联网上奋斗的故事

因兴趣而进入互联网行业

2000年，踏着世纪交替的步伐，我走进入了西北工业大学，学习航空飞行器动力专业而不是计算机专业。在入学之前，我就对计算机有不小的兴趣，进入大学后经常去学校图书馆或实验室上网，对计算机的兴趣越来越浓厚，就去图书馆找一些网页设计、网页特效等书籍学习并动手做一些练习。之后我就很喜欢用263的邮箱，因为它的邮箱支持自定义网页格式，我可以给同学和朋友发送自己设计的个性化的网页格式E-mail。那时很多同学对计算机接触还不多，这样的感觉非常好玩，也很有成就感。2001年，全国多所大学开始设立国家示范性软件学院，成立软件工程专业，允许学校内其他专业的学生转专业到软件工程。我得知这个信息后告诉了父亲，在征得父亲的同意和支持后，在大二下半学期我通过学校软件学院组织的考试，转到软件工程专业，成为软件工程专业的一名学生。

2004年，我大学毕业，由于软件工程专业注重理论和实践结合，加上自身兴趣，我在校期间有较多的个人及团队小实践；如做过模拟的图书电子商务网站、写过C++的俄罗斯方块、模拟聊天室、Java的图形小游戏、EJB的学生管理系统以及利用H.263压缩协议实现的视频聊天（在我调试通过，成功在另一台计算机看到自己的视频的时候，那种兴奋无以言表）等。这些可能和腾讯的招聘需求比较吻合，我成为那年我们学院唯一一个被腾讯录取的学生。

十年技术之路——初入职场

从2004年大学毕业到今年，我正好工作了十年。回顾自己在腾讯的十年，从最初大学毕业初入互联网行业的新兵一个，到现在带领团队负责腾讯社交网络事业群所有自研业务的运维工作，我经历了很多历练，也成长了很多。

刚进入腾讯时，我主要工作是业务开发，比如QQ交友、QQ音乐等开发。到了2005年年初，部门正在紧张地筹备着QQ空间，这是一个很多人没有想到会如此受欢迎并引领未来很多年中国互联网Web 2.0时代的SNS产品。而我则有幸成为这个不到10人，开始只有我的导师、Leader以及几个和我一起入职一年左右的新人组成的QQ空间研发团队中的一员，负责完成了日志和留言板模块的开发。在2005年左右，中国互联网还主要以Web 1.0为主，几乎没有QQ空间这样可以有自己个性化网上地盘的产品，产品上线后非常受欢迎。在公测阶段，我们采用了类似现在各种邀请码的形式——英雄贴来引入用户。我负责所有英雄贴的生成和发放，当时公司内外的BBS上都是求QQ空间英雄贴的，非常火爆。而更加个性化的自定义模块功能也充分满足了年轻人喜欢炫酷和自由发挥的特性。就在这样的背景下QQ空间业务出现了爆发式的增长。

在顺利完成日志和留言版模块后，我的Leader找我，希望我来做负责人，和另外4个比我还要晚一年左右进入公司的同事，开发一个精简清爽版的QQ空间Izone供当时的企业版QQ TM使用，满足办公和商务用户的需求。开始我还有些犯嘀咕，心想一个模块我可以搞定，但一个完整的业务，需要协调不少人，有更多的技术环节，心里没底。我的Leader鼓励我说：“遇到困难我会安排资深同事帮助你们解决，另外也要相信自己，而且精简版空间最核心的功能之一就是你负责的日志模块，都已经做过了，还担心什么”。在Leader的鼓励下，我和其他几个同事经过几个月的紧张开发测试，顺利地发布了TM版本的QQ空间Izone（后来简洁版空间和QQ空间合并成同一产品）。

与此同时，由于注册用户和访问量的快速增长，QQ空间的性能问题逐渐暴露，经常出现各种打不开的、加载慢等故障和问题，急需优化。可能很多用过QQ空间的人还记得当年登录空间提示同时在线人数过多需要排队，引导用户去玩一些小Flash游戏的情景。为了保证用户的良好体验，项目组决定将大特性开发暂停一段时间，将团队分成两部分，一部分负责性能优化，一部分负责日常版本开发。而我则作为运营开发的PM负责日常运营版本的开发，同时也兼顾了很多运维建设工作，比如自动化的编译系统、深入业务特性的监控容量系统、数据在线迁移方案等。

这样两年多的“全栈”式开发及运营，使我的综合能力快速提升，为后来从事运维工作打下了坚实的基础。

十年技术之路——转型运维

2006年开始，公司开始流传一个名词叫D/O分离，也就是研发和运维工作分离。我所在的业务系统也成立了专门的运营部，逐渐接管了很多业务的运维工作。QQ空间由于正处于爆发式增长，业务复杂度及运维挑战度比较高，需要很熟悉业务的人才可以支持好，所以领导计划从研发团队切入到运营团队，而最合适的就是我和我的团队。此时我面临的选择是转做运维，还是继续留在研发线。我的Leader找我说，如果想留下来继续作研发，最好早点提出来，如果正式转到运维后，再想回来做研发，在公司推行D/O分离的背景下，可能就比较难了。我当时确实有过犹豫，甚至后来有时候也会想，如果当初我不转运维，现在又会是一个怎样不同的发展。但当时空间业务确实面临很大的挑战，我和我带领的四个同事由于还承担了很多运维的工作，也做出了不少不错的成果，有普适推广价值。深思熟虑之后我选择了支持公司和业务的需要，在2006年年底转到业务运维，逐渐转型进入一个在当年搜索引擎上都搜索不到定义的细分技术领域——业务运维。但现在回头来看，正是由于有过两年多后台前台都要做的所谓“全栈”工程师一样的开发经验，以及经历一个爆发式增长业务的磨炼，我在运维工作中有很多优势，后来快速成长为公司技术运营岗位的T4专家。

刚开始D/O分离的时候，发布无疑是业务运维人员的一个必修课和主要工作内容。操作方法主要是通过后台控制台手工或脚本发布，变更风险高，对人的依赖强。我进入运营部后所做的第一个尝试就是将发布从后台转换到前台来，利用团队在QQ空间业务已经实现的自动编译系统，完成了通过前端界面上的按钮点击来对代码和文件进行拉取、编译、上传测试机、上传发布机、发布等全流程界面操作，并想办法用实时管道模拟控制台的信息滚动效果。这个尝试或许是当时公司内第一个把运维操作从控制台搬到前台实现可视化操作的尝试，并最终和一个公司级的发布项目联合。有同事专门进驻到我们团队调研并联合开发出一个统一的发布系统，并不断完善沿用至今。借助发布系统的不断完善，我们在一两年后和测试团队讨论达成一致，由测试团队同事在版本测试通过后发布日常版本，因为这样既减少了在各类环境同步代码时测试团队同事的等待时间，又减少了运维同事的工作量和压力，可谓双赢。直到现在，很多要做发布的运维团队对我们的模式还是非常羡慕。

我从2007年年底成为运营规划组组长，2010年年底成为运维副总监，角色从单一运维业务逐渐转变为负责所在系统所有业务运维相关的规划和建设工作。在这个过程中我和团队一直与研发线保持很好的配合，联合做了很多建设性的工作。

运维和研发有一个共同目标就是让用户访问我们的业务速度尽可能快。为了提升我们系统业务的访问速度，2008年时我联合研发线的前端开发骨干、网页重构等7个同事，成立了一个联合的速度优化虚拟小组，并作为虚拟小组Leader，定期组织速度优化会议。在会议上，我们讨论各种各样的速度优化手段，并参照当时网络上流传的Yahoo速度优化14条在业务上进行尝试，把实践后得到的效果和经验整理成简单的PPT或文档在例会上跟大家分享，互相学习讨论，然后将成功的方案推广到更多业务上去。这种运维联合研发的优化工作取得了非常好的效果，当看到通过我们的优化，业务的延迟曲线明显下降时，大家都很有成就感。在短短半年多的时间里，我们优化了业务系统的几乎所有业务，几大业务如QQ会员、QQ音乐、QQ秀、QQ空间的访问速度分别提升了30%~200%。项目在当年也获得了公司刚刚设立不久的技术线大奖“重大架构优化奖”的银奖（同批次金奖空缺）。然后我将大家的成果整理成了一个80多页的实践经验类PPT，并以团队名义在腾讯学院开发成一门课程，之后通过各类渠道被分享近20次。随着我们速度优化小组的持续运转，主动加入我们的优化兴趣邮件讨论组的成员最高时候达到了160多人。

2010年，为了提升业务的全国分布能力和容错能力，提升访问速度，我作为运维线的负责人之一与研发运维同事一起，联合QQ团队（当时不属于同一业务系统），通过一年多时间的合作建设，完成了QQ及QQ空间的SET化项目（SET化是将一个大的业务划分成多个小的集群），让两大平台业务分布到全国，实现业务跨机房或跨地域的调度能力。由于两个平台的多地分布，使得平台上的其他业务也可以跟着做多地部署，为亿万QQ用户就近访问各类SNS应用迈出重要的一大步，项目也获得了当年的公司重大技术突破金奖及年度大奖。

在运维团队能力建设上，由于运维支持的部门多，各业务部门都有独立的研发团队，研发人员数量一般都比运维多出一个数量级。为了提升团队的专业性以及维护效率，我提出一个“减少运维对像，专业分工”的理念。

减少运维对象，实际上是专业分工的手段。我们把服务器类型、机房、QA流程、容错架构、软件架构等都看成抽象的、需要运维去管理的“对象”，希望这些对象越少越好。因为对于业务运维来说，人员数量总是远少于研发的，对象越少，我们能够对这些对象有更加深入和全面的掌握，而这种寻找及合并同类项的过程，其实也是专业细分的过程。我逐渐地将业务运维团队划分成接入层运维、数据层运维、逻辑层运维、业务运维、基础运维几大类。

最复杂的是逻辑层运维的独立过程。因为大多数企业初期接入和存储都是使用类似Apache、MySQL等开源软件，并逐渐演化，所以接入和存储的抽象和标准化比较容易，但逻辑层研发会写出很多架构和技术各异的TCP/UDP的SOCKET服务，在D/O分离的情况下，要让所有运维掌握这不计其数的原理和设计各异的SOCKET服务器，是一件非常难的事情。所以开始我专门找了一个综合能力比较强的同事，让他负责统一维护，并推动我们选择的一个通用SOCKET服务器，研发只需要写这个服务器里面的业务逻辑部分，就像Web服务器上的CGI一样，最大限度地限制个性化Socket服务的出现。通过两年多的努力，终于将开始只有几百个的标准框架服务器，推广到覆盖90%以上的标准Socket服务器，并最终形成了一个专业的逻辑层运维团队。

三层分开维护后，需要有人或机制让这三层很好地协调工作和运转。从人员方面讲这就是业务运维团队，由他们来协调三层运维团队来为业务整体提供服务，可以说是对口业务的运维线PM。从技术角度来看，三层的访问需要访问的串接，我们推广使用类似DNS的一个名字服务结合负载容错的公共组件L5，串接三层的访问关系并实现接口级容错，这个组件以及一些三层都使用的公共运维和管理组件，以及和网络服务器接口的一些工作，都让基础运维来支撑。总结来说，就是接入层运维、逻辑层运维、数据层运维、业务运维和基础运维几大类。标准的接入、逻辑、存储三层运维都有同一个要求就是组件的高度统一以及统一后的经验最大化利用。经过几年的努力，我们形成了一个非常稳固的专业分工合作的模式，也使得虽然有非常多的独立业务，但我们的整体业务架构体系很标准化，便于维护。团队也成为一支很有战斗力和优秀的专业运维团队。

十年技术之路——思考感悟

回顾在腾讯的十年，作为一个本科毕业生，在管理上六年升任副总监，技术上七年半晋升T4专家。虽不是发展最好的，但相对平均速度来说都是比较快的。我总结主要的几点是学习成长、合作共赢、总结呈现、思考前行。分享一下这些方面的体会，希望可以帮助初入互联网行业的技术人员或发展遇到困惑的人突破和提升自己，让自己成为精兵再到骨干，并进一步成长为一名强将。

要成为一个团队的精兵，必须是专业知识过硬，经验丰富，指哪打哪，能够非常让人放心的完成领导安排的任务的人。要做到这些，学习和实践是最直接的路径。通常一个毕业生，刚进入企业的时候，所学的知识并不能100%胜任岗位的需要，这个时候，快速地学习补充自己的知识缺陷就显得非常重要。在企业里的学习和实践，要注意以下几点。

1．借助导师、同事资源。这样可以让自己快速解决遇到的问题，少走很多弯路。我刚毕业时的导师就对我有问必答，直到现在和同事讲起我的导师时，我都会说他是我工作以来遇到的技术最全面的、最佩服的人之一。

2．系统化的学习工作所需要的是基础知识，而不是到百度或谷歌查资料解决。这样有助于遇到问题后通过相关知识关联分析，也有助于搭建更合理的技术架构，或改进现有技术架构的不足，让知识形成协同效应。为了让没有做过研发的运维同事对研发不觉得神秘，能够去分析异常故障深层次原因，我特意开发了《直观认识网络通讯》、《直观认识进程间通讯》、《直观认识HTTP协议》等几门课程，将这些知识体系化地通过一个个的小程序案例传递给我们的同事。

3．除了工作中需要的新知识外，建议在工作一段时间后再回头系统性学习相关专业基础知识。因为在学校的学习多数都缺乏实践，很多知识的掌握比较粗浅，在工作一段时间后重新再学，会有完全不同的收获。比如，我有了一段时间排查业务异常和网络问题的经验后，又将学校读过的《TCP/IP详解卷1：协议》1读了一遍，发现收获特别多，很多实际业务在异常时表现的现象都和书上讲的对应起来了。一些只在书上看过但无法在试验环境模拟的现象都在实际工作中找到了场景。

4．借助平台学习成长。实际工作中，爆发式增长的业务或大平台是一个人快速成长和进步非常好的资源。因为爆发式增长的业务会让你在很短的时间内遇到在其他地方好多年可能都不会遇到的问题，而大的平台一定是从小而来，趟过很多的坑，在这样的环境中，保持一个好奇好学的心态，可以快速提高自己。比如，在QQ空间业务开始爆发增长的时候，有段时间我曾经十天里有六天夜里和同事一起分析解决业务异常，经常持续几小时甚至到天明，也正是那段时间，遇到了别人几年才有可能遇到的各类问题，让自己知道该补充什么知识，在后续的运维工作中对我有了很大的帮助。

5．如果可以对自己进行细分定位会更好。就如同我和我的团队在过去的七年里都经历了工作内容和岗位的细分一样，现今社会是一个信息爆炸的时代，IT技术也是不断地出现新的技术分支，要想每一样都做到精通是非常困难的。所以结合自身情况以及工作需要，对自己有一个更加细分的定位，这样做精力才能聚焦，更有可能快速在你所做的领域不断深入，进而成为专家。而如果你想要成为一个综合性的人才，也可以考虑通过阶段性专注于某一细分领域，重点学习积累，具有一定深度后再切换重点关注领域。

随着经验的增长，从精兵变成骨干，我们所从事的工作会逐渐由简单直接变得复杂综合且无法独立完成，这时候就需要团队协作甚至跨团队、跨部门推进。这个时候就需要我们很好地协调平衡各方资源，推进项目达成目标，并将团队的业绩最大化展现，获得肯定。在这个过程中，要注意以下几点。
**
1．保持开放的心态。**需要在沟通合作中更多的换位思考，多创造一些双赢的机会。平时先帮助兄弟团队或同事完成目标，等到自己团队需要帮助的时候，也一定会有兄弟团队或同事出来帮助你。

2．找到一些对大家都有帮助，大家又都感兴趣或可以学到新东西的事情。比如我前面提到的速度优化虚拟团队就是一个例子。

3．注重成果总结和展现。我在公司职级晋升以及一些技术奖项评审中发现有不少人或团队所做的工作成绩非常突出，但在答辩的时候讲得很一般，平时很辛苦，最后呈现很糟糕，没有通过评审或取得的成绩比较靠后，很可惜。职场不是一个只有一次机会的演讲，更像一个马拉松。对于不善表达的人来说，可以更多地注重利用日常工作中通过各类文本的形式表达场景，这样可以在长期的工作中，让周围的同事和领导了解自己及团队的工作成果。

4．注重平时的资料积累。总结展现不好，很多情况也是由于内容不够丰富有价值。为了解决这个问题可以养成将一些日常工作中坚持将成果邮件、PPT、数据图表等案例分类汇总保留。这样在需要总结的时候数据会很丰富，有内容就不怕讲不出。

很多骨干走上管理岗位后，随着管理人数和团队的增加，会发现以前由领导指派的清晰目标逐渐没有了。团队部分成员甚至一些团队整体都会困惑应该做什么，除了不断重复一些任务和工作外，团队成员长远的发展是什么等关键问题不明晰。如果这个问题得不到很好的解决，那么团队就可能出现不稳定、士气不高、战斗力差等情况。

这个时候是很难的一个坎，因为以前不管是单兵作战，还是团队项目，目标多数比较明确，但在带领一个较大规模的团队时会发现，自己的工作内容往往不再是如何完成一个既定的目标，而是思考该做什么，我该将团队打造成一个什么样的团队，怎样帮助团队成员的发展，等等。

我自己也作了一些思考和探索，比如我在运维团队里以减少运维对象以及按专业分工的思路将团队分工不断细化，并尝试清晰地定义每个团队的核心工作职责，让大家在自己团队核心工作职责的方向上不断沉淀，通过积累建立起和别的团队差异化的经验，形成自己独有的经验和平台优势。另外，提出“服务产品、服务研发、服务自己”的理念，特意将产品放在第一位，研发第二位，希望引导运维团队有产品意识，寻找更多的办法去帮助产品、协助研发，从而让产品更加成功。而不是只着眼于自己的运维效率，做一个纯粹的支持者。只有做好这个思考和探索，我觉得才能真正转变为一个强将，我自己依然在这样的思考与探索的路上。

希望每一个刚进入互联网行业的技术人员或发展遇到困惑的人都能突破自己，从精兵成长为强将。

作者简介

赵建春

腾讯社交网络事业群运营部运维总监，T4专家工程师。2004年西北工业大学软件工程专业毕业后加入腾讯，先后参与过QQ交友、QQ音乐、QQ贺卡、QQ空间等业务的开发。2006年后和团队一起专注于技术运维，现负责腾讯社交网络事业群业务的运维建设工作。和团队成员一起经历了业务设备规模从数十台到十万级的快速发展历程，在运维环境标准化、业务Set化部署、多地分布、速度与体验优化、运维自动化式部署等方面积累了丰富的实战经验。