前言
对大量使用CDN产品甚至依赖的直播平台而言，CDN的质量问题，一直是一个长期让人头疼的问题。而质量不好，势必影响业务发展的稳定性。
CDN的质量问题表现有以下几点：
一、平台方“不知道有问题”：同时存在的直播间太多，覆盖的用户更多，不知道好不好，也不知道哪里不好。
二、平台方“被知道有问题”：不能第一时间主动感知到质量变化，直到弹幕里被带了节奏才被动知晓，为时已晚。
三、平台方“不知道问题在哪里”：有N条流，分发给N个节点，又分发给N个用户，业务非常复杂，一旦有质量波动，不能第一时间定位原因所在。
四、CDN厂商“也不知道有问题”：CDN厂商更关注的是整个资源盘的质量，颗粒比较粗，加上没有端做数据支撑，往往比平台方更后知后觉。
综上所述，本质原因是数据的量级和业务的复杂度不匹配，要用极少的数据来监控复杂的业务，本身不现实。而业务的复杂性是客观存在，也是业务本身所需，不可更改，那就需要通过增加数据的量级来做匹配，
要提升数据的量级，并完成匹配，必须具备2个条件：负责数据采集的端和负责数据分析的模型。
数据采集
服务端的数据采集，CDN厂商就能做到。但光有服务端的数据，就分析而言，是很单薄的，有点居庙堂之高，未知江湖之远的味道。
因此，地处“江湖之远”的客户端数据就显得尤为重要，是整个数据集合中的灵魂。只有端的数据才是最真实最正确的，其它模拟检测产品的数据再仿真也只是参考，代表的仅仅是可能，而非确凿。
而客户端的真实数据，是CDN厂商所鞭长莫及的，只有平台自己来采集。
那么，具体要采集什么数据呢？
主要采集（即客户端主动上报）在线人次和卡顿事件，细分的数据有以下
1 时间点：精确到秒，一般卡顿事件就会有。
2 用户IP：上报时服务端从底层可以获取，所以不同刻意加上（其实客户端也不知道自己的公网IP）
3 流名：即代表用户所处的直播间，流名应该全平台唯一。
4 端类型：因为不同的端，特性不同，细分开来，还是有助于深入分析的。主要分flash、H5(PC)、iphone、Android、Ipad、Android_Pad、Android_TV、H5（moblie），事先确认好定义。
5 服务器节点IP：一般首次调度使用IP调度方式即可获取，若使用了域名调度，就获取不到，只能忽略。所以，建议使用IP调度方式。
6 CDN：当前服务的CDN厂商编号。
7 协议类型：目前有rtmp、HDL、HLS这3种主流流媒体协议。就直播而言，使用比重较大的是rtmp和HDL。后来有在上面新增一些P2P的技术，可以理解为新的一种协议，作为独立的考察项。
8 行为ID：表示用户本次拉流行为的ID，这个是很重要的值。比如用户可能会在一段时间内多次拉流，就会生成多个行为ID，也会产生多个卡顿事件，用行为ID，就区别不同的行为，以及卡顿分属哪次行为。否则不同的卡顿事件，除了时间点不同外，以上2-7点的数据都可能相同，就无法做进一步区分了。行为ID的生成算法要求客户端随机生成，且相当长的时间（如24小时）内不重复。
一般建议要记录每一次的卡顿事件，再加上带着这些多维度的实时参数，数据量是应该是足够了的，接下来就要看怎么做数据分析了。
数据分析
数据分析比较看重模型。不同的业务要求，会采用不同的模型。
本文作者基于实操的经验，建议采用的分析模式可以是流-节点-用户模型。
什么意思呢？即先观察流的质量，再观察节点质量，最后观察用户本地的网络质量。
为什么要按这个顺序分析呢？因为从业务特性来看，流的质量影响权重是最大的，节点其次，最后才是用户。
比如一个流本身质量变差了，势必当时看这个流的用户都会受影响，无一幸免，也无从逃避；但如果某一节点质量变差，从流的视角看，只是部分用户被影响，不太容易带节奏，且可以通过换节点缓解；而用户本地的网络质量出问题，影响面最小，很可能一个直播间里就他一个人有影响，处理起来也比较简单。
这里把分析的流程图列出来
其中流卡顿超标的原因分析、节点卡顿超标的原因分析以及用户卡顿原因分析，涉及到的细节很多，这边就给出一个思维框架供参考，不做细解。
其它因素
以上说的都是比较简单和纯粹的模型，但其实整个数据采集和数据分析，还需要考虑到其它因素，比如：
1 多CDN的架构。
一般都会采用多家CDN。有些平台采用的是直推一家CDN厂商，其它CDN厂商会去这一家拉流；也有的平台采用的是直推一家CDN厂商，由该厂商转推给其它CDN厂商。不同的架构，对数据的分析会有不同。
2 转码。
转码，即多码率，也是现在直播平台的功能标配，遇到原始码率高的流，为了适应不同带宽的用户需求，会通过云转码的方式转出超清、高清和标清等不同清晰度（背后的码率参数各自定义）。那么分析流质量的时候，就要同时考虑转码流的质量，若转码流质量不好，但源流好的，那说明是转码过程出问题了；又若转码流和源流质量都不好，那很可能是源流问题。
3 多出口。
中国的网络情况很复杂，很多小运营商的存在，导致很多用户的出口表现为电信、联通，其实并非电信、联通用户，容易在调度和定位问题上混淆视听。而且经常是一会电信的出口IP，一会又小运营商自己的出口IP，走位十分飘忽。为了尽可能定位用户真实的运营商归属，建议可以多获取和记录几次用户IP，按照一定规则，来准确定位。
最后的话
CDN的质量检测是一个复杂而需要耐心的工程。
首先，要求相关人员，不仅要了解CDN的基本原理，并且要吃透平台的业务特色。
其次，要制定适合自己平台的分析模型，特别是各个报警阈值的设定。
最后，有了数据采集和数据分析，才能做之后适合自己的调度工作。
调度工作，又是一个很复杂的话题，就不在本文展开，有机会再讲。