服务器运行速度一旦变慢，很多人的第一反应就是打开top，看到哪个进程的资源占用比较高，就直接重启相关服务或者结束进程。以前从事运维工作的时候，我也经常采用这样的处理方式，偶尔确实能够让系统暂时恢复，但是过一段时间之后，相同的问题往往还会再次出现，真正的原因并没有被找到。
后来处理的故障逐渐多了，我才慢慢形成了一套相对固定的排查顺序。首先确认问题发生的时间以及影响范围，然后再查看系统负载。CPU使用率较高时，需要分清是应用程序计算、内核资源消耗，还是系统正在等待I/O；内存比较紧张时，也不能只看free，还需要结合available、Swap以及OOM日志进行判断；磁盘方面除了查看容量，还要检查inode、I/O延迟和D状态进程；网络访问速度变慢，也不一定就是带宽不足，丢包、重传、DNS解析以及应用响应时间，都可能对访问速度造成影响。
性能排查最重要的并不是记住多少条命令，而是要清楚每一个指标具体能够说明什么问题。下面这组图会按照系统负载、CPU、内存、磁盘、网络、进程以及日志的顺序，把整套排查流程串联起来。
从运维方向转到网络安全以后，我发现以前积累下来的Linux故障排查经验并没有浪费。异常进程、账号行为、系统日志、网络连接以及资源占用突然升高，本身就可能是一些安全事件留下来的线索。运维人员更多关注的是“系统为什么变慢”，而安全人员还会继续判断，这种异常到底属于普通故障、错误操作，还是入侵行为。把Linux、网络以及日志相关基础打牢，再继续学习安全基线、入侵排查和应急响应，后续转向安全运维或者网络安全方向，往往会更加顺利。
