关于预发布环境的思考

前几天跟朋友讨论到这个话题。
他们公司目前还没有预发布环境，于是询问我们是如何做的。

我们公司的发布流程大致是 dev -> test -> pre -> prod。
一直也没去思考过为何要有预发布环境，预发布的意义到底是什么。
就觉得是上线生产前的一个发布流程而已，感觉跟测试环境也没啥特别的。
最多就机器配置比较好，可以用来做压测。

然后就被朋友狠批了一顿，说这样的预发布有什么用。
后面仔细想了想，其实还是很有意义的：
预发布作为上生产前的最后一次测试和演练，能减少上线生产的风险。

因为我们是B端业务，一般上线会有比较多的配置项和脚本，一般测试环境的时间跨度相对比较大，很多配置都是陆陆续续的，测试完直接上生产，配置出错的概率比较大。
还有就是在预发布做上线前的验收，这个虽然在测试环境也能做，不过预发布数据相对来说比较干净，稳定性也比较好。

当然他也发表了他的看法：保证敏捷交付的稳定性。
他的方案是：
通过复制生产部分流量的方式，在预发布环境做请求回放，以此来构建一个模拟生产的长期运行的预发布环境。

然后我和他就这个方案的可行性做了一系列的辩论，双方唇枪舌剑互不相让。

因为我直觉觉得这个方案可行性很低，或者难度非常大。
大体总结如下：

1. 复制部分生产流量，有些接口之间本身就是有依赖关系的，比如登录依赖于注册，怎么保证这些有依赖的接口一定被同时复制？ 如果是多租户系统，倒是可以通过复制部分租户的方式，但是也还有别的一些问题。比如有些请求是跨租户的，就比较难处理。
2. 回放的时候如果某个前置接口失败，那会导致后续依赖的接口都报错。
3. 如果涉及到外部系统的调用，比如给用户发验证码短信，如果只是简单的复制流量，那预发布也会触发短信发送，就直接影响到实际用户了。 (可以通过一些方案来解决，主要是想说长期运行的话，是有这样风险的)
4. 如果发布预发布时更新的代码是兼容性的改动还好，如果是不兼容的接口修改，那直接复制生产流量过来接口可能直接报错。或者新开发的接口，复制的流量根本请求不到，根本起不到验证的目的。

如果说前面几点是方案实施过程中的困难，那最后一点就是这个方案的价值了：
基本只有做兼容性改动的时候，可以拿来做回归验证。对于新增的功能以及非兼容性改动，是起不到验证作用的。

虽然我一直在否定这个方案，但是不得不说，如果能做好，其实是很诱人的：
比如做代码重构，直接拿生产的请求来验证，如果跟生产的表现完全相同，那就可以验证这次重构是成功的。
好像甚至连测试都可以不要了，很完美。

不过这里其实有个风险，如果某个bug只有在很特定情况才出现，可能生产环境也极少出现或暂时还没出现过，那使用复制流量的方式，也没法发现这个bug。
所以还是需要有靠谱的测试人员，进行完善的测试。
如果要追求敏捷和持续交付，那么大量的自动化测试用例，是必不可少的。

那既然有了自动化测试，复制生产流量的做法，还有必要吗？
我个人的看法是：
复制生产流量到预发布用来做压力测试、故障演练、重构或bug修复后的回归测试，都是挺不错的。
不过这种方式本身也是有一定成本和风险的，需要评估好。
合理的运用这种手段作为辅助，应该还是有价值的。
至于长期持续的复制生产流量甚至替代测试人员，目前还是持保留意见。

---

有些公司会预发布和生产环境共用数据库，即预发布环境使用的就是线上的数据，在有些业务场景下也是个不错的思路，不过控制不好可能有一定的风险。