Gemini Cloud Assist 給架構師：先提方案，再找證據

課程概述

架構師真正難的工作，不是背出最多服務名稱，而是在需求不完整、限制互相衝突時，提出幾個做得到的方案，說清楚取捨，再留下能被驗證和回顧的決策。

現行 Cloud Console 與設計工作流裡的產品名稱是 Gemini Cloud Assist。它能協助設計、部署、疑難排解和最佳化，也能在 App Design Center 或 Chat 裡草擬 Google Cloud CLI、kubectl、Terraform 和組織政策。不過目前官方仍把 Gemini Cloud Assist 整體標示為 Preview；所有建議、工具動作和生成設定都要由人確認。

你將學到

• 把事實、需求、硬限制、偏好和未知分開寫
• 要求 Gemini 提出多個候選方案，而不是替你宣布唯一答案
• 用官方文件、實際設定、Quota、監控和價格驗證關鍵主張
• 將自然語言設計轉成可 Review 的 IaC Plan 與政策模擬
• 寫下 ADR、驗收指標、回滾條件和上線後的觀測責任

先提供問題框架，不要先指定解法

與其問「幫我設計一個微服務架構」，更實用的 Prompt 是：

我們有一個 PostgreSQL-backed monolith，平日每秒 20 個請求、活動尖峰 10 倍。RTO 30 分鐘、RPO 5 分鐘，三人團隊，不能在三個月內重寫核心交易。請先列出未知，再提出「維持模組化單體」和「逐步拆服務」至少兩個方案；比較可靠性、成本、維運負擔與遷移風險，不要先產生 Terraform。

內容可分成五類：

• 已知事實：目前拓撲、流量、資料量、事故和帳單
• 成功條件：SLO、RTO／RPO、交付期限和合規目標
• 硬限制：地區、資料邊界、技能、停機窗口和預算上限
• 偏好：受管服務優先、標準化語言或既有平台
• 未知：還沒量過或需要其他團隊回答的問題

Gemini 若把未知直接補成數字，請把它標回假設，不要讓順口的敘述悄悄變成架構前提。

用六個面向比較候選方案

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

不要把常見服務組合寫成「Gemini 推薦模式」。例如 Cloud Run、GKE 或 Compute Engine 都可能適合 Web 工作負載，差別在控制需求、團隊能力、流量形態和依賴，而不是哪個服務看起來更新。

Gemini Cloud Assist 可以幫忙產生 IaC，但核准前要看 Plan

在 App Design Center 或 Chat 裡，可以逐步產生或調整 Terraform、Google Cloud CLI、kubectl Manifest 和組織政策；想在 Antigravity、Gemini CLI 這類工具裡用，要透過 MCP 接上 Gemini Cloud Assist，這條路目前是 Private Preview，要向 Google Cloud Account team 申請。這類輸出至少要經過：

1. 鎖定 Provider、Module、Container 與 API 版本
2. terraform fmt、validate、Plan、政策與安全掃描
3. 檢查 IAM、網路暴露、Encryption、Deletion protection 和 Logging
4. 用 Test Project 或小範圍環境驗證 Quota、Region 和相容性
5. 顯示實際 Diff，由有權 Reviewer 核准後才部署

工具能執行動作時，更要確認它使用的是你的身分還是專用 Agent Identity、取得哪些權限，以及每次變更是否留下完整 Audit trail。

Active Assist 是另一份證據，不是自動變更單

Active Assist 會彙整成本、安全、效能、可靠性、管理和永續建議。Gemini 可以協助解釋，但建議的影響要由了解系統的人審查；官方也明確提醒，直接套用可能造成效能、可靠性或權限問題。

例如 VM Rightsizing 要先確認 CPU 低是不是因為記憶體、I/O、尖峰或災難復原保留；CUD 要看可預測基線和合約風險；閒置 IP、Disk 或 VM 也要確認沒有 DNS、DR 或臨時環境依賴。

ADR 要留下「為什麼」，不只貼聊天內容

一份可用的 Architecture Decision Record 至少包含：

• 問題、上下文、成功條件與限制
• 評估過的選項和沒有採用的原因
• 採用方案、關鍵假設和證據連結
• 安全、成本、可靠性與維運影響
• 驗收指標、Owner、回顧日期和退出／回滾條件

Gemini 對話可以當草稿來源，不能取代決策記錄。文件應連到當時的 Pricing、Quota、Terraform Plan、Diagram 和評估資料，避免幾個月後只剩一句「AI 建議用這個」。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 20, "rankSpacing": 28, "wrappingWidth": 600}}}%%
flowchart TB
  subgraph FRAME_STAGE["1. 先定義問題"]
      direction LR
      FACT["整理現況事實、SLO<br/>限制、偏好與未知"] --> OPTIONS["請 Gemini 提至少兩個方案<br/>列出假設、取捨與故障模式"]
      OPTIONS --> CLAIM["把關鍵主張拆成<br/>可查證的問題清單"]
  end
  CLAIM --> EVIDENCE
  subgraph VERIFY_STAGE["2. 用環境證據驗證"]
      direction LR
      EVIDENCE["查官方文件、Region、SLA<br/>Quota、價格與實際設定"] --> TEST["用 PoC、Load test、Plan<br/>政策模擬與故障演練驗證"]
      TEST --> GATE{"安全、可靠性、成本<br/>和維運門檻都能接受嗎？"}
      GATE -->|"否"| REJECT["淘汰方案或補證據<br/>不要用文字合理化風險"]
  end
  GATE -->|"是"| ADR
  subgraph DECIDE_STAGE["3. 記錄、核准與小步部署"]
      direction LR
      ADR["寫 ADR、IaC、Runbook<br/>驗收與回滾條件"] --> REVIEW["由架構、安全、平台<br/>和服務 Owner 核准"]
      REVIEW --> SHIP["小範圍部署並觀測<br/>用實際結果回顧決策"]
  end

實作重點

• Prompt 先要求列出未知和假設，再產生服務組合，降低一開始就鎖死解法的風險
• 產品名稱、Region、Preview／GA、SLA、Quota 和價格都要查當下文件
• IaC 輸出固定版本，先 Plan／Diff／Policy check，不讓聊天直接改 Production
• Active Assist 建議要確認觀測窗口、影響資源與回滾方式，不自動全數套用
• 成本比較包含 Egress、Logging、Backup、Support 與人力，不只比較 Compute 單價
• 上線後用 SLO、成本與事故資料回顧 ADR；假設失效時要能重新決策

Lab 指引

Lab 連結：Gemini for Cloud Architects — Google Skills

依課程頁，這門課有三段影片、一個測驗和一個 Lab「Provision Cloud Infrastructure with Gemini」，Lab 說明寫的是用 Gemini 了解部署與維護受管 Kubernetes 叢集的各個環節。做 Lab 時每得到一個建議，就替它補一個「我要去哪裡驗證」欄位，至少查 Region、Quota、SLA 與 Pricing；做完後可以自己延伸，把其中一個建議轉成 Terraform Plan。這樣練到的是架構決策，不只是和 Chat 對話。

延伸學習

• GCP PCA：架構框架 — 用一致框架比較方案取捨
• GCP PCA：運算服務選型 — 比較 GCE、GKE、Cloud Run 和 App Engine
• Gemini 輔助網路工程師 — 把證據導向方法套到封包路徑
• Gemini Cloud Assist 官方概觀 — 確認目前功能、權限與 Preview 限制
• Active Assist 建議 — 查閱建議影響、審查與套用方式