大概在我集中隔离快结束的时候，运营发来一张照片，说我们最近好多解冻怎么都没有生效，一直在审核中。当时我还是比较诧异的，系统已经差不多一个多月没上线，居家办公的这个一个月线上也没什么问题，怎么会这么多解冻没生效呢？

当时第一反应是查下线上日志看看，一般这种情况大多是因为网络问题引起的。我的日志令牌一个放在了上海，一个放在了公司里，好不容易找到同事借了一个日志令牌，正准备查呢，想起来这个问题是不是上周五另外一个哥们上线导致的。虽然他最终没有上线完成，但是相关配置是上线了的。而我们的broker系统是有个已知bug的，消费者中有一个返回失败，那么其他的消费者也是收不到消息的。

赶忙联系了那哥们，确认了下，果然是配置上了，而相关代码没有上线。这就坑了，配置到broker系统的http接口相关代码没有上线，那肯定是404啊。又赶忙找运维确认了下broker系统日志，果然，调用到这个接口的地方都404了，导致后续通知解冻的接口收不到相关信息，从而解冻一直在审核中。

问题确认了，接下来就是修复的事情了。查了下broker系统暴露的接口，有让配置下线的功能，在测试环境验证了下。我擦，又是一个bug，这个只能让数据库这条记录失效，broker系统回调时候还是会调整这个配置上去的http接口。没办法，只能上物理删除，直接干掉这条记录了。

sql写完了走上线流程的时候有点犹豫，公司之前发生了点合规相关的问题，dba之前口头上和另外一个同事沟通过，说之后是不能上线物理删除的脚本的。但这次影响有点大，就想试试，谁知道dba竟然可以审批通过，于是也就没再关注，就让另外一哥们追踪去了。哪知道到了傍晚，同事联系我说，dba不执行这条删除的sql。当然真的是想骂娘，不执行你倒是别审批啊，浪费老子这么长时间。

想投机取巧取巧没成功，想上线的话现在也没这条件，居家办公期间公司一般不让上线。只好又重新研究了下broker的代码，发现调用接口的时候只要接口返回200就可以了。这就好办了，我们的接口都是通过nginx反向代理的，那么只需要将暂未上线的接口在nginx配置个200返回就ok了。这个首先和运维沟通了下，没啥大问题，终于顺利的上线了相关配置。

location /account/bpm/audit_result{
        return 200 "OK";
}

晚上8点的时候找运营验证了下，问题算是修复成功了。

经验与教训

直面问题，正面解决，不要想着投机取巧，幻想用其他非技术手段解决

系统已知bug一定要尽快修复，否则不知道下次什么时候你就踩上了