乙個客戶那兒：
1接收報文->2系統轉碼->3傳送給處理程式->4處理程式呼叫資料庫儲存過程
現在系統資料庫庫內記錄出現問題了：某個關鍵字段的值擴大了10倍；自某個時間4-19日開始發現該問題；上游廠商確定沒有變動過介面。
經過：根據分析和經驗，認定問題出現在2上，初步推斷是上游介面發生變化而未告知（上游有前科）。重新依據生產環境部署程式。重新測試。問題仍在。期間發現過和匯率可能有關係。當時沒有程式源**。
接下來..... 找上游爭吵 .....
最後：冷靜下來，向公司原來負責該客戶的同事諮詢求助，在同事的指點下，發現uat的資料庫庫配置不對，依據生產的資料庫配置修改。ok！
反思：1）墨守成規的經驗害死人！
2）2中的配置檔案，有資料庫的連線配置，竟然熟視無睹，沒有追問下去「程式看起來似乎和資料庫沒關係啊，為什麼要連線資料庫？？？？」
3）離開客戶現場的期間沒有看源**
4）為何不早些時候向同事求助！！！！！！！
記錄第一次排查ANR經歷
第一步 找到logcat中的報錯記錄 第二步 拿到 檢視traces檔案 data anr traces.txt 1 人家說在這個目錄下，但是我不知道怎麼找，搜到取這個檔案的文章 adb pull data anr traces.txt users atom downloads 2 adb指令不會用...
記一次線上問題排查
這次線上問題來的比較突然，影響也大，用部落格記錄下整個過程，也當作是對這次事故的一次總結歸納。day1 2018年06月21號上午10點，收到運營同事通知，http com api 訪問量劇增，日誌量達到80g 天，而且有上公升趨勢。運營同事讓我們排查，這種訪問是否正常。運營統計訪問量 收到通知後立...
一次快取效能問題排查
以下分享的都跳過了很多坑，包括redis tomcat環境配置 機器硬體配置等等問題 與線上保持一致，或者硬體效能減配係數，例如線上 8c16g，壓測 4c8g，係數簡單相差2倍 直接把挖掘瓶頸的主要思路搬出檯面。全域性圖預覽 通過對某直播 頁面進行高併發壓測，在apm pinpoint 監控中發現...