十年•杭研大咖说 | 汪源：技术规划与项目管理经验谈

2016年，网易杭州研究院（以下简称“杭研”）成立十周年之际，我们推出“十年·杭研大咖说”系列访谈文章，针对亲历杭研核心技术体系变迁的数位技术大牛发问，揭秘网易云背后的技术脉络、研发思想和技术人成长的故事。本期的受访嘉宾，是网易杭州研究院执行院长汪源。文章分为上下篇，上篇解析杭研的技术体系与未来展望，下篇侧重具体技术选型与研发流程优化的思考。

 

在本篇中，汪源分享了从十年研发和管理过程中积累的主要经验，包括技术架构设计的要点，重要基础技术的选择，项目管理、研发团队建设的技巧。他崇尚IaaS和PaaS层架构设计的一致性，认为开源技术的使用可以让减轻基础研发的负担，但开源的选择还是要围绕商业化、业务需求进行。杭研敏捷项目管理的主要经验，则包括轻量级的项目沟通模式、产品经理负责制和专人就位的职能支撑模式。

 

网易杭州研究院执行院长汪源

 

十年间印象最深刻的事

 

Q：我们用十年时间打造了现在的技术体系，期间有哪些经历是您印象比较深刻的？

汪源：得意之笔和踩过的坑都是我们通往成功的财富，在我心底烙印最深的事情如下：

1、2006年我们开始做海量数据管理平台，包含分布式数据库、分布式文件系统、分布式全文检索、自研的MapReduce，以及结构化和数据和非结构化数据的融合检索系统，这五个核心系统共同构成了当时完整的海量数据管理平台，涵盖结构化数据的管理、文件数据的管理、搜索（包括全文检索和融合检索）和并行计算，都是在2006-2007这两年构建完成，当时在国内是比较超前和领先的，后来部分平台被更加成熟的开源平台代替，比如自研的MapReduce并行计算系统，到2010年被替换成当时已经成熟的Hadoop（2007年杭研开始自研时Hadoop并不成熟），融合检索系统后来改用基于全文索引的方式来做，这都是因为开源技术是不断往前推进的。

 

2、基于虚拟化开始做云计算，这个平台有两点我比较认可：一是整体架构设计的一致性，上层PaaS服务可以完全基于IaaS层能力构建 – 有些友商的云计算架构比较分散，上层的数据库等服务并没有架设在云主机上，都是独立的一套系统，但网易云计算所有的PaaS服务都统一由底层IaaS支撑、调度和提供高可靠的能力，相互之间的协调性比较好，这和设计得比较好的AWS（EC2+ECS）是同等的水平；二是网易云在网易内部的使用率非常高，网易互联网产品基本都顺利使用这一套系统，包括一些之前没有使用云计算平台的互联网产品，最终也在两三年之内顺利迁移到网易云上来。

 

3、在内容安全方面，我们从2010年开始用分布式机器学习算法、大数据计数来解决垃圾邮件等问题，后续对图像、文本，也比较早地使用了同样的技术，整个内容安全技术水平，从邮箱反垃圾效果来看，我们和竞争对手相比都是领先的，包括鉴黄、大数据技术的积累，都是处在领先的位置。

 

4、最后一个是踩坑的经验。我们在2007年底开始做一个MySQL存储引擎的项目，想法是设计一个针对Web 2.0应用的高性能、高可用的MySQL存储引擎，代替原来使用的InnoDB、MyISAM这样的存储引擎，我作为项目主力程序员亲自编码。但这个项目最终只有少量线上应用，现在也撤下来了，因为没有人维护。主要原因有二：一是随着杭研的发展，原来项目的核心开发人员（如余利华）【点击阅读：余利华：网易数据科学实践与未来挑战】都成为了管理者，再没有精力做具体项目，导致项目团队发生断层，找合适的团队接手非常困难；二是我们比较静态地看MySQL社区的发展 – 从2007年一直到2010年，我们的存储引擎在性能、可用性方面都比当时的社区版本好不少，但2013-2014年的时候，MySQL在InnoDB底层做了很多改进，相对优势不再明显。这也是一个经验，看开源社区，如果只看到现状，就比较容易掉到坑里去 – 当时觉得有很多问题，很容易做一个更好的项目，但是过了三五年，可能就被它超过了。成熟的开源项目，社区的研发力量确实是很大的，不是一家公司的投入所能比的，除非是公司的一个战略性项目。

 

Q：所以，如果现在让您回到十年之前重新开始杭研的工作，在技术体系的构建方面您会做出哪些改变？

汪源：如果再回到10年前重新考虑，我们应该会有两个调整：

1、更加积极地参与到开源社区的项目，和开源社区共同成长，为了满足阶段性历史使命的项目不一定会做。前面说过，换一种方式去做和开源项目定位相同的事情，最终会处于下风。

 

2、更早考虑把杭研技术进行商业化，做更好的产品对外提供服务。首先，作为一个大型互联网企业，网易应用成熟的技术，对市场上的其他互联网企业也是有价值的；其次，要把技术做到极致，要让技术能够有更大的投入，并产生更大的回报，是需要商业化的，如果只是支持网易的业务，在技术的投入、应用的全面性方面，或多或少会有不足的地方，如果做到全世界的人都在用，这个技术才能说是非常成熟、非常可靠的。所以，应该把网易自身的应用当做一个起点，虽然是比较高的起点，但毕竟不是终点。

 

 

为业务选择开源技术

 

Q：网易在OpenStack、Kubernetes等社区都有代码贡献，但我们似乎并不是很看重这些，能否介绍“与开源社区共同成长”的含义？

汪源：我们选择技术方向的时候，会跟着开源走。2012年做虚拟化时就已经这么做，选择使用OpenStack，研发出的一些Feature会提交给社区。现在做容器、微服务，选用的是Docker、Kubernetes，有相关的成果也会回馈给社区。我们确实不是说社区排名，主要还是根据商业化、业务需要来做事情，但最大的区别是不用从头做一套和开源项目定位相同的系统。

 

Q：开源项目的成长需要一个过程，有一篇关于Docker实战失败的文章，谈到了很多问题，比如不稳定、不兼容，我们如何避免此类问题？

汪源：我看到这篇文章的时候，第一时间找到我们的首席架构师了解了这些问题的具体情况。很多问题其实并不是使用Docker就一定会出现的，是因为那个案例使用的公有云，并不是原生支持Docker的平台。当然，Docker这项技术还在不断优化，新老版本确实可能出现一些不一致的问题。所以，我们选择Docker、Kubernetes的版本不会特别激进，会选择成熟可靠的版本在网易蜂巢里面提供服务，并且会提供多个版本的长期支持，客户可以根据自己的需求和习惯采用；其次，网易本身团队在Docker方面已积累较强的服务能力，如果使用官方版本遇到一些问题，我们也能做相应的处理。

 

Q：Kubernetes的优势在于微服务，从您的角度如何看待实施微服务的必要性？

汪源：从研发团队管理的角度来看，微服务不是一个单纯的技术问题。有一句话是组织架构决定技术架构，其实反过来技术架构也会影响组织架构，微服务是一项技术，但也会改变组织架构，会形成一些小团队，这种模式的研发迭代效率更高，而管理成本比较低。从技术方面，微服务还有其他的优势，比如业务瓶颈所在的单个微服务可以单独扩容，不用做整个大服务的扩容，某些服务的功能比较聚焦，开发、维护、上线导致混乱的事情也会减少。

当然，做微服务需要一套成熟的面向微服务的系统来做支撑，否则服务拆分之后，服务的监控、管理就会成为问题。网易蜂巢的目标就是要解决这些问题，让大家享受到微服务的好处，又不会受到微服务所带来的负担干扰，Kubenetes很适合我们的需求。网易有一个典型的案例，是教育产品线，原来是一个研发团队，一个单体应用，经常发现开发进度赶不上业务需求，做一个小的调整都会有很大的影响，现在拆成了云课堂，云课堂企业版，K12里面面向奥数、面向英语、面向儿童编程、面向考试题等多条线，每条线都是一个小团队维护，再组合起来，大家都跑得更快。

 

 

团队建设&项目管理

 

Q：十年前杭研刚刚创立，您自己在一线担任主程，现在杭研成了一个很大的团队，您作为执行院长，您的日常工作重心有哪些变化？

汪源：最初说白了就是码农，后来成长为架构师，现在我主要考虑三件事情：面向商业化的策略、大的技术方向规划和本身的管理型工作。

 

Q：说到管理，杭研有一本《网易一千零一夜》，总结了十年互联网产品项目管理经验，能否简要分享其中一些您认为的最关键的点？

汪源：杭研技术成果的商业化，不仅包括网易云产品体系，也包括了知识体系。《网易一千零一夜》是网易项目管理的核心经验，属于研发流程知识体系，涵盖整个项目管理流程，适合敏捷的互联网项目管理。这里分享一些要点如下：

1、轻量级的项目沟通模式。要用比较轻的项目管理方式来支撑快速迭代的需求，比如最常用的看板。对一块贴满了各种标签、甚至是写字的白板当面沟通，看起来简单，但确实能感受到团队每个人的进展、遇到的问题，是一种非常轻量级的模式，能够把版本迭代周期缩短。如果用文档、邮件沟通，假设一个组有20人，更新进度之后再讨论，这个环节可能就需要花一天的时间，而看板可能用15分钟就解决问题 – 有时候把标签贴上，可能都不用说话了。

 

2、杭研是产品经理负责制，产品经理相当于一个小老板，要考虑很多事情，但也有很多资源，比如核心研发团队，包括服务端、前端开发人员，产品团队，设计师团队，运营团队，全部隶属于这个产品经理，使得他能够调动核心资源执行他的任何决策，自主权是非常大的。这个模式在网易是司空见惯的，和传统2B企业的研发模式别差可能很大。传统行业往往会用矩阵制来做，可能还会分市场产品经理、业务产品经理，研发团队从另外的一个研发中心调配，架构师来自一个架构师团队，各种资源是从各个职能部门组合起来的，产品经理无法做到灵活的决策调整和资源调配。

 

3、专人就位的职能支撑模式。对于一个产品部门和专业职能部门的配合，比如产品团队和用研团队、QA团队、数据分析团队、安全团队的配合，我们提炼了一个词，叫做“专人就位” – 首先一个职能部门支撑一个业务部门的时候，一定是专人，这个人不能支撑两三个不同的业务；其次要就位，这个人在组织架构上隶属于职能部门，职能部门可以对他进行一些专业性的培训和指导，但是他的工位要和业务部门在一起，这就达到一个比较好的平衡点 – 从业务部门感知来说，这个人和团队是很接近的，只给我这一个业务服务，但从专业性的管理来说，这样也可以实施必要的专业性培训管理的职能。通常职能部门支撑业务的人，85%是服务于业务的，只有15%是服务于专业性建设的。当然这种模式也有一些弊端，比如某些人长期服务于一个产品，会导致他的职业发展存在一定的瓶颈，我们会通过调配的方式解决。

以上是最主要的三个方面。其实我在书里面还写了很多细节，比如云计算团队，就算只是核心的IaaS、PaaS，也是一个规模很大的团队，如何分成很多小项目，多个产品经理协作，一个大产品经理和多个小产品经理共同完成一个大工程的整体推进，这也很重要。

 

 

Q：在互联网+的背景下，技术对企业的重要性越来越明显，不少的团队也就以工程师文化自诩，杭研是如何打造研发团队文化的？

汪源：工程师文化有它的好处，比如会追求技术先进性，做事情精益求精，但不能跟用户导向脱节，所以我们不片面提倡工程师文化。网易的文化最主要的还是用户导向的文化。

 

Q：适合杭研风格的研发团队成员，他们的哪些能力和素养是您最为看重的？

汪源：杭研的团队比较复杂，需要分层次来看。

首先我们希望所有的团队人员应该都有客户意识，从客户的视角来分析产品需求，从市场的视角来思考什么样的产品比较容易实现商业的成功；

其次是涉及前沿技术的任务，需要突破技术瓶颈，追求技术领先，需要有很好的前沿学术研究能力，以及很好的工程实践能力，才能把事情做好。

第三类是服务性、技术支撑团队，如QA、运维，我们会制定很多管理的规章制度，强调一定要有很好的服务精神，要能够及时、保质保量地给客户提供好的服务。特别是运维，一定要保证服务的及时性，能够解决各种突发事件，所以纪律性是非常重要的，我们的运维团队不能容忍技术能力很强但纪律性差的员工。

 

 

【上篇：十年•杭研大咖说 | 汪源：秉承孵化创新而生，不止于云和大数据】