白山云科技CTO童剑:性能分析体系建设之路

10月22日，运维帮与国内首家云链服务提供商白山云科技有限公司(以下简称“白山”)联合举办“性能为王”主题沙龙，白山联合创始人兼CTO童剑与五八框架组件部负责人郝新斌、京东MySQL运维自动化平台负责人王伟、《大型网站性能监测、分析与优化》作者唐文一同探讨如何建立全面、及时的性能监控与分析体系，持续对应用与网站进行性能优化。

白山云科技联合创始人兼CTO 童剑

童剑在加盟白山前曾在新浪工作16年，负责研发的动态应用平台和数据库平台，使新浪率先实现技术平台统一，支撑了微博的爆发式发展;并领导推出国内最早一批公有云——SAE。凭借多年的研发与管理经验，童剑对性能优化分析形成了一套独到见解，在现场他与研发同学分享了如何站在更高的视角去了解性能。

一、在更高视角建立性能管理运维体系

(一) 性能管理现状

目前的性能管理主要存在以下问题：技术人员关注系统层面的各种性能指标和监控，对客户端性能重视不够;业务方与技术方性能标准存在差异，系统做得好不代表用户体验好;优先支持产品功能与运营活动，性能问题解决排期靠后;没有性能指标变化与问题定位的对应关系，指标数据异常，却难以定位具体问题;缺乏体系化管理，没有统一的性能指标和运营管理，以及自上而下的协调配合，无法持续进行性能质量改进。

(二)相关的内部角色

性能问题不仅与技术人员相关，公司内部的其它人员也会对应用性能产生直接或间接的影响。业务总负责人：性能质量目标主要影响者;性能质量经理：负责日常的性能质量问题发现和反馈、推进解决; 运维与客服人员：收集和反馈用户的性能质量问题，性能问题的推动方之一;产品人员：负责产品的交互功能设计和任务排期，对性能问题的优先级判断将对问题的解决产生直接影响;技术人员：客户端、后端及其他技术体系的开发实现者，性能质量最重要、直接的影响因素。

(三)性能质量运营管理

性能分析工具建设，包括：完善性能指标体系、完善数据采集、持续提升分析准确度;问题收集反馈机制：通过员工、客服、社会化媒体收集用户反馈问题，统一跟踪处理;性能管理运营机制：由专职的质量经理负责整体运营，持续发现问题并推动解决，关键的性能指标分解到各业务责任人;制定目标、分工合作：性能需要持续追踪，制定每个阶段的性能提升目标和需要解决的性能问题，分解到相关责任人和团队，大领导推动跟进结果。

(四)关键指标定义

建立应用性能管理机制，首先需要根据应用中最重要的用户操作体验定义可量化的性能关键指标及计算方法，关键指标主要可以分为以下几类：

1. 速度类：衡量应用的请求响应时延、文件下载上传速度、图片和视频加载速度;

2. 比率类：衡量应用的成功率、错误率、性能在某个档位的百分比;

3. 容量类：衡量资源利用率和服务请求量，比如每秒请求数、带宽、CPU利用率。

以上关键指标均有预警值，当性能低于该预警值时，就需要我们行动起来。同时我们还需要知道不同的产品或者业务类型，其衡量性能和质量的关键指标可能差异很大，例如：视频是首帧加载时长、不卡比、错误率;电商类是列表页加载时长、商品页加载时长、支付响应速度、错误率等。

(五)拓扑关系梳理

分析性能时需要梳理应用与网络的技术架构，其中拓扑关系是最重要的。

应用拓扑关系

以应用普遍的技术体系为例，由于依赖大量的服务单元，底层服务众多，同时API相互调用，所以应用的拓扑关系较为复杂，可以分为以下几部分进行梳理：

1. 网络物理连接关系，例如网络中3层的路由信息、交换机间的连接信息、服务器的上联信息，两个服务器之间通讯分别经过了哪些网络节点，这些信息都要清楚;

2. 应用依赖的底层服务，例如：数据库、CACHE、存储等;

3. 应用API间的调用关系，业务的不同功能模块之间还需要彼此调用，所以API之间的调用关系也很重要。

这些拓扑信息和调用关系的记录，如果主要依靠人工更新很容易导致错误，或者更新不够及时。现在新的的趋势是自动化采集和更新，自动采集交换机中的信息和应用调用各种服务的日志，通过大数据分析、机器学习的技术，动态更新所有拓扑关系，白山已经在这些方面进行了尝试，并取得了不错成果。

(六)五个维度全覆盖

从数据采集到监测角度多纬度覆盖，利于更加快速精准的定位性能问题，主要采集以下五个维度的数据：

1. 网络层：主要采集丢包率、出口带宽、上联端口带宽、负载均衡等数据，通常的采集力度是3-5min，我们建议做到30s以内，这样才能捕获到瞬时的网络异常抖动;

2. 系统层，包括：负载、磁盘IO、内存、CPU、网卡PPS、带宽;

3. 服务软件层，包括：Apache、Nginx、MySQL、Redis、Kafka等;

4. 应用与API层，包括：请求数、错误率、平均时延，以及日同比、周月环比的数据;

5. 客户端，包括：响应时长、下载性能、错误率、上网信息。

(七)客户端数据采集

客户端的数据采集十分重要，客户端的性能表现，除受端上自身因素影响外，还与服务器端API性能直接相关。这就要求我们精细规划客户端数据采集体系，一方面用来区分客户端的实现逻辑造成的性能问题，另一方面能更好地评估服务器端的性能，为整体性能优化提供精准信息。

1. 资源请求：客户端数据采集中的重要部分，需全量或者抽样记录客户端向服务器端发起的各种请求信息和返回状态，包括API请求、图片请求、视频请求等;

2. 异常错误：采集客户端运行产生的异常错误信息，以及服务器端返回的各种错误信息;

3. 联网信息：采集客户端的上网连接信息，比如WIFI/4G/3G/2G等，以及用户的基本信息。

采集以上信息时要求各端规定统一的状态返回码，以免造成重叠，导致统一日志分析时复杂度增加。

(八)服务端数据采集

1. WWW日志：标准化日志，内部尽量能统一日志格式规范，也预留出扩展字段位供不同业务自定义使用;

2. 应用日志：应用处理请求过程中重要的外部服务调用记录，性能相关的环节处理时间记录等;

3. 基础服务日志：如消息服务处理日志，数据库查询日志、慢日志，缓存的异常请求日志等;

4. 错误日志：全部服务的错误日志、应用程序的错误日志。

采集日志时，需要注意：(1)格式统一标准化;(2)记录用户ID和请求ID;(3)记录IP地址(客户端、服务端)。

(九)分析计算平台

分析计算平台

如上图，最底下一层是数据采集部分，数据采集相对麻烦，上报体系包括主动抓取、服务器上报等方式;当服务器和数据规模较大时，一个中心的存储节点压力将逐渐加大，此时我们建议采用分层级的数据收集体系。从下往上数的第二层是数据聚合与数据清洗;存储层常规的技术有：时序数据库、ES数据库、HBase、HDFS;计算层也都是比较常规的技术;最上面一层是和性能分析有关的功能，如实时监控预警的系统、自助搜索查询、可视化报表、运营管理工具(作为事件追踪平台)、数据API平台(将产生的数据供其它运维工具调用，用以查询问题、分析状态)。

二、实战案例参考

(一)图片性能体系

移动端图片性能体系数据采集指标

很多应用都有图片下载与显示功能，这对于用户体验影响十分重要，图片加载缓慢主要影响因素包括：源站存储、CDN、客户端加载渲染机制，因此图片的性能监控也主要包括这3方面。

基于采集数据生成的分析报表

上图上半部分是错误率指标，我们可以分别找到移动客户端、CDN、源站的错误率，通过这三个部分我们可以清晰地看到具体是哪个因素导致的性能波动，据此进行问题定位。

下半部分是平均下载时间，与错误率类似，我们可以看到三个部分中各自的平均下载时间，该报表目前只展示了部分内容，我们同时还监控了各个CDN在不同运营商、不同地区的数据，可以每天把性能较差的地区调度给其它CDN观察性能变化，将性能的运营管理变成持续迭代的提升过程。

客户端分类错误统计

分析错误的主要目的是为了更好的发现产品和技术上的问题，为此我们进行了更加细致的分析。如上文所提到的，我们对标准错误码进行约定，并按照错误码进行细分，同样，错误码也按照源站和CDN进一步区分出来。

(二)视频性能体系

视频与图片类似，主要分析源站存储、CDN、客户端三方因素，CDN与源站性能主要指标是下载性能与错误率，客户端还需要分析首帧加载时长、卡播比、播放成功率等因素。很多视频需要通过API获取视频文件，所以API的性能、响应速度、失败率、成功率也要进行采集与监测;除此之外还需第三方监测工具，从多个维度进行采集与分析。

首播加载与播放成功率