昨天晚上测试交流群一位同学问了一个问题，问题大概这样：
公司的各种配置混乱，上线总是出错，比如API的key，生产环境用了测试环境的配置这种。作为QA，除了上线前把这些相关的检查一遍，大家用过什么好的工具管理起来这些吗？
这个问题中暴露出了很多她所在团队目前存在的一些不良现象以及导致的一些问题，比如：
- 线上问题频发；
- 配置管理不规范；
- 生产和测试环境未做隔离；
当然，上述问题只是表象，背后隐藏的问题和折射出来的不良因素更多，比如：
- 线上交付质量不高；
- 流程规范不完善，执行落地效果不足；
- QA缺乏好的工具和手段开展质量保障；
关于质量保障这个话题，要谈的内容太多。这篇文章，我想聊聊基于上述问题，如何通过管理测试环境来解决影响线上交付质量的一些思考和方法。
测试环境有多重要
聊测试环境配置管理之前，先看看正常的软件研发交付流程，都要经过哪些环境：
本地环境（host）：开发在自己电脑或本地服务器进行需求开发的环境，只要自己负责的部分能实现既定功能即可；
开发环境（dev）：开发同学将自己本地实现的代码统一发布进行功能联调的环境，一般单元测试也在这个环境进行；
测试环境（sit）：绝大多数测试活动开展的环境，在这个环境开展接口/功能/性能/自动化等一系列测试活动，对代码功能实现/异常处理/构建成功率/是否存在性能瓶颈进行测试验证；
验收环境（uat）：将通过测试的代码发布，让产品介入进行验收，确认是否满足其预期的环境；
预发环境（ppe/ade）：也有称之为灰度环境的，简单来说就是将测试验收通过的代码发布到该环境，运行一段时间并做持续的跟进观察，是否存在其他问题或者遗漏项（也有通过技术手段让小部分用户的请求路由到该环境，进行验证）；
生产环境（prd/prod）：所谓的线上环境，即用户使用的环境；
注意，上述的所有环境，基本都要遵循如下几点规范！
- 网络隔离：即请求不能跨环境访问，特别是非生产和生产环境；
- 数据隔离：即不同环境都要有自己独立的数据源，原则上不能共享同一份数据源；
- 流转卡点：代码发布到下一个环境节点，原则上都要满足流转的状态或者标准，不能随意发布；
- 其他事项：如果某个环境有多套，建议共享数据源，这样维护和变更成本低；
说完上面对环境的释义，相信有同学发现了测试环境的重要性。
大多数测试活动在测试环境（包含sit/aut/perf）开展，如果测试环境不稳定，那测试结果无法保障水平之上的质量。
如何管理测试环境
上面聊了一个稳定的测试环境对交付质量的影响和重要性，这部分来聊聊常见的一些测试环境管理方法。
变更管理
如何理解变更呢？变更并不是简单的代码发布，还包含配置变更/服务器变更/DDL变更甚至业务活动的开关等变更，理论上所有的变更都会对代码运行结果造成影响。据统计，线上大部分问题或者说线上故障，都是由于变更导致的，因此变更管理是很重要。
对于变更，常用的手段有变更review/变更check/变更审批。一方面通过不同的角色参与，从不同的角度进行review，查漏补缺；另一方面通过check和审批的方式落实责任，这样才能提高团队所有成员对于变更风险的认识和质量保障意识。
在变更review和double check时候，需要变更申请人说明变更内容/影响范围/异常情况的解决方案等，这样即使变更出问题，也可以及时修复，将风险控制在合理范围内。
当然，变更的review和审批流程，需要视环境不同而有不同程度的执行力度。
下面是一段我之前工作中和DBA负责人的对话：
我：XX大佬，我要搞测试环境治理，希望减少随意的表结构变更，让底层数据保持一致，需要你的帮助；
DBA负责人：那可真是太好了，我一直想干这个事情，但我去推业务那边一直不搭理我，阻力很大。。。
我：那你看我们合作怎么样，我去和业务研发以及测试协调这个事情，你把底层的技术规范搞定？
DBA负责人：没问题，权限收口，表结构变更统一走工单，降低变更频次，规范数据库和SQL规范，我来搞定；
我：那行，你先准备相关的技术方案和规范，我们先挑一个环境试点，业务方我去沟通，好了我们就开始搞；
DBA负责人：可以，有啥需要我帮忙的尽管说，做这个事情对我们DBA也是个好事情。。。
分享上面这个对话过程，实际上要表达的是：很多时候我们工作中面临的痛点，也是其他人想解决的问题，寻求利益共同体，协作达成一件事，比孤军奋战更轻松，达成的效果也会更好。
权限管理
前几天爆料的某国企机构数据泄露，据说原因是某研发将accesskey上传到了csdn导致。
这里不对这个事件进行评价，而是希望借助这个事件说明权限管理的重要性。
从我个人的工作经验来说，测试环境的权限最好是让测试同学自己维护和管理，特别是发布权限。原则上，从测试环境开始，后续每个流转环境的发布权限，最好都由测试同学来负责，这样一方便可以避免未经许可的发布，另一方面测试同学对于发布和变更及时了解评估，也有助于控制风险和出现问题及时周知和补救。下面是几个案例：
- 服务发布没有限制：通过发布平台设置服务发布时间窗口，和各研发及测试团队协商沟通确认（降低任意发布带来的服务不可用）；
- 任何人任何时间都发布：每个应用或业务域应用合集指定服务owner，服务发布需要在发布平台经过owner二次确认才可以执行发布流程；
- 信息不同步&沟通成本高：建立专项的服务发布信息同步群，某应用需要发布，自动艾特对应的owner进行通知确认（可设置免打扰，但带来的影响需要owner自己负责）；
数据管理
测试数据的重要性不言而喻，每次测试活动开展都需要数据的支撑，这也是我上面提到的数据源隔离和同类型环境共享数据源的原因，看似很矛盾，实际上都是踩了很多坑之后的经验总结。有类似经历的同学相信都有过下面的工作体验：
- 多个测试环境的表结构变更，需要提多次DDL工单，DBA同学任务量大；
- 假设测试过程中测试环境切换，变更就要重新进行，很容易遗漏或者变更有误；
- 即使有专门的测试数据预埋工具，但多环境多数据源会导致数据准备更耗时，加大复杂度；
- 不同环境不同数据源，进行自动化回归的时候，测试case和数据可能要进行修改适配，耗时费力；
- 即使多个项目同时进行，但最终发布线上仅是一套环境和数据源，这样会导致频繁变更带来的线上风险概率；
针对这些现象，我是怎么做的呢？
首先，选择一个环境作为基准环境，所有的DDL变更都先变更到基准环境，然后自动变更到其他环境的数据源上；
其次，stable环境落地，环境发散现象会逐渐收敛，搭建维护变更成本降低后，反而有时间资源做专门的优化工作；
然后，变更权限和入口收敛，通过统一的工单系统进行，降低整体的变更混乱现象，所有变更有迹可循有记录可查；
工具手段
上面聊了测试环境重要性和常见的环境管理方法，总结一下，核心思路有下面几点：
- 所有变更都需要check，重大变更需要审批；
- 借助工具和平台，将变更权限收口，用统一的流程去规范操作过程；
- 降低变更频次，明确变更流转的准入准出标准，测试同学做好质量卡点；
其他管理方法
除了上述的一些案例和技术方案之外，还有下面的一些手段，比如：
- 代码分支命名规范；
- 服务不可用订阅通知；
- 服务发布通知功能上线；
- 环境不可用问题及解决方案培训；
- 成立虚拟小组，每个域指定负责该域的测试owner；
- 整合不同业务线的自动化框架和方式，提供统一的技术方案；
- 测试环境接入日志监控告警，从服务层-DB层，监控告警做到自动化和透明化；
- 环境和服务不可用时长纳入故障SLA计量维度，定时复盘和分析，并不断落地改进；
