記一個bug的排查過程---復盤
公眾號做了新需求：菜單的click事件，支持多條客服消息。
上線後，只有一個功能不好使，是點擊菜單，預期發一條文本類型的客服消息。
實際操作時，點這個菜單項後，什麽也沒有發生。
elk上看日誌，也沒有什麽報錯。也不應該有報錯，如果後端服務異常，公眾號上會提示，“服務不可用”
如果在後臺打開 菜單管理 頁面，什麽也不做，再點個 保存 ，菜單 的功能就恢復正常了。
====================================================================
當時把註意力鎖定在這個更新操作上了【原因是測試人員一直在講點下更新就好了，根據事後的分析，肯定也執行了“同步到微信”的操作】，
但點擊菜單後， 期望的純文本客服消息，就是沒有出來。
一下子僵住了。
==========================相持階段==========================
緩存的原因----排除掉。因為表小，沒有使用緩存
因為是線上，後端服務也沒有打印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的排查過程---復盤