一、尽可能清楚问题的前因后果

不要直接跳到服务╳器前面，你需要弄清楚对服务器的了解程度以及故障的具体情况。否则，你▲很可能会漫无目的。

必须澄清的∩问题有：

·失败的表现是什么？没有反应？错误？

·故障是什么时候♂发现的？

·故障可重现吗？

·有没有规律性（比如一小时一次↓）

·整个平台（代码、服务器等）的最后一★次更新是什么？

·受故障影响的具体用户群有哪些（登录、注销、在某个区域……）？

·能否找到基础设施（物理的、逻辑的）文档？

·有监控平台吗▽？ （例如服务々器运维技术，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/硬件/网络或系统配置（有问题的代码、系统内核♂调整……）有关。

·这个故障是否有一些你熟悉的特征？例如，数据库索引使用不当，或后台进程过多ㄨ。

您甚至可以找到失败的真正根源。就算你还没有找到，在你弄清楚上面的ぷ情况之后，你现在已经具备了深入挖掘的条件了。继续努力！