Qunar 机票测试环境管理方案

背景

项目过程中，测试环境的问题无疑是最常见的吐槽之一。因为测试环境的问题导致的 delay 频发，因为测试环境的问题导致的漏测和错测也不在少数。持续做到测试环境的可用、好用、标准化，是每一名环境使用者的期望。

容器化框架实现测试环境的快速构建思路，提供了一个方向，但是受限于硬件资源、构建性能、复杂调用和数据量的各种原因，对于超复杂链路的完整交易系统和大量基础数据支撑的环境很难完全做到随用随建、快速构建、用完销毁。

于是，我们除了需要有相对快速的环境构建能力，还很有必要对现有环境的稳定性和可用性上下功夫，使之更上一个台阶。

环境治理思路

可将测试环境治理的内容归为六要素：

• 环境可用度

• 主动修复

• 数据标准化

• 配置标准化

• 测试代码管控

• 合理使用分配

环境可用度

如图所示，环境可用度体现在：交付时可用、基础组件和机器存活、业务链路通畅、使用期间持续可用、有直观的平台和报表反馈环境状态。

环境创建时监控服务器、应用启动的成功和失败，能够反馈上述两点可用度。除此之外的其它关注点，我们需要使用另外的策略主动实现。环境检查的核心服务“照妖镜”就是在这样的背景下诞生的。

照妖镜实现两个基本功能：

• “照射”出环境中的异常和基本情况

• 主动修复

其基本原理是在环境初始化时在每一台服务器上部署一个照妖镜 server，该 server 通过 salt API 进行调度管理，开启 monitor，主动获取环境信息，针对性地收集当前服务器上的应用信息，包括虚机状态、服务存活与否、磁盘、负载、内存、部署信息、版本信息等等，并主动收集至 server 后台持久化存储。对于可自行处理的异常进行自动修复。

例如磁盘空间超过阈值，自动清理 tomcat 历史日志；对于 tomcat 的服务暴露情况进行监测，如失败则做自动重启尝试，如重启依旧失败，则主动告警；对于环境代码信息为非 master 的情况，将使用者及 PMO 和分支信息收集并展示到平台上，供他人查看；通过自主串联业务接口或数据结果，进行业务链路验证，并将验证结果汇总至平台和报表展示。

图示照妖镜实现思路：

照妖镜具体实现：

Server 部署代码示例：

注：http 域名为测试环境信息接口，提供测试环境中服务器+应用的详细信息。

照妖镜实现的基本检查和修复包括：

上述内容可扩展，自由定制所需。Git 定制后只需要执行一个调度接口即可在指定环境全量更新生效。

照妖镜检查结果展示：

业务检查日报小时报：

配置同步策略

随着热配系统越来越多地应用在业务系统中，它承载了越来越多的业务逻辑轻量实现和开关管控的功能。那么，如果一个业务的线上开关和测试环境有差别，势必会导致错测、漏测，或者排查问题的成本增加。

实现热配自动同步线上的基本思路，是利用热配系统的兜底节点。常规的方式，是测试节点下直接创建测试配置文件，或者在测试节点下生成环境维度的子节点，在子节点下创建测试配置文件。这样做法的弊端在于测试节点下的文件长期存在，与线上不同步。

而热配系统往往存在一个兜底节点，作为一个被多数人忽视的节点，长期空白，却正可以实现这个诉求。原理为：

步骤一：剪切线上节点下的全部文件至兜底节点下。（此时线上节点下无文件，热配系统会取默认的兜底节点下的文件，实现对线上配置的无侵扰读取。）

步骤二：删除测试节点下的全部文件。（测试下无文件，则会默认读取兜底节点下的内容。此时自动实现测试和线上都读取兜底配置，即测试配置读取线上配置的诉求）。

步骤三：存在一些线上内容和测试必须不一致的配置内容。不用担心，我们在热配系统中实现了一个二次替换的功能。当存在独立映射替换时，在读取线上配置之后，热配会在 tomcat 启动前自动进行二次替换。此类思路应为通用思路。

热配系统的二次替换实现：

只需利用 salt 脚本进行调度管理，在照妖镜的配置管理菜单中配置替换映射，即可轻松实现自动的二次替换。

步骤四：测试需要修改的配置，使用方式有几种，例如 copy 需要修改的文件至测试节点下，进行修改。由于测试节点优先级高于兜底配置，那么测试节点下的文件修改会直接生效。此种使用方式需要测试文件的存在会覆盖自动同步逻辑，不推荐使用。另外一种方式，是在照妖镜的业务类配置页面进行配置，此配置需要填写项目编号和环境信息，提交后只对单行内容和指定环境生效，并且随项目状态进行自动管理，当项目关闭时，自动触发销毁。

数据同步方案

数据库的同步管理思路是：

• 创建环境时库表结构和数据取自线上；

• 线上有 SQL 变更时，能够主动同步测试环境；

• 测试数据需要覆盖替换的，通过预先设置替换配置，在同步时做数据替换实现；

• 考虑同步数据量的问题。

基于以上思路，那么需要 DBA 协助实现获取线上数据和结构的安全接口，并当库表有变更或提交申请时，发送消息。同步系统接收消息，实现测试数据库的同步变更。当数据量巨大时，可以利用 mysql 的 copy 文件的方式，做异步同步，提升效率，确保测试环境数据库的稳定可靠。

代码和环境分配管理方案

此处不得不先提一个 Qunar 优秀的项目管理平台：奥丁桌面。

其使用入口，在 JIRA 项目测试菜单中的第一项“奥丁桌面”。使用奥丁桌面，可以将项目信息、项目中对应的代码工程、使用者、发布操作进行整合。奥丁桌面又可以整合环境分配入口和照妖镜环境信息结果。使用者在奥丁桌面中，即可查看想要发布的工程，在当前有哪些可用环境列表，同样的工程被哪些人、哪些分支在占用中。

由于集成了 JIRA 状态和分支信息，那么当分支发布线上、JIRA 关闭后，奥丁桌面可以监听 JIRA 关闭的消息，调度照妖镜配置管理和发布接口，对当前测试环境进行 master 代码的主动恢复，部署检查结果正常后，再发起其它测试环境对应工程的 master 代码自动同步（跳过该工程有 JIRA 占用的其它测试环境，避免误冲。）

总结

两个简单数据反馈 Qunar 机票测试环境治理的成果：

1.支撑数十套开发和测试环境，无人值守，实现自动运转，自动修复，自动分配、环境按需隔离、信息集成和主动预警。

2.取自项目管理周报中的统计，因环境问题导致的项目占比，从 2018 年及以前的 15%~20%，降至 2019 年全年 8% 以下。

受限于篇幅，很多方案细节并未详细产出，但测试环境治理的根本思路是：

• 照妖镜一键接入；

• 环境全程无人值守，主动发现，主动修复；

• 有可靠完整的指标反馈环境信息；

• 有强大闭环的策略保证环境真正长期可用且标准；

• 平台化管理项目周期，在其中整合环境分配和恢复策略，使之合理有效。

期待有同样诉求和想法的同事持续交流，共同进步。

头图：Unsplash

作者：王怀坤

原文：https://mp.weixin.qq.com/s/QK49muAhvvM3PX2dz1EKpw

原文：Qunar 机票测试环境管理方案

来源：Qunar 技术沙龙 - 微信公众号 [ID：QunarTL]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。