上週是不幸的一週。
週六還在愉快玩耍的時候，突然被@，線上出現嚴重的bug，還是老大大發現的。
原因是因爲數據端開發未通過QA測試，私自改了邏輯，重啓服務，導致線上出現bug，功能能可用，但數據不可用的情況。
問題已經出現了，那就得去快速的去解決
出現這個問題，我們追本溯源的方法是：
1. 搞清楚上線這個事情的來龍去脈，爲啥上線？
2.要解決什麼問題，修改的代碼邏輯？
3.出了什麼問題？
4.出問題後解決方案是什麼？
如何讓止損
5.待開發定位完成問題，及時的去做代碼邏輯的確認
6.快速的線上驗證
7.線上加入監控
Bug review模板
【問題描述】
- 線上XXXX到的部分商品出現XXXX失效。
【問題經過】
- 5.18，11:39左右，小王重建索引，重啓兩臺服務，未經過QA驗證，直接上線；
- 5.18，11:51左右，老李發現問題：XXXXX失效；
- 5.18，11:51左右，小王收到反饋的問題，開始排查；
- 5.18，12:00左右，小王定位到問題，開始解決；
- 5.18，12:15左右，修復完成，開始自測；
- 5.18，12:27左右，自測通過，打包上線；
- 5.18，13:50左右，QA同步到該問題的消息；
- 5.18，16:00左右，QA與開發完成邏輯確認開始驗證；
- 5.18，17:10左右，線上驗證完成，未發現異常情況。
【影響範圍】
- 影響時長：48分鐘；
- 期間請求次數245次，每次請求會出現10條數據，理論錯誤概率爲1條，在不點擊進入商品詳情頁的情況下，用戶無感知；
- 具體影響用戶數暫無法統計。
【問題原因】
- 流程方面：
- 開發未遵守測試上線流程
- 技術方面：
- XXXX上mysql庫出現大量無效數據與搜索不同（已與小馬溝通，他來修改）；
- 爲解決數據不同步問題，重建索引，並重啓服務，其中調整了過濾邏輯，出現了bug，導致對過期XXXX過濾無效。
【修改方案】
重新修改過濾邏輯，如下圖
【改進措施】
- 開發需要嚴格遵守開發流程；
- 增加對XXXXX業務部門進行發佈權限控制；
- 開發上線前需做code review。