记一个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、如果对微信公众号的业务比较熟悉,肯定就能预知这种情况。提交沟通好,或者直接写个接口,批量同步下就好了
- [知其然不知其所以然-2]设备D3hot状态切换到D0状态的一个bug排查过程
- 很好的一个分析bug的文章,供以后疑难bug参考,转一下:一次segfault错误的排查过程
- 解决工作中遇到的一个"打开,保存"文件框的bug的过程
- 一个杀不死的小强,kill进程无效的原因 记录故障排查过程中kill进程无效的分析过程
- 一个长时间parse的bug解决过程
- 一个panic bug的分析过程(一)
- 一个BUG的发现过程
- 一个job运行问题的排查过程
- 项目中一个Bug的解决过程
- 记一个bug定位与修复过程
- 一个罕见的MySQL redo死锁问题排查及解决过程(pt-pmp)
- 调试一个socket通信bug的心理过程和反思
- 【bug for plug in】往一个应用程序当中plug in menu的过程----第一节
- erlang关闭一个socket进入死循环的bug修复过程
- 一个panic bug的分析过程1
- 开发过程碰到的一个bug
- IE下ul li 互相嵌套时候的bug,排查,解决过程及心得
- Android一个权限相关的bug修复过程
- linux内核bug问题排查过程详细报告
- 记录一个使用HttpClient过程中的一个bug