基础设施升级：告别 Cron Pull，全面转向 GitHub Actions 推送部署
在运维博客这件事上，我一直信奉一个原则：能自动化的绝不手动，能 Push 的绝不 Pull。
最近我对 TAOBLOG 和 Hugo 博客的部署流水线进行了一次底层逻辑的重构。核心目标只有一个：提高可用性，降低故障恢复成本。
TAOBLOG：从「服务端拉取」 -> 「构建端推送」
之前的 TAOBLOG 部署逻辑比较「原始」：
本地写作 -> Push 到 GitHub -> VPS 定时任务 (每分钟一次) -> Pull 仓库 -> 本地编译 -> 部署到静态文件夹。
这种模式的痛点太明显了：
一旦 VPS 挂掉或者环境配置出问题，重新部署简直是噩梦。而且每分钟拉取一次不仅浪费资源，还存在一定的同步延迟。
现在的全新逻辑：
本地写作 -> Push 到 GitHub -> GitHub Action (统一编译生产静态文件) -> 通过 SSH 将成品同步到多台 VPS。
现在，GitHub Action 在构建完成后，会直接登录 VPS 将静态文件同步到网页文件夹中。这意味着我实现了多机同步部署，目前覆盖了：
- 甲骨文服务器 (
boshi.886423.xyz) - CT8 免费服务器 (
tao.ct8.pl)
这种「构建一次，分发多处」的模式，让我在面对单台服务器故障时具备了极强的容灾能力，恢复时间从「小时级」缩短到了「分钟级」。
Hugo 博客：部署矩阵扩容
对于 Hugo 博客，我进一步扩展了部署的目标阵列。在原有的 Action 工作流中，新增了对 server00 服务器的部署支持。
目前 Hugo 博客的新阵地：
- server00 节点 ->
hugo.886423.xyz
Bosh 的总结
这次升级本质上是将部署权重从服务端转移到了 CI/CD 端。
- 旧模式 (Pull)：VPS 是大脑，负责感知变化、构建和部署。一旦大脑宕机，全线崩溃。
- 新模式 (Push)：GitHub Action 是大脑，VPS 变成了纯粹的「静态资源承载端」。
这种解耦让我的基础设施变得异常轻量。不管后端服务器怎么换，只要 .github/workflows 里的配置在，我的博客就能在几秒钟内复活在任何一台新服务器上。
Stay automated. 💻