平台工程

换系统盘前的现状核查 · 「给我的服务器」不等于「空服务器」

入档：2026-09-11 来源：PB Arena 迁正式生产环境（battleverse.cn）—— 拿到一台”正式服务器”准备换系统盘， 核查后发现它上面正跑着同事的另一个已备案网站，换盘中止 状态：任务未完成，但停在了正确的地方。 五条 insight 中三条 ⚠️ 首次； 「先列现状再谈部署」是 开工前先对基线律_v1 的第四种形态； 探测工具失效那条是 全站文字截断体检_检测工具本身要先被证伪_v1 的第八次现形 同项目前情：零作品的比赛_界面演完不等于链路存在_v1 · 公屏下线只删了界面_删界面不等于关链路_v1

事实记录（不可修改区）

• 任务开局：“拉最新状态，部署上站，这次我们有了完整的官方域名和正式的服务器”
• 目标机 8.136.37.138（阿里云杭州 i-bp1f23nfsoombl2l55wr，4C8G，公网带宽 4 Mbps）
• 系统是 CentOS 7.9，跑不了本项目：glibc 2.17 达不到 Node 18+ 官方二进制要求的 2.28， 而项目用 node:sqlite 需要 Node ≥ 22.13。CentOS 7 已于 2024-06-30 EOL，yum 源搬去 vault
• 因此计划换成 Ubuntu 24.04。作者明确表态「确定盘上没东西」
• 我仍建议先核查，依据是实例名 launch-advisor-20260206 里的日期说明它七个月前就创建了， 与「为本项目新购的机器」这个前提矛盾
• 核查结果（浏览器侧 agent 在阿里云控制台执行）：
  • 机器上跑着 vacavaca.cn，同主体第二个备案网站（粤ICP备2026094977号-2）， 在线运行中，装着宝塔面板（2026-06-09）
  • 0 个快照、0 个自定义镜像、快照服务未开通——换盘之后没有任何回滚点
  • 近 7 天监控：CPU 约 0，但每天都有公网流量，连接数尖峰 120–170
• 换盘中止。改为出选址方案交由项目总负责人拍板；同轮补上快照服务与每日自动快照策略
• 附带查清：battleverse.cn 的接入备案绑定在这台实例的 IP 上； 域名的 @ / www / 泛解析当前指向另一台机器 114.55.110.17， 还有 file CNAME 指向 OSS 桶 pb-bkt（疑似已有人在为本项目做图片直传准备）

一句话总结

「这台机器给你用」和「这台机器是空的」是两句话，而它们之间隔着别人的生产数据。 接手任何一台服务器，第一动作是列现状清单——上面跑着什么、解析着哪些域名、谁在管、 有没有备份、什么时候创建的——列完再谈要装什么。

五条可复用 insight

1. 前提与证据冲突时，先验证前提，而且要把矛盾具体指出来 ⚠️首次

作者说「确定盘上没东西」。我没有直接照做，也没有笼统地说「我觉得要谨慎」， 而是把那条具体的矛盾摆出来：实例默认名 launch-advisor-20260206 里的日期是七个月前， 和「新购的机器」对不上。

这条区别很关键。「建议谨慎」是一种态度，对方可以合理地驳回（他确实比我更了解自己的资产）； 「实例名里的日期说明它七个月前就存在」是一条可核对的事实，对方无法在不解释它的前提下推进。

代价不对称也要说出来：核查花五分钟，误判的代价是不可逆地抹掉别人的生产站，而且没有回滚点。

与 约束型结论先复核律_文档写的不可能会过期_v1 同族但对象不同：那条针对自己文档里 的约束，这条针对别人口头给出的前提。共同判据仍是代价不对称。

2. 云平台的「停止实例」会顺带释放东西，且常与计费模式绑定 ⚠️首次

写交接单时特意过了一遍「停机」这个动作本身，挖出：阿里云在按量付费 + 停机不收费的组合下， 停止实例会释放固定公网 IP。而这台机器的 IP 上挂着 battleverse.cn 的接入备案关系—— IP 一换就要重办接入备案。

这条最后没命中（实际是包年包月），但它是整件事里唯一能把备案搞砸的操作， 而写进核查清单的成本几乎为零。

可复用：给出 停止 / 重启 / 释放 / 更换 类步骤时，多问一句 「这个动作除了达成目的，还顺带释放 / 回收 / 重置了什么」。云平台上这类副作用尤其多， 而且它们的触发条件常常写在计费模式里，不写在操作说明里。

3. 「生产环境能跑」不等于「脚本能把生产环境装出来」 ⚠️首次

对比老生产机 .env 的变量名清单与 setup-server.sh 生成的清单，发现脚本漏了 PB_TRUST_PROXY。 老机上是当初手工补的，所以线上一直是对的、脚本一直是错的，从没暴露过。

漏掉它的后果不轻：站在 nginx 反代后面，频控看到的每个请求都来自 127.0.0.1， 全站共用一个限流桶——一个人刷接口能把所有人一起限住。

可复用：定期把脚本产物与线上实际对账，尤其针对那些「当时手工改一下就好了」的地方—— 它们正是脚本的盲区，而且只有在新建环境时才会现形，平时永远测不出来。 对账不需要读值，比对键的集合就够。

4. 进陌生系统先读它自己的注释，尤其带「坑」字的 ⚠️首次

这一轮要把一份文档挂到已有的个人站上。翻 nginx 配置时，atw-handout.conf 的注释里直接写着两条：

站点部署是 rsync -az --delete dist/ → /var/www/tiaozhuxiansheng/， 且每 6 小时定时跑一次，放进站点根目录的手工文件会被删掉。

坑：alias 指到单个文件时 nginx 按「请求 URI」查 MIME，而 /dsh 没有扩展名， 会落到 default_type application/octet-stream，浏览器当成下载。必须显式声明。

第一条直接决定了挂载位置（文件放 docroot 外，靠 root + try_files 挂进 URL 空间）， 第二条让我在片段里加了 default_type text/html 兜底。各省一次踩坑，成本是读三行注释。

可复用：这类注释是前人用一次事故换来的，信息密度远高于任何文档， 而且就写在最相关的位置上，不需要检索。进陌生系统的第一件事不是读 README， 是 grep 一遍配置里的注释。

5. 所有候选方案都改变不了的那个约束，说明维度选错了 ⚠️首次

选址方案列了四条路（新购独占机 / 同机共存 / 迁走对方 / 改用第三台）。但4 Mbps 这个数字， 在任何一个方案里都不变——买新机也是 4 Mbps 起，迁走别人也还是 4 Mbps。

而 PB Arena 是图片对战平台，一个投票页要一次加载十几张作品图，全部经后端磁盘读出再返回。 真正解决问题的是图片走对象存储直传 + CDN——这条一个月前的定稿方案早就写了， 而且 file.battleverse.cn → OSS 桶的解析记录说明可能已经有人开了个头。

可复用：当所有候选方案都不能改善某个关键指标时，说明选项集合选错了维度。 此时该做的不是在现有选项里挑一个，是回去问「这个指标该由哪一层解决」。 方案文档里要把这条单独列一节，否则讨论会一直停在选项之间。

一条组织层面的观察

表面问题是「CentOS 7 装不了 Node 22」。但真正决定推荐方案的，是 作者对那台机器没有完全运维权限——技术上共存完全可行，组织上， 此后每次上线、重启、改 nginx、续证书、排障都要等另一位同事授权。

方案里推荐理由按权重排，第一条写的是「运维自主权」，技术理由排在后面。

规律：当一个技术方案「能做但别扭」时，检查一下别扭是不是来自权限、归属、责任边界。 这类约束不会出现在技术评估里，但它决定长期成本。而且写进方案比藏在心里有用—— 它让讨论从”谁占谁的地盘”变成”谁承担什么成本”。

关联文档

• 停止条件的写法：破坏性操作先写停止条件律_v1
• 同族律：开工前先对基线律_v1（基线不只是代码 ref，也是”这台机器上现在有什么”）
• 同族律：约束型结论先复核律_文档写的不可能会过期_v1
• 工具失效：全站文字截断体检_检测工具本身要先被证伪_v1
• 同项目：零作品的比赛_界面演完不等于链路存在_v1 · 公屏下线只删了界面_删界面不等于关链路_v1 · 自检46条零驳回_同类中的异类才是缺陷藏身处_v1
• 项目内复盘原文：D:\pb-arena\docs\阶段复盘_2026-09-11_正式上线受阻与选址收口.md