| 编辑推荐: |
本文主要介绍大型网站性能监测对象、如何监测、监测数据如何分析、如何定位故障并优化等问题希望对您的学习有所帮助。
本文来自于运维帮，由火龙果软件Alice编辑、推荐。 |
|
1.1 关于应用性能
应用性能是互联网产品的一种非功能特性，它关注的不只是产品能否完成特定的功能，而是在完成该功能时展示出来的及时性。由于感受应用性能的主体是人，所以应用性能是一个可感知的综合用户体验值。这个体验值深受用户使用产品的所有因素响应，这些内在和外在的很多因素都对应用性能和可用性造成影响，如从用户发起对应用的访问，到收到该访问反馈的内容，通常会经过DNS查询、网络传输和接入转发，以及Web服务、应用服务、中间件、数据库等应用组件的信息处理，这些组件的性能优劣，都会直接影响业务交互的实时性、准确性和稳定性，但是这些影响基本上都无法完全消除或解决，且主要发生在生产环境，难以在开发、测试环境中发现。
1.2 关于应用性能管理
其实应用性能管理由来已久，IT从业者们对它的理解与实践也几乎是从IT诞生至今就已开始。而最终应用性能都通过产品体现给最终用户。诚然，应用性能管理的本质是通过掌控应用性能状况，从而改善应用性能，为用户提供最好的用户体验。当下的应用性能管理已经不是传统的监控系统，也不是单纯的使用“Web最佳实践”去优化网站，而是为针对企业应用特性建立一套科学完整的应用性能监测、分析、优化体系。由于监测和优化势必将影响应用性能的所有维度，所以在生产运维环境中，一旦出现应用问题征兆，应在影响扩大之前，发现问题、判断原因、隔离故障，从而达到高效解决问题之目的。
应用性能管理是系统工程
Strangeloop的研究数据表明，网站出现1秒的延迟后会导致页面转换率降低7%，流量下降11%，用户满意度降低16%。那么，在100%的网站访客中，就会有57%的访客在等待3秒后放弃，其中80%访客不会再回来，50%访客转向其竞争对手网站。性能问题无时无刻不发生在我们所使用产品的所有过程和所有环境，例如PC、移动、网络、系统、应用、硬件、产品逻辑等。正因为应用性能如此重要且时刻存在，腾讯从2006年开始了大规模性能优化，并将此发展为腾讯工程师文化之一。百度、阿里在2010年后也陆续启动了大规模的性能优化项目。近几年来，越来越多的企业进行了系统性的性能优化，例如新浪、携程、美团、58同城等。正是因为以上企业对性能的不断追求，才奠定了中国互联网性能优化理论与实践基础。
应用性能管理具有门槛性
在举国互联网+的时代，用户至上已经被多数企业接受。我相信企业级的应用性能管理与优化的时代即将来临，也是企业可持续保持好的用户体验的基本前提。其实像BAT级别的大型互联网企业都有专职的性能管理团队，多年进行性能管理和优化，并建立起完整的性能管理平台来协助。意旨让性能管理和优化变得更高效，并保证其产品能够给用户带来卓越并可持续的体验。事实上，如果大多数中小企业要进行性能管理和优化是有门槛的。除了需要人力投入以外，还需要实践积累的过程及可持续的维护能力。所以即便很多二、三线互联网企业涉及到了性能优化，在绝大多数情况下也只是产品级和部门级。而随着产品版本迭代和人员流失，性能管理随即出现退化和断层，这也是当前的基本现状。
第三方推动作用在增强
如同CDN行业一样，应用性能管理也在加速商业化脚步，即APM行业 。越来越多的云服务商投入到APM行业，加快了产业化进程。随着美国排名靠前的APM厂商纷纷上市，国内APM厂商也日趋繁荣。一方面，厂商的投入及商业化手段有利于增加应用性能管理的技术水准和丰富方法论，直接降低企业落地应用性能门槛。另一方面，APM
的SaaS化，使得每家企业、甚至每一个开发者都可以直接使用最优秀的APM云服务帮助改善产品性能，而无需投入额外的人力和资源来搭建应用性能管理平台。换句话说，第三方厂商的服务能力会从根本上帮助企业减少应用性能的学习成本。
1.3 基本意识
应用性能木桶理论
互联网产品是创意、研发、系统、网络、硬件、维护等所有资源相互交织的集合体，这些资源彼此之间有着千丝万缕的联系。它们必须通过共同协作以期达到稳定产品运行及良好用户体验的最终目标。如用木桶理论帮助理解的话，也就是说一只木桶能盛多少水，并不取决于最长的那块木板，而是取决于最短的那块木板。所以也可称之为短板效应。而将木桶理论进一步延伸来看，新木桶理论认为一只木桶能装多少水，不光取决于最短的木板，更应该取决于木桶是否存有缝隙，若木桶存有缝隙，则水将不断流失。应用性能木桶理论如下图1-1所示。
图1-1 应用性能木桶理论
基本意识和思路
应用性能监测、分析、优化的过程就是找出“木桶”的短板、缝隙并进行修复的过程。而“木桶”中的水，就是产品价值和用户体验。本人的一些相关思路，会在随后作详细阐述，以便帮助大家参考理解。
1.3.1 价值与意义
在互联网行业，要成为受人尊敬的互联网企业，产品的用户体验是一块基石——即应用性能。在腾讯工作时，常听到CEO马化腾要求所有核心产品要做到业界速度最快，并多次强调：用户放弃一个产品只需要2秒种，1秒关掉网页，1秒打开竞争对手的网页；在百度工作时，CEO李彦宏也多次强调，百度搜索80%的用户要在1s打开。事实也证明减少检索加载时间等于增加用户检索次数和广告收入。从两个中国互联网航母级的企业如此重视应用性能可以看出，应用性能对互联网产品有至关重要的价值，而更多权威机构统计数据从侧面说明了这一点。
速度影响用户满意度和访问量
1、Google的一项试验显示随着页面加载时间从400毫秒增至900毫秒，每页面搜索结果数从10增至30，将导致25%搜索者在第一个结果页放弃。
2、有研究显示，如果3秒后，网页还未加载完毕，57%的用户会放弃。74%的用户登录某网站时间超过5秒后就不会再登录这个网站。
3、有研究显示，宽带用户比窄带用户更没有耐心。宽带用户愿意忍受的最长等待时间，往往只有4～6秒。60%的用户希望手机上的页面加载时间不要超过3秒。
速度影响网站收益和SEO排名
1、Amazon的统计显示每延长1秒，亚马逊一年就会减少16亿美元销售额，首页打开时间每增加100毫秒，网站销售量会减少1%。
2、据估计每年电子商务网站都会因载入速度过慢，而损失11亿到13亿$的收入。
3、速度在Google的PR评分中占有一定的比例，Google的PR算法中加入了速度评分一项。也就是说，一个好的网站，是不可能让它的页面加载速度很慢的。
速度是应用性能最直接体现
速度表示物体运动的快慢程度，应用或网页速度简单理解就是用户打开一个应用或网页的快慢程度。有些书也总结为浏览器向服务器发送第一个请求到最后一个网页元素加载完的消耗时间。总言之，应用或网页加载消耗的时间越少，代表网页速度越快。根据参与腾讯、百度多个产品线优化实践的体会，通常一个网页的总加载时间<=5s基本不会让用户产生反感，用户对网页第一屏加载时间<2s的网站会形成良好印象。如下图1-2所示，结合第三方公司的一些调研结果，以便大家能够更好理解应用性能。
图1-2 用户满意度示意图
应用性能具有可控、可管理性
应用性能发生在产品逻辑、前端、网络、后端、硬件、系统、应用等所有环节，而这些环节之间既环环相扣又互相干扰、叠加，让性能问题更加严重，反之亦然。所以应用性能管理的最佳状态是让各环节平衡，并且让各环境发挥最理想性能状态。其实就像人的健康管理一样，人在有疾病的情况下，只有两个选择：要么逐渐严重并产生多种并发症让影响更严重，要么尽快就医尽快恢复减少影响。实际上，无论疾病的大小都会影响日常生活，应用性能也如此。所以应用性能管理的意义，如同健康管理的意义一样，在尽快发现和修复性能问题，并保持、甚至增加产品的体验和价值上，至关重要。以下是作者在百度参与部分性能优化项目的数据，以便帮助大家理解应用性能：
1、百度网页搜索优化收益，包含app query 1.83s->0.61s，首屏做到极致。
2、百度移动云性能优化，首页2.46s->0.9s，全面反超竞品。
3、百度LBS速度优化，首页2.32s->1.8s，全面反超竞品。
4、百度移动LBS性能优化，首页2.31s->1.08s，落地页7.35s->6.25s。
5、百度国际化性能优化，国际化搜索速度3~8s->1~2s，国际化网址导航3.46s ->
2.57s。
6、百度贴吧frs页优化，优化后页面基本功能可用时间提升30%。
7、百度贴吧wap页优化，优化后页面减少40%，直接带动session上升。
8、百度Image改版通过预读取提高图片展现速度，浏览量增加60%。
1.3.2 出发点
产品的性能问题就与人的健康状况极其相似。通常只有在我们遇到身体不舒服时，才会去医院检查，才能得知究竟哪里出了问题，且对症下药之后仍需一定时间恢复健康。而产品的性能问题与人不同之处在于，如若出现问题之后再修复已经太晚，因为此时已影响到所有用户的使用，甚至已经影响到了营收，并且在事后发现性能问题需要时间、修复问题更需要时间，所以性能出现问题对用户的影响是持续长时间的，而对于产品而言更加是一场噩梦。试问如若性能问题能够被事先发现和修复，那么在产品研发过程中就能够被有效回避。这就是性能优化最根本的出发点，也是用户获得更好产品体验的基本前提。
基本要求
1、性能问题暴露前，尽早发现应用性能问题，减少对用户的持续影响。
2、性能问题发现时，尽快修复主要性能问题，减少应用性能影响力度，最大程度改进用户体验。
3、性能问题优化后，杜绝发生性能问题，可持续保持应用性能优化成果，防止性能退化。
基本原则
1、在产品不同生命周期性能侧重不同，优先验证简单假设，从简单到复杂，优先选择足够简单、容易出收益方案。
2、先别急着优化，优先规避性能恶化，事实和推测分开、事实验证推测，没有论证预期收益不做优化，把有限的精力投?到关键性能问题上。
3、从前端到后端，从外到内层层剥离，缩小范围到模块，模块内部分割单元测试，确定优化目标。
4、性能优化没有尽头，在高速迭代中完成优化的同时，还需要与时俱进，移动时代的当下，不断投入和提高移动应用性能更具价值。
5、需要塑造情怀和氛围，追求高性能的工程师文化，写快速友好的代码。另外性能优化是持久战，是一个系统工程，需要耐得住寂寞。
1.3.3 相关的人
互联网企业就是产品工厂，无论移动端还是PC端，都是由产品设计工程师构图，再由软件工程师开发生产，最后由质量和运维工程师把关，以保障产品线上的稳定可用。任何一个环节都是由人及人控制的机器完成，而性能问题的根源也在于此。一定程度上，人为因素决定了性能问题的发生和修复。而往往一个产品的性能问题是由多个人导致的（很多性能问题的产生是因负责人的意识淡漠及“功力”不足而直接导致的），我们能做的是将这些人通过性能相关的数据，联动起来，一起解决并保持。
应用性能管理角色与分工
众所周知提高一个网站的性能很难，而以一个很小的团队让一个大规模网站一直保持高性能则更难。性能问题可以发生在一个模块，也可以是一个产品，更可以发生在一个部门的多个产品。基于一家公司对所有产品进行对应性能优化，就是最大规模企业级的全公司产品性能优化。例如腾讯、阿里、百度都有专职优化团队来负责公司级产品优化。而我在百度负责的UAQ团队就是具有这样使命的团队。在日常工作中，需要同时配合14条核心产品线进行性能优化。而通常比较多的情况是产品级性能优化，一个产品团队的技术经理负责组织前端、后端、运维等同事立项，分期优化达成目标。通常不同角色的分工如下图1-3所示：
图1-3 性能优化团队角色及分工
1、FE（前端研发）
1）分析前端程序执行效率，改进前端逻辑和代码性能。
2）前端公共框架和代码质量管理，前端发布质量规范。
3）负责前端JS测速、用户性能数据收集和分析，前端性能分析工具开发，
2、RD（架构师、后端研发、移动研发）
1）分析程序执行效率、系统架构中的性能瓶颈，优化系统结构。
2）设计更好的应用系统架构和落地。
3）针对影响性能的模块和接口进行专题项目改进和持续迭代。
3、OP（运维）
1）分析系统运行状况（系统），分析系统资源使用情况(硬件)，
3）分析应用程序对资源的使用情况，应用程序执行效率及相关压力测试。
4）负责服务器硬件、软件、软件配置性能优化，前沿相关技术调研和落地。
5）提供与竞品的瓶颈分析、速度优化、评测报告、收益评估。
4、SYS（网络）
1）IDC、CDN、硬件性能测试、商务采购、上架，新硬件调研和落地。
2）负责IDC外网、内网传输及相关QoS保障，负责IDC、CDN性能优化。
3）负责操作系统母盘、内核、TCP传输、网络路由等调优。
正视团队在性能管理的短板
性能问题发生在成长型团队或产品快速迭代的团队中是很常见的，而发生在成熟团队中则较少见到。Team
Leader是性能问题发生和优化的主要负责人，起到性能问题的关键把控作用。通常看一款产品的性能问题，也能看出团队领导人的底蕴。可以预见的是，如果Team
Leader能规避多数性能问题，这款产品的体验肯定是优秀的。并且这个团队的成员在性能优化的储备肯定是足够的。反之则刚好相悖。从我在腾讯、百度做性能优化的这几年看来，正常情况下，多数团队达不到理想状态与Team
Leader出现短板和没有意识是最糟糕的情况，而团队中部分角色出现短板则是很常见的情况。
无论因何种原因导致性能瓶颈！无论是谁指出来我们的产品存在性能问题！Team
Leader一定要重视。因为只要存在性能问题，就会影响使用产品的所有用户，包括未来的新用户。如果不优化，放任自流，就会延续影响。Team
Leader不仅需要具备规避性能风险的能力，更需要提升整个团队性能优化的意识。只有在日常迭代中减少性能问题的发生，才能从根本上保证在新产品开发过程中杜绝性能问题。值得注意的是，在保持和优化应用性能的经验和教训上，以下三个方面也非常重要：
1、找到“头狼”，让有经验的性能优化高手来主导并快速启动性能优化，快速聚焦最高价值（的）优化目标的同时，在过程中提升整个团队的性能优化能力和意识。
2、一切以数据说话，优化的决策和优化后的度量都是要建立在科学、能说服所有人的性能数据之上。并能监测最终用户体验及优化收益，把性能数据价值化与全团队分享，最终得到认可，。
3、分担责任，性能问题的发生是由产品各环节的角色决定的，首先要自己担当并正视性能问题。性能优化的成功必须建立在与产品研发、测试、运维等团队长期合作之上，不可能单方向完成，更不可以一蹴而就。
1.3.4 解决的问题
所谓信息量是指从N个相等可能事件中选出一个事件所需要的信息度量或含量，也就是在辩识N个事件中特定的一个事件过程中所需要提问“是或否”的最少次数。应用性能优化也如此。每家互联网企业都有若干产品及产品对应的开发环境、测试环境、生产环境。（以及）这些环境运行的IDC、服务器、系统、应用、用户端等都同时存在大量的性能事件。这些性能事件最终会综合发生在用户使用产品的体验中，而应用性能管理要解决的问题也应运而生。以下将结合个人实践，提出应用性能管理主要待解决问题如下。
最终目的是提高用户体验
用户体验与产品影响力、企业形象，甚至企业营收都有直接关系。性能管理最终目标都是以提高用户体验为根本。例如BAT都是以追求极致体验著称。一切应用性能优化和资源投入都是围绕核心产品展开，力争在同行业将产品体验做到最快。百度在提升搜索体验中不断探索和追求极致，为了加快100ms，投入数千台服务器，足见其对于用户体验重要性的把握。
让应用性能完全透明可控
建立完整体系的性能监控和海量实时数据分析平台，有助于实时跟踪页面性能、及时发现页面性能问题，并为性能优化效果提供数据支持。应用性能管理最基础的工作是监测所有，宛如雷达一般的作用。也只有全方位监测到所有环境中的性能事件并将这些性能逐一可视化、趋势化，才具备应用性能管理的前题。应用性能中衡量用户体验的指标超过100个，分布在移动、PC、网络、系统、应用等大的维度，后面的章节会详细介绍如何搭建体系的监测平台和（介绍）如何评测相关性能指标。
积累团队性能优化实践
积累性能分析和评估方法、研究性能优化的方法，有助于提高工程师在优化性能方面的知识。而提供优化性能的工具和库，为多个产品线性能优化提供支持，则能让所有人都考虑性能，快速实施性能优化。性能问题经常在线上被用户反馈或人工巡检发觉，这在初创团队或新产品团队是很常见的现象。一方面，因为成熟的团队或大的产品线都具备足够的人力和时间来完善应用性能，但肯定都是从不完善中走过来的。另一方面，由于团队不断在流动和变化中，这需要在团队不断积累与性能相关的意识。从一定程度上讲，应用性能对于研发亦或是运维都属于高阶技能，需要在日常工作中不断实践和积累。
自动化解决常见性能问题
研发、测试、运维等工程师的主要压力源自实现产品性能稳定、可持续发展。在大多数情况下，由于主观上对性能优化方法和工具了解有限，而学习和实践又需要较长时间，所以最理想的状态是实现产品线优化工程化的解决性能问题——即能自动化地规避、优化应用性能。但是现下对多数团队来说可操作性极弱。以下列举较为常见的实践场景，以便理解：
1、成熟互联网企业，例如BAT有公司级统一高性能前端框架、统一CDN、BGP网络接入、高性能应用组件等相关部门，并且有专业的人来维护这些平台。产品只需要拆分接入即可享受到最优性能，而且不需要自己维护。除此之外，成熟的互联网企业应当具备完整的应用性能管理体系和意识，在产品测试和发布前尽量将性能问题发生概率减至最低。
2、逻辑简单的产品，例如以静态模块为主的电商、咨询、UGC用户产生内容等类产品，大量内容即是用户访问的对象。这些内容在发布时就可以自动做大量的优化，并自动发布。也可以直接使用第三方高性能的云，例如计算、存储、网络等。
1.3.5 前提条件
具备分析问题能力
具备应用性能相关的基础知识和学习能力是做应用性能管理的基本条件之一。任何企业和团队有关于应用性能管理的经历都是由小到大、由浅入深的积累过程。我在腾讯工作时，腾讯成熟团队最先开展性能优化，并不断将优化成果在公司内部分享。这是我们当时最快的学习途径之一。由于部门和产品之间存在差异性，所以我通过消化其它产品团队的优化思路和方法，结合个人的体会，总结几个主要学习途径如下：
1、公司内部。相对大的互联网企业，多部门多产品，有些产品和团队肯定走在最前面。从研发的技术发展通道看，前端技术方向肯定会涉及到性能优化相关。因为前端负责看得见摸得着的产品构建，直接产生大部分性能问题。而在公司内部首先找到这些部门和接口的人，安排部门之间技术交流或当面沟通都可以快速学习他们的实践。
2、专业大会。当前是用户至上的时代，各公司或多或少都有不少性能管理的实践，在各种大会上都能看到相关的分享，这些都是学习的途径。例如Velocity大会的主题就是性能，InfoQ上也有很多与性能相关的采访和文章。
3、多认识牛人。无论是国内或国外公司都有这个方向的牛人。而性能优化本身是互联网技术体系里的“上乘武功”。往往这些牛人都可以通过朋友介绍或在微博、微信上找到，也可以通过各种大会上认识，而且这些牛人多数都有在网站写博客等，这些都是学习和交流的突破口，如果问题较多可以整理出来集中约时间或邮件交流。
争取领导和同事支持
首先可以肯定的是，所有领导在用户体验和应用性能上都是愿意投入时间和人力的，只是需要引导领导去正视现在的问题及排期。其次，每个产品团队的构成和长短各不同。有些团队的负责人是产品出身，有些是研发出身，有些甚至是销售出身等，这些都需要通过对应的侧面去引导。此外，还存在一种情况是领导需要更多的数据做支撑，需要说服相关的同事配合去做一些问题的验证，做出几个收益来辅助说明。最理想的状态是让领导亲自摇旗呐喊，落实充足预算，与奖金挂钩。举个例子，阿里有个产品团队就与总裁级别的领导对赌过应用性能，即通过设定速度KPI。如果完不成KPI当年考核最低档，当然如若完成KPI资金很丰厚。
多了解公司内外资源
性能优化要想做得深入，需要建立一整套监测、分析、优化平台，特别是监测平台。而很多团队初期往往是从0开始的，一方面需要借助公司其它团队和公共团队的相关平台来拿到数据，才能将数据二次加工集中到自有平台。除了相对监测起点较高外，优化的资源更容易获取，例如网络、硬件可以预算采购、人力可以协调排期、公共的基础平台可以沟通接入等。另一方面，也就是公司外的资源主要是通过找到优秀的基础云平台，并将这些云平台的技术人员也吸纳进来共同达成目标。
1.3.6 组织形式
多数互联网产品团队往往因新产品功能和迭代会忽视应用性能，但当应用性能的问题积累到临界点后，会毫不留情地以影响产品体验的方式体现在产品的使用过程中，从而对产品的总体价值产生负面影响。而要平衡这个临界点是需要具备一套完整的应用性能监测与分析平台，这些工具平台的建立需要时间和不断调优。所以优秀的企业会招聘专职的性能优化工程师来搭建监测平台和分析应用的性能，从而帮助企业多个产品团队可持续优化。这些性能优化团队与产品团队是可平行发展的，甚至可以理解为内部的甲乙方关系，这是常见的企业级应用性能管理的组织形式。
虚拟团队
组织保障是非常有必要的。正所谓闻道有先后，术业有专攻。产品线RD＼FE＼QA＼OP团队主要精力集中在生产和维护产品上，而性能优化团队的主要职责在系统化的性能分析与优化上。实际情况是，性能优化工程师综合能力和技术等级越高，产品线团队与性能优化团队两者则更能完美互补。在一定时间段内，两个团队需要组成一个虚拟团队并设定一个性能优化目标。例如在腾讯做门户性能优化时，我们会持续对比三大传统门户网站的速度，优化前排名第４，经过优化后完全反超竞争对手。在百度PC搜索、移动搜索也是类似的形式，最后结过虚拟团队的协调和持续优化，最终全面反超竞品。
值得一提的是，也可将第三方相关团队纳入到虚拟团队中。例如第三方CDN、APM、TCP加速服务商等。特别是在中小企业内部人力有限的情况下，第三方的人力是非常好的补充，而且他们经验丰富，服务和配合能力较强。通过第三方团队可以了解业务，并借助其曾经帮助过的其它企业实践过的优秀经验，直接转化为提高自身企业应用性能优化效益。
资源
古语云“巧妇难为无米之炊”。其实也有这层意思，这里说的资源主要指非人力因素，专用于支撑应用性能改善的资源。例如网终资源IDC＼CDN＼BGP＼TDO、内部或外部高性能云平台等。这些资源之间需要提前协调，在不同的阶段要沟通好到位的时间。如果过早就绪会直接导致闲置、浪费成本。举个例子，如果在Q2需要使用100台全新服务器，而在Q1就已经全部上架，将导致90天的机架租用成本、电费及服务器折旧。
平台
这里的平台主要指应用性能的监测、分析、优化平台。其中监测权重最大，前期性能监测不到位或监测不完整都会让性能优化失真，甚至是偏离方向。后期则需要持续监测应用的性能并保持性能优化的成果。监测按大的分类主要可以分为PC、移动、国际化等，例如移动监测又细分为Web
App、Native App（IOS\Android）监测，其中PC监测范畴最广。主要分为PC和移动真机监测、PC和移动JS监测、网络监测、可用性监测、流媒体监测、应用监测等。监测是应用性能管理的“眼睛”。可以说如果没有监测平台，一切性能优化都将失去度量，更无法发觉性能问题。
笔者之前在百度负责UAQ性能优化团队，结合个人体会，企业级性能优化组织形式如下图1-4所示。
图1-4 百度优化团队组织形式
1.4 如何正确开始
应用性能管理三部曲
性能问题是实时发生的，并且会像人生病一样反复出现。对于互联网企业或产品负责人，需要持续的关注应用性能，并不断进行改进。而面临最大的问题是如何正确的开始，少走弯路。纵观国内外多个优秀企业的性能优化团队沉淀和自己在腾讯、百度的实践，个人认为性能优化主要围绕监测、分析、优化三个核心循环。第一步，监测最是关键。监测好比掌握应用性能的“眼睛”。可尽管万事开头难，但良好的开端即是成功的一半。所以我认为前期的最主要精力应该放在监测上，监测对象、如何监测、监测数据如何分析、如何定位故障并优化等问题都会在后面的章节详细阐述。应用性能管理的三部曲如图1-5所示：
1、监测。通过监测产品及竞争对手在各终端、各产品形态下的性能，例如PC、手机、平板终端及操作系统、网络、应用等，全面评估自身及竞争者的表现，并作出迅速定位故障及排错。
2、分析。通过标准来评估网页/应用/网络IDC、ISP、CDN等性能，为优化及资源投入提供依据，为优化效果提供衡量，提供性能及故障预警、报警。
3、优化。通过网络、系统、前端、应用等各层进行体系优化，以将产品网页速度优化提升至达到业界最快为目标，进而提高用户忠诚度、购买意愿、品牌价值等。
图1-5 应用性能管理三部曲
如何正确开始
1、部署监控。前期最重要的是部署监控，无论自有监测平台还是第三方监测，必须在实际进行优化前完成。因为如果没有对比测试，就无法证明优化效果。只有通过监控平台获取到竞品及网络相关的数据，才对确定优化方案具有参考价值。
2、查找瓶颈。接下来对于这些监测对象和数据，需要分析出影响性能的瓶颈在哪？有哪些方面需要不断调整或深入监测。这一阶段的主要工作是搜集各种相关信息，方便接下来制定优化方案。
3、确定方案。完成瓶颈查找后的下一步是确定优化方案。通过分析之前收集到的各种数据来进行判断，并完成需要发起性能优化的讨论及确定人力、资源投入的统筹。
4、优化实施。这一步主要指优化方案的实现过程。例如研发从前端、后端、移动端进行全方面的代码和逻辑优化及硬件、网络升级等。由于某些优化会导致一些关联的问题发生，需要做好前期的沟通和充分的论证。而核心产品需要单独搭建线下测试环境，经充分测试没有问题后，在上线过程中还可以灰度做A/B测试，通过监测真实用户的数据，选择最优方案。
5、跟踪反馈。持续反馈也是非常重要的工作，性能优化是一个繁杂的系统工程，除了参与人和优化项多以外，有些优化是需要长时间持续优化的。并需要进一步建立周会或报告机制，需要指定各方向的负责人来跟踪并反馈。
另外，除了以上基本步骤以外，一些有助于正确的进行性能优化的思路分享如下：
1、初期以探索为主，不急于优化。主要以找短板，搭建监测平台，掌握数据为主。中后期迭代过程中在稳定的前提下以重点优化核心产品为主。
2、从视觉感受和数据监测上同时分析问题。在数据的基础上设定优化目标，从一开始就需要准备稳定可靠的长期应用性能监控机制。
3、与关联的产品线提前接触。从设计优化方案到优化上线全程邀请他们一起参与，提前准备好应急方案。
1.5 投入与收益平衡
做好长期投入的准备
无论应用性能管理生命周期中的监测还是优化，都需要投入资源才有产出。例如人力、服务器（包含硬件）、机架、IDC\CDN带宽等。这些资源投入只要有科学的监测数据来衡量引导，肯定会有收益，只是收益的大小和质量不同而已。事实上，往往在性能优化立项之初，我们只需知道要达到的总目标，例如80%的用户加载时间<2s。但要达到这个目标不可能一蹴而就，需要分期分阶段完成。特别是在大型互联网企业周期更长。例如我在腾讯做门户性能优化时期，一共花费2年时间历经3期；在百度做搜索性能优化时，共耗时3年。所以需要从一开始决策投入与收益，基本原则如下：
1、抓住主要矛盾，制定性价比最高方案、让收益最大者先行。通常立项时已经能够大致分析有多少改进空间、这些改进空间需要什么样的资源。例如使用CDN、将旧业务迁移高性能公共平台等。需要将最容易落地，最容易出收益的先做，通常系统层、网络层的优化最容易出成果，受益面最广，而且是一劳永逸。
2、联合到所有相关的人并协商好时间并行。例如前端工程师、移动工程师，运维工程师可以并行、也可单独进行优化，优化上线时也可以约定好时间共同上线，合并收益。也可以分前端、后端、移动端、网络端等同时进行。总之，灵活机动，合理分配。
3、提前协调资源，特别是贵资源。例如IDC、服务器，至少需要提前半年做预算，并最终通过发起采购、生产、物流、上架、配置环境和应用等一系列复杂的流程才能落地使用。人的时间也是需要提前协调的，特别是部门的高工或架构师，基本全年都排满了，多数情况下需要BOSS特批才能腾挪出有限的时间。还有一种常见的做法是借，借机器、借人，都需要上层领导足够支持。
应用性能优化 VS 成本优化
首先明确一点，性能优化最大的收益是改善用户体验，增加产品的口碑和商业价值，且同时还存在另一种极为重要的收益，即运营成本收益。结合我在腾讯、百度参与了大量的产品性能优化项目经历之见，由于系统总会有历史包袱，初期随便抓一个产品，分析后总能看到或多或少的性能问题，可随着优化工作的进展，越到后面，优化的工作慢慢变少，保持和维护优化之后的性能慢慢成为主要工作。笔者在众多性能优化实践中得到的经验是，应用性能管理的初期，优化空间最大、优化收益最容易体现。这里的优化空间往往还包含大量的运营成本减少，性能优化与成本优化通常在优化前期是能够两者兼得，而优化后期优化空间和难度越来越大是需要用成本换速度的，两都的关联如图1-6所示。
性能优化伴随大量的页面和应用性能提升，而内容瘦身、业务合并会直接降低带宽成本和服务器投入。恰逢这两种成本是互联网企业运营成本主要构成，性能优化通常伴随以下成本减少：
1、内容瘦身和大量使用全国CDN减少、北上广中心IDC带宽和服务器使用，降低带宽、机架、服务器成本。
2、提升后端模块性能和迁移规模化的高性能集群，从而降低资源消耗，提高资源利用率，合理冗余以抵御灾难。
3、通过服务器性能优化和管理，让资源管理透明化，预算估计更规范化，以减少不必要的资源闲置和浪费。
图1-6 性能与成本优化示意图
1.6 优秀企业的经验
国际一流互联网企业（Google、Facebook、Yahoo等）
1、性能管理方法论的先驱，并成立独立的性能优化团队，将性能优化发挥到极致。
2、开源和沉淀了大量性能管理原则、工具、流程。其中以Google将性能做为网站检索的重要权重。
3、性能优化领域最专业的Velocity大会，每年为业界分享最新、最前沿的性能优化相关成果。
4、Yahoo有专业的性能管理团队，并对外产出工具和指南，例如Yslow。
5、Google有专业的性能管理团队，并对外产出工具和指南，例如webpagetest/pagespeed/SPDY。
6、Facebook有专业的性能管理团队，建立大量应用性能数据统计和分析模型。
国内一线互联网企业（腾讯、阿里、百度等）
1、紧跟国际先行者，针对自身特性进行大量性能优化实践，并不断总结、完善。
2、腾讯从2007年就开始进行大规模用户体验优化。百度、阿里在2010年开始将性能管理体系化。
3、公司级性能监测、优化团队随着逐年性能优化不断深入，并形成具有中国互联网特色的完整性能管理方法论。
国内二、三线互联网企业（新浪、携程、美团、58同城等）
1、近年开始进行性能优化实践，并取得重大收获，性能提高20%~50%。
2、逐渐深入到研发、测试、发布等产品生命周期，在性能上不断领先竞争对手。
3、性能优化相关体系日渐完善，并不断将性能优化成果在各主题大会上分享。
笔者有幸在百度负责用户访问质量UAQ（User access quality）团队。团队定位主要是负责百度产品应用性能管理与优化，通过建立用户访问质量监测平台，提供百度产品及竞品访问质量一对一的监测、分析、优化服务，进而建立可持续的用户质量分析、评估体系和优化最佳实践。主要通过内容和应用、网络、系统层等优化，达到提升用户体验和产品价值的目标。覆盖百度33个产品线，监测1200个任务，1~2重要级的产品线覆盖率为93%，输出300+份评测报告，全力配合百度14条核心产品线性能优化，性能管理的形式如图1-7所示。
图1-7 百度应用性能管理实践
|
