应用程序中的服务器错误快速诊断与解决方法
半夜被警報簡訊吵醒，看到儀表板滿江紅的體驗，幹這行的應該都懂。客戶的電商結帳頁面突然噴「503 Service Unavailable」，營運團隊在群組裡瘋狂@人。這種時候與其瞎猜，不如拎著咖啡直奔機房，順手抄起這套實戰磨出來的診斷流程——專治各種應用層抽風。
第一步先看CDN這面照妖鏡。別急著登伺服器，打開Akamai或Cloudflare的儀表板，重點盯住兩個地方：邊緣節點回源狀態碼和請求排隊圖。上個月遇過案例，源站CPU明明很閒，但CDN報502錯誤。翻WAF日誌才發現客戶更新API時手滑，把某個查詢參數規則寫崩，邊緣節點每秒被攔截上萬次惡意請求——其實是正規用戶觸發了誤判。這種時候把WAF切到學習模式暫放行，立刻止血。
源站日誌要像法醫驗屍那樣挖。Nginx的error.log若出現「upstream timed out」配上110秒的離譜響應時間，八成是資料庫查詢卡死。我有回在AWS RDS抓到某條SQL沒吃索引，全表掃描拖垮整個讀庫。更陰險的是記憶體洩漏，表面看CPU正常，但用htop監控發現Java進程吃掉實體記憶體的150%，頻繁觸發OOM Killer殺進程。這時候jmap -heap直接抓heap dump，用MAT工具分析比對快照，往往能揪出某個快取框架沒設TTL的蠢事。
網路層埋的雷最難防。曾有個跨國遊戲服，亞洲玩家狂掉線。traceroute顯示繞道歐洲再回香港，根本違反物理定律。最後發現是BGP劫持：某個上游ISP錯誤通告了IP段。立刻啟動Cloudflare的Anycast流量牽引，手動鎖定POP點路徑才穩住。另一次是防火牆狀態表爆滿，SYN封包被丟棄，表面症狀和DDoS一模一樣。用netstat -s | grep overflow確認後，調大net.ipv4.tcp_max_syn_backlog參數秒解。
重定向死循環這種低級錯誤反而常出現在大廠架構。某金融APP登入後無限刷新，查了半天是Load Balancer把HTTPS卸載後，用HTTP轉發給後端。但Django設定強制跳HTTPS，後端收到HTTP就302重定向…結果LB又轉成HTTP送回去。解決方案要嘛在LB加X-Forwarded-Proto標頭，要嘛後端改認這個標頭。工程師在Staging環境測得歡，忘了正式環境LB多了一層。
真要深挖的話，連作業系統參數都能搞事。某客戶用K8s部署.NET Core服務，壓力測試時隨機出現SocketException。最後發現是Linux預設的net.core.somaxconn值太低，服務還沒來得及處理就連接隊列溢出了。調參數加垂直擴容才壓住。現在我工具箱常備ss -ltn看監聽隊列，dstat -tcmny看即時資源，比等監控告警快十分鐘。
搞運維的都有種病態執念：寧可凌晨三點蹲機房查日誌，也不願明天看客戶投訴信。下次看到5xx錯誤，記得先從CDN邊緣往回打，八成能省下半天腦死會議。畢竟伺服器不會說謊，但絕對會用最嘲諷的方式罷工給你看。
评论: