问题背景：大型APP质量保障困境

之前手机淘宝客户端的研发质量保障体系大致如下， 研发期会进行需求管控、代码扫描、单元测试、UI测试、性能、稳定性等专项测试、适配回归等保证集成质量。发布期会对要发布产物进行一系列的发布卡口检查，如包产物校验、高可用检查、功能回归检查、适配确认等，还会通过灰度发布来进行更多系统、机型、用户场景的覆盖， 补充覆盖到线下测试无法覆盖到的盲区， 期间收集相关的稳定性、高可用问题、舆情体验问题，修复完成后才会进行正式发布。 此外对于大促版本，还会对大促相关活动进行发版前的提前验收，以确保不会有大促态下的叠加问题。 到了版本发布完成后的运维期， 主要是进行监控、告警处理、问题定位、问题恢复等线上运维活动。当我们做完这些质量保障工作，会发现线上问题仍然存在， 有时甚至会有严重的故障。

类似手机淘宝这样的大型APP可能都会遇到类似的质量保障困境， 究其原因， 还是由于大型APP自身的系统特性及发布节奏所决定的：

• 一方面， 由于互联网产品迭代速度快， 客户端版本往往一月已发布，甚至每周一发布，在有限的时间内，考虑到ROI， 会主要去保障主链路和重点场景， 一些长尾场景可能被遗漏；
  
• 另一方面， 由于动态化因素众多导致发布前的线下及灰度测试是不可能覆盖全面所有的场景，发现全部的问题；
  

• • 业务多、模块多：依赖复杂， 模块相互之间的影响是黑盒的、混沌的；
    
  • 二方、三方生态繁荣：开发者不仅来自手淘内部，也有集团还有外部研发者， 已经建立了相关的准入机制，但难免有不可控和遗漏的部分；
    
  • 变更多、发布多：服务端、前端、配置、Push推送， 以及营销活动等都可能对端侧代码路径造成影响；
    

还有一个很重要的因素——外部不可控因素。线下测试可以覆盖全面用户使用的真实设备和操作系统版本。客户端应用的体验会受到操作系统和手机厂商的影响， 由于系统和手机厂商经常会有升级更新， APP研发人员需要紧跟其脚步，每次苹果或者Android系统升级都可能带来一些不可预期的问题。

解决思路：基于混沌工程建设客户端攻防演练

介于前面介绍的事实，我们会发现一个悲观的事实， 在发布前发现所有的问题是不可能的。我们可以做的是：1. 减少意外问题发生的可能性；2. 降低问题发生时带来的影响。服务端分布式系统较多，应对未知问题的经验比较多，客户端可以借鉴。

混沌工程是近年来服务端分布式架构应对未知风险的其中一项比较热门的实践。“混沌工程原则”网站给出了下面的定义——混沌工程是一门对系统进行实验的学科，旨在了解系统应对生产环境的各种混乱状况的能力，建立对系统的信心。攻防演练是混沌工程的一个子集， 通过沉淀通用的故障模式，以可控成本在线上进行重放， 以持续性的演练和回归方式来暴露问题， 不断推动系统、工具、流程、人员能力的不断演进。

客户端作为一个广义意义上的分布式系统， 因此也可以参考混沌工程的理念来提升其健壮性，降低故障发生的风险。经过评估，我们发现攻防演练可以一定程度补充和完善客户端质量保障的能力。

• 面向失败设计：为了避免失败去提前往系统注入失败并想好应对规避策略以及预案；
  
• 验证链路高可用：通过故障注入，去验收证明全链路的高可用性， 包括监控、告警、定位、恢复体系；
  
• 提升应急能力：通过故障演练， 提升研发团队应对线上问题时的应急能力；
  

此外， 攻防演练对项目其他角色也具有一定的意义：

• 对于架构&研发， 在架构和技术方案设计时，可以设想在不同场景下可能导致系统失败的各种因素，并在方案中对失败进行预防处理；
  
• 对于研发&运维， 可以在发生问题时及时找到提前设计好的恢复预案进行操作， 达到快速恢复的目的。同时通过类线上环境的故障演练， 可以提高应急能力；
  
• 对于产品&设计， 可以对系统出现异常情况下的产品体验做出优化， 并验收产品；
  
• 对于支撑&平台，能够对监控、告警、定位、恢复的线上运维全链路系统进行验收， 并且发现薄弱点加以改进；
  

从研发全生命周期来看，研发到线上运维各阶段都可以进行攻防演练。

具体方案：客户端攻防演练实施原则及体系

实施混沌工程有5大原则：第一是建立一个围绕稳定状态行为的假说， 需要定义一系列能够描述系统处于稳定状态的相关指标，服务端可以是请求成功率、RT等，客户端则是另一套指标，后文会继续介绍。第二是多样化真实世界的事件， 能够覆盖全面真实世界中的各类事件。第三是在生产环境中运行实验，这样得到的实验结果才是最贴近真实情况的，实验环境往往不被大家所信任，为了屏蔽不必要的影响（实验环境数据不同，配置不同导致差异等），应该尽量在真实的生产环境中进行混沌工程实验。第四是持续自动化运行实验， 混沌工程本身应该是一个持续迭代的过程，通过混沌工程发现的问题，得到修复后希望可以加以验证。如果该过程不是自动化可持续进行的，会导致实施成本太高， 难以常态化进行。第五是最小化爆炸半径，因为混沌工程是有损的，会对系统造成一定的影响， 所以希望不会因为实验对真实用户体验带来伤害，最好能将其影响面控制到一定的范围内，可以随时终止。

从混沌工程的5大原则，我们可以结合客户端特点总结出客户端攻防演练的5大原则：符合客户端特点的稳定状态假说， 全面覆盖客户端故障类型，在生产环境但不影响真实用户， 可持续开展，过程可度量。

第一个实施原则是需要定义出客户端的稳定状态假说， 可以分为以下4个具有客户端特色的领域：第一是稳定性指标，包括Crash率、ANR率等， 第二是性能或高可用指标， 包括客户端内存、CPU、FPS等性能指标， 以及性能问题如主线程卡顿、内存泄露等。第三是功能指标， 和业务特性强相关， 各类业务指标、异常埋点等，如页面打开成功率、视频播放成功率等。第四是体验指标， 如启动时间、页面响应时长、白屏率等。

第二个实施原则是要全面覆盖客户端故障类型。市面上大部分混动实验工具都是服务端的，主要是系统、应用、容器等实验场景。客户端也可以参考类似思路，将客户端的故障类型分层梳理出来。这里我们把客户端故障类型氛围了三层， 系统层、中间件层和业务层， 各层次对应的故障类型如下图所示：

   

第三个实施原则是尽量真实但又不能影响真实用户，这个原则要求比较矛盾， 如果要尽量贴近真实，那么大概率会使用真实环境， 不可避免的影响到真实用户。客户端相较服务端有一个特点：只有通过应用市场和自有渠道发布出去的正式包才会影响真实用户，如果打出和正式包相同代码的测试包注入问题在线下进行攻防演练，是不会对真实用户造成实际影响的。因此我们采取的方案是通过在真机实验室安装特殊的APP包来隔离线上环境，通过自动化去不断的触发这些故障场景。监控数据上报到服务端后，对相关数据加以放大，使之能达到故障或问题的告警门限，触发线上问题。同时这些监控数据也被打上了特殊标记，避免污染真实数据。

第四个实施原则是可持续开展， 这里主要是通过场景自动化和配置沉淀复用实现的。场景自动化是把故障场景通过自动化脚本的方式沉淀下来， 可以通过自动化反复在真机实验室触发。配置沉淀复用是指把注入配置、攻击场景、计划进行分层，不同层次的配置可以重复组合使用，达到降低攻防演练准备成本的目的。

第五个实施原则是过程可度量， 攻防演练需要对参与的红军进行量化的评估，因此我们将线上问题应急的过程进行了划分，定义了以下几个阶段：问题发生（问题实际发生的时间）， 问题上报（问题通过数据通道上报到监控系统的时间），问题发现（达到问题门限，触发告警时的时间）， 问题响应（相关业务收到告警上线处理问题的时间）， 问题定位（相关业务定位到问题原因的时间）， 问题处理（开始实施恢复手段的时间）， 问题恢复（系统真正恢复到正常状态的时间）。我们与监控系统、告警系统、问题处理响应系统进行了打通，采集了这些关键节点的数据，用于演练后的过程度量。

上面介绍了客户端攻防演练的实施原则， 下面将介绍下具体的实现方案。可能的实现方案主要有以下4种，围绕他们的使用成本、场景覆盖和真实性进行了分析， 最终选定了端侧SDK+注入配置的方案。

下面是客户端攻防演练的整体方案，分为蓝军和红军两方。蓝军主要由安全生产小组、架构专家、业务专家组成，主要目标是通过攻击工具对业务发起攻击。红军主要由业务开发和测试同学组成， 主要目标是在攻击发生时，使用发现、定位、恢复工具对故障进行快速响应和恢复。

下面这张图是攻防演练平台的总体架构， 最核心的部分是攻防演练配置中控台，以及注入SDK。蓝军通过配置中控台进行演练场景的配置， 该配置通过配置下发通道下发， 端侧SDK收到配置后进行解析和注入。

攻防SDK主要由以下几部分能力组成：配置接收解析、环境感知、注入决策和切面注入。切面注入主要实现了以下几类注入：Java/OC方法注入，Native方法注入、系统注入（CPU、内存、线程等）、请求拦截（篡改请求参数、返回值、请求延时）、日志注入、舆情注入，后续还会进行扩展。

攻防场景配置平台提供了注入配置、演练场景、演练计划的配置，以某个业务为例， 某次计划演练页面异常和无法点击按钮的两个场景， 可以设置注入配置为：请求超时或请求异常，拦截掉点击方法修改其行为。

攻防中控台提供了演练准备、演练审批、演练执行、演练过程、演练复盘的能力，可以一站式完成全部攻防演练流程。

攻防场景的来源主要有以下几类：线上问题， 真实的线上问题和故障是非常好的素材， 同一个问题对相关业务产生第二次攻击，观察该业务在问题发生后的复盘Action是否有效落地是很有意义的。此外也可以进行故障平移，把A业务发生的问题用来攻击B业务。主链路场景， 通过梳理业务的P0P1场景， 对这些场景进行攻击。系统Review，主要是业务或架构专家介入，对现有系统进行review分析，找出薄弱点进行攻击。泛化攻击，通过将某一类问题对不同的场景或业务进行泛化，如对某个业务下所有的方法进行拦截，使之返回空指针或抛出异常。

实践落地：手机淘宝的常态化攻防演练

前面的内容主要是介绍原理和技术方案， 攻防演练是一个技术和实践相结合的领域，整个过程需要人的强参与，尤其是红军：业务研发和测试团队。因此我们也进行了一系列的常态化运营实践，主要分为5个方面：理念宣导、培训考试、定期演练、应急数据大盘、团队积分制度，来推动攻防演练在团队落地，发现问题和产生价值。理念宣导和培训考试主要是对业务团队进行定期的培训， 让他们了解攻防演练以及线上问题处理的相关知识，做好理论知识准备。

定期演练是将攻防演练常态化，主要形式有全生命周期演练和专题演练。全生命周期演练有code review攻击（对CR进行问题注入，考察reviewer是否认真进行了review）， 变更突袭（在应用或配置发布时发起攻击， 考察发布人是否有进行系统指标的留观）， 线上突袭（随时随机对目标业务发起攻击， 综合考察目标业务的应急能力）。专题演练有监控告警专场（只考察监控和告警点是否覆盖全面， 监控告警系统是否有效）， 修复专场（考察业务快速修复能力，主要是看修复时间）， 业务蓝军专场（由业务测试或业务团队中的成员发起攻击），大促/非工作日专场（考察非工作日情况下的组织应急能力）

此外还建立了团队积分机制，对每一次的演练按标准进行打分衡量， 定期对团队演练成绩进行排名， 激励业务积极参与，通过数据发现自己应急能力待完善的地方，也会晒出攻防演练中发现的最佳实践供大家学习。

参考文献

• 混沌工程实战：手把手教你实现系统稳定性， 拉斯 • 迈尔斯；
  
• 混沌工程：Netflix 系统稳定性之道；