首页>博客正文
十年•杭研大咖说 | 汪源:技术规划与项目管理经验谈
2017-04-11 14:40:44

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

 

 

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

 

照片wy

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

 

十年间印象最深刻的事

 

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

 

图2

 

为业务选择开源技术

 

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

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

 

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

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

 

Q:Kubernetes的优势在于微服务,从您的角度如何看待实施微服务的必要性?

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

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

 

图3

 

团队建设&项目管理

 

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

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

 

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

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

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

 

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

 

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

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

 

图4

 

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

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

 

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

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

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

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

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

 

图5

 

 

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

分享到:

评论(1)
评论文章前您需要先登录
发表评论
61****6@qq.com 1 楼
4月 27日 下午5:35

点赞


热门标签
热门推荐