出現線上問題的時候，緊張在所難免，有一篇文章講解新手與老手處理線上問題的差別：新手遇到問題後，都是忙於排查問題，「這個是怎麼回事」，「怎麼突然宕機了」，老手會首先想「是否有服務降級策略」，「怎麼快速恢復服務」，「重啟吧，90%的問題能夠靠重啟解決」，「是不是上游或者下游有異常」。
在分布式系統橫行的今天，大部分故障可分為一下幾類：
系統資源不夠用（單機記憶體/cpu/網路流量等等）
上游流量**，超過下游承受的最大能力
下游故障，導致依賴的介面的時長或者服務掛掉
**bug，執行緒池或者物件池使用不當、記憶體洩漏、死迴圈等等
硬體問題
第三方服務影響：多個服務共享某些資源（redis例項、mysql例項部署在同一臺實體機，多個服務共同部署在一台實體機），當其中乙個服務發生異常的時候，會影響到別的服務。比如線上經常看到的有redis的記憶體被某個服務耗盡了，別的服務快取的資料就被lru策略驅逐；mysql出現慢查詢或者突然的大批量的insert等擦操作；多個服務在同乙個實體機，如果其中乙個服務的流量突然暴漲，就會導致別的服務的網絡卡流量降低。
在上面的各個型別中，主要講解如何排查**bug造成的問題，這一類的問題有幾個共性：
通常表現為系統執行一段時間後突然宕機或者服務響應突然變得奇慢無比
通用的解決方案是，將集群重啟，但是留下一台或者幾台機器做分析（視情況而定，很多時候使用jmap很容易導致服務掛掉，從而丟失現場）
通常情況下，bug的表現也可以做分類：
cpu和load飆高
cpu低但是load高
記憶體耗盡
執行緒池耗盡
tcp指標飆高
針對不同情況，可以使用不同方案。
但是但是，首先
對比問題出現前和出現後的**差異，通常能夠解決90%的問題。
很多時候bug都是一些低端問題，可能就是昨天晚上熬夜想著小姐姐時候寫出的愛心bug。
服務宕機問題排查記錄
用jediscluster進行管道操作psetstr ps ef grep 查詢程序號，jstat gcutil 程序id 2000，top檢視當前記憶體占用 c檢視執行指令碼 free m 檢視機器可用記憶體，幾個命令，分析出當前機器空閒記憶體不足 修改 調整程式啟動的最大堆記憶體引數 修改程式，...
線上PHP問題排查思路與實踐
前言常見問題 不同使用者看到的錯誤可能不一樣。一般使用者看到的錯誤都是表層的現象。如，裸奔的錯誤頁面 這種裸奔的錯誤頁面，經常被使用者成為亂碼，太醜太暴漏。甚至把一些不應該暴漏的敏感資訊都暴漏了。如，nginx版本號，檔案路徑等。為了解決這些問題，設計師們又做了有情調的錯誤頁。但是，錯誤五花八門，並...
線上問題排查
問題排查方 長期改進建議 由於業務應用 bug 本身或引入第三方庫 環境原因 硬體問題等原因，線上服務出現故障 問題幾乎不可避免。例如，常見的現象包括請求超時 使用者明顯感受到系統發生卡頓等等。作為乙個合格的研發人員 技術人員 不僅要能寫得一手好 掌握如何排查問題技巧也是研發人高階必須掌握的實戰技能...