解Bug之路-記一次存儲故障的排查過程 高可用真是一絲細節都不得馬虎。平時跑的好好的系統，在相應硬件出現故障時就會引發出潛在的Bug。偏偏這些故障在應用層的表現稀奇古怪，很難讓人聯想到是硬件出了問題，特別是偶發性出現的問題更難排查。今天，筆者就給大家帶來一個存儲偶發性故障的排查過程。 Bug ...

背景說明 　 組織架構被拆分為多個微服務 需求： 一個輸入框 查詢 前后模糊查詢 人員信息（工號、姓名），前后模糊查詢 單位名稱。 跨庫平級查詢！！ 慢sql ： slow sql 2969 millis. SELECT count ...

前言 我們的分庫分表中間件在線上運行了兩年多，到目前為止還算穩定。在筆者將精力放在處理各種災難性事件(例如中間件物理機宕機/數據庫宕機/網絡隔離等突發事件)時。竟然發現還有一些奇怪的corner case。現在就將排查思路寫成文章分享出來。 Bug現場 應用拓撲 應用通過中間件連后端多個 ...

公司對底層基礎庫進行了重構，線上穩定跑了幾天，在查看訂單系統的log時，有幾條error信息非常的奇怪， 訂單有狀態機進行維護 已經被撤消的訂單不能再進行有其他操作，和狀態更改。 已 ...

山竹來臨，窩在家里整理個人文檔。 本篇文章主要講解排查問題的思路，涉及linux 刪除文件的原理、實例誤刪數據恢復、MySQL實例初始化參數優先級別等，雖然涉及知識點比較淺，但是個人覺得挺有 ...

解Bug之路-記一次線上請求偶爾變慢的排查 前言 最近解決了個比較棘手的問題，由於排查過程挺有意思，於是就以此為素材寫出了本篇文章。 Bug現場 這是一個偶發的性能問題。在每天幾百萬比交易請求中，平均耗時大約為300ms，但總有那么100多筆會超過1s，讓我們業務耗時監控的99.99線變得 ...

解Bug之路-記一次調用外網服務概率性失敗問題的排查 前言 和外部聯調一直是令人困擾的問題，尤其是一些基礎環境配置導致的問題。筆者在一次偶然情況下解決了一個調用外網服務概率性失敗的問題。在此將排查過程發出來，希望讀者遇到此問題的時候，能夠知道如何入手。 起因 筆者的新系統上線，需要PE執行 ...

今天測試團隊反饋說，服務A的響應很慢，我在想，測試環境也會慢？於是我自己用postman請求了一下接口，真的很慢，竟然要2s左右，正常就50ms左右的。 於是去測試服務器看了一下，發現服務器負載很高，並且該服務A占了很高的cpu。先用top命令，看了load average，發現 ...