记一个bug的排查过程---复盘

公众号做了新需求：菜单的click事件，支持多条客服消息。

上线后，只有一个功能不好使，是点击菜单，预期发一条文本类型的客服消息。

实际操作时，点这个菜单项后，什么也没有发生。

elk上看日志，也没有什么报错。也不应该有报错，如果后端服务异常，公众号上会提示，“服务不可用”
如果在后台打开 菜单管理 页面，什么也不做，再点个 保存 ，菜单 的功能就恢复正常了。

====================================================================

当时把注意力锁定在这个更新操作上了【原因是测试人员一直在讲点下更新就好了，根据事后的分析，肯定也执行了“同步到微信”的操作】，
但更新操作就是一个纯粹的db操作，不会有缓存【当时有同事分析是缓存造成的问题】，不过这种 点下“更新”就好了事情，与以前的缓存问题，的确很像。

但点击菜单后， 期望的纯文本客服消息，就是没有出来。

一下子僵住了。

==========================相持阶段==========================

缓存的原因----排除掉。因为表小，没有使用缓存

因为是线上，后端服务也没有打印sql日志，也搞不清楚是不是sql的问题。但根据现象，如果sql有问题，重新 保存 后，肯定也会不正常的。

sql错误-----可以排除掉

时间一秒一秒过去
压抑、压抑的气氛，一直罩在头顶

===============================拐点===============================

突然想到，有个菜单管理中，“同步到微信”接口，有一个变动：同步到微信上的 菜单 key有变化：线上key是客服消息记录的kf_msg_id，因为当时只支持一条客服消息
这次的需求是要支持多条客服消息，因此这个key现在是menu记录的menu_id

key	click等点击类型必须	菜单KEY值，用于消息接口推送，不超过128字节

https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421141013

没有执行“同步到微信”操作之前，没有收到客服消息，并且没有报错的原因是，使用kf_msg_id去查menu表中当menuId使用，肯定查不出结果了。

=============================复盘=============================

复盘：
（1）要多了解业务，把各种变更造成的影响，要能提前预知到
（2）要耐心、详细了解问题出现的现象、浮现或不固定出现的操作流程
（3）要看对日志

1、从问题排查角度看，问题解决时，除了执行“更新”操作，肯定还执行了“同步到微信”的操作。但当时，没有仔细问，就把这个忽略掉了------最有问题的地方，反而被忽略掉了
2、排查时，没有把注意力锁定在查看接口返回值，因为当时线上的数据,点击菜单对应的click事件，只对应一条客服消息。会直接返回，这个时候统一处理wx回调的服务，肯定有日志【当时看错了服务了---这个地方要深刻检讨，这个错真是太低级了-----难道是对自己的代码质量太自信，认为没有必要看日志？？】
如果看到返回值为空，则离找到问题根源，只有一步之遥了
3、如果对微信公众号的业务比较熟悉，肯定就能预知这种情况。提交沟通好，或者直接写个接口，批量同步下就好了