打破传统的质量评测手段 -童庭坚（PerfMa技术部CTO）

童庭坚（PerfMa 技术部CTO）

《打破传统的质量评测手段》演讲

TiD2020质量竞争力大会邀请了PerfMa 技术部CTO童庭坚为参会者带来《打破传统的质量评测手段》精彩演讲。

童庭坚从“为何故障防不胜防，不断增强系统的反脆弱性，在不确定性中获益”三部分，阐述打破传统的质量评测手段，增强系统稳定性。

一、为何故障防不胜防

一) 我们总会有这样的顾虑

1. 顾虑一：有做性能测试，但仅代表实验

我们有比较完善的性能测试规范和手段，对于重大项目变更发布前都会进行性能验证，但因为环境、数据和生产的差异，测试结果仅能代表实验室数据。因此，即便有正式的测试报告，运维人员依然会为版本迭代上线后或重大营销活动的容量和性能担忧。

童庭坚讲到这主要是两大原因：一是环境差异，二是场景差异。

2. 顾虑二：我们项目紧急，来不及做性能测试

随着业务需求迭代速度加快，很多项目发布周期短，再加上测试资源不够用，所以发布前大部分变更只做功能验证，而上线后系统响应很慢，或业务不可用的情况难以避免。

3. 顾虑三：平时生产水位很低很低，从没出现过这种情况

考虑到生产容量的安全线，运维部门通常会通过设备冗余手段来保障。所以，平时设备水位会非常低，以应变不确定性大流量业务场景。事实上，这种手段也是防不胜防。

不论是业务场景的变化（线下业务模式转到线上），还是业务量的突增，都可能会导致系统出现用户访问卡顿甚至无法响应的情况，比如：疫情期间线上零售（买药/买口罩/买菜）、直播、教育等行业明显出现此类情况。

(二) 系统稳定性为何如此不堪一击

开发、架构、运维，测试，都会担心系统的脆弱性。那么我们如何去保障整个生产的稳定性？

系统的性能、可靠性能力都将直接影响到系统稳定性，我们把这次测试归属为非功能测试。非功能测试不同于功能测试，功能偏重于对业务的理解和测试方法，而性能、可靠性测试还需要有足够的架构理解和性能分析及调优力，业内在非功能测试（尤其是性能和可靠性测试）上投入大的企业为数不多，这也就意味着不可能建立较为完整的性能保障体系。所以，生产系统的稳定性风险随时可能爆发。

二、不断增强系统的反脆弱性

一) 什么是反脆弱

1. 反脆弱是什么

反脆弱是脆弱的反面，脆弱的反面并不是坚强或坚韧。坚强或坚韧只是保证一个事物在不确定性中不受伤，保持不变，却没有办法更进一步，让自己变得更好。而脆弱的反面应该完成这个步骤，不仅在风险中保全自我，而且变得更好、更有力量。做一个类比的话，坚强或坚韧就像一个被扔到地上的纸团，不会摔坏，但是也只是维持了原貌，这还不够。

2. 反脆弱的目的

和纸团相反，乒乓球扔到地上非但不会摔坏，反而可以弹得更高。乒乓球拥有的就是脆弱反面的能力，也就是反脆弱。反脆弱是塔勒布定义的一个全新概念，和脆弱刚好相反，指向了另一个方向，指出事物在风险和不确定性面前并不是束手无策的，完全可以扭亏为盈。

(二) 打有准备的仗，业务井喷之下，依旧丝般顺滑

IT系统的反脆弱能力不是说高流量下通过限流保护自己不被击垮，而是让生产系统的架构具备弹性能力，更像是提升系统反脆弱能力。

系统的反脆弱能力，可以从两个方面考虑，一个是防御能力，另一个是是应急能力。防御能力包括架构设计、研发实现、质量评测。应急能力包括监控、定位、止血及解决能力。

如何去提升系统的反脆弱能力？童庭坚重点介绍了能力体系中的一种方法:全链路压测。

(三) 为什么“他”的反脆弱性可以历练得如此之强？

童庭坚介绍了自己在阿里经历过的双11期间从提心吊胆、只怕意外到丝般顺滑的3个阶段。

2012年到2014年是提心吊胆阶段。在双11之前，线下对系统进行性能相关的压测，运维同学在生产做引流压测，这两种手段结合对系统的容量进行评估。但事实上，在2013年前的多届双11经常会有各种各样的故障出现，尤其在双11业务高峰时，出现用户体验下滑的情况。

在2014年上半年，当时各业务线架构、中间件、DBA、质量等团队共同落地了全链路压测方法。虽然2014年到2015年期间有了全链路压测方法，但一直处于容量验证的阶段，因为仅仅验证容量是不够的，担心出现意外情况。比如业务场景预判有偏差或其他未验证到位的隐患暴露，可能就会影响系统可用率。

2015年到2017年是丝般顺滑阶段。基于全链路压测方法，实现生产重大变更、预案的演练。全链路压测方法不单单验证性能，其更大的价值会在系统的健壮性和可靠性历练上。在双11的真正业务高峰来临时，各类场景都经过演练，做到胸有成竹的信心对技术人而言，就可以理解丝般顺滑了。这体现了全链路压测方法的整体价值。

前面提到的“从传统质测局面中突围”，其实指的就是全链路压测方法。

(四) 一种“从传统质测局面中突围”的反脆弱能力提升方法

全链路压测方法

全链路压测方法起初在蚂蚁经历了几个阶段的演变，在12年前基本的测试方法还是线下做单系统压测，针对评测出的问题进行分析和优化。这种测试方法可以发现单体系统本身的性能瓶颈。由于验证整条业务链路上的系统集成性能表现，所以生产出现一些集成情况下的性能容量问题仍然常见。

2012-2013年我们在实验室环境中构建了全链路系统进行了业务链路系统回归，由于蚂蚁的系统较多，我们根据系统的等级划分来确定核心业务链路回归范围。对于核心链路以外的系统，可以采用挡板模式做服务模拟。通过这样的方法针对每个日常迭代版本进行实验室评测，当时我们把这个方法叫关键业务链路回归压测。

事实上，关联业务链路回归压测毕竟是在测试环境，和生产的环境差异较大，压测的结果对运维部门而言参考度并不高，所以，通常在营销活动前，运维人员会在生产上做大规模的引流压测（通过真实流量转发的方式实现引流），这也是早期在蚂蚁金服用的最多的容量验证手段，就是引流压测。

由于引流压测只能针对单个集群间的流量转发，所以验证的方式和实验室的单系统压测类似，只是引流压测在生产是真实环境，不存在环境差异导致的仿真度问题。但弊端也很明显，所以希望做全链路级别的生产压测。

生产压测有几大不可缺失的能力。包括：流量模拟、流量识别、风险识别、风险熔断等，这些能力的目的都是考虑如何规避生产环境压测所带来的风险。

。。。。。。