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

Posted 沧海一滴

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一个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、如果对微信公众号的业务比较熟悉,肯定就能预知这种情况。提交沟通好,或者直接写个接口,批量同步下就好了

 

以上是关于记一个bug的排查过程---复盘的主要内容,如果未能解决你的问题,请参考以下文章

记一个程序oom的排查过程

Bug解决过程复盘

记一次因@Async引发的程序bug

this.$router.push页面不跳转 -- 记一个糊涂的 Bug,排查了好久

DDD落地实践复盘 - 记理论培训&事件风暴

记crond导致备份失败的排查过程