我所理解的测试环境管理

包括以下几个方面：

1. 测试基础环境，相当于测试环境的运维：
   a. 测试硬件资源的申请，变更，释放等流程及具体工作的受理和实施。
   b. 基础应用的部署和维护，如应用服务器、数据库等，及相关的问题处理、备份恢复等，可参考运维的问题处理流程。
   c. 可覆盖当前所有类型的测试环境。（包括sit，uat，性能，投产验证等）
2. 测试环境之上的，发布管理，需理清和开发版控系统的接口，投产的接口，可实现的自动化的自动化掉。
   a. 覆盖纳入管控的sit测试环境，uat测试环境等，（理清准入条件，符合要求的再纳入）
   b. 实现效果，版本清晰，变更清晰，状态可视化。
   c. 包括：批量，数据等。
3. 关于纳入管控的，全部只有一套环境，明确准入需求，不符合在不纳入管控。
4. 管控的原则，有能力承接，就承接一个。没有能力承接的，由开发自己管理。（需要对应用系统有深入的认识，包括业务和架构，自动化的前期是深入理解流程，手工可以做的基础上用自动化替代，并根据不同系统的情况推进相关的自动化的动作，如测试、部署等，需持续改进。。。）
5. 相关流程和平台：
   a. 测试环境申请，变更，释放流程；
   b. 问题处理流程，类似运维的工单流程；
   c. 相关的测试环境的可视化，包括主机，ip，应用版本，状态，数据等。
6. 人员角色：
   a. 流程中的相关审批类角色；
   b. 具体的环境管理角色，类似运维层面；
   c. 发布管理：需要深入理解应用系统。在项目组外的角色难以做好。
   d. 数据和批量相关：也需要深入理解应用系统。

我个人更加倾向于：
更好的方式是把c、d交给项目组，通过一套体系来评估各个系统的成熟度，鼓励项目组内的持续改进、推动项目组自身的devops。需要把开发和运维都带进来。
金融行业有其特殊性：
1：风险控制、监管层的要求；
2：金融行业大部分系统的耦合性太强。
所以对于devops的推动不宜太激进，不要为了做而做，一切要基于项目组，分项目组而治，鼓励项目组内加强开发、测试、运维的沟通（全部对效率和质量负责），一切以减少线上bug，加速业务需求发布为目的。对于互相响应较大的系统变更，做好协调工作。

对于nb研发管理部：负责相关的基础环境建设，相关的流程建设、及相关的可视化平台的统一建设等。具体的devops，不用出具详细的流程方案，但应该鼓励项目组加强内部沟通，鼓励内部的持续改进。通过一套体系来评估各个系统的成熟度，鼓励项目组内的持续改进、推动项目组自身的devops。