测试环境建设之路

测试环境是每一个软件开发团队都必须认真面对的事物。不管底层环境提供能力如何变化，与之对应的上层相关的环境可用性建设方法却有相似之处。本文记录了我司测试团队内部的线下环境可用性小组（简称小组，下同）在测试环境方面的实践，旨在留下阶段总结以便后续借鉴。

一、小组成立背景

公司层面公用统一的测试环境建设，其实开始已久。只不过，多个环境虽已存在，但是该有的环境能力没有被充分使用，也没有达成一致的使用公约。比如，sit环境本应是公司内各个业务组（特别是有上下游依赖的）之间使用的集成测试环境，但却没有真正用起来，导致某些业务的上下游测试链路不通、某些场景没法验证，从而漏测、引入线上故障；另一种场景是测试环境不稳定，容易出现测试五分钟、排查两小时的情况，影响产研效率。基于这个背景，测试团队内部几个人组建了线下环境可用性小组（当时叫sit环境可用性小组，因为第一阶段是建设sit环境，第二阶段才是整个线下环境的治理）。

在具体开始介绍小组工作之前，有必要进一步讲解下我司测试环境治理的情况。和大多数引入devops的公司一样，我司的测试环境治理和devops实践相辅相成。虽然一般来说测试环境治理先于devops实践，但却是devops实践加速了测试环境治理。那么测试环境治理，从治理过程来看会先后经历：环境编排能力建设、CI/CD流水线建设、应用发布管理平台建设、中间件组件支持等硬件建设阶段，以及业务方试点推动、环境能力异常监控、环境使用规范制定、线下环境标准化等软件建设阶段。两个阶段的建设，虽说子模块不一定会按照上面说的顺序依次建设，但整体上会相互依赖并相互成长，彼此关系示意图见图1：

在小组成立之初，测试环境治理的硬件建设阶段基本完成，那么对应的软能力建设将是小组的工作重点（当然硬件建设方面也会有对应的迭代更新），如同高速公路的沥青路面、防护栏和收费站等设施已完善，接下来就是车道按需划线、高速公路交通管理办法推广和交通流量管制等内容了。

二、sit环境推动

小组成立之后，第一目标是推动sit环境的建设。我们从sit环境现状摸底开始，先后展开了以下几个关键行动。

2.1 环境组件统一化与适配

从线下采访和查阅之前的文档得知，当时测试环境治理的大部分硬件建设工作已接近尾声。不过还有两件事情要做：

（1）底层基础组件重新整理配置，线下环境只保留和维护一套公用的中间件和存储组件，包括：缓存（ redis，memcached）、数据持久（mysql，mongo等）、消息队列（kafka、*mq）等；

（2）前端工程版本选择功能做改造，使得前端部署代码支持切换并访问sit环境后端服务。

这两件事情的完成，使得线下各个环境的衔接和流转变得流畅，并为后续链式发布（功能测试环境、集成测试环境、预发测试环境、生产发布环境、stable基础环境）提供了必要铺垫。

2.2 推动sit环境业务试点

推动环境建设之时，对sit环境的使用，各业务方是各自为政。以某业务组A为例，具体情况是：

（1）sit环境没被强制定为集成测试环境，所以完整的集成测试验证可能不在sit环境上进行；

（2）即使某应用部署在sit环境上，对应的应用分支也可以随时随意被切换；

（3）该业务组内还有部分服务，以及依赖的其他组的服务，大部分都不在sit环境上。

其他业务组的情况也类似，只是程度或多或少罢了。这就导致了sit环境没有真正用起来，如同刚铺装好路面的高速公路因无规范约定导致或堵塞或无序，而没法实现高速公路存在的意义。

摸清问题之后，本着尽可能少打扰正常业务测试进度的原则，我们选取部分业务组进行sit环境试点。被选中的业务组，会被要求梳理组内的待部署应用（即主要的业务应用，包含“核心”应用和部分“非核心”应用），如下面的线下环境统一化服务对接文档中的部分表格（表格1）所示，并按照规定部署对应的master分支。

接下来就是在sit环境上，进行较为全面的业务回归验证测试，找出因为sit环境导致的链路不通的问题：某些依赖服务没有部署、对应部署的服务soa version不对、sit环境数据库链接配置不对等。解决了一轮问题之后，再将此过程中收获的经验应用到剩余的业务组中，最后进行全业务链路的整体回归。至此，公司全部业务组的核心后端服务，都已部署到sit环境并完成了全链路的调试验收。整体的推进流程可参见图2：

2.3 应用部署流程环境卡点

在进行sit环境业务试点的过程中，我们意识到：如果单纯依靠人肉检查或者流程主观约束，那么sit环境上服务的部署最终会重新走向无序状态。因此和devops团队商议后，决定对我们的后端应用发布管理系统进行改造：将sit环境部署纳入发布管理的首要环节，使得集成测试成为发布上线的第一步；同时将stable基础环境代码更新设置成发布上线的最后一步，且只能由prod生产环境部署成功后自动流转。这就从系统上约束了stable环境只能部署master分支代码且不能随意发布，从而保证了基础环境的稳定性。至此，新的应用发布上线整体流程参考图3，具体的应用发布管理上的实现见图4：

另外，将sit环境设置成发布上线第一步的同时，我们要求各业务线研发测试同学尽可能保证sit环境上部署分支的稳定性。之所以没有在应用发布管理系统上限定发布分支，是因为实际测试过程中存在偶尔部署临时分支验证的可能性。于是乎，sit环境维稳相关的第一份“君子协议”由此诞生：我不限定你在sit环境部署分支的自由，但是你应该保证服务稳定性。不过我们依然会通过统计sit环境上各服务部署分支的数据，如表格2所示，来追踪对应的情况并及时对异常情况进行修正和对当事人“批评教育”。当然，至于后续要不要将此也像部署流程一样在平台上固化，需观察一段时间收集民意再定。

2.4 前端代码部署规范

上面3个行动，主要作用对象都是后端应用，只在推动sit环境业务试点时偶尔处理了一些前端相关的问题，所以前端代码部署相关的放在此处跟进。前端服务的部署流程，跟后端服务的类似，所以前端服务的环境实践方式基本直接复制后端服务的做法了。只是前端服务目前的部署方式比较多，由于历史原因，除了jenkins还有其他几种诸如pub的内部发布平台，部分服务还存在手工部署的方式，当时的现状和过程处理可见下方表格3。目前前端平台架构团队正在推进pub发布统一化的建设，加强和他们的合作以推进实现和后端服务那样统一的部署流程，是我们现在进行的事情。

2.5 环境监控与恢复机制

从sit环境支持全链路业务贯通开始，各种各样的环境问题伴随而来，尤其是刚刚开始的时候。我们建立了对应的问题反馈群和Confluence协作文档，跟进问题解决并记录在文档中，形成了故障知识库，为后续小组成员客服轮值、问题解决、环境精细化监控提供了原始数据。下面是记录的sit环境问题部分摘录（表格3）：

从环境整体宏观角度来看，前期（2019Q4，有效记录问题数38个）出现的TOP3问题是：服务没有存活、中间件不稳定、API 500，后期（2020Q1，有效记录问题数15个）则主要是服务没有存活、API 500、服务停服部署；全部的问题归类对比参考如下（图5）：

其中，前期相对后期的问题数量比较多，符合环境建设过程的客观规律；

服务没有存活，包括2种原因：对应应用没有在sit环境上部署、已部署的应用因为某种原因被killed，前期主要是前者原因，后期则是后者原因；

中间件不稳定，包括了：数据库连接问题、缓存问题、es等组件问题；

API 500：业务应用接口返回了500错误码，服务没有存活也是导致这个问题的原因之一，两者经常结合起来一起分析。

上面的问题记录和归类分析，对我们每个阶段着重处理问题的方向有着指导作用。不过对于sit环境中的问题，早期的反馈链路是这样的：某开发或者测试同学发现了问题，在问题反馈群中暴露问题，小组成员轮值客服协助定位问题并找到对应问题解决方，问题解决方解决问题，环境恢复正常。在这个过程中，问题主要靠人工在使用环境过程中发现，问题属于被动发现；而且也依赖轮值客服或问题反馈方对问题的理解程度，接着还要根据责任人文档找到问题解决方，整个过程效率也较低下。结合实践当中的经验，我们现在推出了新的处理流程（图6，加入了精细化监控的内容，旨在先于用户发现问题并提高找责任人的过程效率，而且利用大盘数据指导监控警报处理和后续环境质量运营）：

新处理流程中的精细化监控，是基于第一版的普适性监控做出的改良。精细化监控的基本操作思想是：利用公司监控系统的能力，对sit环境上部署的应用提供系统指标和应用指标的定制化监控，并及时将监控警报推送给应用（包括中间件组件）责任人。这里，应用责任人的维护也从之前的Confluence文档维护切换到从cmdb系统获取，保证了和其他系统测试owner信息的一致性。具体的监控指标此处不展开描述，当前除了系统运维指标，服务API非200的问题也可以监控到，当然各自服务对这些指标可以定制各自的敏感度，总体上解决了问题发现不及时、找人解决效率低的问题。

下面是监控指标的部分展示（图7），和对应推送到用户企业微信里面的监控详情（图8）：

2.6 环境使用手册

sit环境的推动和后期维护，是一个偏流程约束和意识培养的过程。团队内部不断会有新人加入、转岗流动的情况出现，因此我们不仅注重解决环境推动过程中出现的问题，也关注测试团队整体解决问题能力的培养，正所谓授人以鱼不如授人以渔，于是有了《sit环境使用手册》。

《sit环境使用手册》主要分为：环境介绍、环境配置、故障知识库、应用owner信息维护等模块：

（1）环境介绍：从基本概念说起，讲述了环境Stage、Version以及JAVA_OPTS的基本术语，以及feature、sit、perf、prod_test、prod、stable等环境在基础参数配置方面的区别；另外也从宏观层面描述了线下环境建设的预期，以及当前线下环境所具备的能力；再者，也从职能规范的角度单独描述了sit环境的基本职能：集成测试，其他与此不相干的操作，如性能压测、研发联调，是不允许在sit环境上操作的；

（2）环境配置：这一模块讲解了新增服务从0到1部署到sit环境上的创建过程，以及对应服务环境变量的日常维护操作。由于跟具体的应用发布管理平台等内部系统联系密切，不具有普适性，就不详细描述了；

（3）故障知识库：按照平时问题的处理过程，一般都是群里反馈、讨论和直接处理。随着时间的推移，这些信息就会淹没在消息流中。将曾经出现过的问题记录下来并分类归档形成知识库，有助于沉淀曾经的处理经验，也能形成问题处理方式的快速索引从而提高问题解决效率，这就是我们创建和维护故障知识库的初衷。目前小组内部记录了自sit环境正常启用以来的环境故障，故障基本信息包括：问题描述、原因、故障等级、解决结果、反馈人、处理人、故障持续时间区间等；后面可以考虑以更友好的方式来记录和呈现。

（4）应用owner信息维护：维护对应应用的owner信息，主要是为了能够在sit环境出现业务问题的时候，能够根据这份信息快速找到问题解决人。目前我们采用协作文档记录和cmdb系统更新的方式，来进行信息互补。不过当前的线下线上相结合的形式会维持一段时间，最终的预期是在线平台化统一管理。

这几个行动下来，sit环境承载集成测试职能的愿景已达成。当前环境使用手册的入口，在我们小组维护的问题处理企信群中、iTest内部测试管理门户等都有透出，方便日常查阅。当然，保障sit环境稳定高可用，是一项需要长期推进和优化的任务。

三、线下环境标准化

上面第二部分，基本上都是讲述sit环境推动到落地实践的内容，这和我们小组一开始的切入点和任务优先级有关。当这一任务完成之后，我们小组的使命变成了促进线下环境标准化落地、达成线下环境各链路协同从而助力产研效率的提升。不过补充说明下，此处线下环境标准化更多指的是使用层面（软能力建设）的标准化，建设层面（硬件建设）的标准化已在开篇处提到：和devops、中间件团队共建的大框架已经完成，这里不展开描述这方面的内容了。

3.1 线下各环境分治

在这一新的任务阶段中，我们对sit环境的稳定性提出了更高的要求，引入了SLA指标来推动环境运营。当然，线下环境不仅仅包括sit环境，feature、perf和stable环境也是任务升级后重点关注的对象。

（1）feature环境的定位是：研发联调和新功能测试的环境。其中，研发联调环境支持按需申请和动态释放，保证了有环境可用和环境资源利用率最大化；新功能测试环境则是使用频率较高的类“dev”（这里只是指代名称）环境，本质上也是可以按需申请和动态释放的，只是被经常使用而固化了下来。目前应用发布管理系统在此环境上支持功能测试和项目（跨服务）测试，基于此我们编写了feature环境的实践操作指南（包括功能测试环境创建和使用、项目测试环境实践）。

（2）sit环境，上面已经提到，定位是集成测试环境。对于这个环境，当前我们提出了SLA>99%的稳定性目标。除了加强测试团队owner意识之外，我们在此基础上保持对故障知识库、环境使用手册保持持续更新，并进一步优化精细化监控策略。此外，推动部署非核心后端服务、前端部署规范化、前端功能测试指南制定，是我们目前正在进行中的项目。

（3）perf环境，是一个专门进行性能测试相关的环境，包括性能基线任务执行、性能测试初步验证等。和sit环境一样，perf环境对稳定性要求也比较高，所以我们借鉴之前推动sit环境积累的经验，也对perf环境做了处理。当然，由于环境职能定位不一样，perf的预期是保持核心服务稳定可用、服务依赖配置正确即可。目前该环境已投入日常使用，剩下的工作就是推出规范和引导合理使用。

（4）stable环境，前面提到这是整个线下环境体系中的基础环境，所以我们在应用发布管理系统使用流程中用强限制的手段保证了该环境的部署分支和部署时机的统一，研发调试和QA测试过程无须特别关注，从而无缝衔接了线上环境生产上线和线下环境最新代码更新，也从环境流转上完成了产研过程的闭环。

至此，目前我们参与建设和维护的各个环境的情况汇总如下：

3.2 线下环境标准化

上面一节已经对线下环境的组成子环境进行了分治，当然除了维护各子环境的正常运作之外，思考和推动环境间的协同落地，是我们努力优化的方向。从环境级别来看，线下各子环境的环境级别都是dev。各子环境虽定位不同，但是有些共性的内容却可以统一化管理。比如，sit和perf环境部署的应用分支都应该是master分支；sit、perf、stable环境都可以设置同一套精细化监控模板；各子环境的服务环境变量，都应该按照约定规则配置soa version等参数以保证同一环境内调用链路不“越境”访问。当前，我们认为环境建设可标准化的内容，汇总如下（持续更新中）：

回顾这大半年来的建设之路，上面刚提到的子环境分治，目前已基本完成；统一化相关的内容，我们还在路上。理想的目标是线下各环境规范化使用，配合必要的数据统计、工具或平台支持，实现小组无人值守的环境自我恢复。共勉。