一次Testing in Production方案的探索 | 洞见

引子

传统的软件测试大多是在测试环境下进行的。人们普遍认为生产环境是服务于最终用户的，只有在测试环境下进行充分测试后才会发布给用户。

基于非生产环境的测试-单元测试、集成测试、功能测试等，很多都是基于预期结果的测试，测试人员一般是带着这样的思路来工作 “如果这样做会发生什么呢” -属于known-unknowns。而生产环境往往充满了惊喜-属于unknown-unknowns。我们不知道最终用户怎么操作(参考同事姚琪琳的文章《被踢出去的用户》)，数据是什么样的，基础设施有什么差异等。

Stage作为类生产环境，是和生产环境最接近的一个测试环境。然而每一次新的发布都是一组代码和环境的组合，只有真正部署到了对应的环境，我们才能确定到底有没有问题。Stage环境也是测试环境，是抱着一定目的进行的操作，并不能完全反应真实用户的行为。

项目背景

我们当前的测试流程如下:

产品经受了多个测试环境的考验，但是在部署生产环境后依然暴露出很多意想不到的问题，初步分析后归结为下面两个因素：

1. 生产环境下数据复杂多样

我们对客户报过来的production问题进行了分析，下图可以看出由于数据问题导致的功能/性能问题在10%左右的区间波动。

软件系统的灵活性给与了用户各种各样的操作可能，代码/脚本的不确定性也会造成数据的不一致。这些都赋予了生产环境下数据的多样性，是其他环境无法模拟的。

2. 软件配置的集中化

ThoughtWorks团队主要负责软件的开发，而Stage和Prod环境部署在云平台上，这些访问权限严格控制在客户手中，基础设施严重依赖于客户。

项目即将大规模将配置由原来的SVN迁移到ZooKeeper实现集中管理。作为一个技术的改进，同时也蕴含着风险 - Stage和Prod的配置将由客户进行单点手工维护，对ThoughtWorks团队不可见，因此我们无法预知某个配置是否已经被添加/修改以及是否赋予了正确的值。

Testing in Production如何做

环境的特殊性带来了产品的不确定性，我们希望把测试的触角向前延伸，到生产环境去做测试，提前暴露产品的潜在问题，提高用户的满意度。

由于各种因素的约束，在生产环境能做的事情往往有限。比如我们项目的安全等级很高，开发团队是不能够访问生产环境的服务器的，甚至连脱敏的数据也接触不到。Stage环境下的数据也仅仅是客户的测试数据，不能把生产环境下的数据迁移过来。

业界实践

TiP并不是一个全新的事物，业界已经有了很多成熟实践：蓝绿部署、金丝雀测试、A/B测试等。

蓝绿部署是在有两个一样环境的前提下，不停老版本，部署新版本进行测试。测试没问题之后直接把流量切到新版本上，再把老版本也升级到新版本。一般适用于对用户体验有一定的忍耐度、机器资源丰富的团队。

“金丝雀测试”得名于以前旷工下井前会先放一只金丝雀去看是否有有毒气体，以金丝雀能否存活进行判断。一般是部署新版本到很小比例的服务器上，并允许小部分用户来使用新版本，测试通过则把剩余的服务都升级为新版本。一般适用于对新版本缺乏信心的团队。

A/B测试主要用于产品功能对比，版本A和版本B分别部署在不同的服务器上并开放给不同的用户使用，一般适用于收集用户反馈辅助产品功能设计。

蓝绿部署

基于当前产品环境的复杂架构，构建另一套相同的生产环境来实现蓝绿部署作为第一方案被提出来。蓝绿部署的思路如图：

在同一个时间段，蓝作为当前的生产环境供线上用户使用，绿作为部署新功能的测试环境供部分用户使用。两个环境的基础设施相同，配置一样，数据都是真实的生产环境数据。绿环境下发现的问题可以随时诊断修复，确认满足上线需求后即可把线上用户引流到绿环境，实现了最小化的宕机时间。

蓝绿部署的这个优势看似极好的契合了项目当前的诉求，但是准备一套同样的生产环境需要的成本在可视化出来之后也是令人震惊的！新的服务器就需要7台，而且每个月还需要预留出足够的时间来同步数据。在功能交付的压力之下，客户是不会为这样一个昂贵且成果未知的方案买单的，我们连自己都说服不了。

改进的方案

就在焦灼的时候，在一次头脑风暴中我们获取到一条线索-客户的灾备环境(Disaster Recovery)在定期从生产环境同步数据，但也仅仅是同步数据，代码已经很久没有部署过。也就是说灾备环境没有真正起到它应有的灾难备份和恢复，只是一个数据的备份而已。

方案就此而得到转机 - 是否可以复活灾备环境，利用它可以访问生产环境数据的天然优势来解决前面的痛点呢？在蓝绿部署方案的基础上，改进的方案如下：

鉴于灾备环境的基础设施不足以支撑其作为线上环境供所有用户使用，但是它的配置是等同于产品环境的。DR的定位为分时的灾备和测试环境 - 大部分时间用于灾备，小部分时间作为金丝雀进行新版本的测试。

灾备环境测试通过后的版本按照当前的部署流程进行生产环境的部署。这样一来不仅能恢复其本来的灾备作用，也解决了之前数据和配置集中化问题带来的痛点。

展望

从当前的测试流程来看，QA和Stage环境承担的工作有很大一部分重叠，带来了一定的浪费。希望未来有一天能去掉Stage环境，直接把这些server用在生产环境下构建一套新的环境，做到充分的基于生产环境的测试，实现新老版本的无缝切换。 期待测试流程会变成如下所示：

当今软件的部署越来越多的基于第三方的云平台，给团队带来了不可控因素。Testing in Production是基于生产环境下真实用户的行为和数据进行的一系列QA活动。传统的基于测试环境进行的测试活动，辅助以生产环境下的QA活动为提高软件的质量注入了新的活力。