为了让更多的中腰部商家以及小主播们，有更多机会曝光和透出，小时榜的玩法开始进入直播间，给到商家和主播弯道超车的机会。

据悉，这次排位赛的赛道一共有85条赛道之多，在直播排位赛小时榜中，淘宝直播小二建议玩家可以选择在7-10点、12点-14点 、16点-18点等时段开播，错峰直播。活动期间，小时榜的热门广场也正式上线，每个赛道 TOP10 都会获得小时榜热门广场的个性化推荐，获取到更多的公域流量。

这套新玩法帮助主播们 get 了更多流量，也意味着支撑整个淘宝直播的技术系统，一直在提升稳定性和流畅度的路上不断迭代和升级。

今天，我们来分享揭秘淘宝直播买买买的背后，是如何通过4大保障手段，以及一套整体质量策略来支持亿级用户在排位赛里“冲锋陷阵”的？

增长背后的挑战

淘宝直播始于2015年底，到现在有繁荣的主播生态，并早早就是年度成交千亿的业务。在高速增长的背后是整个系统持续的稳定可靠。但是快速的业务迭代、复杂的系统设计和苛刻的成本控制给系统稳定性带来了不小的挑战。

电商直播是音视频、实时互动和电商交易的技术结晶，相比于传统的电商媒介（图文、视频）它的技术复杂度更高。整个技术框架由音视频流链路和电商/互动逻辑链路构成。

音视频流主要涉及推流节点、中心流服务和播放节点；电商/互动逻辑核心是主播中控台、实时消息通道和互动播放。这些系统涉及到不同的技术架构，它们相互复杂地交织在一起，其中任何一个系统的变更都可能影响整个业务链路和逻辑。

随着 4G 移动网络普及，互联网内容从文字逐步演进到了视频、直播，直播形态的各种产品遍布互联网行业。
移动时代直播本身就是一种新的产品形态，当它和电商交织在一起的时候就衍生出更多的可能。业务方往往要从这千万种的可能性中摸索出行之有效的业态和模式，而这种摸索意味着高强度的迭代和尝试。

淘宝直播的客户端几乎以每周一个版本的速度前进，服务端更是以日在变化，我们同时维护着 8 个端；除此之外还要承接源源不断的合作诉求和大促职责。不停的迭代和变化确实能够带来产品的进化，但是过于频繁的变更也将系统的稳定性逼到了墙角。

除开前述的两点之外，直播的内容形式与曾经的图文是截然不同的。更加强调实时的互动、强烈的氛围和流畅的观看，而这些特点本身又对消息通道、网络和 CDN 等软硬件资源提出了更加苛刻的要求。

技术上必然追求最低的成本带给用户最好的体验，包括最小的带宽消耗、最大的机型覆盖、最清晰和流畅的观看体验。这就意味着，必须有一套有效的度量手段来评价我们的成本和产出让 ROI 最大化。

四大保障手段

淘宝直播的质量保障体系主要围绕着如何解决上述三大挑战来进行建设。限于文章的篇幅，会从最核心的四个方面来介绍如何有效地保障淘宝直播以及电商媒体的质量。

▐  工具建设

俗话说“工欲善其事，必先利其器”。前文说过直播是一个迭代频繁的业务，测试人员在频繁的迭代下不得不面临一次次的测试和反复的业务回归。当业务高度复杂功能繁多的时候，这样的测试和回归简直就是噩梦。

以下图为例，图中展示了部分淘宝直播的互动玩法，通过主播中控台配置具体的互动玩法就能实时地投放到直播间与用户形成互动。但是不同的互动配置和不同的前端展现组合出大量的业务场景，仅靠传统的测试手段或者自动化是无法支撑的。

有什么更好的办法呢？回到业务逻辑实现，在拥有良好的编程规范的前提下，无论是客户端还是服务端，核心的业务逻辑实现是由各种内部或外部的接口组合而成。通过解构业务逻辑，再将接口组合成测试逻辑。仍旧以互动玩法为例，互动功能可以解构为互动服务、消息通道、主播服务和客户端渲染，将互动服务、消息通道和客户端渲染剥离再按照内置互动配置、调用消息通道接口触发客户端渲染的方式重新构建出新的功能，通过复用业务接口重新构建逻辑的方式可以将业务逻辑上不相关的能力关联起来形成一系列的测试工具。

对整个直播系统进行抽象解构，下图“业务域”内“的主播服务”通过消息通道和服务网关利用互动服务和直播基础服务与客户端进行交互，客户端自身具备通过服务端指令进行动态或者静态渲染的能力。在“测试域”内，可以将业务域解构的各个逻辑重新进行组合。

这种重组可以分为两个方面，客户端侧和服务端侧；在服务端侧不同的接口组合后可以重构出多维信息查询、互动模拟、开放验收等各种业务保障工具；在客户端侧基于动态、静态层和 native 的接口进行二次开发，将服务端信息和客户端本地能力聚合到测试专用的“调试浮层”便于快速能力验证、组件配置和信息透出等。

通过以上的思路，我们构建了成系列的直播（媒体）专用测试工具、打造了端侧媒体框架，全面提升了测试工作的效率，并以此为基础反复打磨形成一个完整的质量技术架构（见“整体质量策略-技术架构“）。

▐  链路排查

仅仅通过测试工具提升效率是不够的，在快速迭代中会发生各种线上/线下的问题，问题的快速排查准确定位至关重要。淘宝直播的系统纷繁复杂，涉及到音视频流链路和电商/互动逻辑链路，横跨服务端、CDN、移动端和PC端。通常需要使用不同的工具、平台和手段进行问题排查，而且大多数时候平台之间数据无法关联互通。

因此需要为复杂的直播体系构建一套全链路的排查系统。工具建设是在接口层面进行业务解构和重新组合，那么链路排查也可以复用这种思想。不同的是要进行链路抽象和简化、业务流程划分、业务数据重组和排查流程构建。更直白的说，就是将不同的业务阶段和不同的技术平台进行抽象和划分；将同一技术平台的数据按照唯一的 ID 进行聚合，再将不同的阶段同一 ID 数据进行聚合；对于聚合在同一 ID 下的数据进行诊断，利用规则匹配、智能算法和人工经验；同时结合线下的测试工具，协助快速调试和复现。

▐  数据分析

通过工具建设和链路排查再结合自动化手段，建立了高效的线上线下的质量保障能力；然而链路排查仅解决了具体的问题，对于系统和业务全局层面需要了解更多，例如线上整体质量状况、潜在问题的发现和预防、业务/技术效果评价等等。

在链路排查中，已经将不同业务阶段和技术阶段的数据进行了聚合和分析，在这些数据的基础上进行再加工，包括清洗、计算、聚合和分析，就能够将这些数据更有效地组织起来进行利用。

基于这样的想法，我们设计了一套数据分析的方法将数据划分为“大盘数据”、“纬度数据”、“详情分析”三个层次。

大盘数据主要针对线上的某个横向层面的整体分析和监控，一般划分为“业务”、“技术”、“舆情”、“异常”四个方面，大盘数据的波动意味着某个环节发生了问题。

在大盘的基础上按照不同的业务域和技术域进行拆分，每个域代表一个纬度的变化，每个纬度由多组该域内的指标构成；一般我们按照不同的端来划分技术域，按照不同的业务场景来划分业务域（图中仅为示意）。

当大盘、纬度划分清楚后，每个细节的数据指标都会归属到相应的“大盘”-“纬度”之下，再对这些细节的指标提供对比、趋势分析、多维度聚合等分析工具从而实现从全局到细节的分析和监控，针对特定的指标结合监控系统就能进行有效的告警。

这一整套数据分析的方法都建立在实时和离线的大数据分析平台之上。首先通过各端的上报工具采集原始数据形成实时数据流和转储的离线数据表；实时数据流通过实时计算平台(阿里云实时计算)对数据流进行清洗和计算；计算完成后将数据转储到搜索引擎，由引擎负责索引、排序和聚合；最后通过引擎接口返回给服务端，服务端可以对引擎提供的数据进行二次加工。

在整个过程中如果实时计算任务出现异常或者丢失，可以通过转储到离线表的数据进行补偿计算再流入到搜索引擎。

▐  媒体质量

工具建设（技术框架）、链路排查和数据分析提供了通用的质量保障能力，可以被应用到直播或者多媒体之外的场景。而音视频（直播）有自身的特点，例如画质清晰度的要求、CDN带宽的消耗和移动端的性能限制等，需要媒体专项来保障，因此我们将这些专项定义为媒体质量。

媒体质量总结为三大测试专项和两个建设领域，三大测试专项指的是“特性测试”、“（媒体）SDK测试”、“专项测试”，两大建设领域分别是“音视频实验室建设”和“标准化建设”。

• 特性测试（画质、特效、卡顿、延时等）
  

构建一套通用的媒体特性测试框架，对媒体的特性进行检测和评估

• SDK测试（推流、播放、剪辑三大SDK ）
  

构建统一的媒体demo、统一的SDK测试和报告、

• 专项测试
  

覆盖各端的性能指标、渲染能力评估，同时与竞品对比

• 音视频实验室建设
  

统一的线下物理实验室、模拟各种光照、音源、采集环境

• 标准化建设
  

媒体质量评价的核心，三统一（环境统一、流程统一、标准统一），一体化执行结果可沉淀可分析

重点介绍下特性测试框架，整个框架由推流端的“预处理模块”、网络端的“可编程网络控制”、播放端的“分析模块”以及“评估模块”四部分块构成。

• 预处理模块
  

通过hook的方式实现在推流侧统一采集内容、定制单帧检测点；

• 可编程网络控制模块
  

通过程控方式来调节推流端到播放端的网络环境，自动实现网络环境切换统一网络参数；

• 分析模块
  

主要是负责抓取播放端解码YUV数据并结合帧检测点和评估算法进行特性分析；

• 评估模块
  

提供了不同的特性评价方法可以被分析模块调用。

通过这套框架，模拟完整且标准化的媒体场景，通过调节帧检测点、采集内容、网络参数、编解码参数等实现媒体特性的专项测试。

整体质量策略

通过这四年从无到有的摸索，淘宝直播和媒体电商业务最核心的质量策略可以抽象为一个核心思想、一套技术架构和一份能力模型。

▐  核心思想

• 质量体系必须是平台化的
  
  
• 质量体系不仅仅服务测试
  
  
• 质量体系必须数据说话
  
  

▐  技术架构

• 双端技术框架和全栈开发能力
  
  
• 核心技术是大数据分析和媒体技术
  
  

▐  能力模型

• 链路排查将逐渐成为系统质量保障标配能力
  
  
• 测试团队应当建设业务专项能力深度（多媒体专项）