从一次线上故障说起：服务器运维到底要盯住哪几件事

服务器刚买回来那几天往往最顺，装好环境、跑起服务，看着监控一片绿。真正让人措手不及的是第二周：网站打不开、SSH 连不上、数据库莫名其妙停了。多数情况下不是硬件坏了，而是几个最基础的运维动作没做，问题积累到某个点才爆发。下面按一台普通 2核4G 机器从登录到长期维护的顺序，把真正需要盯住的地方说清楚。

先把登录和进程这两件事管明白

很多人拿到服务器第一件事是装面板，其实更该先确认两样东西：SSH 能不能稳定连上，服务进程挂掉后能不能自动拉起来。

SSH 这块最常见的坑是只开密码登录，端口 22 暴露在公网。密码被爆破只是时间问题。我一般建议直接换非标端口，同时关掉密码认证走密钥。密钥文件权限必须是 600，否则 sshd 会直接拒绝，这个报错信息不明显，新手容易卡很久。

进程管理推荐用 systemd 而不是 nohup。nohup 启动的进程重启服务器就没了，systemd 可以做到开机自启、崩溃自动重启。写好一个 .service 文件，把 WorkingDirectory、ExecStart、Restart=always 三行配好，服务稳定性立刻上一个台阶。这里有个取舍：Restart=always 虽然省心，但如果程序本身启动就报错，会陷入无限重启，日志被刷满。所以务必同时配上 RestartSec=5，留出间隔。

磁盘、内存、日志，故障八成出在这三处

线上服务突然假死，我第一反应通常是看磁盘。用 df -h 确认根分区使用率，超过 90% 就要警惕。MySQL 在磁盘写满时不会直接崩，而是拒绝写入并进入只读状态，表现就是网站能打开但提交表单失败，很容易误判成代码 bug。

• 日志文件是最常见的磁盘杀手，尤其是没配 logrotate 的 Nginx 和 Java 应用
• Docker 的 overlay2 目录如果不清理，镜像和容器日志能在几周内吃掉几十 G

内存问题更隐蔽。Linux 的 OOM Killer 会在内存耗尽时挑一个进程杀掉，通常选中占用最大的那个，也就是你的业务进程。事后用 dmesg | grep -i oom 能看到记录。想避免被误杀，可以给关键进程设 OOMScoreAdjust=-500，但更根本的办法是加 swap 或直接升配置。一台 2核4G 的机器跑 MySQL 加 Nginx 再加一个 Java 服务，内存基本就顶到边缘了。

日志排查要养成看时间戳的习惯。tail -f 只是入门，真正定位问题得靠 grep 加时间范围过滤，比如 sed -n '/14:20/,/14:35/p' 把故障时间段单独拎出来。这一步做熟之后，排查效率比盲目翻日志快很多。

备份和监控，决定你能不能睡好觉

运维做到最后拼的是恢复能力，不是不出故障。数据库每天自动备份、备份文件异地存放、并且定期做一次恢复演练，这三步缺一不可。我见过太多备份脚本跑了大半年，真要用的时候发现导出的 SQL 是空的，因为 mysqldump 的密码写在脚本里被改了却没同步。

监控不用一上来就上重型方案。一个每分钟跑一次的 shell 脚本，检查 HTTP 状态码、磁盘使用率、进程存活，异常时发通知，就能覆盖大部分场景。等业务量上来再考虑 Prometheus 这套。这里有个真实的取舍：自建监控省了钱，但告警通道要自己维护；用现成服务省事，长期有月费。小团队我一般建议先用脚本过渡。

如果机器部署在香港或海外，网络层面的监控还要加一项：从外部节点定时探测端口连通性。本地 curl 通不代表公网可达，中间可能卡在防火墙或线路波动上。像 香港大带宽服务器 XXVI 这类配置，E5-2683v4*2 加 64G 内存、100M 带宽，跑监控采集端和日志聚合比较从容，不用担心采集程序本身把机器资源吃满。

把上面几件事做完，一台服务器的日常维护工作量其实不大：每周看一眼磁盘和内存趋势，每月确认备份可恢复，出故障时先查 dmesg 和 journalctl 再动手。预算有限就从 2核4G 起步，重点放在 systemd 托管、日志轮转和自动备份上，这三样做到位，八成的突发故障都能自己扛过去。真遇到反复 OOM 又不想加内存的，别硬撑，换配置比调参划算。