墨菲定律：如果有可能出错的事情，那么它就一定会出错。
中国还有句俗语，叫“怕啥来啥”。
故事涉及RPC网关，这是一个中间件服务。
这是一个非常大改动的迭代，而RPC网关承接了业务非常大的跨业务rpc调用流量，并且网关还是多租户的。（我们不讨论业务架构层面是否合理）
这意味着，不像我们部署某个业务服务，出问题可能只影响那一小块业务，而是会影响所有的业务。
年前迭代就已经开发，测试验收通过，在预发环境也运行了一个多月。就是等年后再上线。年前还写了发布计划、发布清单。
发布清单，记录着先发哪个服务，要改什么配置，找运维沟通什么，再发什么服务。
发布计划，先灰度亚太区域一个节点，再灰度中国，再全量亚太，再全量中国，再灰度美国，再……
时间过得太久了，对发布的整个过程记不清，发布前看了发布清单，但是没看完。所以，因为这一点粗心，漏了一个配置，结果服务没启起来。
好在进程没启起来，所以没流量进来，就没有什么事情。但是我被吓得更胆小了，配置重新再一个一个过一遍，甚至标点符号都检查有没有少一个逗号。
令我害怕的根本原因有以下几点。
第一，我们的灰度粒度太粗了。
我们没有控制到百分比流量的粒度，而是节点粒度，如果节点只有两个，那就是百分之五十的粒度，这跟全量没区别，相当于直接上线了。
另外，Apollo灰度的功能也成为了摆设。Apollo的恢复策略需要指定IP，如果是容器化部署的服务，容器重启IP就不同，而技术栈的原因，启动的时候拿不到正确的配置容器就启动不起来，所以配置方面也缺失灰度能力。
可以说整条链路现状是缺少细粒度的灰度发布能力的。
第二，这个网关服务有个历史的致命缺陷。
这个致命缺陷就是服务启动初始化至少要十几分钟，这也是此次迭代重构的原因。这个缺陷的存在意味着，出问题回滚也要等待十几分钟才生效，这十几分钟问题就大了。
第三，初始化数据问题。
重构前，跨业务调用rpc网关支持业务的全量接口。而重构后，rpc网关只支持通过规则配置的接口。
所以上线我们需要基于历史最近一个月的rpc调用，通过监控系统去抓取接口。但这个难保没有漏的。比如存在那些一个多月才有一次调用的。
不过这点，出问题的影响可能还好。漏掉的可能就是那些非关键业务接口。
人的粗心再所难免，如果这个项目不是只有一个人在做，如果有一个人陪着一起发布，一个负责配置一个负责检查，那么因为粗心犯错的概率也能降低很多。
而针对这种大迭代的发版，根本原因还是要解决灰度粒度问题。机器都有宕机的时候。
这次升级，给我的感觉就像电影里面的情节，在电影中经常出现的拆炸弹情节：一个人被迫面对拆除一枚定时炸弹的任务，他必须仔细选择正确的线剪断，以防止炸弹爆炸。
说不定今天你阅读到这篇文章，明天作者就领大礼包走人了。
本文经「原本」原创认证，作者吴就业，访问yuanben.io查询【2BAOIW9A】获取授权信息。