將系統 Docker 化並部署至 Cloud Run，整合 CI/CD、監控及 Daily Briefing API，透過壓力測試驗證可用性、吞吐量與成本節省率，完成可操作的端到端 Demo。

讀完能做到：把 30 天原型整理成一份可部署、可觀測、可壓測、可回滾且有人工核准的企業上線驗收清單。

實作狀態：部署指標公式與測試為【本機核心已測試】；Docker、Cloud Run、CI/CD 與壓力測試為【部署設計藍圖】。本文沒有實際建立 Google Cloud 資源，也不宣稱 Gemini Spark 已承受正式流量。

Day 30 不是按下 Deploy

前 29 天完成 Agent、Evidence、評估、安全與狀態機，最後仍可能敗在冷啟動、連線池耗盡、重試風暴或沒有回滾。上線總驗收應回答：系統是否跑得起來、流量來時是否撐得住、失敗時是否看得到，以及新版本能否安全撤回。

Client → Auth／API Gateway → Cloud Run API
                              ├─ Workflow／Checkpoint DB
                              ├─ Queue／Worker
                              ├─ Gemini／Tools
                              └─ Logs／Metrics／Traces
CI → Test → Image Scan → Artifact Registry → Canary → Approval → Traffic

Daily Briefing API 建立 Task 後應回傳 202 + task_id，長任務交給 Queue／Worker，不讓 HTTP 連線一直等待。Checkpoint 放持久化資料庫，Cloud Run instance 則視為可隨時被替換的運算單元。

容器與 Cloud Run 契約

容器須從 PORT 監聽、以非 root 使用者執行，設定 CPU／Memory、timeout、concurrency 及 graceful shutdown。秘密放 Secret Manager，不寫進 Image 或環境範例。

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER 10001
CMD ["sh", "-c", "uvicorn api:app --host 0.0.0.0 --port ${PORT:-8080}"]

Cloud Run 能依請求、事件或 CPU 使用率擴縮 instance；最小 instance 可降低冷啟動，最大 instance 可限制成本並保護下游，但設得太低會讓請求排隊[1]。Concurrency 必須用壓測決定，不能直接抄別人的數字。

Startup probe 判斷服務是否可接流量，liveness probe 判斷是否應重啟；探針只檢查必要依賴，不能每次都呼叫模型。Cloud Run 提供健康檢查設定[2]，正式環境仍要設計降級模式，例如模型暫時不可用時保留 Task 而不是丟失請求。

CI/CD 要有四道閘門

第一道跑單元、Schema、Golden Dataset 與紅隊測試；第二道掃描映像與依賴；第三道部署新 Revision 並跑 smoke test；第四道以少量流量 Canary，比對錯誤率、P95、任務品質與成本後等待負責人核准。Cloud Run 可透過 Cloud Build 或 Developer Connect 從 Git 建立持續部署[3]。

資料庫 migration、Prompt、模型與 Schema 都要能回滾或保持向後相容。回滾 Image 卻沿用不相容的新狀態，仍會失敗。

壓力測試不是只看 RPS

測試情境至少包括穩定流量、尖峰、冷啟動、模型 429／5xx、慢工具、重試風暴、人工核准堆積及併發取消。觀測指標包含 API 可用率、吞吐量、P50／P95／P99、任務成功率、Queue Depth、Token、成本與人工介入率。

本機虛構資料為 1,000 個請求、995 成功、20 秒完成，得到可用率 99.5%、吞吐量 50 RPS；成本由基準 100 降至 72，節省率 28%。這只驗證公式，不是 Cloud Run 壓測結果。真正驗收必須附測試工具、區域、併發、Payload、下游配額與原始報告。

Cloud Run 會自動整合 Cloud Monitoring，能查看效能指標、Uptime Check 與告警[4]。此外還要加入 Agent 自訂指標，例如 Evidence 覆蓋率、回歸失敗、審批等待時間與重複副作用數。

最終人工 Go／No-Go

若品質、安全、可用率、P95、成本或恢復測試任一未達門檻，就不切全量流量。Go／No-Go 記錄核准人、Revision、測試報告、已知風險、回滾指令與觀察期限；模型不能替團隊接受殘餘風險。

本機共用指標與測試：

python outputs/day25_30_metrics.py
python -m unittest work/test_day25_30_metrics.py -v

小摘要

完成 Demo 只是起點。企業級 AI 虛擬員工要同時通過容器契約、狀態持久化、CI/CD、紅隊、壓測、監控與人工上線核准，才能把「會回答」變成「可營運」。

三個讀者重要帶回重點

1. Cloud Run instance 是可替換的，Task、Checkpoint 與 Approval 必須持久化。
2. 壓測要涵蓋下游故障與重試風暴，不能只展示單一 RPS 數字。
3. 最終上線是有測試報告與回滾方案的人工 Go／No-Go，不是 Agent 自動決定。

參考資料

[1] Google Cloud：Cloud Run autoscaling

[2] Google Cloud：Configure health checks

[3] Google Cloud：Continuous deployment

[4] Google Cloud：Monitor health and performance