2.1.1　低级错误

在公司的初创期，服务较少、功能相对简单时，运维人员采用上述方式实属正常，但随着微服务的数量不断增加，以及新增了订阅、中间件、定时任务等各种场景，测试环境所产生的问题会逐步影响业务的迭代速度，甚至一些低级问题最终会被直接带入生产环境，进而引发故障。尽管存在着各种风险隐患，但仍然有不少运维团队保持着较为简单的维护模式，把测试环境只当作“测试”而已。

请看看如下几个场景，我们可能会遇到：

（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，但在测试环境下忘记使用此方案，最后又将不良的使用方式发布到线上。

对于大部分的中小型团队，特别容易出现类似问题，但这些问题一定要到产品上线后通过故障暴露出来吗？有没有可能在测试环境下通过一些标准化的基建来减少这些问题的发生呢？

细品一下，我们可以在测试环境下通过设计一些监控手段来提前发现这些低级问题，这样可以在上线前解决掉它们。请牢记一句话，稳定性建设并不是将重点放在应急上，而是应该基于对技术风险的认知，提前通过技术手段规避绝大部分问题。

关于如何利用监控手段捕获这些不良操作并形成优化节奏，我们会在后续的章节中进行讲解。