《产品日思录》是我个人公众号上每天更新的系列文章，记录了我在做产品过程中的思考、总结、经验积累，也希望在这里和简书的大家分享~
36氪前一阵进行了一次比较大型的服务端上线，产品技术组对此做了许多准备，从结果来看还是比较成功的，今天的思考就来总结一下这次的上线流程，希望能对有同样经历的读者有所启发。
说是“技术流”，是因为我会主要从后台系统环境出发，描述如何一步步切换环境、测试、再上线的，因此要先对36氪部署结构有个基本了解，如下图所示：
图中黑色连线代表我们平时的测试环境连接示意。
从上到下。第一层，我们会准备3个App，其中2个App为5.9.3线上版本，用于验证服务端上线后是否会被影响，不同在于1个是为测试新代码准备的测试包，会根据上线流程，从测试环境连接到sim环境。第3个为即将发布的6.0版本，用于验证新App读取新接口是否可用。
第二层，我们准备了3套API接口环境，其中的“sim”API接口，是用于正式上线前的“预发布”环境，运行的是修改后的新代码，连接的是线上数据库和测试App，一般是先切换到“sim”环境，利用测试包验证新代码是否可正常运行，再将其发布到线上环境，以防上线后出现问题。
第三层，我们准备了2套数据库，测试库和线上库，最终的sim环境和线上环境都会连接到线上库进行真实情况验证。
第四层，我们准备了3套CMS后台。和第二层一样，sim环境CMS后台，用于验证修改后的代码，是否可以正常操作线上数据库，并通过sim环境API反映在App。确认无误会再发布代码到线上CMS环境。
接下来，在上线当天，第一步，我们会做线上数据库的表结构变更，然后，会将代码部署到sim环境，利用sim环境的cms配置线上数据库数据，同时验证sim环境的cms功能是否OK，此外还会通过5.9.3测试包验证sim API接口的正确性。连接方式如下图①所示：
如果第一步无问题，第二步，我们就会将环境切换到线上。此时要先通知后台操作人员暂停操作，并提前发放好新后台的使用说明书。
切换方式如下图所示：
此时，无论是CMS还是API接口，都会切换到线上环境，切换后的连线如图②所示。做完这步操作后才是最紧张的环节，此时要马上验证线上Appv5.9.3是否会受影响、cms操作是否无误、主流程能否跑通，如果有问题，要立刻回滚到原始版本，以免影响线上用户操作。
当然，我们的这次上线操作并未发生大问题，所以接下来还需再做一步操作——验证新版本Appv6.0是否可行，此时只需将新版安装包连接到线上环境进行测试即可，由开发人员进行Bug修复。如下图③所示：
至此本次上线结束，虽然整体流程跑通了，但也暴露出一个问题，就是开发周期太长，一次性上线内容太多，导致很多细节没考虑清楚需要优化，上线后会出现不少需要调整的地方。之后还是尽量能分批次上线，缓解上线压力。
以上是我们的经验记录，对你有帮助么？期待你的留言~
