一、盡可能清楚問題的前因后果

不要直接跳到服務器前面，你需要弄清楚對服務器的了解程度以及故障的具體情況。否則，你很可能會漫無目的。

必須澄清的問題有：

·失敗的表現是什么？沒有反應？錯誤？

·故障是什么時候發現的？

·故障可重現嗎？

·有沒有規律性（比如一小時一次）

·整個平臺（代碼、服務器等）的最后一次更新是什么？

·受故障影響的具體用戶群有哪些（登錄、注銷、在某個區域……）？

·能否找到基礎設施（物理的、邏輯的）文檔？

·有監控平臺嗎？ （例如服務器運維技術，Munin、、、、New Relic……任何東西）

·有日志可以查看嗎？ （例如，...）

最后兩個是最方便的信息來源，但不要抱太大希望，基本上沒有。只能繼續探索。

二、誰在那兒？

$ w

$ last

使用這兩個命令可以查看誰在線以及訪問了哪些用戶。這不是關鍵步驟，但最好不要在其他用戶工作時調試系統。俗話說，一山不能容二虎。 （沒有廚師。）

三、之前發生了什么？

$ history

查看以前在服務器上執行的命令。看看總是對的服務器運維技術，加上之前誰登錄過的信息，應該很有用。此外，作為管理員，請注意不要利用自己的權限侵犯他人的隱私。

在此提醒一下，稍后您可能需要更新環境變量以顯示這些命令的執行時間。是的，否則，看到一堆不知道何時執行的命令也會讓人抓狂。

四、現在正在運行什么進程？

$ pstree -a

$ ps aux

這都是關于查看現有流程的。 ps aux的結果比較亂，-a的結果比較簡單明了，可以看到運行的進程和相關的用戶。

五、監控網絡服務

$ netstat -ntlp

$ netstat -nulp

$ netstat -nxlp

我通常分別運行這三個命令，并且不希望一次看到一大堆所有服務都列出來。 -nalp 也很好。但我永遠不會使用選項（我的拙見：IP 地址似乎更方便）。

查找所有正在運行的服務并檢查它們是否應該運行。查看每個監聽端口。顯示的服務列表中的PID與ps aux進程列表中的PID相同。

如果服務器上同時運行多個 Java 或其他進程，那么能夠通過 PID 單獨找到每個進程非常重要。

一般來說，我們建議每臺服務器運行較少的服務，必要時添加更多服務器。如果您看到服務器上打開了 30 或 40 個偵聽端口，請做一個記錄，有空時清理它，然后重新組織服務器。

六、CPU 和內存

$ 自由 -m

$

$頂

$htop

注意以下幾點：

·有空閑內存嗎？服務器在內存和硬盤之間交換嗎？

·還有CPU嗎？服務器有多少個核心？某些 CPU 內核是否過載？

·最大的服務器負載來自哪里？平均負載是多少？

七、硬件

$ lspci

$

$

還有很多服務器還是裸機的，大家可以看看：

·找到RAID卡（帶BBU備用電池？）、CPU、空閑內存插槽。根據這些情況，您可以大致了解硬件問題的根源以及提高性能的方法。

·網卡設置好了嗎？它是否以半雙工運行？速度是多少？是否有任何 TX/RX 錯誤？

八、IO 性能

$ -kx 2

$2 10

$2 10

$ dstat --top-io --top-bio

這些命令對于調試后端性能很有用。

·檢查磁盤使用情況：服務器硬盤是否已滿？

·交換模式是否啟用（si/so）？

·誰占用CPU：系統進程？用戶進程？虛擬機？

·dstat 是我的最愛。用它來看看誰在做 IO：MySQL 是不是在吃掉所有的系統資源？還是你的 PHP 進程？

九、掛載點和文件系統

$mount

$ cat /etc/fstab

$vgs

$pvs

$lvs

$ df -h

$ lsof +D / /* 不殺你的盒子*/

·總共掛載了多少個文件系統？

·服務是否有專用的文件系統？ （例如 MySQL？）

·文件系統的掛載選項有哪些： ? 是否有任何文件系統被重新掛載為只讀？

·還有磁盤空間嗎？

·大文件是否被刪除但未清空？

·如果磁盤空間有問題，你還有空間擴展分區嗎？

十、內核、中斷和網絡

$ -a | grep ...

$ cat /proc/

$ cat /proc/net/ /* 忙時可能會計時 */

$

$ ss -s

· 你的中斷請求是否平均分配給 CPU 處理，或者是否有 CPU 內核被大量的網絡中斷請求或 RAID 請求超載？

·SWAP兌換有哪些設置？ 60 對工作站來說很好，但對服務器來說很糟糕：你最好永遠不要讓服務器做 SWAP，否則對磁盤的讀寫會鎖定 SWAP 進程。

·它是否足以處理您的服務器的流量？

·不同狀態下的TCP連接時間設置是什么（，...）？

·如果要顯示所有現有的連接，會比較慢。可以先用ss看大局。

您還可以查看 Linux TCP，了解有關網絡性能調整的一些要點。

十個一、系統日志和內核消息

$dmesg

$ 少 /var/log/

$ 少 /var/log/

$ 少 /var/log/auth

·檢查錯誤和警告信息，例如是否存在過多的連接數？

·看看有沒有硬件錯誤或者文件系統錯誤？

·分析這些錯誤事件能否及時與之前發現的可疑點進行比較。

十個二、計劃任務

$ ls /etc/cron* + cat

$ 中的用戶 $(cat /etc/ | cut -f1-d:);做-l -u $用戶；完成

·是否有運行過于頻繁的計劃任務？

·是否有用戶提交了隱藏的定時任務？

·發生故障時，是否有恰好執行的備份任務？

十個三、應用系統日志

這里要分析的東西比較多，但作為運維人，恐怕沒有時間仔細研究。注意明顯的問題，比如在典型的LAMP（Linux++Mysql+Perl）應用環境中：

·&Nginx;查找訪問和錯誤日??志，直接查找5xx錯誤，然后看看有沒有錯誤。

·MySQL;在 mysql.log 中查找錯誤消息，查看是否有任何結構損壞的表，是否正在運行修復過程，是否存在磁盤/索引/查詢問題。

·PHP-FPM；如果設置了 php-slow 日志，則直接查找錯誤消息（php、mysql、...）。如果沒有設置，請快速設置。

·;在 和 中，檢查命中/未命中率。配置中是否缺少任何允許最終用戶直接攻擊您的后端的規則？

·HA-Proxy；后臺狀態如何？健康檢查是否成功？前端或后端隊列大小是否已達到最大值？

結論

這 5 分鐘后，您應該知道以下內容：

·服務器上正在運行什么？

·此故障似乎與 IO/硬件/網絡或系統配置（有問題的代碼、系統內核調整……）有關。

·這個故障是否有一些你熟悉的特征？例如，數據庫索引使用不當，或后臺進程過多。

您甚至可以找到失敗的真正根源。就算你還沒有找到，在你弄清楚上面的情況之后，你現在已經具備了深入挖掘的條件了。繼續努力！