凌晨两点的报警，逼我把17个镜像站塞进了一个网页

凌晨两点十七分，手机震了。不是女朋友，是监控。主站 502，三个镜像节点两个超时，还有一个在跑三天前的旧数据。我迷迷糊糊点开四台服务器的远程桌面，一台一台看进程、翻日志、手动切 DNS。等用户骂到第十条，我才把流量导到备用节点。那天之后我算了一笔账：管 17 个镜像站，平均每次故障我要摸 6 台机器，浪费 40 分钟。于是我花了一个周末，做了个镜像站群网页版。

为什么要做网页版

所谓镜像站群网页版，说白了就是把分散在各台服务器上的镜像站点，收进一个浏览器面板里。你不用再记每台机器的 IP、账号、证书路径，打开网页就能看到哪个节点活着、哪个同步延迟、哪个证书快过期。听起来像监控面板，但监控只告诉你“出事了”，网页版还能让你直接操作：一键把某个节点下线、把同步任务重跑、批量更新内容、查看 diff。我那个面板里，每个节点旁边有三个按钮：强制同步、拉取状态、切流量。点一下，后端就通过 SSH 或者 API 去执行对应脚本，不用我登服务器。

它和监控面板的区别

有人问我，这不就是 Grafana 加几个报警吗？差别在“动手”这一步。监控面板是看，操作还得去别的地方。镜像站群网页版把“看”和“动”放在同一个界面里。比如节点变红，你鼠标移上去能看到最近一次同步时间、错误日志摘要，旁边就是“重试同步”“摘除节点”“回滚版本”三个按钮。这在半夜特别关键——你不需要清醒到能敲命令，只需要点一下。

实现思路：轻量就够了

做这个东西没想象中复杂。前端就一个单页，后端用 Python 写的，定时任务每分钟去探测各节点 HTTP 状态码和响应时间，WebSocket 推给前端。同步用 rsync 或者对象存储的 mirror 规则，面板只做触发和记录。没有上 K8s，也没用微服务，总共不到 800 行代码，跑在一台 1 核 2G 的小机器上。数据库用 SQLite，存操作日志和节点状态，定期清理。最关键的是，所有危险操作都加了二次确认，避免手滑把主站摘了。

踩过的几个坑

同步不是越快越好。最早我设了每分钟同步，结果两个节点同时写数据库，主键冲突，数据乱了好几天。后来改成主站单向推，镜像只读，冲突少了一大半。别把所有节点都做成可写，镜像是用来扛读的，写入只留主站和一个热备。

安全上也得注意。面板必须加二次验证，SSH 密钥不要放前端，操作日志要全。我一度图省事把密钥塞进前端配置里，被同事骂了一顿，说这等于把家门钥匙挂在门口。

还有 SEO 的坑。如果是公开站点，记得给镜像加 canonical 指向主站，不然搜索引擎会判定重复内容。我一开始没加，流量跌了 20%，后来用 rel=alternate 和 hreflang 才慢慢拉回来。镜像站群网页版里也应该有个一键检查 canonical 的功能，省得手动挨个看。

有了它之后

有一次机房 A 断网，面板上三个节点变红，我点了一下“切换默认入口”，把 CDN 回源改到机房 B，前后不到一分钟。如果没有网页版，我得登 CDN 控制台、改配置、等生效。那种感觉就像家里所有灯都装了双控开关，躺在沙发上就能关灯。

说到底，镜像站群网页版不是一个炫技的东西，它就是给那些被多节点运维折腾到半夜的人准备的。你可以把它做得很简单，也可以加很多自动化策略，比如自动剔除超时节点、自动补同步。但最大的价值是让你在半夜被报警吵醒时，只需要打开一个网页，而不是四台远程桌面。

那晚之后，我手机里多了个书签。再收到报警，我点开它，看一圈红绿，点一下按钮，继续睡觉。这可能就是运维人的小确幸。