服务器运维从零上手：先把这四件事做对，再谈精通

刚拿到一台服务器的头几个小时，决定后面半年你是躺着还是救火。我见过太多人把系统装完、SSH 一连上、网站一挂就当完工，结果两周后被人扫到 root 弱口令，整台机器变成挖矿肉鸡。运维这件事的门槛不在命令多难，而在顺序——先做什么、后做什么，做错顺序就要返工。

下面按我实际接手一台新机器时的顺序讲。不追求一次讲全，只讲那些漏掉就一定出事的环节。整套流程走完大概两三个小时，比后面通宵恢复数据划算得多。

第一步：登录方式先改掉，别用 root 直连

新机器默认给你 root 加密码登录，这是最省事也最危险的组合。公网上的扫描器平均几分钟就会敲一次 22 端口，密码稍微短一点就是时间问题。

我一般先建一个普通用户，把公钥塞进 authorized_keys，然后改 sshd_config 关掉密码登录、关掉 root 直连。这三条做完，暴力破解基本就跟你无关了。

• 改端口只能减少日志噪音，挡不住有心人，别把它当主要防线
• 密码登录关掉之前，务必先开另一个终端验证密钥能进，否则会把自己锁在门外
• 云厂商的控制台 VNC 是最后的救命通道，改配置前确认它能用

这一步花不到二十分钟，但省下的是后面被入侵后重装系统的整个晚上。

第二步：把该开的端口和不该开的服务分清楚

很多人装完环境就把 3306、6379、9200 全放出来，图的是本地连数据库方便。数据库只要暴露在公网，被拖库就是几天内的事，Redis 未授权写入更是老套路了。

我的做法是先用一条命令把所有监听端口列出来，逐个问自己：这个端口需不需要公网访问？答案是否的，就在防火墙里只放行内网地址。

真正需要对外的一般就两三个：Web 的 80/443，加上你自己的 SSH 端口。其余全部收进内网。如果业务本身抗攻击要求高，比如游戏或支付类接口，那机器选型就得提前考虑防御能力，香港高防服务器 II 这类 50M 带宽配基础防护的机型，月付 $199，E3-1230 加 16G 内存，跑中小型站点够用，比事后被打瘫再补救便宜。

第三步：备份不是可选项，是上线前的准入条件

我判断一台机器能不能上线，先看它有没有可恢复的备份，而不是看业务跑没跑起来。没有备份的系统，一次误删或者一次磁盘故障就能让项目归零。

新手最容易犯的错是把备份和源站放同一块盘。数据库文件复制到同机器的另一个目录，那不叫备份，那叫心理安慰。磁盘挂了两个目录一起没。

合理的做法分两层：数据库每天定时导出并传到异地，配置文件改动后立刻同步一份出去。频率按业务能承受丢多少数据来定，电商订单和博客的答案完全不一样。

验证备份能不能恢复，比备份本身更重要。我一般会定期把备份拉到一台测试机上真实还原一次，很多人的备份文件其实是坏的，只是没人打开看过。

第四步：监控和日志，出事后才有线索

机器正常的时候没人看监控，出事的时候没有监控就只能靠猜。最低配的方案是装一个轻量监控，盯住三样东西：CPU 和内存的持续占用、磁盘剩余空间、服务进程是否存活。

磁盘满是最常见的故障，数据库写不进去、日志停止滚动，往往就是因为根分区被日志撑爆。设一个 85% 的告警阈值，能提前几天发现。

日志方面，先确认系统日志和业务日志都有轮转策略。没有 logrotate 的机器，跑上几个月日志文件能吃掉几十个 G，那时候清理起来很麻烦。

把这四步走完，一台机器算是进入了可运维状态。剩下的调优、容器化、自动化部署，都是在这套底子上加东西。顺序颠倒过来，先折腾花哨的工具再回头补安全，返工的成本会高得多。预算有限的话，我会优先把钱花在防御和带宽上，配置够用就行；真要长期跑业务，一台稳定机房里的独立机器，比频繁换低价方案省心。