如何在不影响到用户的情况下去测试生产环境下的新功能？

Question

有的时候我们访问一个网站的时候，可能会显示“服务器暂时不能访问”，请问这个时候是不是开发人员在测试生产环境，所以暂时停止了用户的访问？

比如我现在发了一个生产端的最新版本，我需要一个小时的时间去到线上进行测试，那么这种情况下的最佳实践是什么呢？如何避免影响到用户的使用呢？

我的生产环境经验有点少，请大佬看到这个题目尽可能的发散性的回答，就是说你想到的问题和答案都能写在评论中，让我能多学习学习，这种情况可能遇到什么问题，一般都怎么解决。

非常感谢～

Answer 1

正规一点的网站，都会有多个环境，比如生产环境（正式环境），staging，dev，不同分支等等。

服务器暂时不能访问就是服务挂了，是事故。

不同公司有不同的发布流程，不过一般来说，一个功能或者 bug 修复从启动到上线要经历很长时间，历经不同环境。比如：

1. 开发完成，本地环境自测。
2. 提交 PR/MR，线上自动生成测试环境，邀请测试人员参与。
3. 一个开发周期完成，全部功能上线测试环境，跑自动化测试、冒烟测试等。
4. 上线正式环境前，先上 staging 给大家预览
5. 最后部署到生产环境，交给全部用户

最后一步，有时候也会用灰度发布。因为产品太庞大，很难每次都跑全量回归，就会先推给一部分用户，看他们的数据表现基本正常，再推给全部用户。

有时候，预览环境或者某个大版本的测试环境也会长期向内部人员，或者某些特定普通用户开放，主要是为了收集反馈信息。类似游戏里的各种体验服、测试服。

所以大部分情况下，普通用户不会被发布过程影响到。

目前很多云平台，比如 Vercel、CF 都实现了这些功能，每个分支都有独立的测试环境，用起来很方便。自家的基建，使用一个构建工具配合 K8S 也可以搞，方案很成熟。

Answer 2

用灰度发布，简单点的做法就是再单独搭建一套跟生产环境平行的灰度环境，然后在网关层面根据HTTP请求的来源地址IP或是HTTP请求头是否有带上某个特殊字段来判断流量是否要走灰度环境。火狐浏览器可以用ModHeader这个插件给请求都加上一个自定义的请求头，测试人员可以加上特定请求头来在灰度环境测试。

复杂一点的微服务环境可能还要针对每个服务实现灰度策略，微服务调用时也要考虑灰度标识的透传，使得调用链保持在灰度容器上，这种比较推荐直接上Istio。

Answer 3

先说一点，任何具有破坏性的测试都不应该出现在线上，即使是在可控范围内，也应当谨慎，避免造成难以挽回的损失。

对于大多数时候的测试，你应该要在除本地环境以外环境进行测试，如：测试环境、预发布等，经测试无误后，再发布到线上。

新功能验证，你可以提供“隐藏”的入口来进入，比如 由后台控制、或者像 Android 彩蛋那样，连续点击某个元素 N 次后才显示。

有的时候我们访问一个网站的时候，可能会显示“服务器暂时不能访问”，请问这个时候是不是开发人员在测试生产环境，所以暂时停止了用户的访问？

大多数情况下，部分系统为了避免在更新期间，用户操作导致新旧版本之间数据出错等原因，会先择停机发布，待发布后的会有“验收”环节，来确保系统的正确性。

当然，出现这个错误，也可能是系统的某一部分挂掉了，导致不能正常提供服务。

比如我现在发了一个生产端的最新版本，我需要一个小时的时间去到线上进行测试，那么这种情况下的最佳实践是什么呢？如何避免影响到用户的使用呢？

应该先在其他环境测试 OK 后才能更新线上，将可能的影响降低，比如在贴近生产的 预发布环境测试好，大部分应用经过这个阶段验证后就直接发布了。

一些大型系统，会提供 AB 发布（灰度发布），即让一部分用户先用上新版本，确认没问题后，再逐步覆盖全部用户，在一些大型系统比较常见。

对于一些影响范围较广的功能，为了避免新的功能导致系统崩掉，还要制定好回滚计划和相关预案。