下载掌阅APP，畅读海量书库
立即打开
正常的发布迭代都会经历如图2-1所示的几个环境，在每个环境中需要处理的事情均有所不同，其目的是让产品可以顺利上线并提供预期服务。
图2-1 迭代发布的各类环境
运维人员会针对每个不同的环境投入不同的精力进行维护。应该如何投入，每家公司都会有不同的经验和时间规划，本章我们会对测试环境和预发布环境的维护方式进行说明，让大家从SRE的视角对这两套环境重新认识，建立一种与以往维护模式不同的机制。
注意： 本章中出现的很多问题均来自真实场景，特别是对于业务迭代快、基建平台还未建设完善的团队来说，更容易遇到类似的问题。
笔者接触过不少运维团队，他们在测试环境下的日常工作主要如下。
（1）资源保障，避免因资源不足导致的各种问题，比如对磁盘空间的清理，对CPU内存资源的保障，如果这类问题较少发生，在测试环境投入的精力会非常少。
（2）持续集成的稳定性保障，在CI/CD的生命周期内出现了一些不稳定性现象或服务宕掉等情况。
（3）运维初始化配置的一些服务，如Nginx、DNS等。
总之，测试环境的维护核心是保证可用性，并将测试环境交付给测试人员和开发人员。
在公司的初创期，服务较少、功能相对简单时，运维人员采用上述方式实属正常，但随着微服务的数量不断增加，以及新增了订阅、中间件、定时任务等各种场景，测试环境所产生的问题会逐步影响业务的迭代速度，甚至一些低级问题最终会被直接带入生产环境，进而引发故障。尽管存在着各种风险隐患，但仍然有不少运维团队保持着较为简单的维护模式，把测试环境只当作“测试”而已。
请看看如下几个场景，我们可能会遇到：
（1）某小伙伴写了一条查询SQL语句，未做合理索引，也未做SQL分析优化，测试环境数据量少，“跑”代码的时候也没有出现任何缓慢的现象，于是匆匆忙忙上线了产品。
（2）某小伙伴写了一个接口，从Elasticsearch获取数据，将一条一条数据循环取出，然后放入Redis，结果从Elasticsearch一次性读出了几万条数据，测试环境下请求量小，感知不明显，但生产环境下这个接口的QPS会非常高。
（3）某小伙伴让运维人员做测试环境的Nginx变更操作，结果在产品发布上线时，运维人员忘记了将配置同步到生产环境。
（4）某小伙伴经常在Redis中存放数据，但忘记在方法中加入TTL缓存时间的限制，导致Redis中存在很多永久保存的数据（一般不建议在Redis中存放永久Key）。
（5）最近测试环境的日志量比以往大了很多，这是由测试环境下有人写了很多info信息导致的，上线时这个info日志中的代码也跟随上线了。
（6）在I/O频繁的服务中，我们常会利用Pipeline来提升性能，如HTTP Pipeline，但在测试环境下忘记使用此方案，最后又将不良的使用方式发布到线上。
对于大部分的中小型团队，特别容易出现类似问题，但这些问题一定要到产品上线后通过故障暴露出来吗？有没有可能在测试环境下通过一些标准化的基建来减少这些问题的发生呢？
细品一下，我们可以在测试环境下通过设计一些监控手段来提前发现这些低级问题，这样可以在上线前解决掉它们。请牢记一句话，稳定性建设并不是将重点放在应急上，而是应该基于对技术风险的认知，提前通过技术手段规避绝大部分问题。
关于如何利用监控手段捕获这些不良操作并形成优化节奏，我们会在后续的章节中进行讲解。
测试环境对迭代速度的影响有多大？大家会定时统计每天有多少问题阻塞测试进度吗？如果有还没做过这类统计的小伙伴，请先和测试团队共同分析下现状。
如果你们的测试团队在测试环境下内耗较低，那么恭喜！你们团队的持续集成已经做得非常好了，反之，请开一个测试环境“吐槽”会，看看到底问题有哪些。
如果你已经听到过不少人反馈测试环境下的各种阻塞问题，那么可以试试如表2-1所示的计划。
表2-1 测试环境治理启动计划
续表
SRE职责包括提效职责，而优化测试环境架构本身就是一件非常有实践价值的事情，既可以提效，降低内耗，又可以发现不规范的开发方式，排除隐患。
预发布就好比足球场上的守门员，它是技术风险最后一道把关门神，很多时候也成了产品发布前的救命稻草。
但是，若一个项目频繁地预发布，则间接表明这个项目在测试阶段缺乏充分的验证，所以预发布应该有一定的次数限制和问责机制，大家应该对预发布产生敬畏之心。
请看看如下几个场景，你可能有过类似的经历。
（1）项目的交付期限马上就要到了，为了产品及时上线，于是绕过测试环境，直接进行预发布验证，避开了测试环境的各种监管（如果有监管的话）。
（2）预发布时需要修改系统时间才能验证某个服务，但时间的修改却关联着多个预发布服务，人工切换烦琐，内耗严重。
（3）针对某个功能，需要修改Redis/Etcd的数据来保证预发布的接口按照新的业务逻辑使用，但这些数据也被生产环境所依赖，修改后，会导致线上服务逻辑出现异常。
（4）预发布启动了一个脚本任务来变更数据，如发布前的初始化动作，但执行时间超出预期，并且对生产数据库造成了较大压力。
细品一下，什么样的流程和功能可以减少相关问题的出现，预发布本来是一道强有力的防线，最终却成为导火索。
预发布环境下经常存在各种零散的任务需要执行，如初始化数据、修改时间等。这些操作在某些场景下会对线上服务产生影响，所以在操作时需要有确认流程，避免影响当前的正常访问，但如果每个操作都需要进行确认，执行效率又会下降。如果让运维人员来执行这些操作，耗时耗力，但如果开放机器权限让理解操作顺序的开发人员来操作，又存在一定的安全隐患。
SRE如何从稳定性和效率出发做到双赢，这本身也是一道难题。
所以，预发布并非只是简单地与线上环境保持一致，让开发人员和测试人员方便使用，还要能及时发现一些技术风险隐患。
首先，前述问题并非只是技术实现上的难题，更多地来自价值观和工作视角的不一致，请看看大家对测试环境的想法，这些想法存在于很多团队内部。
（1）开发人员的角度：我的核心任务是在交付期限内完成任务，只要我将代码按时交付到测试环境，剩下的问题就留给测试人员了，他们会主动找人解决的。
（2）运维人员的角度：我的任务是保证测试环境的稳定性，基础设施不“挂”，业务流转问题和我没有直接关系，我主要关注生产环境。
（3）测试人员的角度：测试环境下的各种问题都是开发人员和运维人员带来的，我们作为使用方，没有义务解决测试环境下的问题，我们主要确保测试通过和降低Bug发生率，环境问题不应该由我们来负责。
（4）项目经理的角度：交付期限到了却交付不了产品，总要有人“背锅”。
说到底，产生以上想法是因为测试环境下没有明确的用户，用户体验无从谈起。SRE的金字塔顶层是用户体验，那么使用内部环境的人算不算SRE的用户呢？
这个问题是否应该由SRE解决，不同的公司理解不一样，但SRE理应将稳定性和效率作为自身的职责，将这些能力赋予测试环境和预发布环境，并间接地降低生产环境的技术风险。
环境问题的根源在于，大家并没有对内部治理达成共识，没有一个团队愿意出来负责。在这种情况下，我们需要从上至下对现状进行理解和复盘，找到项目治理的负责人，明确治理目标。如果你的团队遇到了上面的问题，请将问题的严重性暴露给更高层的领导者，从上至下进行共建。
微拍堂作为文玩电商垂直领域的佼佼者，近几年发展迅猛，高频的项目迭代给公司的测试环境带来了极大的挑战（笔者在之前工作的公司也经历过类似的情况）。
在这样的背景下，微拍堂从上至下明确了测试环境治理的目标，运维团队承接了这项任务，要将测试环境的问题减少80%，并且为了确保测试环境的维护和治理省心省力，需要实现1小时内拉起一套可供使用的测试环境的技术方案。回到之前的内容，从上至下地推进，这已经成功了一半。
运维团队承接测试环境治理任务后，大致的工作流程如下。
（1）获得当前测试环境的各种问题。
（2）开会倾听大家对测试环境的使用感受，希望解决什么问题，是否有超预期的治理目标（有些团队的测试环境问题太多，导致测试人员不敢奢望提出更符合自身需求的要求，我们要深挖出更多的需求）。
（3）日常运维工作任务梳理，评估出运维人员大概有多少时间可以花在测试环境的任务上。
（4）日常配合解决测试环境问题的人，解决问题的方式，是根治还是临时治理，临时治理的问题是否有根治的可能性，实现根治的代价如何。
（5）汇总所有的信息，拉上几个共建任务的部门，分析根本原因，制订计划。
图2-2是对测试环境治理目标的说明。
图2-2 测试环境治理目标
根据目标，确认阻碍测试环境治理的各项因素，拆分任务，如图2-3所示。
图2-3 确认阻碍测试环境治理的各项因素
确认三大因素后，我们继续细化可以落地的任务，如图2-4、图2-5和图2-6所示。
图2-4 环境不稳定
图2-5 规范和标准未实施
图2-6 故障定位难
治理测试环境的具体实现方式不再说明，主要讲解了问题拆分的过程和推进思路，然后有节奏地将其完成。
本次治理的结果符合预期，并再次体现了良好的监控和流程设计对服务治理的重要性。感谢本次共建的小伙伴（特别是陆游、李启龙、张博），一起完成了测试环境的稳定性建设。
在本章中，我们对测试环境和预发布环境的重要性从稳定性和效率上进行了介绍，其中包含了一个很重要的认知——“测试和预发布不仅是为了功能测试的正确性，也是为了及时发现大部分不规范或者性能异常的变更”。如何发挥两个环境的作用，我们会在后续的章节中进行详细介绍。