個人接案者的最小可行 SRE：用 GitHub + Cloudflare 自動化的發布流
不是每個專案都需要完整的 GitOps + Kubernetes。對個人 SRE 接案來說，「能跑、能版控、能回滾」三件事就夠。本文整理我自己在用的最小工作流。
- #DevOps
- #SRE
- #CI/CD
- #GitHub Actions
- #Cloudflare
「最小可行」不是「能用就好」，而是「砍掉所有可砍的、剩下的都是必須」。
我幫客戶做維運諮詢時最常被問：「我們公司想做 DevOps，是不是要先導 Kubernetes 加 ArgoCD 加 Prometheus？」。我的答案幾乎都是反問：「你們現在連自動部署都還沒有嗎？」。
對個人接案、小團隊、未上市規模的客戶，導 Kubernetes 是用大砲打小鳥。本文整理我自己在 elongma.tech 與幾個客戶專案上實際跑的最小工作流，三個元件、零基礎設施成本。
元件一：GitHub 作為 SoT（Source of Truth）
不只是程式碼放 GitHub，所有可程式化的東西都進 GitHub：
- 程式碼
- 基礎設施配置（Terraform / Pulumi 或本文後述的 wrangler 配置）
- CI/CD 設定（
.github/workflows/） - 規格文件（OpenSpec change 也是 git-managed）
- 部署 secret（用 GitHub Encrypted Secrets，不要塞 env file）
唯一不進 git 的是：客戶的真實憑證、生產資料。這兩樣放進 GitHub 等於資安事故等著發生。
元件二：Cloudflare 作為部署 / 邊緣 / DNS / SSL 一條龍
CF 在 2024 後越來越像「邊緣作業系統」：
| 需求 | CF 對應產品 | 月費 |
|---|---|---|
| 靜態網站 | Pages | $0 |
| API / SSR | Workers | $0 起 |
| DB | D1 | $0 起 |
| KV / Cache | KV / Cache API | $0 起 |
| 物件儲存 | R2 | $0 起（無 egress 費） |
| DNS / SSL | DNS / Universal SSL | $0 |
| WAF / DDoS | 內建 | $0 |
| Email Routing | Email Routing | $0 |
對個人接案規模，全部在 free tier 跑得下去。最重要的是「沒有要管的伺服器」這件事 — 沒有 OS patch、沒有 SSH 密鑰要輪換、沒有防火牆規則要寫。
元件三：GitHub Actions 不一定要寫
很多人以為「自動化 = 寫 GitHub Actions YAML」。但 CF Pages 的 Git 整合已經內建了 push → build → deploy 的工作流，連 YAML 都不用寫：
- 在 CF dashboard 連 GitHub repo
- 設 build command（如
pnpm build） - 設 build output directory（如
dist） - 完成
每次 git push 到 main 就自動部署。每個 PR 自動產出 preview URL。這就是工作流。
什麼時候才寫 GitHub Actions？
- Build 前需要外部資源（如從 Notion 拉內容、從 CMS 同步資料）
- CI 需要跑測試或 lint（Astro check、ESLint、Vitest）
- 多階段部署（dev → staging → prod，且 staging 在不同 CF 帳號）
- schedule 自動化（每天凌晨 rebuild）
對只是「程式碼推上去 → 網站更新」的場景，CF Pages 的 Git 整合就夠。少寫一份 YAML 就少一個出錯的點。
回滾機制：CF Pages Deployments 比你想的好
意外把錯版本推上去，不需要 git revert 再 push 等 build 跑完。CF Pages 的 Deployments 頁面可以直接 rollback 到任何歷史版本，秒級切換流量。
這個是很多人沒注意但生產級 SRE 的關鍵能力：把「回滾」從「需要工程介入」降為「dashboard 點兩下」。客戶在凌晨網站爆了，你能 30 秒搞定的價值遠超過月費。
監控：Cloudflare Web Analytics + UptimeRobot
最小工作流的監控也最小：
- Cloudflare Web Analytics：免費、無 cookie、無需 GA。流量、Core Web Vitals 都看得到。
- UptimeRobot 免費版：5 分鐘探測一次，網站掛了會 email / Telegram 通知。
- CF Pages 內建 build 失敗通知：build error 自動發 email。
不需要 Datadog、不需要 New Relic、不需要自架 Prometheus。當網站本身只有一個前端 + 邊緣資源時，這三件套夠了。
什麼情況下這個最小工作流會失效？
老實說：
- 客戶有 SSR / 動態 backend：要導 Workers 或外接 API，工作流複雜度升一級
- 多人協作 + 強制 review：要加 GitHub branch protection + required checks
- 合規要求（SOC 2 / ISO 27001）：需要審計日誌、變更紀錄、權限控管，CF 的 audit log 要付費
- 預算不是問題：那就上完整 IaC 與 GitOps，沒人攔你
結語
DevOps 不是工具堆疊比賽。對個人接案與小團隊客戶，「能跑、能版控、能回滾」是最該優先的三件事，其餘都是後話。我目前的客戶有用這套工作流跑 1-2 年的，零 incident、零基礎設施帳單。
如果你想了解這套工作流如何套用到你的專案，歡迎聯絡諮詢。