服务器运维管理必须要做几件事

今天把服务器管理中“绝对不能碰”的几件事整理出来，每一条都是踩过坑、付过代价的经验，不管你是运维、开发还是创业公司老板，都建议记好——毕竟服务器出问题，补锅的成本永远比预防高10倍。

1. 直接用 root 账号日常操作。

风险解析：root 是 Linux 最高权限账号，一旦误操作（比如rm -rf /删根目录、chmod 777 /改全权限），几乎没有挽回余地。而且 root 操作的日志难以追溯到具体责任人，出了问题都不知道是谁干的。

真实案例：去年帮一家做 SaaS 的公司排查故障，发现他们技术部 3 个人共用 root 账号。有次新人想删自己目录下的测试文件，却写成rm -rf /home/test/../，误删了整个/home目录，里面存着客户的核心数据备份，最后花了 2 天才从异地冷备恢复，损失了近 10 万订单。

正确做法：

• 新建普通账号（比如ops01），日常操作只用普通账号；

• 需要管理员权限时，用sudo临时提权（比如sudo yum install nginx）；

• 编辑/etc/sudoers文件，严格限制普通账号的操作范围（比如只允许执行安装、重启服务的命令，禁止删除、修改系统目录）。

2. 服务器密码简单 / 复用 / 明文存储。

风险解析：弱密码（比如123456、admin@123）5 分钟内就能被暴力破解工具猜中；复用密码（和个人微信、邮箱密码一样）一旦某平台泄露，服务器会直接遭殃；明文存储（比如把密码写在记事本、配置文件里）更是等于把钥匙插在门上。

真实案例：前几年某教育机构的服务器被黑客入侵，原因是管理员把服务器密码设为edu2020，还和自己的 QQ 密码一样。黑客通过暗网买到泄露的 QQ 密码，试了 3 次就登录了服务器，删光了所有课程视频，最后勒索 5 个比特币才恢复。

正确做法：

• 密码至少 12 位，包含大小写字母、数字、特殊符号（比如Srv@2025!Ops）；

• 服务器密码和个人账号密码完全区分，不同服务器用不同密码；

• 用密码管理器（比如 Bitwarden、Keepass）存储，或通过密钥登录 SSH（彻底不用密码）；

• 配置文件里的敏感密码（比如数据库密码），用环境变量或加密工具（比如 Vault）存储，别明文写db_pass = “123456”。

3. 不及时更新系统 / 软件补丁。

风险解析：系统和软件的漏洞（比如 Log4j、Heartbleed）是黑客最常用的突破口。很多管理员觉得 “更新麻烦”“怕出兼容问题”，但漏洞暴露后，黑客的利用工具往往几小时内就会上线，不更新等于等着被攻击。

真实案例：2023 年某电商平台大促前，服务器被植入挖矿程序，CPU 占用率飙升到 99%，导致商品页面加载不出来。排查发现，是服务器用的 Nginx 版本有个已知漏洞（CVE-2022-41741），官方 3 个月前就发了补丁，但管理员一直没更，黑客通过漏洞直接拿到了权限。

正确做法：

• Linux 系统：每周用yum update（CentOS）或apt upgrade（Ubuntu）更新补丁，生产环境可先在测试机验证兼容性；

• Windows 服务器：开启 WSUS 自动更新，或手动下载微软官网的安全补丁；

• 常用软件（Nginx、MySQL、Redis）每月查一次官方漏洞库，有高危漏洞立即更新；

• 实在不能更的旧版本，用防火墙限制访问来源（比如只允许公司 IP 访问 Redis 端口）。

4. 不做数据备份或备份不验证。

风险解析：服务器硬件会坏、会被勒索、会误删数据 —— 没有备份，任何一次小故障都可能导致数据永久丢失。更坑的是 “假备份”：备份了但没验证，真出事才发现备份文件损坏、无法恢复，等于没备份。

真实案例：有个客户是做线下门店管理的，服务器存着 100 多家门店的销售数据。他们每天凌晨自动备份，但从没验证过。直到有次硬盘坏了，想恢复备份时，发现备份目录下只有空文件（脚本执行失败没报警），最后只能手动补录 3 个月的数据，花了 10 多万人力成本。

正确做法：

• 核心数据至少做 3 份备份：本地 1 份、异地 1 份、云存储 1 份；

• 备份类型结合用：全量备份（每周 1 次）+ 增量备份（每天 1 次），减少备份时间和空间；

• 每周随机抽 1 次备份文件，在测试机恢复验证（比如恢复 MySQL 备份，查是否能正常查询数据）；

• 备份脚本加报警机制（比如执行失败发邮件 / 企业微信通知），别等出问题才发现备份没成功。

5. 随意开放防火墙端口。

风险解析：服务器的端口就像窗户，开得越多，黑客能钻的空子就越多。很多人图方便，把防火墙设为 “允许所有端口访问”，或开放不必要的端口（比如 MySQL 的 3306、Redis 的 6379），结果被黑客扫描到后暴力破解。

真实案例：之前帮一个创业团队处理服务器被黑的问题，发现他们的 Redis 端口 6379 开放了公网访问，还没设密码。黑客用扫描工具找到这个端口后，直接写入恶意脚本，拿到了服务器权限，把所有业务数据加密后勒索。

正确做法：

• 遵循 “最小权限” 原则：只开放必须用的端口（比如 Web 服务开 80/443，SSH 开 22），其他端口全部关闭；

• Linux 用iptables或firewalld配置规则（比如firewall-cmd –add-port=80/tcp –permanent），Windows 用 “高级防火墙” 设置；

• 非必要不开放公网访问：比如 MySQL、Redis 只允许内网 IP 访问，外部要连的话用 VPN 或 SSH 隧道；

• 定期用工具（比如 nmap）扫描服务器开放端口，检查是否有多余端口没关。

6. 生产服务器装无关软件。

风险解析：生产服务器是用来跑业务的，装无关软件（比如杀毒软件、视频播放器、聊天工具）会占用 CPU、内存资源，还可能带来安全隐患 —— 很多软件会后台联网、收集数据，甚至自带漏洞（比如某些国产杀毒软件曾被曝有提权漏洞）。

真实案例：有个客户的生产服务器跑着电商订单系统，管理员觉得服务器卡，就装了某国产杀毒软件。结果杀毒软件的实时监控功能占用了 20% 的 CPU，导致订单接口响应时间从 100ms 涨到 500ms，高峰期还出现了订单丢失的情况，最后卸载杀毒软件才恢复正常。

正确做法：

• 生产服务器只装业务必需的软件（比如 Nginx、MySQL、Java），其他软件一律不装；

• 想管理文件用scp/sftp，想远程操作用 SSH，别装 FTP 工具、远程桌面客户端；

• 不需要装杀毒软件：Linux 系统本身病毒很少，只要做好权限控制和补丁更新，比装杀毒软件更安全；

• 定期用ps -ef（Linux）或 “任务管理器”（Windows）查进程，发现陌生进程立即排查。

7. 不开启 / 不分析服务器日志。

风险解析：服务器日志是 “黑匣子”，能记录所有操作和故障：谁登录过服务器、执行了什么命令、软件报错原因是什么…… 不开启日志，出了问题根本没法溯源；开启了不分析，也会错过早期风险信号（比如多次失败的登录尝试）。

真实案例：某公司的服务器被人删了核心代码，查了半天不知道是谁干的 —— 因为他们没开启 SSH 登录日志，也没记录用户执行命令的日志。最后只能通过服务器的物理访问记录排查，发现是离职员工偷偷登录删的，但因为没有日志证据，没法追究责任。

正确做法：

• 开启关键日志：

• SSH 日志：Linux 默认存在/var/log/secure，记录登录成功 / 失败信息；

• 系统日志：/var/log/messages（Linux）、“事件查看器”（Windows），记录系统报错、进程启动停止；

• 应用日志：Nginx 日志（/var/log/nginx）、MySQL 日志（/var/lib/mysql），记录请求和 SQL 执行；

• 用工具（比如 ELK、Graylog）收集和分析日志，设置报警（比如 10 分钟内 SSH 登录失败 5 次就报警）；

• 日志至少保留 3 个月，方便后续排查问题（比如客户反馈上周某订单异常，能查当时的应用日志）。

8. 给普通用户分配过高权限。

风险解析：普通用户只需要能完成自己工作的权限（比如开发只需要改代码的权限，运营只需要看日志的权限），如果给过高权限（比如sudo ALL，允许执行所有命令），一旦用户账号被黑，黑客就能拿到完整的管理员权限，想删数据、改配置都能做到。

真实案例：有个开发团队为了方便，给所有开发账号都加了sudo ALL权限。有次一个开发的电脑被黑客入侵，黑客通过远程桌面拿到了开发的服务器账号密码，登录后用sudo删了整个代码仓库和数据库备份，导致项目停滞了 1 周。

正确做法：

• 按 “职责分工” 分配权限：开发账号只给/var/www（代码目录）的读写权限，运维账号给服务管理权限，财务账号只给报表日志的只读权限；

• 编辑/etc/sudoers文件时，严格限制命令范围（比如只允许执行sudo systemctl restart nginx，不允许sudo rm）；

• 用chown/chgrp设置文件所属用户组（比如代码目录属于www用户组，开发加入这个组就能改代码，不用给 sudo 权限）；

• 定期用sudo -l查看用户的 sudo 权限，移除不必要的高权限。

9. 文件 / 目录权限设为 777。

风险解析：Linux 文件权限 777 意味着 “所有人（所有者、组、其他用户）都能读、写、执行”，相当于把文件公开在大街上，任何人都能改内容、删文件。很多人图方便，把网站目录、配置文件设为 777，结果被黑客上传恶意脚本（比如 webshell），直接控制服务器。

真实案例：某个人站长的博客被挂马，打开页面就跳转到钓鱼网站。排查发现，他把/var/www/blog目录设为 777 权限，黑客通过博客的评论功能上传了一个shell.php文件，因为权限是 777，能直接执行这个脚本，拿到了网站的控制权。

正确做法：

• 遵循 “最小权限”：

• 普通文件：权限设为 644（所有者读写，其他人只读）；

• 目录：权限设为 755（所有者读写执行，其他人只读执行）；

• 执行脚本：权限设为 700（只有所有者能执行）；

• 网站目录的权限：所有者设为www（Web 服务用户），普通用户只能读，不能写（防止上传恶意文件）；

• 定期用find / -perm 777查找系统中 777 权限的文件 / 目录，改成正确权限。

10. 生产环境与测试环境混部署。

风险解析：生产环境跑的是真实业务，测试环境是用来测新功能、改 bug 的 —— 混在一起的话，测试时的误操作（比如删测试数据时删了生产数据）、新功能的 bug（比如代码报错导致服务崩溃），都会直接影响生产业务，造成损失。

真实案例：有个电商公司为了省服务器成本，把生产数据库和测试数据库放在同一台服务器上。有次测试人员想清空测试数据，执行drop database test_db时，手滑写成了drop database prod_db（生产数据库名），直接删了所有订单数据，导致平台停服 6 小时，损失了 20 多万销售额。

正确做法：

• 生产环境和测试环境完全隔离：用不同的服务器，甚至不同的机房 / 云账号；

• 环境配置区分开：生产用高配置服务器、关闭调试模式，测试用普通配置、开启调试模式；

• 数据库严格分开：生产库只允许生产服务访问，测试库只允许测试服务访问，禁止从测试环境连接生产库；

• 测试前必须确认环境：开发 / 测试人员操作前，用hostname（Linux）或 “计算机名”（Windows）确认是测试环境，再执行操作。

11. 不限制 SSH 远程登录。

风险解析：SSH 是远程管理服务器的主要方式，如果不限制登录规则，黑客会用暴力破解工具尝试登录 —— 比如不断试账号密码，一旦成功，就能完全控制