| 编辑推荐: |
本文来自于云社区，本文主要介绍了美团智能支付业务在稳定性方向遇到的挑战，并重点介绍QA在稳定性测试中的一些方法与实践。
|
|
背景
美团支付承载了美团全部的交易流量，按照使用场景可以将其分为线上支付和智能支付两类业务。线上支付，支撑用户线上消费场景，处理美团所有线上交易，为团购、外卖、酒店旅游等业务线提供支付能力；智能支付，支撑用户到店消费场景，处理美团所有线下交易，通过智能POS、二维码支付、盒子支付等方式，为商家提供高效、智能化的收银解决方案。其中，智能支付作为新扩展的业务场景，去年也成为了美团增速最快的业务之一。
面临的挑战
而随着业务的快速增长，看似简单的支付动作，背后系统的复杂度却在持续提升。体现在：上层业务入口、底层支付渠道的不断丰富，微服务化背景下系统的纵向分层、服务的横向拆分，还有对外部系统（营销中心、会员中心、风控中心等）、内部基础设施（队列、缓存等）的依赖也越来越多，整条链路上的核心服务节点超过20个，业务复杂度可想而知。
此外，技术团队在短时间内就完成了从几个人到近百人规模的扩张，这也是一个潜在的不稳定因素。曾经在一段时间内，整个系统处在“牵一发而动全身”的状态，即使自身系统不做任何发版升级，也会因为一些基础设施、上下游服务的问题，业务会毫无征兆地受到影响。
痛定思痛，我们对发生过的线上问题进行复盘，分析影响服务稳定性的原因。通过数据发现，72%的严重故障集中在第三方服务和基础设施故障，对应的一些典型事故场景，比如：第三方支付通道不稳定、基础设施（如消息队列）不稳定，进而导致整个系统雪崩，当依赖方故障恢复后，我们的业务却很难立即恢复。
解决方案
基于这些问题，我们开展了稳定性建设专项，目的很明确：提升服务的可用性。目标是逐步将系统可用性从2个9提升到3个9，再向4个9去努力。这个过程中最核心的两个策略：柔性可用，意思是尽可能保证核心功能可用，或在有损情况下尽可能保证核心用户体验，降低影响；另一个是快速恢复，即用工具或机制保证故障的快速定位和解决，降低故障修复时间。
围绕这两个策略，在稳定性建设中的常见操作：限流、熔断降级、扩容，用于打造系统的柔性可用；故障响应SOP、故障自动处理，用于故障处理时的快速恢复。而QA的工作更侧重于对这些“常见操作”进行有效性验证。基于经验，重点介绍“三把利剑”：故障演练、线上压测、持续运营体系。
故障演练的由来
举个真实的案例，在一次处理某支付通道不稳定的线上问题时，开发同学执行之前已经测试通过的预案（服务端关闭该通道，预期客户端将该支付通道的开关置灰，并会提示用户使用其他支付方式），但执行中却发现预案无法生效（服务端操作后，客户端该支付通道仍处于开启状态）。非故障场景下预案功能正常，故障场景下却失效了。
这就是故障演练的由来，我们需要尽可能还原故障场景，才能真正验证预案的有效性。
故障演练的整体方案
故障演练的整体方案，主要分为三部分：
1.负载生成模块，负责尽可能还原系统的真实运行场景（要求覆盖核心业务流程）。
2.故障注入模块，包含故障注入工具、故障样本库（涵盖外部服务、基础组件、机房、网络等各种依赖，并重点关注超时、异常两种情况）。
3.业务验证模块，结合自动化测试用例和各个监控大盘来进行。
为了更高效地开展故障演练，我们的策略是分为两个阶段进行。首先，针对单系统进行故障演练，从故障样本库出发，全面覆盖该系统所有的保护预案；在此基础上，进行全链路故障演练，聚焦核心服务故障，验证上下游服务的容错性。
故障演练的效果
事实证明，故障演练确实给我们带来了很多“惊喜”，暴露了很多隐患。这里列举三类问题：数据库主从延迟影响交易；基础设施故障时，业务未做降级；依赖服务超时设置不合理、限流策略考虑不足等。
线上压测的由来
面对业务的指数级增长，我们必须对系统可承载的流量做到心中有数。对于QA来说，需要找到精准、高效的系统容量评估方法。我们碰到的难点包括：链路长、环节多、服务错综复杂，线下环境与线上差异大等等，基于测试有效性和测试成本考虑，我们决定要做线上压测，而且要实现全链路的线上压测。
线上压测的整体方案
全链路压测的实现方案，与业界主流方案没有太大区别。根据压测流程，首先，场景建模，以便更真实的还原线上系统运行场景；其次，基础数据构造，应满足数据类型以及量级的要求，避免数据热点；之后，流量构建，读写流量构造或回放，同时对压测流量进行标记和脱敏；再之后，压测执行，过程中收集链路各节点的业务运行状态、资源使用情况等；最后，生成压测报告。
基于全链路线上压测方案，可以根据业务需求，灵活地进行单链路压测、分层压测等。更为重要的是，基于压测我们可以进行线上的故障演练，用于更加真实的验证系统限流、熔断等保护预案。
线上压测的效果
通过全链路线上压测，一方面让我们对系统容量做到心中有数，另一方面也让我们发现了线上系统运行过程中的潜在问题，而且这些问题一般都是高风险的。同样列举三类问题：基础设施优化，如机房负载不均衡、数据库主从延迟严重等；系统服务优化，如线程池配置不合理、数据库需要拆分等；故障预案优化，如限流阈值设置过低，有的甚至已经接近限流边缘而浑然不知等等。
持续运营体系的由来
智能支付的稳定性建设是作为一个专项在做，持续了近3个月的时间；在效果还不错的情况下，我们从智能支付延伸到整个金融服务平台，以虚拟项目组的方式再次运转了3个月的时间。通过项目方式，确实能集中解决现存的大部分稳定性问题，但业务在发展、系统在迭代，稳定性建设必然是一项长期的工作。于是，QA牵头SRE、DBA、RD，建立了初步的稳定性持续运营体系，并在持续完善。
持续运营体系的整体方案
下面介绍持续运营体系的三大策略：
流程规范工具化，尽可能减少人为意识因素，降低人力沟通和维护成本。
如：配置变更流程，将配置变更视同代码上线，以PR方式提交评审；代码规范检查落地到工具，尽可能将编码最佳实践抽取为规则，将人工检查演变为工具检查。
质量度量可视化，提取指标、通过数据驱动相关问题的PDCA闭环。
如：我们与SRE、DBA进行合作，将线
上系统运维中与稳定性相关的指标提取出来，类似数据库慢查询次数、核心服务接口响应时长等等，并对指标数据进行实时监控，进而推进相关问题的解决。
演练压测常态化，降低演练和压测成本，具备常态化执行的能力。
如：通过自动化的触发演练报警，验证应急SOP在各团队实际执行中的效果。
基于以上三个策略，构建稳定性持续运营体系。强调闭环，从质量度量与评价、到问题分析与解决，最终完成方法与工具的沉淀；过程中，通过平台建设来落地运营数据、完善运营工具，提升运营效率。
持续运营体系的效果
简单展示当前持续运营体系的运行效果，包含风险评估、质量大盘、问题跟进以及最佳实践的沉淀等。
未来规划
综上便是智能支付QA在稳定性建设中的重点工作。对于未来工作的想法，主要有3个方向。第一，测试有效性提升，持续去扩展故障样本库、优化演练工具和压测方案；第二，持续的平台化建设，实现操作平台化、数据平台化；第三，智能化，逐步从人工运营、自动化运营到尝试智能化运营。
|
