一台正常运行了380天的Nginx服务器，因为一个未设置文件描述符上限的数据库连接池，在第381天凌晨3点突然崩溃。这不是硬件故障，不是DDoS攻击，而是最容易被忽略的运维细节——你手里的服务器，可能就差一个ulimit配置就能扛住更大的流量。

系统初始化：别让默认配置坑了你第一个月

我接手过一台新部署的阿里云ECS，系统是CentOS 7.9，默认的ulimit -n只有1024。业务上线第三天，用户量刚到200并发，MySQL连接池就报错“Too many open files”。后来检查发现，运维同事只装了Nginx和PHP，没改任何内核参数。解决方案其实简单：在/etc/security/limits.conf加上“* soft nofile 65535”和“* hard nofile 65535”。同样，需要同步调整/etc/sysctl.conf里的net.ipv4.tcp_tw_reuse=1和net.core.somaxconn=10240，否则高并发下TIME_WAIT堆积会直接吃光端口——这比文件描述符问题更隐蔽，却更致命。

监控告警：别等用户电话才知道服务挂了

有个客户用Prometheus+Grafana搭了全套监控，但只配置了CPU和内存告警。某次凌晨2点，磁盘Inode被日志文件占满，系统无法创建新文件，Web服务直接瘫痪。直到早上8点用户投诉他们才发现问题——CPU和内存都正常，但df -i显示Inode使用率100%。正确的做法是：除了CPU、内存、磁盘空间，必须监控磁盘Inode使用率、TCP连接状态数、进程存活状态。用node_exporter加Alertmanager，设置磁盘Inode超过80%就发钉钉报警，超过90%直接触发重启日志轮转脚本。别信“日志会自动清理”，我见过logrotate配置错误导致日志不轮转的案例，最后磁盘写满，服务停摆。

安全加固：最常被捅的篓子不是0day，是默认密码和未更新的组件

某次安全审计，一台Tomcat服务器用的还是8.0.32版本，CVE-2017-12615漏洞直接可以PUT上传JSP木马。更离谱的是，这台服务器的root密码是“root123”，MySQL端口3306直接暴露在公网。安全加固要抓三个硬指标：第一，关闭不必要的端口，只留80/443/22，22端口改成非标准端口并禁用密码登录，只允许密钥登录；第二，所有组件必须用yum或apt定期更新，尤其OpenSSL、Nginx、MySQL这类底层依赖，每周跑一次安全扫描脚本；第三，数据库和Redis必须绑定内网IP，用iptables限制来源IP段，别信防火墙默认规则——Cloudflare的WAF规则包里都有现成的SSH爆破拦截规则，直接导入就能用。

最后给你三条最容易被忽略的实战建议：

• 别信“默认配置够用”——新服务器必须执行：ulimit -n 65535、sysctl -w vm.swappiness=10、关闭selinux。这三步能避免80%的早期崩溃。
• 日志是运维的命门——用logrotate配置每天压缩归档日志，保留7天，同时把错误日志独立发送到远程日志服务器（比如ELK），这样即使服务器崩了，你还能从日志里找出原因。
• 备份不是“复制一份”那么简单——每周全量备份数据库，每天增量备份配置文件，备份文件必须存储到与服务器不同的物理机或对象存储。我曾经见过备份脚本把备份文件存在同一台服务器的/backup目录下——服务器被rm -rf后，备份文件也一起没了。