2012年，百度云正式推出，随即推出一系列服务（如数据存储、文件分享、个人主页、图片智能管理、视频播放、离线下载、闪电互传、手机忘带、数据线等），构筑了一套完整的云上生态。与国内外主流厂商如三星、OPPO等合作让云能力成为终端机标配，3年实现3亿用户的增长。与此同时产品与技术不断创新，对质量保障工作带来了不小的挑战。本文将从测试技术、专项保障，体系经验三个维度讲述了百度云的质量保障工作。
质量保障的核心目标是质量 & 效率并重，对于互联网产品来说诠释如下：
-
不仅仅是功能可用性层面，需要关注用户体验。
-
不仅仅是上线前的质量保证，需要延伸至把关上线中、线上的质量。
-
不仅仅只停留在好坏的感性模糊认识，需要将质量概念量化、可视化。
-
不仅仅光靠抽样个例，需要大数据统计做强有力的支撑。
-
不仅仅只局限自身产品的质量，也需要关心竞品。
-
加快产品迭代，唯快不破。
-
提高问题暴露，定位以及解决速度，快中求稳。
对产品建立质量标准，将其度量化并形成稳定的、可衡量的产品质量benchmark，对于个人云存储产品可以列出数据完整性、安全性、传输速度、在线消费体验等最核心的质量维度。线下以此作为发版标准，驱动产品质量迭代越来越接近目标；线上以此作为监控范围，对线上质量问题主动防御，加快应对。
线下集成持续化、测试服务化，以应用质量（QPS、SLA、性能）、业务指标、过程质量（代码覆盖率，千行 bug 率）一系列发版标准为目标，将自动化测试、性能、单测、异常等工具集成入构建—部署—quickcheck—slowcheck—release 的流程中，快速发现问题并解决，迭代质量。线下需要更多精力关注在异常和性能测试中，这些往往是线上问题多发区。
上线过程中灰度控制，把产品发布过程划分为多个级别，每个级别限制一定的流量和用户范围，并在每个级别对产品进行部署和验证的迭代过程。一方面逐步放量，小心验证，降低上线带来的风险；另一方面开展用户测试，让用户参与产品测试，加强与用户互动。让用户参与 beta 环境分为两种情形：被动命中（将同一特征的用户强制划分至小流量环境中）和主动邀请（邀请粉丝或有偿用户）。对服务器来说架构能够支持逐步放开流量，对客户端发版来说有一个平台支持哪些版本哪些用户能升级到beta版本，并且在小流量阶段要密切关注监控和用户反馈，将问题及时扼杀在萌牙阶段，不带到全量阶段。
线上监控 & 定位，从基础拓扑（网络、单机、数据库等底层服务）、服务稳定性（接口成功率、5XX、4XX非预期返回码的占比等服务器可用性层面）和业务质量（上传、下载的成功率等用户功能层面的易用性）三个核心要素延展开全方位细粒度的监控覆盖，并从质量标准、质量防线和质量闭环三个维度进行质量建设：首先对产品建立一套完善的产品质量标准体系，并将其度量化，固定成 benchmark。紧紧围绕质量数据，组建从用户（舆情热点）、端（产品体验）、服务器（稳定性）到基础网络（SLA）的层层实时防护网，最后通过上线管理—报警中心—智能定位—故障通报的质量闭环环节落地，不断迭代优化，能够快到线上问题快速预警、定位及解决。
（1）多副本分布式存储：旁路测试 & 线上数据检查，以数据完整 & 安全为使命
考虑灾备冗余、成本因素，云存储都会使用多个机房，跨机房的传输相比单机房的数据流动本身即增大了延迟，不同机房网络属性、机器性能等差异更对服务质量的保障提出了挑战。单一的机器性能测试已经不满足需求，需要引入旁路测试：复制线上的部署拓扑，进行等比例缩放，仿真线上的数据，在测试环境里重放，观察复杂部署和网络环境下服务的稳定性，辅佐一定的异常流量，评估系统的容错性以及灾难发生时预案是否能生效等。为更进一步保障数据的安全，对线上每日新增的数据较验各个副本的一致性及完整性。
（2）多机房 & P2P 流量架构：流量 diff 系统 & 实网系统 & 众测测速，传输速度体验
下载由源站IDC、CDN和P2P三部分承担，用户端、网络端、服务器云端的每一个环节都会影响速度。服务端的流量调度是根据用户地点、运营商网络、请求入口、文件所在机房、资源热度等多重属性对用户分配多个可带优先级的下载域名，让客户端充分并发及容错。多重维度的组合注定了调度策略的复杂性以及验证的难度，流量 diff 系统应运而生：在线下构造两套流量系统，一套线上代码环境，一套测试代码环境。通过回放线下真实流量，diff 前后调度是否符合预期，是否带来了非预期的变化。
P2P公司测试与用户网络差异大，大规模用户节点的互连测试也受资源所限，只能借助线上真实用户的环境协助，即实网系统。将 SDK 包封装成独立的应用程序下发至众测或是粉丝用户本地进行下载，验证联通率以及联通速度。
对于运营商、第三方CDN、P2P这类非自身服务，云存储对他们的服务质量可感知以及可操控能力甚微，需要把控线上用户的传输质量需要邀请全国众测用户为监控节点，定期探测将地域性、运营商性属性、本地接入网络属性、服务器连接信息并上报服务器，以做全国用户的大数据分析。从运营商、地域、域名、文件大小等多个维度展现网络服务质量，量化了速度大小、失败率质量数据，同时补充了域名联通性、第三方CDN、骨干网络这类第三方服务监控的空白，为文件传输服务线上问题的监控、定位、解决和服务优化提供全面的数据支撑。
首先，以百度云为例回顾一下产品从0到N一路护航过程：
（1）产品从无到有阶段，QA进入“积本夯木，完善线下测试”重心阶段。12年底的增设机房和机器的迁移，多机房网络延时大，传输质量差都会加剧服务的稳定性和性能降低的风险，随即推出的一系列大型运营推广活动，对线下测试带来不小的挑战。针对此探索出来的多机房测试方案以及旁路测试、运营活动测试方案很好地保障了质量，也对后续其他产品起到很好的借鉴意义。
（2）产品进入功能迸发式增涨阶段，QA进入“TestinProduction”重心阶段。此时上线风险把控变得尤为关键，代码的变更是否影响用户的使用，新功能推出时用户的接受度如何？我们在服务器推行分级发布的落地，同时这一思路推广至端的发版，支持了很多1.0产品的发布，较快的收集到用户反馈并回馈到需求中迭代，同时也将上线中的问题收敛到小流量阶段，全量回滚数为0。
（3）产品服务日趋便利强大之后，QA转移“TestOPs”重心阶段。此时用户进入迸发式增涨阶段，“稳定、速度、安全、成本”成为关注重点。要让线上质量看得见，以质量度量的方式促进服务优化，我们开启了“云图”计划。
该计划经历了四个阶段:
1.0阶段：利用自动化 Case 定期对线上环境运行的方式进行监控。但经过一段时间的运行，发现两大弊端。其一，单一 Case 对于线上不同的机房，不同的运营商，不同的文件等等维度的爆炸式组合的覆盖面仅仅是九牛一毛；其二，Case 的稳定性维护成本大，并不能协助发现线上问题，需要探索新的监控模式。
2.0阶段：从线上核心功能数据安全性和数据传输速度入手，利用全量用户真实的端做智能节点做核心质量监控。
3.0阶段：2014年5月网盘有次故障，经过一段时间才得以恢复，原因是 DB 机房和 PCS 服务机房某一个链路出现丢包严重，导致 PHP-CGI 资源耗尽而拒绝服务。说明承载线上几亿用户的产品在自身的模块以及依赖的第三方服务越来越多的情况下，单一的核心质量监控已经满足不了需求，需要从基础拓扑、服务稳定性和业务质量三个核心要素延展开全方位、细粒度的监控覆盖。
4.0阶段：从质量标准、质量防线和质量闭环三个维度进行质量建设。首先对产品建立一套完善的产品质量标准体系，并将其度量化，固定成 benchmark。紧紧围绕质量数据，组建从用户（舆情热点）、端（产品体验）、服务器（稳定性）到基础网络（SLA）的实时防线，最后通过“上线管理—报警中心—智能定位—故障通报”的质量闭环环节落地，不断迭代优化。
回顾网盘QA伴随着百度云产品的成长之路，完善质量保障体系的征程中多半是问题驱动的，以踩坑、填坑、防止再次入坑的模式前行。分级发布的触发时机也是因为线下测试的不完备导致问题在线上爆发影响用户，速度监控也是应对日益暴涨的用户关于数据传输的体验报怨。除了基本的服务稳定性监控之外开始加速、做网络等底层。视频卡顿的业务监控同样也是因为几次网盘服务基本不可用的重大故障修复速度未及时跟上所催生。
以百度云三年的经验来看，一个成熟的产品都是经历“目标顾客—小范围实验—反馈修改—产品迭代—获得核心认知—高速增长”的正向良性循环中，从0到1、再从1到N不断发展壮大的。至关重要的质量保障一环除了线下持续集成能力加快迭代，上线分级发布能力降低风险以及线上业务监控防御能力三类基础的工程能力之外，也需要不断相对调整重心，提早做好准备，跟上产品的节奏。
（1）产品从无到有创立时期，以最快的方式、以最少的精力验证市场需求为目标。质量的重点则是保证核心功能的正确性的前提下，与所有角色达成共识，精简并确定发版标准，招募第一批体验用户，将 MVP（第一个最小化可行化产品）尽早地将产品抵达用户，去接受市场验证，收集有需求的顾客最在意的是什么品质的服务，与此同时核心监控应同重要运营指标统计一起上线，密切关注数据变化。
（2）产品在从1进入N的发展时期，新功能进入爆发期，技术上需要支持邀请用户来体验新功能，同时产品在此阶段会借助一些运营活动造势，利用传播的力量将产品普及到更多的用户，激发用户更多的使用产品。使应对可能蜂拥而至的流量服务能正常运转成为质量保障的重点。
（3）当产品到达N，积累到一定量的用户规模后，线上服务的稳定性成为质量的重中之重。建立一套自下而上的系统级、应用级、业务级和用户体验级监控，打造线下持续集成、上线管理、线上监控、用户反馈的质量闭环，事先及时预警发现故障，事后提供翔实的数据用于快速追查问题。
