Linux服务器从零搭建到稳定运行实践

　　跟产品吵完第三轮之后我直接把防火墙配置表打印出来拍他桌上，纸边都翘了。他盯着 iptables 那行 --log-prefix "DROP-FROM-CDN-" 看了十八秒，说“这前缀是不是太长？影响日志轮转”。我说你先看看上周被扫掉的 /wp-admin/ 路径日志里混进多少个 /api/v2/user/profile?token= 了再说。他摸出手机想截图，发现锁屏壁纸是去年双十一的压测看板，还没换。

　　首屏救火——这次真不是比喻。凌晨四点十七分收到告警，Lighthouse 跑分截图发到群里没人回，连个已读都没，只有前端小张在十一点零三分发了个“？”，后边跟着三个句号。我切过去看控制台，console.timeEnd('render-first-paint') 居然输出的是 1.2 秒，但 real user metric 里 FCP 是二百三十六毫秒。我原以为是 Chrome DevTools 的 timing API 坏了，结果重装 Canary 才发现是 nginx gzip_vary 没关，Edge 浏览器缓存了一堆错版响应头。这个我敢打包票，因为我在三台不同内核版本的机器上复现过七次，第七次是在老板新领的那台 M3 MacBook 上——他连 Linux 虚拟机都懒得开，全程用 ssh + tmux 折腾。

　　Linux服务器从零搭建到稳定运行实践？优胜劣汰罢了。不是说系统本身淘汰人，是人自己选出来的。你看刚上线那会儿谁都在改 /etc/sysctl.conf，调 net.core.somaxconn，调 vm.swappiness，调内核参数像调咖啡浓度。三个月后剩下的人只做两件事：写 systemd service unit 的 RestartSec=5，以及每天手动 kill 一次卡死的 journalctl -f 进程。桌面那个没关的录屏还在后台跑着，窗口最小化在右下角，时间戳显示下午三点十四分，音轨里能听见空调外机重启的嗡声。

　　我昨天帮后端同事修一个证书链断裂的问题，他用 certbot renew --force-renewal 在生产环境跑，结果把 staging 的中间证书硬塞进了 fullchain.pem，curl -v 连的时候 OpenSSL 报“unable to get local issuer certificate”……但浏览器不报错。我当场打开 chrome://flags/#unsafely-treat-insecure-origin-as-secure 加了个 localhost:8080，结果发现他代码里写了 hardcode port=8080，而真正监听的是 8443。他倒水去了，我盯着那个 if (port === 8080) { ssl: true } 发了半分钟呆。回来后他说“要不要加个 feature flag？” 我点了根烟——办公室禁烟，所以只是拿打火机开了盖又合上。

　　其实最烦的不是参数调错，是人总想用 Ansible 把一切固化。上次部署时，playbook 里 copy 模块用了 backup: yes，结果磁盘满了——不是日志占的，是 /etc/hosts.backup.237 这种文件堆了四百一十二个。我 grep 了一下，backup 生成规则是每执行一次就加个数字后缀，不管内容有没有变。这个我说不准是不是 Ansible 的 bug，也懒得提 PR，直接改成 shell: cp -f /tmp/hosts /etc/hosts，加了个 ignore_errors: true。反正只要 hostfile 不炸，谁管它备份逻辑像不像丧尸片续集。

　　CDN 账单的事得提一嘴。上月多花了三千六百二十元，原因是 WAF 规则误匹配了健康检查探针，返回了 403，触发了源站重试+缓存穿透，最后流量全打到了 /healthz?ts= 后面带随机参数的 URL 上。PM 说“这不是刚好验证了我们限流兜底策略的有效性吗”，我没接话。她电脑贴纸是“API 优先”，可她连 curl -I 看 header 都要查文档。旁边坐着的那个穿灰卫衣的后端，刚换了一根蓝色编织线给 MacBook 充电，旧的那根缠在显示器支架底下，胶皮磨秃了。

　　优胜劣汰不是说弱者活不下来，是弱者根本没机会暴露弱点——他们早就被 sudoers 权限、crontab 权限、docker socket 权限、甚至 journald 的 MaxLevelStore= 的默认值，层层筛掉了。真正撑下来的，要么记住了 ulimit -n 不能只改 /etc/security/limits.conf 还得碰 /proc/sys/fs/file-max，要么干脆在所有脚本开头加一句 set -e -u -o pipefail，靠失败倒逼稳定。当然，也有人靠运气，比如某次 init.d 脚本里漏了个 exit 0，系统 reboot 后服务居然起了——因为父进程 exit 之后子进程被 init 接管，阴差阳错保活了。这事我信，因为去年十月二号下午我亲眼见他 ssh 连进去 ps aux | grep python，然后默默删掉了脚本末尾的注释符号 # exit 0。

　　我现在不写初始化脚本了，直接扔个空白 Ubuntu 22.04 ISO 过去，手动跑一遍 apt update && apt install -y htop tmux vim wget curl git dnsutils net-tools openssh-server。其他全部用 configmap mount 或 secrets 注入。原因？因为三年前我亲手写的 bootstrap.sh，在一次内核升级后触发了 systemd-resolved 和 dnsmasq 的端口争抢，导致所有 outbound DNS lookup 延迟飙到三秒。修复方案是删掉脚本里一行 rm -f /etc/resolv.conf && ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf ——但现在我不动它了。反正机器重启后它自动好了，而我的运维笔记里写着：“2025年11月，实测可行；别问为什么，问就是 systemd 自愈。”

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!