新手运维看到服务器告警时，第一反应往往是重启，而不是去看日志文件——这个习惯让70%以上的服务器故障被掩盖，而非解决。

别急着重启，先学会阅读系统日志

某次线上故障，新同事发现数据库响应缓慢，立即执行重启命令。结果数据库恢复后不到两小时又崩溃，最终排查发现是磁盘I/O瓶颈导致。如果当时他先查看/var/log/messages或journalctl输出，会发现内核反复报错“I/O error”，重启只是暂时清空内存队列。正确的做法是：先用tail -n 100 /var/log/syslog查看最近100行日志，再根据时间戳定位异常模式。例如，连续出现“connection refused”可能意味着端口被占用或服务PID耗尽，而非单纯的服务死机。

配置备份不是“存一份就行”，要验证恢复流程

一位朋友在迁移服务器时，自信满满地用rsync备份了/etc和/var目录。迁移后恢复配置时才发现，rsync漏掉了软连接指向的外部文件，导致Nginx启动失败。更典型的踩坑是：很多人用crontab每晚打包备份，却从未还原测试过。实际工作中，备份文件可能因磁盘满写入不完整，或权限问题导致恢复时读不出。正确的做法是：备份后立即在另一台测试机上执行tar -xzf backup.tar.gz -C /test_restore，并对比校验和。至少每季度做一次完整恢复演练，确保备份文件确实可执行。

监控系统别只盯着CPU和内存，磁盘I/O和网络延迟才是盲区

新手常犯的错误是：看到CPU使用率80%就紧张，但实际业务卡顿往往来自磁盘等待（iowait）过高。比如某电商网站促销期间，应用服务器CPU空闲70%，但用户反馈页面加载慢。用iostat -x 1查看，发现磁盘平均服务时间（await）超过200毫秒，正常值应低于10毫秒。再配合netstat -s检查重传率，若超过0.5%则说明网络链路有丢包。建议至少配置以下三个监控维度：磁盘读写延迟（%util和await）、TCP重传率、交换分区使用率（swap usage超过10%就是预警信号）。

最后给出三条具体建议，也是新手最常踩的误区：

• 不要用root账号日常操作。创建一个普通用户并赋予sudo权限，避免因一条rm -rf命令误删系统文件。误删后即使有备份，恢复时间也足够让业务中断数小时。
• 修改配置前先cp备份原文件。例如改nginx.conf之前，先执行cp nginx.conf nginx.conf.$(date +%Y%m%d)，这样出问题后可以直接回滚，不必回忆原始内容。
• 别把“能跑就行”当标准。服务器偶尔卡顿或内存泄漏初期，看起来业务正常，但积累到临界点会突然崩溃。建议每周至少检查一次uptime和free -h的输出，负载均值超过CPU核心数或内存使用率长期高于80%，就需要提前介入优化。