测试环境建设之路--part 1(集成测试环境)

Posted 2021-05-01 酷家乐技术质量

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

一、写在前面的话

和大多数引入devops的公司一样，我司的测试环境治理和devops实践相辅相成。一般来说测试环境治理先于devops实践，但却是devops实践加速了测试环境治理。从治理过程来看，会交叉经历“硬件能力”和“软件能力”建设的阶段。

具体建设内容可参考图1：

我司的测试环境建设，其实开始已久，并伴随日常的业务研发一起成长着。只不过，多个环境虽已存在，但是该有的环境能力没有被充分建设和使用。就拿集成测试环境（下称sit环境）来说，没有发挥作用，从而导致：

（1）某些业务的上下游测试链路不通、某些场景没法验证，从而漏测、引入线上故障；

（2）测试环境不稳定，容易出现测试五分钟、排查两小时的情况，影响产研效率。

基于这个背景，测试团队在去年下半年组建了6个人的线下环境可用性小组（当时叫sit环境可用性小组），目标是实现集成测试环境稳定可用。在小组成立之初，测试环境治理的“硬件能力”建设基本完成，那么对应的“软件能力”建设将是小组的工作重点，当然“硬件能力”方面也会有对应的迭代更新。

二、集成测试环境建设推动

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

2.1 环境组件统一化与适配

从线下走访相关同事和查阅之前的技术文档得知，当时测试环境治理的大部分硬件建设工作已接近尾声，不还有一些历史问题和非主干流程待完善。

其中比较明显的问题就是：线下的几个环境，中间件组件各自隔离，配置和维护管理成本比较大；另一个就是，前端工程和对应版本的后端服务之间的调用链路需打通。

针对这两个问题，我们主要做了两件事情：

（1）底层基础组件重新整理配置，线下环境只保留和维护一套公用的中间件和存储组件，包括：缓存（ redis，memcached）、数据持久（mysql，mongo等）、消息队列（kafka、*mq）等，最终内网环境和基础设施层的关系见下面简单示意图2：

说明：

• 环境这一栏代表日常业务发布发布上线的流程，其中perf环境非必选，prod发布后目前会自动部署stable环境；

• stable环境在上图没有画出来，不过和feature、sit和perf等线下环境一样，共用一套中间件和存储组件；

• 线下环境之间，中间件组件逻辑隔离，数据存储共享；线上环境之间，中间件组件逻辑隔离，数据存储共享；线上线下环境之间，中间件组件和数据存储都物理隔离；

• 业务层简单示意，表示所有的业务后端服务部署和彼此间的调用；

• 技术支撑层、业务间调用、整体数据流等细节，请忽略

  
  

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

默认情况下，jenkins、moon和pub等内部前端发布系统发布代码后，各个环境之间的前端、后端代码，只要部署在对应的环境，不用特意配置，使用独立的域名就能让前端请求落在对应的后端服务上。

当然，也保留了用户手动选择后端服务版本的权利（如果需要特定访问路径验证某些问题的话），这个操作可以在内部提供的前端工程版本选择功能页（图3）进行：

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

2.2 推动业务试点

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

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

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

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

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

摸清问题之后，本着尽可能少打扰正常业务测试进度的原则，我们选取部分业务组进行sit环境试点。被选中的业务组，会被要求梳理组内的待部署应用（即主要的业务应用，包含“核心”应用和部分“非核心”应用）。

如下面的线下环境统一化服务对接文档中的部分表格（表格1）所示，并按照规定部署对应的master分支。

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

至此，公司全部业务组的核心后端服务，都已部署到sit环境并完成了全链路的调试验收。整体的推进流程可参见图4：

2.3 应用部署流程环境卡点

在进行sit环境业务试点的过程中，我们意识到：如果单纯依靠人肉检查或者流程主观约束，那么sit环境上服务的部署最终会重新走向无序状态。

因此和devops团队商议后，决定对我们的后端应用发布管理系统进行改造：将sit环境部署纳入发布管理的首要环节，使得集成测试成为发布上线的第一步；同时将stable基础环境代码更新设置成发布上线的最后一步，且只能由prod生产环境部署成功后自动流转。

这就从系统上约束了stable环境只能部署master分支代码且不能随意发布，从而保证了基础环境的稳定性。至此，新的应用发布上线整体流程参考图5，具体的应用发布管理上的实现见图6：

另外，将sit环境设置成发布上线第一步的同时，我们要求各业务线研发测试同学尽可能保证sit环境上部署分支的稳定性。之所以没有在应用发布管理系统上限定发布分支，是因为实际测试过程中存在偶尔部署临时分支验证的可能性。

于是乎，sit环境维稳相关的第一份“君子协议”由此诞生：我不限定你在sit环境部署分支的自由，但是你应该保证服务稳定性。

不过我们依然会通过统计sit环境上各服务部署分支的数据，如表格2所示，来追踪对应的情况并及时对异常情况进行修正和对当事人“批评教育”。当然，至于后续要不要将此也像部署流程一样在平台上固化，需观察一段时间收集民意再定。

2.4 前端代码部署规范

上面3个行动，主要作用对象都是后端服务。前端服务的部署流程，跟后端服务的类似，所以前端服务的环境实践方式基本直接复制后端服务的做法了。

只是由于历史原因，前端服务目前的部署方式比较多，当时的现状和过程处理可见下方表格3。目前前端平台架构团队正在推进pub发布统一化的建设，加强和他们的合作，是我们现在进行中的事情。

2.5 环境监控与恢复机制

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

下面是记录的sit环境问题部分摘录（表格4）：

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

其中：

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

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

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

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

上面的问题记录和归类分析，对我们每个阶段着重处理问题的方向有着指导作用。不过对于sit环境中的问题，早期的反馈链路是这样的：某开发或者测试同学发现了问题，在问题反馈群中暴露问题，小组成员轮值客服协助定位问题并找到对应问题解决方，问题解决方解决问题，环境恢复正常。

在这个过程中，问题主要靠人工在使用环境过程中发现，问题属于被动发现；而且也依赖轮值客服或问题反馈方对问题的理解程度，接着还要根据责任人文档找到问题解决方，整个过程效率也较低下。

结合实践当中的经验，我们现在推出了新的处理流程（图8），加入了精细化监控的内容，旨在先于用户发现问题并提高找责任人的过程效率，而且利用监控数据指导监控警报处理和后续环境质量运营。

新处理流程中的精细化监控，是基于第一版的普适性监控做出的改良。精细化监控的基本操作思想是：利用公司监控系统的能力，对sit环境上部署的应用提供系统指标和应用指标的定制化监控，并及时将监控警报推送给应用（包括中间件组件）责任人。

这里，应用责任人的维护也从之前的Confluence文档维护切换到从cmdb系统获取，保证了和其他系统测试owner信息的一致性。

具体的监控指标此处不展开描述，当前除了系统运维指标，服务API非200的问题也可以监控到，当然各自服务对这些指标可以定制各自的敏感度，总体上解决了问题发现不及时、找人解决效率低的问题。

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

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环境只是线下测试环境的一部分。从sit环境的建设过程中提取经验，进而推广到整个线下环境的建设，是水到渠成的延申。此处限于篇幅就不展开了，下文敬请期待。