服务器运维最大的误区，是把“能跑”当成“没事”。多数事故不是突然爆发，而是长期忽视小信号后的集中清算。磁盘写满、内存泄漏、连接数耗尽、时间不同步、日志塞爆根分区，这些问题几乎每一台长期运行的服务器都会遇到，区别只在于你有没有提前处理。
先讲磁盘。根分区被写满是运维中最常见的低级事故。很多团队习惯把应用日志、数据库备份、临时文件全放在根分区，一旦日志增长失控，SSH登录都会失败，服务全部中断。避坑的核心是分区规划要提前做：根分区只放系统和核心配置，/var、/home、/tmp、/data独立挂载。已经上线的服务器，要设置日志轮转和定期清理任务。用df -h和du -sh *定期检查占用，比事后抢救有效得多。inode耗尽同样致命，大量小文件会占满inode导致无法创建新文件，用df -i可以提前发现。
内存问题比磁盘更隐蔽。Linux的缓存机制会让free命令看起来内存所剩无几，新手容易误判为内存不足。正确做法是看available字段，而不是free。真正需要警惕的是swap使用率突然升高，这通常意味着物理内存已经不够，系统开始用磁盘当内存，性能会断崖式下降。排查思路是先看top或htop中哪个进程占用最高，再看是否有内存泄漏。Java应用要关注堆内存配置和GC日志，Node.js要检查是否有未释放的全局变量或闭包引用。内核参数vm.swappiness也值得调优，数据库服务器建议设为10以下，避免无谓的swap交换。
连接数耗尽是一个典型的“看起来没事，一压就崩”的问题。服务器能建立的TCP连接数受文件描述符限制，默认值往往偏小。高并发场景下，如果ulimit -n还是1024，流量一上来就会报Too many open files。解决方法是修改/etc/security/limits.conf，给应用用户设置更高的nofile值，同时检查应用是否正确关闭连接。数据库连接池也要设置合理的最大连接数，避免连接泄漏。用ss -s和netstat -an可以查看当前连接状态，TIME_WAIT堆积过多时要考虑调整内核参数或优化应用连接复用。
时间同步是分布式系统的基础，却经常被单机运维忽略。服务器时间漂移会导致日志时间错乱、证书校验失败、数据库主从同步异常，甚至分布式锁失效。所有服务器都应该配置NTP或chrony自动同步，并且要确保重启后服务自动启动。用timedatectl status可以检查同步状态。特别提醒，云服务器虽然通常有母机时间同步，但容器和虚拟机内部仍可能出现漂移，容器环境建议在宿主机层面统一处理。
日志管理是运维的基本功，但很多团队做得并不好。日志不是越多越好，无限制的日志会拖垮磁盘和IO。关键是要区分日志级别，error和warn必须保留，info和debug按需开启。日志轮转用logrotate配置，按大小或时间切割，保留最近N份即可。更重要的一点：日志要能定位问题。如果日志里只有“连接失败”，没有目标地址、错误码和上下文，出了问题等于没有日志。规范日志格式，带上时间戳、请求ID、用户ID和关键参数，排查效率能提升数倍。
权限管理是最容易出安全事故的环节。root用户直接操作是常态，但也是最大的风险来源。一次误删、一条错误命令，就可能造成不可逆的损失。建议的做法是：日常操作使用普通用户，需要提权时用sudo，并且sudoers配置要精确到命令级别，不要直接给ALL。应用运行用户要独立，不要用root跑Web服务或数据库。SSH登录禁用root，改用密钥认证，同时修改默认端口虽然不能完全避免扫描，但能过滤掉大部分自动化攻击。防火墙策略要默认拒绝，只开放必要的端口。
备份是最后一道防线，但很多备份策略经不起推敲。常见的错误包括：备份文件和源文件在同一块磁盘上、备份从不验证可恢复性、只备份数据不备份配置。正确的做法是至少保留一份异地备份，备份完成后定期做恢复演练。数据库备份要特别注意一致性，MySQL用mysqldump加--single-transaction参数，或者用物理备份工具。备份不是目的，能恢复才是。如果从没测试过恢复流程，等于没有备份。
监控和告警是运维的眼睛。没有监控的服务器就像盲人开车，出事只能靠用户投诉。监控指标至少要覆盖CPU、内存、磁盘、网络、负载、连接数、服务进程存活状态。告警阈值要合理，太灵敏会让人麻木，太迟钝会错过最佳处理时间。告警信息要包含足够的上下文，比如哪台机器、哪个指标、当前值是多少、持续了多久。监控系统本身也要做高可用，避免监控和业务同机部署，否则服务器宕机时监控也一起消失。
自动化运维是减少人为失误的有效手段。手工操作容易出错，而且不可追溯。用脚本或配置管理工具统一管理服务器，把环境配置、软件安装、服务启停都代码化，既能保证一致性，也方便审计和回滚。Ansible、SaltStack这类工具学习成本不高，但收益很大。即使不用完整工具，把常用操作写成脚本，也比每次手动敲命令可靠。关键操作要有审批和记录，生产环境的变更不能随意执行。
内核参数调优是进阶运维必须掌握的技能。默认内核参数面向通用场景，高负载服务器需要针对性调整。比如net.core.somaxconn影响TCP监听队列长度，默认值偏小，高并发Web服务器建议调大。net.ipv4.tcp_max_syn_backlog影响半连接队列，抗SYN攻击时需要提高。文件系统层面，ext4和xfs的挂载参数也会影响性能，数据库服务器常用noatime减少写入。这些参数调整前要理解含义，调整后要做压测验证，不要盲目照搬网上的配置。
安全更新和漏洞管理不能拖延。很多入侵事件利用的都是早已公开的漏洞，补丁早就发布了，只是没人打。建立定期更新机制，至少每月检查一次系统补丁和依赖库版本。对于无法立即更新的系统，要有临时的缓解措施，比如通过防火墙限制暴露面、关闭不必要的服务。生产环境更新前先在测试环境验证，避免补丁本身引入新问题。安全不是一次性的工作，而是持续的对抗过程。
最后强调一个容易被忽视的点：文档和操作记录。服务器数量少的时候，靠人脑记忆还能应付，一旦超过十台，没有文档就是灾难。每台服务器的用途、配置、依赖关系、历史变更都要记录在案。操作记录可以用history命令配合审计工具，也可以要求团队成员在操作后更新文档。文档不需要多正式，但要准确、及时。好的文档能在故障发生时节省大量排查时间，也能让新人快速接手。
服务器运维没有银弹，所有技巧都建立在持续关注和规范操作的基础上。把基础工作做扎实，把监控和备份做到位，把权限和变更管住，大部分事故都可以避免。剩下的，就是在实践中不断积累经验，把每一次故障都变成改进的机会。
