专项质量保障
　　（1）多副本分布式存储：旁路测试 & 线上数据检查，以数据完整 & 安全为使命
　　考虑灾备冗余、成本因素，云存储都会使用多个机房，跨机房的传输相比单机房的数据流动本身即增大了延迟，不同机房网络属性、机器性能等差异更对服务质量的保障提出了挑战。单一的机器性能测试已经不满足需求，需要引入旁路测试：复制线上的部署拓扑，进行等比例缩放，仿真线上的数据，在测试环境里重放，观察复杂部署和网络环境下服务的稳定性，辅佐一定的异常流量，评估系统的容错性以及灾难发生时预案是否能生效等。为更进一步保障数据的安全，对线上每日新增的数据较验各个副本的一致性及完整性。
　　（2）多机房 & P2P 流量架构：流量 diff 系统 & 实网系统 & 众测测速，传输速度体验
　　下载由源站IDC、CDN和P2P三部分承担，用户端、网络端、服务器云端的每一个环节都会影响速度。服务端的流量调度是根据用户地点、运营商网络、请求入口、文件所在机房、资源热度等多重属性对用户分配多个可带优先级的下载域名，让客户端充分并发及容错。多重维度的组合注定了调度策略的复杂性以及验证的难度，流量 diff 系统应运而生：在线下构造两套流量系统，一套线上代码环境，一套测试代码环境。通过回放线下真实流量，diff 前后调度是否符合预期，是否带来了非预期的变化。
　　P2P公司测试与用户网络差异大，大规模用户节点的互连测试也受资源所限，只能借助线上真实用户的环境协助，即实网系统。将 SDK 包封装成独立的应用程序下发至众测或是粉丝用户本地进行下载，验证联通率以及联通速度。
　　对于运营商、第三方CDN、P2P这类非自身服务，云存储对他们的服务质量可感知以及可操控能力甚微，需要把控线上用户的传输质量需要邀请众测用户为监控节点，定期探测将地域性、运营商性属性、本地接入网络属性、服务器连接信息并上报服务器，以做用户的大数据分析。从运营商、地域、域名、文件大小等多个维度展现网络服务质量，量化了速度大小、失败率质量数据，同时补充了域名联通性、第三方CDN、骨干网络这类第三方服务监控的空白，为文件传输服务线上问题的监控、定位、解决和服务优化提供全面的数据支撑。
　　百度云QA成长史
　　首先，以百度云为例回顾一下产品从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）的实时防线，后通过“上线管理—报警中心—智能定位—故障通报”的质量闭环环节落地，不断迭代优化。
　　浅谈产品从0到N的质量保障之路
　　回顾网盘QA伴随着百度云产品的成长之路，完善质量保障体系的征程中多半是问题驱动的，以踩坑、填坑、防止再次入坑的模式前行。分级发布的触发时机也是因为线下测试的不完备导致问题在线上爆发影响用户，速度监控也是应对日益暴涨的用户关于数据传输的体验报怨。除了基本的服务稳定性监控之外开始加速、做网络等底层。视频卡顿的业务监控同样也是因为几次网盘服务基本不可用的重大故障修复速度未及时跟上所催生。
　　以百度云三年的经验来看，一个成熟的产品都是经历“目标顾客—小范围实验—反馈修改—产品迭代—获得核心认知—高速增长”的正向良性循环中，从0到1、再从1到N不断发展壮大的。至关重要的质量保障一环除了线下持续集成能力加快迭代，上线分级发布能力降低风险以及线上业务监控防御能力三类基础的工程能力之外，也需要不断相对调整重心，提早做好准备，跟上产品的节奏。
　　（1）产品从无到有创立时期，以快的方式、以少的精力验证市场需求为目标。质量的重点则是保证核心功能的正确性的前提下，与所有角色达成共识，精简并确定发版标准，招募第一批体验用户，将 MVP（第一个小化可行化产品）尽早地将产品抵达用户，去接受市场验证，收集有需求的顾客在意的是什么品质的服务，与此同时核心监控应同重要运营指标统计一起上线，密切关注数据变化。
　　（2）产品在从1进入N的发展时期，新功能进入爆发期，技术上需要支持邀请用户来体验新功能，同时产品在此阶段会借助一些运营活动造势，利用传播的力量将产品普及到更多的用户，激发用户更多的使用产品。使应对可能蜂拥而至的流量服务能正常运转成为质量保障的重点。
　　（3）当产品到达N，积累到一定量的用户规模后，线上服务的稳定性成为质量的重中之重。建立一套自下而上的系统级、应用级、业务级和用户体验级监控，打造线下持续集成、上线管理、线上监控、用户反馈的质量闭环，事先及时预警发现故障，事后提供翔实的数据用于快速追查问题。