在阿里，我们如何管理测试环境

前言

阿里的许多实践看似简单，背后却蕴涵着许多思考，譬如测试环境的管理。

互联网产品的服务通常是由Web应用、中间件、数据库和许多后台业务程序组成的，一套运行环境就是一个自成一体的小生态。最基本的运行环境是线上环境，部署产品的正式发布版本，为用户提供持续可靠的服务。

除此以外，还有许多不对外部用户开放的运行环境，用于产品团队日常的开发和验证，统称为测试环境。正式环境的稳定性，除去软件自身的质量因素，主要与运行的主机、网络等基础设施相关，而测试环境的稳定性则更多受到人为因素影响。由于频繁的版本变更，以及部署未经充分验证的代码，测试环境出故障的情况屡见不鲜。

良好的代码提交习惯、适当的变更前检查有助于减少故障的发生，但无法彻底杜绝后患。增加多套测试环境副本能够有效控制故障的影响范围，然而企业的资源终归有限，降低测试环境成本和提高测试环境稳定性成为了矛盾的两面。

在这个领域里，独具匠心的阿里研发效能团队设计了一种服务级复用的虚拟化技术，称为“特性环境”，其巧妙的思路令人赞叹。本文将围绕测试环境管理的话题，聊聊这种具有阿里特色的工作方式。

测试环境管理的困局

测试环境的用途很广泛，常见的测试环境譬如系统集成测试环境、用户验收测试环境、预发布测试环境、灰度测试环境等，它们体现了产品的交付生命周期，也间接反映出整个团队的组织结构。

小作坊型产品团队的测试环境管理起来十分简单，每个工程师本地就能启动全套软件组件进行调试，倘若不放心，再加上一个公共的集成测试环境也就足够。

随着产品规模扩大，本地启动所有服务组件逐渐变得既费时又费事，工程师们只能在本地运行一部分待调试的组件，然后利用公共测试环境上的其余组件组成完整系统。

与此同时，团队规模的扩张，使得每个团队成员的职责进一步细分，新的子团队被划分出来，这意味着项目的沟通成本增加，公共测试环境的稳定性开始变得难以控制。在这个过程中，测试环境管理复杂性带来的影响，不仅体现在服务联调变得繁琐，更直接反映在交付流程和资源成本的变化上。

在交付流程方面，一个显著的变化是测试环境种类增多。出于不同的用途和目的，工程师们设计出了各式各样的专用测试环境。这些测试环境的组合形成了各个企业独具特色的交付流程。下图展示了一种用于大型项目的复杂交付流程。

从单独服务的角度来看，环境与环境之间是由流水线相连的，再加上自动化测试或手工审批操作组成关卡，实现环境之间的传递。通常越高级别环境的部署频率越低，因此相对稳定性也越高。与之相反，在级别较低的环境上，就随时可能存在新的部署，会打扰正在使用该环境的其他人。有时为了复现某些特殊的问题场景，一些开发者不得不直接登录到服务器上面去“搞事情”，进一步影响环境的稳定性和可用性。

面对随时可能崩溃的测试环境，小企业会试着去“堵”：约束服务变更时间、设立严格的变更规范，大企业则善于用“疏”：增加测试环境副本，隔离故障影响范围。显然，不堪重负的测试环境一定越“堵”越“漏”，千年以前大禹治水的故事早就揭示了的道理，刻意的管控拯救不了脆弱的测试环境。

近年来，DevOps文化的兴起，端到端解放了开发者的双手，这对于测试环境的管理而言却是一把双刃剑。一方面，DevOps鼓励开发人员参与运维，了解产品的完整生命周期，有助于减少不必要的低级运维事故；另一方面，DevOps让更多的手伸向测试环境，更多的变更、更多的Hotfix出现了。这些实践从全局来看利大于弊，然而并不能缓解测试环境的动荡。单纯的流程疏通同样拯救不了脆弱的测试环境。

那么该投入的还得投入