QQ音乐技术总监傅鸿城：好的技术优化要以体验为中心

“什么是好的架构师？好的架构师在架构重构之前会考虑什么？ 什么是好的技术优化？怎么做到以体验为中心进行技术优化？技术团队要怎么进行管理？……这里有你要的答案。

5月7日，「腾讯SNG & msup技术开放日」将在深圳召开。壹佰案例将采访一些与会讲师，谈谈他们将在会上分享的内容。本期我们采访的讲师是来自腾讯的专家工程师、QQ音乐技术总监傅鸿城。

壹佰案例：请简单介绍您目前的工作，以及关注的领域、技术积累。

傅鸿城：个人成长历程和各阶段关注的技术领域可见下图。

我对互联网技术领域都有一些涉及，比较擅长流媒体运营和优化；从web架构到客户端架构，从传统互联网到移动互联网，对新领域的快速学习和掌握比较感兴趣。平时保持关注业务运营数据，通过立体化监控持续优化架构、提升服务质量，对公共组件规划和通用架构设计具备技术视野，在技术实现中考虑产品长远规划。

壹佰案例：您所做的事情都与架构息息相关，能够谈下您对架构的理解？以及您对于架构师是如何定义的？ 

傅鸿城：毕业后参加工作八年了，负责大大小小的架构设计和系统优化的确不少，有一些经验总结。架构设计并没有标准，模式也经常在变化。所谓架构设计没有标准并非没有标准，而是太多了。架构师都希望找到最好的设计方案，然而什么是最好各有不同的理解。

好的架构师，在架构设计之前不管是新的系统还是重构优化原有的系统，需要优先理清系统需求。我们可以通过一系列问题来厘清，更好看清主持，比如：这个需求一定要做么？带来的系统代价有多大，有无变通的方法？能不能下次再做？不做会有什么损失？如果是老系统重做，很多以前的需求可能都不存在了，这样可以减少很多限制，甩掉这些历史包袱，新设计也能够轻装上阵。

此外，作为架构师，在做系统设计前需要考虑公司内和行业内有无相似系统，这也是腾讯对于高级工程师的基础能力要求，尤其避免重复造车，最好你的系统一面世就站在巨人的肩膀上。

架构师平时也应保持对内外部架构的学习积累，包括优秀的技术论坛和峰会，在设计一个新系统时就会不断的灵感涌现。

互联网架构设计遵循一些原则，大系统小做。简单是设计者通过对需求的深刻理解和精心设计，从而保持系统的简单，简单绝不等同于简陋，这样的系统是相对可控的生态，可理解程度高且具备良好的扩展演进的能力，如果是复杂的系统也有必要拆分成简洁的子系统，定好子系统间清晰简单的交互。

我也是公司研发晋级管理委员会的评委，我们对高级工程师的要求是一切尽在掌握，即在设计阶段就能对各方面进行深入分析、进行正确决策，并保证结果最终符合设计目标。

举例讲后台架构师，就需要对后台服务系统的整个运作过程有深入的理解，从网卡收到网络请求包，到最后网络回应包从网卡发送出去，整个过程中到底发生了什么事情，计算机的各个部分是如何协作完成的，哪些地方会是瓶颈，预计实际能达到的负载能力是多少等。

此外，估算是一个架构师的基本技能之一，估算不能避免所有问题，但可以避免犯更大错误，例如你要非常了解内存顺序读性能多少，ssd的读写性能，memset1k、shmat数据耗时等，这是预测能力的基础。

大部分刚参加工作的程序员都会有一颗成长为架构师的心，平时保持积累和总结的习惯以学习的心态多问向老同事请教，未来的几年也许就有机会得到独立负责一个系统的机会，成长为架构师。

壹佰案例：作为QQ音乐研发负责人，您如今是如何安排自己的新技术学习、研发团队管理、编程、生活等时间的？ 

傅鸿城：亲自写代码说实话现在并不多了，这点比较内疚，希望有机会还是多写写，记得毕业后前三年系统统计到我自己在新增或修改过qq音乐超过60%的后端代码，人员代码新增和修改量排行在一两年后还是top的，不过当时团队的人也比现在少许多。目前我在code review和bug fix还是会参与到代码的层级。

关于你说的研发团队管理，这里简要分享下我所理解的一位团队技术负责人应该做什么，他的时间应该怎么分配合理。作为一个研发团队的领导者首先要有清晰的认识，具备把主要的事务性工作剥离出来并需要适当放弃一些管理权力的能力，以提高团队整体研发质量和效率为最主要的目标去安排自身工作，同时不影响到下属尤其核心组长的发展空间，在一些事情上需要识别放权与否。一般来说技术总监需要承担主程以及部分偏技术化项目管控的职责。

主程的工作包括开发指导、人员培训和管理，其中开发指导方面的工作包括包括提出非功能性需求、设计并修正软件架构。我们也看到当下互联网不少创业项目死在研发问题，由于性能、产品质量、扩展性、二次开发效率等非功能性需求没认真去解决而导致。作为团队经验最丰富的成员之一，必须要利用自己经验尤其教训提出那些非功能性需求来保障整个项目在发布后不会倒塌。

此外人员培训是稳定团队成员的核心手段，这部分工作应该占用20-30%左右的时间，这里工作包括代码走查、架构评审、技术讲座。

我负责的各个研发团队保持有双周技术分享会和月度的开发中心技术交流会，这点是SNG各团队中做得比较好的，我觉得对团队的稳定性和成员成长有良好促进作用。

在团队管理方面我注重目标导向，关注过程，以提升团队整体效率和质量为核心目标。技术团队管理手段需要创新，想出新的方法去解决问题，平时在一些团队推行开发成员日常行为包括研发质量指标、主动分享、带新人等等考核评估，这为每半年的团队成员绩效考核提供一定的参考，此外作为技术负责人跨团队和跨部门的技术合作和推进也是一个方面。

在你工作安排得当后效率得到提升后也就会有时间来陪你的家人，我现在也会留一些时间来陪陪家人，最近也有不少自己的时间和伙伴们打打团战游戏。不过坦白讲互联网从业人员，即便陪着家人的时候也需要时刻关注业务，避免业务突发故障和临时的问题需要紧急响应，这点也是责任心和敬业度的一个基础体现吧，腾讯的大多员工如此。

壹佰案例：QQ音乐这项业务的架构的成长和发展过程中的几个时间节点或节点性的事件？QQ音乐架构是处于成长阶段还是成熟的稳定阶段？以及还会面临着怎样的技术难点？  

傅鸿城：简要讲讲最近三四年以来的吧，近四年也是移动互联网化最为迅猛的几个年头。

在2011年底12年初QQ音乐也快速从原有的pc QQ音乐逐步扩展到手机QQ音乐以及各个终端，并成为主战场；

在2013年我们专项做了流媒体专项优化彻底解决了听歌卡顿下载慢的问题；

2014年重点发力移动端的体验优化、曲库发布系统性能得到突破性改善，信息录入、转码、分发，全平台生效等发布时间从1天缩短为半小时乃至现在的准实时生效，这对QQ音乐大量的电视节目类的运营打下了良好的技术保障；

2015建立数据中心对千万正版曲库数据做梳理，在基础数据、曲库质量、分类电台等方面精打细磨，建立了良好的用户口碑。

QQ音乐业务还处于快速成长的阶段，我想技术架构也如此，仍在持续成长。未来还会面临不少的技术难点，智能推荐、数据挖掘领域仍在不断发力，例如最近我们在通过机器学习挖掘和训练歌词，提取歌词中心思想进一步训练相似单曲组等，弥补之前从音频频谱相似和歌曲歌手整体曲风分类上的不足，效果预见不错。

另外微服务、docker也会有更多尝试，目前QQ音乐的转码服务已经在用docker，另外我们也在持续关注国内外优秀互联网公司的优秀技术，保持学习的心态多去了解和接触，有好的技术团队能用到的也会保持关注和学习。

壹佰案例： SNG是如何做到以体验为中心工作的，相对其他业务来说，音乐这种流媒体业务在技术攻坚上的特殊性有哪些？

傅鸿城：挺好的问题，这里我想说的还比较多。SNG的很多优化都不会以损失用户体验为代价，包括设备和带宽优化也是在体验不受影响甚至反而大幅提升体验的情况下通过优化系统架构，提升架构合理性来实现。

在一切以用户体验为中心的互联网时代，任何开发活动都应该以改善用户体验为终极目标，技术性能优化当然也不例外。优化产品性能最忌陷入纯粹为了追求技术极限而优化的境地。QQ音乐流媒体架构我们也有过专项的攻坚，对以体验为中心的技术优化深有感触，可以详细展开说说。

记得两年多前我们成立联合团队做专项优化之前，尽管整体听歌还比较流畅，但是相比国外行业竞品(如spotify)有不少差距，甚至某些性能指标落后于一些国内竞争对手；CDN依赖一家CDN，导致性能，效率，风险不可控，这样导致经常有一批用户持续地反馈听歌卡，无法听歌,下载速度慢。

那时候我们也意识到QQ音乐要保持行业第一并设立高的行业门槛，听歌性能质量是重要环节，面对中国复杂的网络环境如何让用户秒听、流畅地听歌是需要持续投入的优化课题。

最终在我们投入大量的精力做流媒体性能优化之后，核心性能指标大幅领先竞品，而且用户给予了非常正面的反馈。当时的联合团队由于优化成效显著，还获得了腾讯公司级卓越技术运营奖金奖。这和一切以体验为中心的技术优化是分不开的。

首先在优化之前和团队核心成员制定了联合团队的目标，这些目标后面通过客户端、后台、p2p、基础数据等模块团队一起努力后顺利达成。目标围绕用户体验展开，使QQ音乐全国的用户能够一点就听，流畅听歌，做到全行业第一的流畅体验；在这过程建设统一质量监控和资源调度管理平台，提高运营效率，降低运营风险。

之后开发人员用了大概3周的时间，专门到论坛上搜集用户关于听歌慢，下载卡的反馈，并逐个联系用户，深入到高校、二线城市的网络调研，为优化获得了宝贵的方向，我们团队的一刚入职的技术骨干zack就有一段时间专注在联系用户，包括申请加入到高校的一些QQ群，不断询问他们使用QQ音乐听歌时遇到了哪些问题，遇到卡顿了就邀请学生抓包，了解学生的使用网络环境。

我们一开始就定位于解决困扰用户的体验痛点: 在线听歌开始时需要缓冲等待; 听歌过程中出现卡顿; 听歌发生错误; 下载歌曲速度慢; 歌曲下载不下来。

此后团队对体验指标的优先级进行排序，给每个指标赋予不同的权重, 再将权重值与指标的完成度相乘得到每项体验的得分; 然后将每项体验得分相加，就得到了体验总得分。如果体验得分提升，我们可以认为用户的体验是改善了; 否则认为用户的体验变差了。

以这次优化为例，我们提取了听歌过程中的卡顿几率，听歌开始前的缓冲等待时长，下载歌曲速度，听歌下载错误率四个体验指标以后，按优先级排序，依次赋予的权重值是40%, 25%, 20%, 15%。指标的优先级可以在产品的不同阶段根据产品策略作不同的调整。比如手机用户为了节省流量，相比PC客户端更倾向于把歌曲下载到本地以后再听。这样对手机用户而言下载速度这个体验指标比在PC上就要更重要一些。

为了监控不同优化策略产生的实际优化效果，我们搭建了一套海量用户数据分析平台，用以在服务器侧监控每天用户数十亿次的听歌下载数据，进行计算，处理和展现。所有用户的宏观听歌数据被计算成核心体验指标平均值，再进一步计算成核心体验得分。

通过监控宏观体验得分的走势，就可以掌控不同优化策略带来的效果。在确立了核心体验指标，并完成了体验得分监控以后，才可以进行优化策略的提出与实施。最终完成了三十多项大大小小的优化点，包括接入层尽量采用竞速接入、尽量将数据缓存在离用户最近的地方、尽量预测用户的行为并预先获取数据、尽量根据用户环境提供定制化的参数等国内乃至国际创新性的流媒体优化经验。

在这过程中我们也申请了接近20篇的流媒体技术专利，由于篇幅原因，详细的技术细节就不展开了，这里也要感谢腾讯架构平台部流媒体组兄弟伙的给力配合支持。回归到技术优化本身，优化始终围绕提升用户体验，否则很容易陷入为了显示技术实力而作出效果不显著的优化的困境，既浪费了资源，又打击了士气。

壹佰案例：走上了技术团队管理者的岗位，能否谈谈您在不同的阶段的研发团队规模、软件开发的方法、管理的经验？ 

傅鸿城：这点前面问题我已经有回答到一些了，这里就不再多讲了。目前我主要负责的团队大概100人左右，不同阶段有不同的管理的思路和方法。

团队规模大起来，不一定每一位成员你都能很好的关注到他们在想什么，有什么需求，最大程度保持团队核心骨干的稳定对于业务的发展是好事，不断的激励他们，通过团建、组织学习分享交流培训等不断让他们感受到成长和被关怀，另外我的团队酒量大的人不少，战无不胜。