前言

这篇文章我不会去讲一些看起来很厉害的技术，而是和大家聊聊，我之前负责测试环境稳定性治理时候，面临的种种问题和痛点。

我是如何梳理和分析，并尝试去解决这些问题的过程。

项目背景和痛点

先交代下背景吧，这样能更好的理解做测试环境稳定性治理的出发点和治理方案为什么要如此设计。

我会从业务需求和技术现状两个方面来说明当时技术团队面临的痛点。

业务需求

当时公司业务处在高速发展期，除了日常的版本迭代之外，同时可能还并行着好几个独立项目（其实就是需求排不进版本迭代，需求评审时候被PK掉了，又搞了一个独立项目的名义进行需求交付）。

由于线上发布和灰度的时间节点各不相同，且每个独立项目和日常版本迭代涉及到的业务域以及背后的应用各不相同，有重叠又有新建的服务，因此每个项目都需要不同的测试环境来保证需求交付不受影响。

技术现状

聊完了业务需求背景，再来看看整个技术团队和体系当时面临的问题：

1-整体的需求研发测试交付体系是从Dev-Test-Pre-Pro四个阶段；

Dev：即开发环境，一般由开发自己负责日常维护；

Test：测试环境，也是本文的重点讨论对象，一般由测试维护；

Pre：即预发环境或灰度环境，是线上正式发布的最后一个验证环节；

Pro：我们所理解的生产环境&线上环境，所有外部的用户都可以访问；

2-测试环境有十几套，每套环境几乎都有独立的数据源，且表结构和数据各不相同；

3-所有应用都部署在阿里云上面，交易业务应用是ECS的虚拟机，社区业务应用是基于Isito的容器化；

4-有跨境和国际交易业务，是单独一个BU，但业务逻辑和应用调用关系上又强依赖国内的部分交易业务和应用；

5-微服务架构下各服务之间依赖关系复杂，但服务发布都是不同的测试负责，经常出现A测试同学测试过程中报错，结果是B同学在做服务发布。

或测试过程发现异常，排查很久发现原因是做了DDL变更或者测试数据被使用了导致的各种问题；

6-需求越来越多，需要的测试环境越来越多，但搭建一套环境的成本太高，运维不愿意联调，测试不愿意验证，都想要现成可用的东西来完成各自的工单和任务；

面临的痛点

出于上面的业务需求和技术现状，对技术团队来说，最大的痛点有下面几点：

1-环境太多，云资源成本和日常维护成本太高；

2-发布流程太过随意，消息不及时同步导致出现各种异常；

3-需求太多导致大部分时间耗费在环境维护和异常问题排查方面；

4-需求多任务紧要求更多的测试验证和维护环境占用了大量人力和时间资源的矛盾；

5-多套数据源导致最终线上发布时DDL变更频繁，出现缺少字段或字段格式不正确等情况；

6-为了保证各自项目的交付，各个项目的Owner甚至开始出现“先上车后补票”抢占环境的操作；

7-研发和测试都有测试环境的变更权限，服务的发布和数据库的变更不受控制，“走心发布”随意而为；

上述描述的现状和痛点，当时导致了不少的线上故障，最终避无可避的，环境稳定性治理落到了测试的头上（这里不讨论应该运维负责环境稳定还是谁使用谁负责的话题）。

分析过程及治理规划

针对上述的种种问题和痛点，我用了一周的时间做调研分析和评估，最终落地了环境稳定性治理规划和方案。下面是我的分析评估和治理规划，仅供参考。

调研分析过程

通过调研和访谈以及我自己工作过程中发现的种种问题，我抽象总结出了几个共同点：

1-环境多成本高维护成本大；

2-造轮子和重复建设现象严重；

3-流程不规范且无人遵守默认的原则；

4-环境资源竞争日趋激烈，没有较好的协调机制；

5-沟通成本大，信息同步延时高甚至丢包现象严重；

6-环境问题发现定位排查手段原始，部分同学缺乏相关技能；

稳定性治理规划

调研分析出上述几点共性问题后，我输出了如下的稳定性治理规划：

落地过程的一些典型案例

测试环境稳定性治理在落地的过程中，做了很多的技术优化以及跨团队的协调沟通，每个阶段都会遇到很多挑战和问题。

当然，解决问题的过程中，个人也学到了很多新的技能，和不同的角色沟通协调过程中也学会了从不同的维度和角色的角度上去思考解决问题。

下面是六个不同阶段中，典型的治理案例和我个人的思考收获。

1-规范变更流程

这里的变更除了服务发布、参数配置的变更之外，还有测试环境的DDL变更。典型的案例有：

服务发布没有限制：通过发布平台设置服务发布时间窗口，和各研发及测试团队协商沟通确认（降低任意发布带来的服务不可用）；

任何人任何时间都可以发布：每个应用或业务域应用合集指定服务owner，服务发布需要在发布平台经过owner二次确认才可以执行发布流程；

信息不同步&沟通成本高：建立专项的服务发布信息同步群，某应用需要发布，自动艾特对应的owner进行通知确认（可设置免打扰，但带来的影响需要owner自己负责）；

收获：很多时候，运维和DBA也是希望能规范发布和变更流程的（这样他们的工单和任务量会减少，能提效）。

但如果业务方不配合，就很难推进。如果涉及到类似的事情，可以找运维和DBA负责人一起协调推动，团结相关的利益团体，反而能提高整体的进度和效果；

2-降低维护成本

环境多维护成本高：收敛环境的数量，将重复造轮子的部分抽象成公用的部分，我当时采用的方案是搭建stable环境，抽取公用的服务和基础设施，

版本迭代和独立项目，只需要部署各自涉及的应用（这样也能避免不同项目遇到公共应用时，便于部署不同分支的代码）；

环境资源竞争激烈：版本迭代固定占用某个环境，独立项目根据提测时间和上线发布时间做资源协调。

如果有同一天发布上线的，根据提测时间，各自拉取对应分支到同一个环境，后续的项目代码分支合并到最早提测的分支上进行测试（一方面降低了环境竞争的问题，另一方面测试资源和环境维护范围更集中）；

Stable环境规划图（仅做示意，已脱敏）

3-打通底层数据

前面提到了多套测试环境多套数据源，这样会导致下面几点有趣的现象：

1-多个测试环境的表结构变更，需要提多次DDL工单，DBA同学任务量大；

2-假设测试过程中测试环境切换，变更就要重新进行，很容易遗漏或者变更有误；

3-即使有专门的测试数据预埋工具，但多环境多数据源会导致数据准备更耗时，加大复杂度；

4-不同环境不同数据源，进行自动化回归的时候，测试case和数据可能要进行修改适配，耗时费力；

5-即使多个项目同时进行，但最终发布线上仅是一套环境和数据源，这样会导致频繁变更带来的线上风险概率；

针对这些现象，我是怎么做的呢？

首先，选择一个环境作为基准环境，所有的DDL变更都先变更到基准环境，然后自动变更到其他环境的数据源上；

其次，stable环境落地，环境发散现象会逐渐收敛，搭建维护变更成本降低后，反而有时间资源做专门的优化工作；

然后，变更权限和入口收敛，通过统一的工单系统进行，降低整体的变更混乱现象，所有变更有迹可循有记录可查；

4-变更权限收口

上面第三部分“打通底层数据”实际上已经介绍过变更权限收口了，这里我想分享的是之前做环境治理时候，和DBA负责人的一次聊天过程：

我：XX大佬，我要搞测试环境稳定性治理，希望减少随意的表结构变更和让底层数据保持一致，需要你的帮助；

DBA负责人：那可真是太好了，我一直想干这个事情，但我去推业务那边一直不搭理我，阻力很大。。。

我：那你看我们合作怎么样，我去和业务研发以及测试协调这个事情，你把底层的技术规范搞定？

DBA负责人：没问题，权限收口，表结构变更统一走工单，降低变更频次，规范数据库和SQL规范，我来搞定；

我：那行，你先准备相关的技术方案和规范，我们先挑一个环境试点，业务方我去沟通，好了我们就开始搞；

DBA负责人：可以，有啥需要我帮忙的尽管说，做这个事情对我们DBA也是个好事情。。。

分享上面这个对话过程，实际上要表达的是：很多时候我们工作中面临的痛点，也是其他人想解决的问题，寻求利益共同体，协作达成一件事，比孤军奋战更轻松，达成的效果也会更好。

5-测试环境容器化

谈到测试环境容器化，又是另一个故事了。

当时基础架构一直想推业务线接入容器，但一直很难推下去，理由也很正当：“业务迭代需求太多，没时间没资源接，而且稳定性也是要考虑的”。

正好我在牵头做测试环境治理，希望能快速拉起环境和服务（ECS虚拟机部署服务太麻烦了，速度还慢），结果聊着聊着，一拍即合。我负责和业务方沟通，基础架构提供技术解决方案。

这里要补充说明下，不是我有多高的职位和权利，才能去和业务方沟通。而是测试环境的痛点已经影响到整个技术团队的需求迭代研发交付了，大家即使不太乐意，但这个问题不解决大家都很痛。

6-环境资源下线回收

按照整体的治理规划，完成上述步骤后，就可以开始做环境割接，即：

搭建好stable环境，测试环境以容器化搭建，给业务方交付一套可用的测试环境，就下线回收一套ECS的虚拟机环境。

同时相关的权限收口以及变更管理规范，沟通协调机制在不断的落地和推进过程中，也能不断解决环境使用过程中的种种痛点。

当然，环境割接过程中，有几个点需要注意：

割接的时间节点需要和运维DBA以及业务方明确，不可随意下线；

环境割接不可一刀切，建议先关机，观察一周后再下线，避免遗漏的业务方有依赖而导致其他问题；

环境治理和技术改造方案，在开始前一定要做好调研，坚持推进，否则很容易被遇到的困难和组织架构变更导致项目流产；

写在最后

这些方法都需要我们亲身去实践才会有深刻的感受和理解，但最根本的方法就是保持我们对这个行业的热情和对最佳实践的追求，这才是我们能不断突破自我、勇攀高峰的不竭动力源泉！

这篇贴子到这里就结束了，最后，希望看这篇帖子的朋友能够有所收获。

都到这了记得三连支持一下吧。