优酷双11猫晚技术质量保障

阿里QA导读：大家还记得天猫双11狂欢夜（猫晚）吗？小编依然还会经常听到真实力老酷guy腾格尔老师钢铁硬核版的《丑八怪》。与往年猫晚相比，今年是最“国际化”的一届，整场晚会通过优酷进行了全球直播覆盖，在这样的双11猫晚的特殊场景下，如何完成质量保障工作，让全球直播也能“如丝般顺滑”，让不同地域、不同设备的用户都能享受极致的体验？

本文为阿里文娱测试开发专家宫浩在【阿里文娱2019双11猫晚技术沙龙】中的演讲。

与开发团队不同，质量保障是一个横向支撑的团队，涉及的业务场景和技术点很多而且非常重要。在双11猫晚这样的特殊场景下，我们是如何输出保障能力的，并结合质量保障的平台能力，去保障双11和猫晚的全链路稳定性的？如何保证不同地域、设备用户都有极致的用户体验?

一、双11猫晚质量保障的挑战

双11猫晚的挑战有两大块，一是‍稳定性，在这种超级事件中，稳定压倒一切。其次，是在稳定的基础上，如何创新，并实现成本的降低。

优酷双11战役包含两大块，优酷站内的活动和猫晚，站内活动从10月20日就开始预热了，所以整个活动周期持续将近20天，我们要在这个长周期内保持整个活动的稳定，而且还要针对猫晚直播当天的创新性玩法做好针对性的测试保障工作，在人员有限的情况下，整体挑战很大。

1、稳定性压倒一切

直播链路的稳定性：4个小时的直播，可能有不同的网络环境，优酷、淘宝和天猫三个APP，六个客户端，而且不同APP上的技术架构是有差异的，相同的猫晚互动玩法在不同APP上投放，在技术实现上也有一定差别。从测试角度，我们需要把整体的测试保障能力提炼出来，否则工作量是乘以3倍和6倍来增加的；
端能力稳定提供：我们的客户端，能够提供什么样的稳定性保障能力，这对我们来说也是一个挑战；
商业价值稳定实现：我们在站内从10月20号开始有站内活动，涉及优酷站内和淘宝的权益发放，量级比较大，如何保证权益的发放量的稳定性，如何保障权益稳定的核销。
基础服务的稳定性：所有的线上系统，服务侧的能力，如何保障在大促期间的稳定性。

2、在稳定中创新和节省成本

除了稳定性之外，我们还有针对双11创新场景下的重点关注的一些点。

整个国际化链路。今年猫晚提出国际化的直播，在直播链路上我们要求是全球播全球玩，在测试的角度我们怎么来保障，怎么来模拟国际化场景下，播放场景和互动玩法的延时，能不能真实的模拟用户的这种体验场景。
今年也是优酷第一次支持IPv6-only的网络环境，借助运维的团队搭建的网络实验室，如何做链路的回归。
整体的体验成本，用户想要更高的清晰度，但CDN是有成本的，直播场有特有的策略，站在测试的角度，怎么去验证策略的可靠性。

二、稳定性基础保障策略

前面讲了那么多挑战，下面介绍下我们在稳定性方面的整体技术策略，主要分为客户端和服务端这两块。

1、客户端稳定性

我们第一次承担了猫晚的直播，且是淘宝、优酷双域，支持优酷、手淘、猫客多端，端的技术架构的不同，会带来技术实现上差异，在功能、性能、适配、体验。如何保证各端的体验一致，比如手淘要求适配的是六七十个机型，十几个互动玩法，还有猫晚国际化的场景，如何模拟海外用户体验。这两部分，是通过海川实验室跑功能自动化和性能专项，然后将整体的回归的工作量适当的降低。

特别提一点，关于iOS审核，苹果新版本过审比较严格，一旦拒审，即使再次提审，也会耽误时间，就会影响新版本APP的覆盖率，从而直接影响用户体验和商业效果。降低拒审风险，也是客户端的挑战。

我们在实验室，会去跑端上的自动化，以及端上的性能自动化，还有质量基本盘的保障能力，比如CDN的兜底、从客户端开始的全链路的排查能力，在容器层面的保障，在架构端的稳定性方面的输出，而且针对双11的版本，有特别的监控和专项，整体保证发版质量。

2、客户端支持体系

下图是客户端的整体支撑体系，其实针对双11版本，在版本的交付体系上从需求到提测到集成到灰度，到发布整个流程都在做管控，同时通过卡口，结合开发、提测以及灰度这不同的阶段里面，暴露出数据做分析，及时发现版本里的一些潜在风险和问题。

端上的我们有性能专项，埋点专项，还有客户端CDN的兜底能力。优酷是一个内容场，我们大多数是做内容场的分发，可能首页上，在某个抽屉或者区域，因为部分请求的超时会开白窗，我们三层的兜底就基本上解决这个问题，包括CDN层面、客户端缓存能力的建设，对这个内容的兜底，保证端上用户的体验。

3、服务端稳定性

服务端面临的挑战，第一个挑战来自于手淘业务的对接，包括互动玩法平台、权益平台对接集团新的发奖平台。今年第一次完全由优酷来做猫晚的直播，我们也有不熟悉的地方。比如互动玩法的平台，在权益平台对接新的发奖平台，整个的互动玩法好几十个节目穿插了互动的玩法，有公域也有私域的；比如活动过程中，如何保证说主持人口播的同时，互动能够对齐；比如押宝开始或者抽奖开始，端上如何迅速的展示玩法；比如如何保证整体的对齐率，在测试的角度如何验证压流的准确性，如何验证在高并发下SEI的对齐率。另外是整个权益平台的发放的稳定性。在很多业务场景下，如果权益没发出去，提示未中奖就可以了。但对于双11猫晚，很大的KPI是不让用户受到损失，只要参与玩法都能够保证中奖，如何在系统做保障，在验证当中，确保全链路的稳定性。

第二个挑战是猫晚的峰值。首先今年的预期流量比去年更大，且玩法门槛降低了，所以最后的脉冲流量会给系统带来很大的压力，而相比去年我们是没有加机器的，如何确保在高并发高脉冲的情况下，最终的功能体验和端测的体验能正常。我们通过不断的业务场景梳理、系统压测、调优，在容量评估、系统利用率、缓存使用策略、强弱依赖梳理、资损梳理等，发现了诸如缓存穿透、容系统量预估不合理、系统IO、无线接入层容量预估不足、机房单元化配置不合理等问题，并在多轮压测中持续摸高模拟猫晚当天互动场景，直到系统能力达到我们预期。同时相比去年系统性能也有很大的提升。另一方面,我们通过故障演练、攻防模拟等手段,对系统在特定场景下出现可能故障的情况下进行模拟和预案的准备,保证系统能在可能的依赖服务出现问题的情况下良好运行

4、服务端的支撑体系

从线下测试环境、预发环境和线上环境都有一定的保障手段。

线下更多的在服务端这一侧做服务端的CI，接口自动化，测试手段和静态扫描，还会结合线上的热点链路，把线上的代码跑出热点链路，知道哪些场景和路径，是线上真正用户跑到的。我们会将这些热点链路抓下来，和线下的自动化路径覆盖做匹配，这样就能够发现我们覆盖的不足，而且更容易优先保障线上影响用户最核心的链路。
在预发布环境会做引流层面的自动化，把线上的一些应用日志拉下来，在预发环境做回放和对比。基本能保证在发布的过程中，通过线下引上的流实现一层兜底。
对线上的监控，区别于开发和运维的系统级别的监控，在测试的角度我们更多去关注具体业务粒度的监控，比如运营配置变更的监控，对应校验的策略。还有线上活动，可能一个活动在系统层面占比很小，即使有问题波动也是很小的，我们会把关注的核心场景单独拎出来。比如发放权益，核心权益就那么几个，因为它比较贵，但如果出问题，系统波动不出来。这个情况下我们通过场景化的监控，会按渠道和业务级别来做覆盖。

针对双11场景和猫晚，无论是过程保障还是专项保障，包括全链路，故障演练，预案演练等，对整体服务端稳定性做一个保障。

三、猫晚直播的稳定性

上面介绍了服务端的保障能力，接下来介绍猫晚直播的稳定性。直播价值流转，直播流的生产和传输，到最后C端场景（直播和互动场景的消费）。

猫晚过程中我们有什么样的保障能力呢？

1、流媒体生产的保障能力

这是直播流生产过程中，我们需要保障的场景。整个直播流生产过程中，测试需要关注很多点，比如转码测试，我们通过基准视频来做基线的分析，在系统变更时，我们有一组视频作为基线的验证数据，通过代码变更后生产的视频数据来与基线数据做多维度对比：帧的对比、码率的对比，时间戳对比，通过对比来验证视频生产的基础能力，去发现我们关心的指标有没有下降。

点播的能力是我们在日常的建设中沉淀出来的平台保障能力，在双11场景下，就直接用到直播转码的场景。在优酷的场景下，除了把系统测好，我们还需要确保这些系统生产出来的数据，它是可用和稳定的。视频是千差万别的，不太可能说完全在测试环境，去覆盖所有的视频流的异常，除了线下的测试，我们还需要对线上生产出来的数据有保障能力。

在直播开始前会去做功能层面验证，直播开始时，首先预热过程中我们会去检查画面质量，会去判断CDN水位是否正常。直播进行中有做一些异常监控，转码进程的监控，一旦监控发现问题，会推荐问题解决和止血方案的落地。

2、点播保障

相对直播而言，优酷的剧集和综艺我们称作点播。在生产、开播前、上线后，从转码、入库、播放，从媒资生产的环节，到后面与业务结合，从广告场景和会员场景，测试如何保证整个全链路生产和播放的稳定性。我们在各环节，上传耗时比平时要长，有异常报错，转码效率没有平时高，都会有一些通知和报警，会保证点播质量效果。

3、直转点

在猫晚直播过程中也会把直播流转化会点播流，从直播源流到拆条剪辑到转码到入库、品控打标、视频分发。我们都有一些监控，这是对当时质量监控大盘。

四、客诉与舆情的稳定性

对线上整个客诉和舆情的感知与处理。从用户体验出发，我们需要尽快发现线上问题并解决，以前的问题是在客服角度，因为一线的客服对业务并不是那么了解，问题的反馈和上报不会那么及时。为了解决这个问题，我们通过从客服渠道自动收集问题、部署站内机器人，收集外部比如微博、豆瓣、应用商店评论，将信息抓取做语义解析和文本聚类，在客诉钉钉群里直接报警出来，这样问题发生后，技术和业务的响应速度就会更快，问题升级几率也会低一些。

问题排查：通过客户端的埋点治理，服务端的日志上云，从用户的行为维度来把日志串起来，一旦用户出现问题，能马上分析出用户在端上点击了什么、在服务端流程如何流转，串起来可以将问题定位出来。对常见的问题可以做到一键定位，智能化触达到用户去帮助用户解决问题。在线上形成了一个从问题的感知到排查，到解决的一个相对的闭环。

五、基础服务稳定专项

在阿里体系内，全链路是很成熟的。在猫晚场景下，分享下压测过程中我们的经验。

第一个是压测场景的设计。我们一定要去要看线上链路是什么，热点链路是怎么走的，压测时模拟线上真实的场景。比如，我们遇到过服务端水位很好，且没有问题的，但是用户的请求失败了，在网络接入层挂了，因为线上的网络拓扑先走一个网关层，因为其它业务的影响，网关层的量饱和了，导致用户流量根本没有进来。所以说要做好压测，需要知道线上真实的场景，比如要分清流量是PC的HTTP进来的，还是走的无线端网关层，这个流量的模型一定要确认清楚。

我们还会做数据上的治理，系统跑了很长的时间，有没有一些表的数据比较多，有没有一些慢Sql。还有脉冲流量，在猫晚抽奖场景中，这个接口真的就是一年空闲很久，但是一但有流量进来就是脉冲流量，非常非常的大。在这个场景下我们在压测过程中，除了尽量的模拟脉冲流量之外，还要结合业务场景确认脉冲流量在哪些地方会出问题，比如说脉冲流量进来之后，会有多少个请求因为缓存的读写而失败，如果有这样的情况，下一步需要在业务场景下去考虑这个场景的预热。真实情况下是在猫晚直播前两个小时跑各种的预热脚本，会把DB的连接和访问，Tair缓存的访问，包括JVM，提前做好预热。

六、猫晚端消费的稳定性

端消费的能力，我们是首次实现了直播间常规性能的自动化，图中的小盒子是性能实验室，因为测试过程中需要拍照，就用乐高搭建了一个小盒子，盒子里是跑性能自动化的机器，盒子上面是用手机拍照的，通过一帧一帧的做对比，看检测每个操作的响应速度和卡顿。

我们在端上的测试自动化的测试和端上的性能测试都有一些标准化的解决方案。

七、猫晚权益消费：资损防控

权益消费主要介绍一下资损防控，今年第一次发这么多的站内和淘宝权益，也是首次在整体上做资损防控。

什么叫资损防控？无论是产品设计的原因，还是运营配置的原因，还是bug漏测的原因，或者在高并发的场景下出现的缓存和DB数据不一致，再或者降级限流的场景没有处理好，接口返回异常给端上，端上没有很好的处理逻辑去告知用户未中奖等等，这些涉及资金层面的异常导致的赔付，都叫资损。

今年我们整体做了梳理，通过两种方式：人工介入、工具辅助来实现。

资损场景目前不能通过工具彻底解决，需要我们在各个环节有SOP管控，再结合工具的支撑。今年猫晚通过开发、测试、产品一起的配合，做权益的核验，并沉淀标准化核验的流程。

在资损前尽量做规避，梳理资损点、并做好规则校验工具；活动进行中，通过实时核对和报警，一旦有资损发生，通过监控脚本实现自动下线，来及时止血，还有监控的大盘做整体权益的观测。猫晚期间，我们通过对活动的线上的比对校验工具建设，起到也一些效果，发现一些配置问题，也发现了线上运营变更导致的有资损风险，并在活动开始之前，就及时修复了，整体防控效果不错，双11期间0资损。

八、质量保障的技术战果

每年的双11猫晚，对于技术人都是一场洗礼，在巨大的挑战和不可能中，找到新出路新方向。回过头再看过程中的煎熬，你会特别明显感受，自己对技术的理解和战役的理解，更深一层。

对于优酷整体的测试能力，像多视角的帧对齐、FPGA流媒体生产能力、移动端稳定性，都得到了落地和验证；像Crash治理、动态patch客户端的兜底能力、资损防控，多轮复核机制以及权益发放稳定性保障，在技术上的策略更加成熟，尤其是完善了移动端的通用性能评价能力。每年的战役一结束，我们就马不停蹄开始复盘和新一轮的迭代，为来年的双11蓄力。