昨天講三個部署踩坑。今天講部署完之後的日常操作。

改環境變數不用重新部署

這是昨天踩坑 1 的修法，也是日常最常用的一條：

gcloud run services update <svc> --region <region> --update-env-vars K=V

第一次發現不用重跑 deploy 的時候我有點意外。Cloud Run 的環境變數改動會產生新的 revision，但不需要重新建置映像，所以快很多。

想清楚原因之後就不意外了。revision 本質上是「同一個容器映像加上一組設定」的組合，改環境變數只是產生一筆新的設定紀錄，指向的還是同一個已經建好的映像。真正耗時的步驟是建置映像本身，那要跑 Cloud Build，把原始碼打包成容器，這一步在只改環境變數的情境下完全不需要重跑。

取得服務 URL

部署完 gcloud 會印出 URL，但那行很容易被淹沒在輸出裡。之後要拿的話：

gcloud run services describe <svc> --region <region> --format='value(status.url)'

這個 URL 就是要填進 orchestrator 那份 remote agent 清單的東西。上雲之後 Agent Card 裡的端點也要改成它，不然 orchestrator 抓得到卡但打不到人。這個坑容易漏掉，部署完就該立刻檢查，不要等呼叫失敗才想起來。

URL 那行容易被淹沒不是意外，是 gcloud run deploy 本身的輸出習慣：建置紀錄、映像 push 紀錄、部署進度全部混在一起，URL 通常夾在最後幾行。如果指令是背景執行，或者終端機的捲動緩衝區不夠長，那行往前捲一下就找不到了。所以比較保險的習慣是不要依賴記憶那行輸出，需要 URL 的時候就跑一次 describe，反正這條指令本身也不慢。

看 log

gcloud logging read 'resource.type="cloud_run_revision" AND resource.labels.service_name="<svc>"' --freshness=20m

--freshness 這個參數很好用，限定時間窗才不會被歷史 log 淹掉。如果沒有這個參數，gcloud logging read 預設抓的時間範圍可能很寬，會把過去所有部署、所有測試的紀錄一起撈出來，量一多，哪些是這次要看的反而更難分辨。

這條指令在後面診斷 Gemini Enterprise 打不通的時候是關鍵證據，因為它能回答一個很硬的問題：對方到底有沒有真的送請求過來？ 零筆就代表問題不在你這端。這個用法比看錯誤訊息可靠得多。錯誤訊息只會在服務端真的收到請求之後才會出現，請求根本沒進來的話，服務端不會留下任何東西可看，只有 log 裡「有沒有這筆紀錄」看得出來。

小結

環境變數、服務 URL、看 log，這三件事都是日常維運會一直用到的基本操作，比讓人印象深刻的踩坑更重要，因為它們決定你多快能發現問題出在哪一端。

明天講服務帳號的權限邊界，以及一件我覺得所有雲端教學都該做但很少做的事：把刪除指令跟建立指令放在同一頁。