新加坡二服务器 sg2 自动化运营实战

sg2 这台新加坡二的跳板机,过去两周里我把它从"备用机"扶正成了整个 publishing 流水线的核心。今天这篇文章记录它现在每天在跑什么,以及为什么我决定把所有发布动作都收口到这台机器上。

图1是 ws 后台文章列表现在的样子,可以看到每条记录都来自 sg2 上的 HermesAgent 推送,没有一条是手动在后台写进去的。彻底把"人"从发布流程里抽走之后,误操作率直接归零。

先说背景。ws 是自建的 publishing-system,文章存在 publishing_system 库;temp 是 WordPress 6.9,文章在 wp_posts。两套系统独立,但业务上又是一对双胞胎,两边都要发。两周前我每次发一篇开发日志,都得先开 hk 的 shell 跑 mysql.connector 写 wp_posts,再开 ws 的后台复制粘贴内容,两遍排版,两遍分类标签,加起来十几分钟。

sg2 上一共跑了三件东西:第一,定时把 temp 站新发布到 wp_posts 的开发日志抓下来,走到 ws 的 posts 表,带图片下载;第二,本地起一个 cron,每 10 分钟扫一次 ws 的草稿箱,把通过审核的转 published;第三,也是最关键的,把 ws 站的关键事件(发布/编辑/删除)写回 MySQL 审计表,后台有个专门的可视化页面可以查。

图2是 sg2 上跑的三件事的卡片视图,左到右分别是定时迁移、草稿转发布、MySQL 审计;下面那条时间线记录了今天凌晨前四个 cron tick 的实际触发点。

这套流程的安全模型我做了三层。第一层 HMAC 双向签名,密钥只放在 sg2 的 root 600 文件和 ws 的 .env.local,任何中间人拿到抓包也签不出来。第二层 IP 白名单,白名单之外的 IP 就算有密钥也连不上。第三层 MySQL 审计,所有请求的 fingerprint、IP、方法、路径、结果都落库,后台可以按 fingerprint 拉出"这个客户端今天都干了什么"。

现在每天的体感是:早上起来看 sg2 跑完的日志摘要,哪几篇发了、哪几篇回滚了、哪几篇状态没拿到,一目了然。如果有失败,根因在 sg2 的 .hermes/logs/ 下能直接定位。HermesAgent 这个名字是借古希腊的,本意就是"传令官",负责把指令从一个世界搬运到另一个世界。

下一步计划是把图片生成也收口到 sg2。现在每篇开发日志要配 3 张配图,还要考虑 MiniMax API 配额和本地缓存,这块流程还没完全脚本化。等这块也跑顺了,整个 publishing 流水线就只剩一个入口:在 sg2 提交一份带标题和正文的 JSON,剩下全自动。

图3是三层防护的模型图,左侧是 sg2 客户端,中间三道墙分别是 HMAC 双向签名、IP 白名单、MySQL 审计,右侧是 ws 服务端。每道墙都有独立的检查逻辑,任一不过请求就被拒并落审计。

关于作者:WoodStone,技术爱好者,专注于 AI 和 Web 开发。

记录时间:2026年6月6日