14年程序员实战：建站资源优化新范式

　　告警响的那一刻，我正把泡面叉子插进最后一根面条里——没吃完，汤还浮着油花，屏幕右下角钉着三个窗口：一个跑着 certbot renew --dry-run，一个连着灰度环境的 tmux，还有一个是微信聊天框，开发老张发来一句“前端静态资源改了个 CDN 域名，顺手切了”，底下跟了个眨眼表情。

文章配图，仅供参考

　　我划掉那句“顺手”，点了回车。三台机器里，两台崩得像被抽了脊椎——HTTP 503 比呼吸还勤快，证书链断裂报错堆满 terminal，curl -I 看一眼，Connection refused 跳得比心电图还亢奋。第三台撑到凌晨三点半，硬盘 IO 吃到 98%，我盯它时它还在苟延残喘，像在等我手动敲 shutdown -h now 好给它个体面。

　　我原以为是证书续期脚本又撞上 Let’s Encrypt 的 ratelimit——去年七月搞过一回，八台机器全轮着重签，结果 nginx reload 顺序错半秒，服务雪崩二十分钟。可这次不对劲：renew 日志清清白白，私钥权限没错，OCSP stapling 也开着。我查了一圈，直到看见 /var/log/nginx/error.log 里一行小字：“SSL_do_handshake() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca)”。对，不是“self signed”，不是“expired”，是“unknown ca”。我盯着这六个字看了四分钟，窗外天快亮了，机房冷气嗡嗡响，吹得我后颈起皮疹。

　　其实是上游 CDN 服务商悄悄升级了信任链策略，把中间 CA 换了个新 Root，而我们所有站都硬绑着旧根证书 bundle，且全部用的默认系统 ca-certificates 包——去年二月份，Ubuntu 22.04 默认包里还没塞进那个新根。没人提，没人测，没人配 override，就那么裸奔着上线了三个月。开发老张第二天上午十点才看到钉钉消息里有人问“为什么首页 JS 加不进来”，他截图给我看 Network 面板里一堆红色 cross-origin blocked，然后补了一句：“是不是 CDN 改配置了？你问问？”

　　我认了。真认了。不是认错，是认这个节奏：你不踩一遍坑，就永远不知道哪条路底下铺的是玻璃渣还是水泥地。我们早年搞负载均衡，还靠手动调权重；后来玩自动扩缩容，全靠 Metrics 打点骗自己；现在搞资源优化，嘴上喊“精细化治理”，结果优化来优化去，连 root CA 有没有更新都不知道。什么叫优胜劣汰？就是你昨天写的优雅降级逻辑，在新 CA 报警面前脆得像薯片；就是你信誓旦旦说“监控覆盖 100%”，却漏了证书链可信锚点这种事——因为 nobody 在 grafana 里给“CA bundle 新鲜度”建 panel。

　　同事老王半夜赶来，进门就脱外套挂衣架上，顺手把我泡面盒捏扁扔进垃圾桶。“你这锅底焦成黑炭，还吃？”他翻出 ansible-playbook -i staging deploy-ca-bundle.yml，跑完说：“先顶三天。”结果顶了七天，第七天晚上他自己值班，又加了个 cron ——每天凌晨两点 wget https://curl.se/ca/cacert.pem -O /etc/ssl/certs/ca-bundle.crt && update-ca-certificates。我说这太野了，他说：“你告诉我怎么优雅？写个 Operator？上 Istio？还是让 SRE 团队下周给你排个季度规划？”我答不上来。机房的人端着保温杯路过，探头看了眼终端输出，说：“你们现在不都用 HashiCorp Vault 存证书了么？”我没接话。Vault 我们有，但没人往里面塞 cacert.pem，因为空间不算，不走 PKI 路由，不在 SLA 里。

　　这事后来谁也没追责。不是不想，是没法。因为同样问题，测试环境压根没复现——他们镜像版本滞后三个月，自带旧 bundle；生产环境用的是最新镜像；预发呢？预发用的镜像是上周五临时构建的，刚好卡在变更前七小时……所以三套环境全活成了对照组，还特么互不干扰。你说巧不巧？反正我删了三条准备发给老板的邮件草稿，其中一条写着“建议建立 CA bundle 自动同步 SOP”，删完关机睡觉，路上收到我妈微信：“今晚回来吃饭吗？饺子馅都剁好了。”我回了个“看情况”，其实知道肯定不回——当晚还有个紧急 patch 要合并，devOps 组长明天一早要飞深圳，交接文档里漏写了 backup-cron 的时间偏移逻辑，我得补上。

　　反常识结论？我早就信不了“常识”了。以前觉得磁盘空间不够是常态，后来发现是备份脚本把 /tmp 写满了；以前觉得宕机必有单点故障，结果是 DNS TTL 设成一分钟，运营商抖了一下，整个集群开始疯狂解析失败；去年二月份这事之后，我把全部静态站点的 CI 流程里加了一行：openssl s_client -connect $CDN_HOST:443 -showcerts /dev/null | openssl x509 -noout -text | grep "CA Issuers"。跑通了就合入主干，跑不通就钉钉@所有人，不管几点。没人抱怨，因为上个月开发老张自己写了段 Python 检查 CDN 响应头里的 Strict-Transport-Security max-age 值是否低于 31536000，跑挂了三次——他说：“总得有人先把石头摸热。”

　　其实最该补的，是我自己那份本地开发机的 ca-certificates 更新策略。现在还指着 apt upgrade 瞎碰运气。今天下午我就动手，不走自动化，就手动 wget + cp + update-ca-certificates ——先让它活过下一轮 Let’s Encrypt 根迁移再说。这事本来能避免。要是去年二月份那天，我在 dev 机器上多 run 一次 curl -v https://cdn.example.com/js/app.js，要是当时终端里那行 “subjectAltName: DNS:.cdn.example.com” 下面，我多扫一眼 issuer 是不是熟悉的 CN=GlobalSign Root R1，而不是什么 CN=DigiCert Trusted Root G5，估计后面三周都不用喝速溶咖啡灌自己清醒。

　　屏幕上还开着那个微信聊天框，老张又发来一张图：新域名下首页加载瀑布流，TTFB 缩短了 212ms。下面写着：“你看，这次真的快了。”我没回。泡面盒已经凉透，塑料盖子凝了层薄雾。我关掉所有窗口，只留 vim 里一个空文件，光标闪着，等我打第一行注释。

（编辑：站长网）

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