唐文：挖掘产品生命周期潜藏的商业价值——应用性能管理

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

于 2016-10-07 19:00:00 发布

阅读量173

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89031031

版权

阿里CTO行癫近期分享提到：通过网络性能优化可以直接增加5.07%的订单，数据证明了提升性能可以增强用户的购买意愿。百度也曾做过搜索速度和用户体验关系的试验：在一个较小的区间内，搜索速度每延迟100ms，无点击比例就会增大1%，随着区间的增长，这个关系会呈现出指数级的曲线。阿里、百度的案例都印证了高性能网站能够增加流量、提高用户体验，最终为企业增加营收。

2016年12月2-3日，ArchSummit全球架构师峰会将在北京举行。本届大会组委会策划了“应用性能管理最佳实践”专题，并邀请了高升控股技术VP唐文老师担任出品人并对该专题进行把控和策划，我们借此机会采访了唐文老师，他为我们分享了应用性能管理（以下简称APM）的前沿趋势以及如何进行性能优化等经验，希望可以为大家带来启发。

受访嘉宾介绍：

唐文，在腾讯、百度工作近十年。曾负责腾讯四大平台之一腾讯网整体运维、运营规划，参与将腾讯网速度优化到门户最快，反超新浪、搜狐等竞品，获得腾讯最高技术奖；曾百度T7架构师、负责百度访问速度TOPIC，百度UAQ、APM平台负责人，协助将百度网页搜索、移动搜索、多个商业产品及社区产品速度优化到业界最快。mmTrix创始人，后并入主板上市公司高升控股，出任技术VP。《海量运维、运营规划之道》、《大型网站性能监测、分析与优化》作者。

InfoQ：能否描述您目前作为高升控股技术副总裁的职位角色？能否谈谈您和APM之间是如何产生渊源的？

\
唐文：高升控股是国内A股主板上市（000971.SZ，当前市值110亿RMB）的云基本服务提供商，主营IDC、CDN、APM等业务，我负责APM产品线及相关控股公司的基础平台研发。
\\
个人与APM的渊源主要来自在腾讯、百度经历的海量产品性能优化相关工作，性能优化需要数据做支撑，APM工具是性能数据采集和分析的一个第三方渠道。早在2007年资讯门户时代在腾讯做腾讯网速度优化时已经开始接触APM，真正体系的自研APM产品是在2011年加入百度后，那时我主要负责百度核心产品的速度优化工作。
\\
当时国内互联网已经进入“搜索时代”，而搜索速度一直是搜索引擎用户体验重要的组成部分，也是技术上挑战最大的难题之一。由于当时没有成体系的APM工具，第三方厂商只能满足很小的一部分需求，而且要支撑公司级性能优化，每年要支付给第三方厂商300多万元。
\\
最终我们团队搭建了UAQ（用户访问质量）、APM（应用性能管理）平台，协助百度网页搜索、移动搜索等多个商业产品及社区产品速度优化到业界最快，这些平台后期通过融入百度商业平台，直接让百度的企业客户受益。
\

InfoQ：您曾在腾讯/百度参与和主导将多个产品速度优化到业界最快，能否从你的角度谈谈您与其他部门是如何协作推动产品优化的？推动产品优化有哪些基本原则？

\
唐文：多数互联网产品团队往往因新产品功能和迭代会忽视应用性能，但当应用性能问题积累到临界点后，会毫不留情地以影响产品体验的方式体现在产品的使用过程中，从而对产品的总体价值产生负面影响。所以大的企业会招聘专职性能优化工程师来搭建监测平台来分析应用性能，从而帮助企业多个产品团队的可持续优化。
\\
这些性能优化团队与产品团队是可平行发展的，甚至可以理解为内部的甲乙方关系。各产品线会以虚拟团队的组织形式来保障项目的有效进行。
\\
正所谓闻道有先后，术业有专攻。产品线RD＼FE＼QA＼OP团队主要精力集中在迭代产品上，而性能优化团队的主要职责在系统化的性能分析与优化上。实际上，性能优化工程师综合能力和技术等级越高，产品线团队与性能优化团队两者则更能完美互补。
\\
在一定时间段内，两个团队需要组成一个虚拟团队并设定一个性能优化目标。例如在腾讯做门户性能优化时，设定的目标是门户访问速度排名第一，我们从排名最尾经过优化后成功反超竞争对手。在百度PC搜索、移动搜索也是类似的形式，设定80%的用户访问速度\u0026lt;1s做为目标，最后经过虚拟团队的协作和持续优化，最终全面反超竞品。
\\
基本原则：
\\
\
产品不同生命周期的性能优化侧重不同，优先验证简单的假设，从简单到复杂，优先选择足够简单、容易出收益的方案；
\ \\
\
先别急着优化，优先规避性能恶化，事实和推测分开，用事实验证推测，没有论证预期收益前不做优化，把有限的精力投入到关键性能问题上；
\ \\
\
从前端到后端，从外到内层层剥离，缩小范围到模块，模块内部分割单元测试，确定优化目标；
\ \\
\
性能优化没有尽头，在高速迭代中完成优化的同时，还需要与时俱进，移动时代的当下，不断投入和提高移动应用性能更具价值；
\ \\
\
需要塑造情怀和氛围，追求高性能的工程师文化，写快速友好的代码。另外性能优化是持久战，是一个系统工程，需要耐得住寂寞。
\ \

InfoQ：性能管理体系化目前是一套标准化的过程吗，能否简单谈谈其具体的操作？期间会有怎样挑战以及如何应对？

\
唐文：是的。性能问题是实时发生的，并且会像人生病一样反复出现，对于互联网企业或技术负责人，需要持续地关注应用性能，并不断进行改进。纵观国内外多个优秀企业性能优化团队沉淀和自己在腾讯、百度的实践，个人认为性能优化主要围绕监测、分析、优化三个核心循环。
\\
第一步的监测最关键，监测好比掌握应用性能的“眼睛”。所以前期主要精力应该放在监测上，如何监测那些对象、监测数据如何分析、如何定位故障等是性能优化的关键。应用性能管理的三部曲如下：
\\
\
监测，通过监测产品及竞争对手在各终端、各产品形态下的性能，例如PC、手机、平板终端及操作系统、网络、应用等，全面评估自身及竞品的表现，并作出迅速定位故障及排错；
\ \\
\
分析，通过标准来评估前端、移动、后端、代码、网络（IDC、ISP、CDN）等性能，为优化及资源投入提供依据，为优化效果提供度量，提供性能（以及故障）预警、告警；
\ \\
\
优化，通过网络、系统、硬件、前后端、应用等各层进行体系优化，以将产品速度优化提升至达到业界最快为目标，进而提高用户忠诚度、购买意愿、品牌价值等。
\ \

最大的挑战是企业产品类型多而且产品生命周期一直在变化，任何互联网企业都是由多个行业细分、多个产品体现商业价值，有新旧、大小之分。互联网产品经过产品策划、设计、研发、运营，然后上线进入市场，它的市场生命周期才算开始。产品、架构、成本都会随时间推移而改变，呈现一个由少到多由简单到复杂的过程，就如同人的生命一样，由诞生、成长到成熟，最终走向衰亡。
\\
往往产品在迭代过程中性能会发生较大变化，比如新版上线，哪怕是一个网页元素变大都会在原来的性能基础上增加加载时间，例如服务器折旧、人员流失也会影响应用性能。特别在之前从事过性能优化的产品，如果在往后的产品迭代中不加以管理，将会使之前优化的劳动成果付之东流，即使及时再优化，也很难保持。
\\
所以非常有必要从流程、规范、平台、告警等维度融入到产品生命周期中，对当前应用性能进行保持，防止应用性能退化，从而使优秀的应用性能不断随产品迭代而保持并良性循环。
\

InfoQ：APM行业在国内大热，您认为是受哪方面的推动？应用程序本身正变得越来越难以管理您认为有哪些原因？

\
唐文：随着国外排名靠前的APM厂商纷纷上市，国内APM行业在资本推动下也日趋繁荣，加上中国互联网发展阶段性企业需求扩大以及越来越多的厂商投入到APM行业，这些因素都加快了产业化进程。
\\
\
一方面，厂商的投入及商业化有利于提高应用性能管理技术水准和丰富方法论，直接降低企业APM落地门槛；
\ \\
\
另一方面，APM SaaS化，使得每家企业、甚至每一个开发者都可以直接按需使用优秀的APM云服务帮助改善产品性能，而无需投入额外的人力和资源来搭建应用性能管理平台。
\ \

换句话说，第三方厂商的服务能力会一定意义上帮助企业减少应用性能投入和学习成本。
\\
应用本身正变得越来越难管理，个人体会是全新云时代，商业、技术、社会各层面都在深刻变革，互联网产品越来越多样和复杂，全球化、移动化、多终端，海量用户数据和实时性等新特点为改善用户体验带来了更大的挑战，甚至可以毫不夸张地说今天的互联网时代比历史上任何时期都面临更为严峻的挑战。
\\
几乎参与产品的人、事务和资源都会产生性能问题，例如移动、前端、后端、网络、系统、应用、硬件、产品逻辑等，而往往这些不同维度的性能问题会叠加并不断放大。而且以上这些都是企业和厂商的共同挑战，而厂商则更难跨越。
\

InfoQ：据了解APM在国外已经是比较成熟的产品，目前国内这方面技术与生态相比国外有哪些优势与不足？

\
唐文：国外因整体企业级服务市场成熟，加上起步早、迭代快，商业化进程比国内快很多，而且经过洗牌与重组，整体更产业化、差异化，优秀的厂商有Compuware（Dynatrace）、NewRelic、APPDynamics、AppNeta（TraceView）。
\\
国内厂商最大的优势是本土化，而且教育用户多年，抓企业的痛点和持续按客户的诉求交付，个性化服务较强，也受益于中国式关系型销售助力。不足是起步晚，在一个相当长的时期停滞不前，而且是重度依赖销售关系。与国外厂商相比，是被动式跟随国外厂商和资本驱使的畸形快速发展阶段，这些都是由厂商、企业、资本、大环境等当前综合因素决定的。
\\
另外，国内厂商与企业供需关系不可避免存在脱节现象，这是由双方天然隔阂决定的。
\\
\
首先每家企业是非常个性、复杂的生产环境和需求，厂商不可能完全理解企业内部具有历史负担且不断演进的架构和环境，也不可能满足所有企业需求，更不能深度参与企业性能优化（受沟通、技术、理解限制）；
\ \\
\
其次企业也有自研且符合产品迭代特性的性能监测渠道，这些监测渠道完全可控、个性化、安全、无成本、灵活抽样等优势；
\ \\
\
最后无论厂商是侵入和非侵入式监测，对企业产品而言是存在不避免地额外影响（延时、安全）和信任（隐私、用户数据）问题。
\ \

综上所述，厂商做为第三方视角和补充是普遍现象，但肯定不是主导地位，特别是在大型互联网企业中。
\

InfoQ：结合大数据、云计算等方向，APM在哪些领域仍有提升的潜力，APM未来会朝哪些趋势发展？

\
唐文：潜力与发展趋势放在一起讲，个人体会，未来以下两个方向将逐渐成为APM重要价值：
\\
\
机器学习，包括无人参与下的自主学习（数据植入与采集），自动发现关联应用、环境和常规运行状态，自动动态计算性能事务流和判断健康度。例如超前感知给出预警，提前分析出事务链条中哪一步出现了问题，按当前趋势发展即将要出现哪些问题等。减少人工参与是一个高度自适应、智能化的实时服务，智能发现、理解、判断、响应及优化性能问题；
\ \\
\
大数据分析，提供大规模数据实时集成、计算、存储、可视化服务（数据落地与分析），借助机器学习算法提供完整（用户\u0026lt;-\u0026gt;终端\u0026lt;-\u0026gt;网络\u0026lt;-\u0026gt;后端）性能数据全流程分析，将复杂、关联的应用高度拓扑化和可视化。
\ \

InfoQ：持续监测与即时监测这两方面在业界技术实现上有什么不同，有哪些使用场景？

\
唐文：简单理解，持续监测是7*24小时不间断的监测，即时监测是一次性监测，它们技术原理一样，以下重点介绍即时监测。
\\
即时监测与体检类似，体检已经成为大家保持健康的一种重要手段，人们对自己健康的管理，重点通过体检对疾病进行早期发现。即时监测达到的目的与日常体检具有相同的意义，每一次对产品进行一次评测如同对产品做一个全面的“健康体检”，将表象的性能问题罗列出来，快速解决掉，并且与持续监测互补。
\\
相比持续监测，即时监测更效率、更快、更低门槛，虽然监测维度广，但深度和可持续性弱于持续监测。无论在产品、研发、测试还是运维都可以在产品迭代或上线时进行性能分析。
\\
通常即时监测具备多视图、全方位分析在不同地理位置、网络、设备、浏览器、分辨率下的产品性能瓶颈，并自动提供行之有效的优化建议，主要覆盖前端、后端、系统、网络、安全、速度等维度性能。主要分为以下三类：
\\
\
移动即时监测，一次性在不同移动设备（不同的iOS和Android操作系统、不同厂商、不同款手机平板电脑、不同运营商、不同屏幕大小等）上监测Web App和Native App加载性能，并将存在的性能问题分析出来；
\ \\
\
PC即时监测，主要通过不同屏幕、不同浏览器厂商、不同版本及不同运营商等环境下进行真实浏览器渲染网页应用，将问题和瓶颈分析出来；
\ \\
\
网络即时监测，主要通过全国不同地理位置、不同运营商的真实用户来分析应用在全国的IDC、CDN、DNS、ISP等维度的分布和解析策略，将网络维度的问题体现出来。
\ \

InfoQ：性能分析是应用性能管理中重要环节，在一套APM方案中数据的收集和分析是怎么完成的？具体使用了哪些技术？

\
唐文：当前应用性能工具基本划分为4大模块：
\\
\
应用性能管理（语言类监测）
\ \\
\
最终用户管理（JS监测，移动监测，真机监测）
\ \\
\
基础设施管理（服务器监控，数据库，中间件等）
\ \\
\
应用分析（事务分析，日志分析，用户体验/分析）
\ \

数据采集主要以侵入和非侵入的方式通过Agent、SDK、Client（按采集触发机制又分主动与被动）将性能数据回传到服务端集成、计算（离线、在线）、存储、可视化，以上工作流都是分布式、模块化的集群。细节如下：
\\
\
Kafka cluster缓冲各类Agent和SDK实时采集回来的数据。（Kafka Manager监控Kafka集群，并提供对Kafka的基本操作）
\ \\
\
HBase、OpenTSDB存储各种监控数据及业务数据。（Ganglia监控Hadoop，HBase等情况）
\ \\
\
Redis部分数据的缓存及秒级业务数据。
\ \\
\
Mysql、Hadoop、Spark等离线计算的主要存储数据库。
\ \\
\
HDFS存储由Kafka2hdfs落地的原始数据，以及Mapreduce的中间结果。
\ \\
\
Hadoop YARN、Mapreduce、Spark离线计算各类监测数据。（Hadoop cluster UI、Hadoop job history监控Hadoop任务情况）
\ \\
\
Storm、Spark streaming实时计算各类监测数据。（Storm Monitor UI监控Storm任务情况）
\ \\
\
Zookeeper协作Hadoop、Storm、Hbase等分布式开源框架。
\ \

InfoQ：性能优化有很多方向，从底层协议到前端都有可能需要优化，面对这么长的优化链条，优化思路是怎样的，在资源有限的情况下优先级如何选择？

\
唐文：优化思路如下：
\\
\
整理前端、系统、网络、后端、移动等5大方向性能优化最佳实践，针对各个技术细节进行深度调研并在产品线中优先前端、系统、网络优化，这三部分最容易出成果；
\ \\
\
可持续的研发性能优化的工具、平台、框架、库等，并集成到基础平台中，提供给产品线使用；
\ \\
\
提升工程师在性能优化方面的知识，汇总各个部门的优化成果，积极组织交流、培训；
\ \\
\
推动性能优化方法、工具和性能分析指南在产品线中的推广，并指导工程师解决性能问题。
\ \

优先级考虑：
\\
\
确保优化方向正确，产品特性和阶段决定优化方向，这是优化的首要条件，优化方向决定了优化的效率和收益；
\ \\
\
确定优化带来的收益，无收益不优化，只有明确收益才启动优化；
\ \\
\
在投入和产出上做取舍，合理地设定优化目标和资源投入，做高性价比的性能优化；
\ \\
\
功能与性能的平衡，产品功能优化是最低成本、高性价比的优化之一，并且立竿见影；
\ \\
\
防止过早和过度优化，过早或过度直接导致人力成本增加以及资源浪费。
\ \

InfoQ：现在是运维创造价值的时代，您认为被动低效率手工救火的运维角色到优秀的APM开发工程师需要具备哪些能力，有哪些途径可以帮助成长？

\
唐文：在举国互联网+时代，用户至上已经被多数企业接受，加上互联网第二个十年中后期，运维在平台、架构能力甚至整个行业和技术已经经历了一个很长时间的沉淀，当下已经不是被海量用户和产品快速迭代双重夹击中力求可用、稳定的时代，而是在此之上增加产品和企业商业价值的时代，而应用性能管理就是其中重要工作之一。个人体会，应该具备以下能力：
\\
\
系统，分析系统运行状况（操作系统），系统资源使用情况（硬件）。分析应用程序对资源的使用情况及瓶颈，分析应用程序执行效率及相关压力测试。负责服务器硬件、软件、软件配置性能优化，前沿相关技术调研和落地；
\ \\
\
网络，IDC、CDN、硬件性能测试，新硬件调研和落地。IDC外网、内网传输及相关QoS保障，IDC、CDN性能优化。负责操作系统母盘、内核、TCP传输、协议、网络路由等调优；
\ \\
\
应用，分析前端、移动、后端程序执行效率、逻辑和代码性能。分析应用模块执行效率、系统架构中的性能瓶颈，设计更好的高性能系统架构和落地，前沿技术调研与应用，例如SPDY、HTTPS、HTTP/2、ESI、SDCH、BigPipe、DNS Prefetch、HHVM等；
\ \\
\
平台，搭建综合性能监测、分析平台，提供竞品的瓶颈分析、速度优化、评测报告、收益评估。
\ \

结合个人的体会，企业和团队应用性能管理的经历都是由小到大、由浅入深的积累过程，总结几个主要学习途径：
\\
\
公司内部学习，相对大的互联网企业是多部门多产品线结构，有些产品和团队肯定走在最前面。从技术发展通道看，前端、后端、移动端等技术方向肯定会涉及到性能优化，因为这些角色负责看得见摸得着的产品构建。在公司内部首先找到这些部门和接口人，安排部门之间技术交流或当面沟通都可以快速学习他们的成功经验；
\ \\
\
参加专业大会，当前是用户至上的时代，各公司或多或少都有不少性能管理的实践，在各种大会上都能看到相关的分享，这些都是学习的途径，InfoQ上也有很多与性能相关的采访和文章；
\ \\
\
多认识牛人，无论是国内或国外公司都有这个方向的牛人。而性能优化本身是互联网技术体系里的“上乘武功”，往往这些牛人都可以通过朋友介绍或在微博、微信上找到，也可以通过各种大会上认识，而且这些牛人多数都有在网站写博客等，这些都是学习和交流的突破口，如果问题较多可以整理出来集中约时间或邮件交流。
\ \