開發團隊諮詢

架構師作為顧問的角色

對於 Professional Cloud Architect 來說，成功不僅僅是繪製架構圖；更在於使開發團隊能夠安全地建構與部署。您的角色是彌合業務需求、基礎設施能力與開發者工作流程之間的鴻溝。

有效的諮詢角色專注於標準化、自動化以及消除摩擦。

白話文解釋（Plain English Explanation）

把諮詢角色對應到大家熟悉的關係，會比較直觀。

比喻 1 — 顧問醫生 vs. 主治醫生（Architect as Consulting Physician）

Cloud Architect 是會診的專科醫師，不是主治醫師。開發團隊擁有病人（也就是服務），他們開立處方並負責日常診療。您診斷的是深層的架構性疾病（例如選用 Cloud SQL 無法擴展到 64 TB 以上、Pub/Sub topic 的訊息順序設定錯誤），建議治療方案（遷移到 Spanner、啟用 message ordering keys），然後把病歷交還給主治。如果您每次 commit 都跟著巡房，您就會變成瓶頸。好的架構師每個 sprint 巡房一次，透過設計審查會議 (design review meeting) 完成，接著就信任團隊依照已記錄的 ADR 自行執行。

比喻 2 — 烹飪導師 vs. 廚師（Culinary Mentor for Developers）

想像一位米其林訓練的主廚指導 line cook。您不會把每一道菜都先煮好；您教的是刀工技術（GCP IAM 模式）、前置備料 mise en place（Terraform 模組、Artifact Registry 維護）以及擺盤標準（SLO 定義、結構化日誌規範）。當廚師想用 sauté pan 油炸（在 Compute Engine VM 上跑 Postgres 而非用 Cloud SQL），您糾正一次技術，記錄標準食譜（一個 golden-path Terraform 模組），然後讓他們自己烹煮接下來的 100 個服務。您的廚房能規模化，是因為您教的是技術，而不是因為您站在每個工作台。

比喻 3 — 教練 vs. 球員（Coach on the Sideline）

教練從來不自己進球得分。您站在 sprint planning 的邊線，看團隊比賽（讀 PR、觀察 Cloud Monitoring 儀表板），當模式開始劣化時喊暫停（例如一個微服務的 Pub/Sub 訂閱數超過三個，通常代表它該被拆分了）。您主持賽後影帶檢討 — 也就是 Cloud Run 冷啟動事故之後的無責難事後檢討 (postmortem)。您的價值體現在團隊的 DORA 分數（部署頻率、變更失敗率），而不是您親自寫了多少行 YAML。

提供雲端原生設計建議

當團隊從地端搬遷到 Google Cloud 時，他們通常會嘗試帶著「舊包袱」。您的建議應該引導他們轉向雲端原生 (Cloud-Native) 原則。

1. 無狀態化 (Statelessness): 鼓勵團隊將連線階段 (session) 資料存放在 Memorystore (Redis) 或 Firestore，而非記憶體內。這有助於實現無縫的自動擴充。
2. 不可變性 (Immutability): 建議使用容器 (GKE/Cloud Run) 而非長期運行的 VM。如果伺服器損壞，不要修復它 — 直接更換它。
3. 鬆散耦合 (Loose Coupling): 使用 Pub/Sub 解耦服務。如果服務 A 失敗，服務 B 應該完全不受影響。

開發諮詢的白話比喻

比喻 1 — 主廚與食譜 (標準化)

開發者就像 主廚。他們想要發揮創意。身為架構師，您提供標準食譜書和廚房佈局。您不會告訴他們如何煎牛排，但您要確保每個人都使用相同類型的爐灶 (GKE) 和相同的量杯 (CI/CD pipeline)。這確保了如果一位廚師離職，另一位可以接手而不會讓食物味道變樣。

比喻 2 — 機場控制塔 (CI/CD)

沒有 CI/CD 的開發就像飛行員隨時隨地降落飛機。身為架構師，您建造了控制塔。您定義跑道 (部署環境) 和降落協定 (自動化測試)。開發者 (飛行員) 專注於飛行，因為知道控制塔會防止他們與其他飛機相撞。

比喻 3 — 房屋檢驗 (安全性審核)

提供安全性建議就像擔任房屋檢驗員。您不蓋房子，但您檢查電線 (IAM 角色) 和門鎖 (加密金鑰)。您告訴屋主 (開發者)：「您忘了關前門 (公開的 Cloud Storage bucket)」，並幫助他們在小偷 (駭客) 到來之前修好它。

諮詢的關鍵領域

1. 「12-Factor」應用程式

建議團隊遵循 12-factor 方法論，特別是：

• Config (組態): 將組態存放在環境變數中 (Secret Manager)，而非寫死在程式碼裡。
• Backing Services (後端服務): 將資料庫與佇列視為外掛資源。
• Disposability (易處理性): 快速啟動與優雅關閉，以利擴充。

2. CI/CD 整合

協助團隊從手動部署轉向自動化 pipeline。

• Artifact Registry: 集中化、經過掃描的容器映像檔。
• Cloud Build: 隨團隊一起擴展的 serverless CI。
• Cloud Deploy: 適用於 GKE 與 Cloud Run 的代管 CD，具備內建回滾功能。

3. 可觀測性 (SRE)

建議團隊應該量測什麼。

• 不要全部都記錄: 只記錄可採取行動的錯誤。
• 分散式追蹤: 使用 Cloud Trace 找出微服務中的瓶頸。
• 自訂指標: 鼓勵團隊將與業務相關的指標 (例如「每分鐘處理的訂單數」) 匯出到 Cloud Monitoring。

管理技術債

身為顧問，您必須協助團隊在「速度」與「品質」之間取得平衡。

• 辨識「捷徑」: 如果團隊使用手動的權宜方法，請確保它被記錄為帶有「償還日期」的技術債。
• 重構: 在每個 sprint 分配 20% 的時間用於「架構健康度」 — 改進程式碼、更新函式庫，或優化成本。

架構師見解： 專注於開發者體驗 (DevEx)。如果您的治理與安全政策太難遵循，開發者會想辦法繞過它們。讓「正確的方法」成為「最簡單的方法」。 ::

GCP 決策的 RFC 與 ADR 流程

Request for Comments (RFC) 在決策定案之前捕捉提案；Architecture Decision Record (ADR) 則在達成共識之後捕捉結果。在 GCP 團隊中，兩者都與受其治理的 Terraform 程式碼放在同一個 Git repository 裡（例如 /docs/adr/0042-choose-spanner-over-cloudsql.md）。

適用於 PCA 風格決策的 ADR 結構

最精簡的 ADR 包含五個段落：

1. Context（情境） — 業務與技術上的限制條件（例如「5 region active-active 寫入可用性、RPO ≤ 1 秒」）。
2. Decision（決策） — 選定的服務（例如「Spanner 多 region nam-eur-asia1 設定」）。
3. Alternatives Considered（評估過的替代方案） — Cloud SQL HA + read replica、AlloyDB、在 GKE 上自管 CockroachDB。
4. Consequences（後果） — 成本差異（Spanner 每節點約為 Cloud SQL 的 4–6 倍）、interleaved-table schema 的限制、遷移工具 (HarbourBridge)。
5. Status（狀態） — Proposed / Accepted / Superseded by ADR-####。

GCP 上的 RFC 工作流程

• 作者開一個 PR 新增 /docs/rfc/NNNN-title.md。
• 審查者（架構師 + senior engineer + SRE）在 5–10 個工作天內留下行內評論。
• 一旦合併，建立一份 ADR 摘要這次決策。實作它的那個 Terraform PR 必須在 commit message 中連結到該 ADR ID — 這會建立一條永久的稽核軌跡，在 Cloud Audit Logs 調查時非常有用。

GCP 程式碼基底上的程式碼審查文化

程式碼審查是落實架構標準最便宜的地方。身為顧問，您塑造的是審查者該看什麼，而不是要不要審查。

在 GCP Pull Request 中該標記什麼

• IAM 漂移 — Terraform 裡任何 roles/owner、roles/editor 或 allUsers 綁定都必須附上書面的正當理由。
• 寫死的 project ID — 必須來自 Terraform 變數或 Workload Identity 注入的環境變數，永遠不要用字串串接。
• 缺漏的 label — 每一個會計費的資源（google_compute_instance、google_storage_bucket、google_bigquery_dataset）都需要 cost-center、env、owner 這幾個 label，給 Billing export 查詢使用。
• 未限定範圍的 service account — 給 Cloud Run 使用的 service account 不應同時給 Compute Engine VM 使用；一個 workload、一個 identity。
• Dataflow / BigQuery SQL — 標記出分區表上的 SELECT *；要求加上 _PARTITIONTIME 過濾條件。

審查 SLA

常見的顧問標準：第一輪審查 4 個工作小時內、完整審查 1 個工作天內。Cloud Build 可以在 PR 超過 SLA 仍未關閉時，透過 Pub/Sub 觸發器發送 Slack 提醒。緩慢的審查會悄悄地拖垮 DORA 的 Lead Time for Changes。

技術指導 (Mentoring) 模式

當您教的是模式而不是解答時，指導才能規模化。

GCP 上的「三層式」指導模型

1. 第一層 — 服務選擇。 導師帶領走過決策樹：「無狀態 HTTP？Cloud Run。長時間執行的非同步？GKE。Cron？Cloud Scheduler + Cloud Run jobs。」
2. 第二層 — 營運姿態。 SLO、Cloud Monitoring 告警政策、error-budget burn alert，以及 PagerDuty / Cloud Ops 中的 on-call 輪值。
3. 第三層 — 成本衛生。 BigQuery slot 預留 vs on-demand、committed-use discount (CUD)、Cloud Storage 生命週期規則。

Office-Hours 模式

每週舉辦 GCP Office Hours — 一個 60 分鐘的開放議程，任何工程師都可以帶設計問題來。把決策記錄在一份共享文件中，並把重複出現的問題升級到 ADR backlog 或內部 Tech Radar。

GCP Workload 上的結對程式設計

在雲端原生程式碼上進行結對，與單體式應用結對不同：一半的工作發生在 GCP Console、gcloud 或 Terraform plan 輸出上，而不是編輯器裡。

有效的 GCP 結對設定

• 共用的 Cloud Shell session — 兩位工程師看到相同的 gcloud config 與專案情境。避免因 ADC credential 不一致而出現「在我電腦上是好的」。
• Cloud Workstations — 一個已預先設定好的代管開發容器，內含正確版本的 Terraform、gcloud 與 kubectl。每次結對省下 20 分鐘的環境設定。
• 即時 terraform plan 審查 — plan 輸出才是您要結對審視的成品，而不是只看 .tf 檔案。讀 plan 才能學到 GCP 實際會做什麼。
• Driver / Navigator 輪換 — 每 25 分鐘換手。Navigator 在整合測試期間於第二個分頁觀察 Cloud Logging。

何時結對才是正確的工具

• 帶新工程師熟悉 GKE cluster 的網路政策模型。
• 偵錯 Cloud Run 冷啟動的回歸問題，且失敗模式不明顯時。
• 在發送第一則訊息之前設計新的 Pub/Sub topic schema — 在這裡結對，可以避免日後 schema 演進的痛苦。

知識轉移給團隊

只存在架構師腦中的知識是單點故障 (SPOF)。把文件視為與程式碼同等重要的交付物。

撐得過人員流動的 KT 產物

• Runbook 與服務的程式碼放在同一個 repo。一個 Cloud Run 服務的 runbook 應涵蓋：如何讀取日誌、如何透過 gcloud run services update-traffic 回滾、哪個 SLO 違反時呼叫誰。
• 以程式碼形式撰寫的架構圖 — 使用 d2lang 或 Mermaid 並 check-in 到 Git。可以在 PR 中審查，可以做時間軸的 diff。
• 錄製的設計審查 — 存到私有 Cloud Storage bucket，套用 1 年的生命週期。透過 Speech-to-Text + BigQuery 取得可搜尋的逐字稿。
• 「新人入職」清單 — 一份字面意義上的檢查清單（組織層級的 IAM 權限、repo 存取、gcloud auth login、VPN、on-call 輪值加入），讓新工程師能在 3 天內進入產能狀態。

應該拒絕的 KT 反模式

「你有問題就在 Slack 找我吧。」Slack 不是知識轉移；它是知識稅。逼架構師把答案寫一次、放上連結，並拒絕在私訊裡重複回答。

GCP 服務的 Tech Radar

Tech Radar（由 ThoughtWorks 推廣）是一份每季更新的活文件，把技術分成四個環：Adopt（採用） / Trial（試行） / Assess（評估） / Hold（保留）。

GCP Tech Radar 範例條目

• Adopt： Cloud Run、Artifact Registry、Cloud Logging、Workload Identity Federation、BigQuery on-demand。
• Trial： AlloyDB for PostgreSQL、Vertex AI Agent Builder、Cloud Run jobs、GKE Autopilot。
• Assess： Spanner Graph、Cloud Workstations、Dataform。
• Hold： Deployment Manager（已淘汰，請改用 Terraform / Config Connector）、舊版 App Engine Standard runtime（Python 2.7、Go 1.11）、Cloud SQL Proxy v1（請改用 v2）。

如何維護

每季更新一次，匯整架構師、SRE 與資安的意見。每個條目附上一段理由，並連結到對應的 ADR。發佈在內部 wiki 上，並從每個新 repository 的 README 連結過去，讓團隊在隨手抓一個服務之前，先參考 radar。

技術債登錄簿

沒被追蹤的技術債會在看不見的地方複利累積。技術債登錄簿 (Tech Debt Registry) 是架構師的儀表板。

登錄簿綱要（用 BigQuery 表格就很夠）

把登錄簿做成 Looker Studio 儀表板，讓工程主管能看到趨勢（各類別技術債數量隨時間的變化）。讓新增條目的成本越低越好 — 一個 Slack slash command 打到 Cloud Functions endpoint，把一列寫入即可。

償還資金

每個 sprint 預留固定比例（原本的 ProTip 建議 20%）給登錄簿項目。沒有這條規則，急件總是會把償還工作擠掉。

架構師的績效考核

那麼，您要如何評估架構師本人？不是用 Terraform 行數。

架構師專屬的 KPI

• 被指導團隊的 DORA 分數 — 部署頻率、lead time、變更失敗率、MTTR — 由 Cloud Build、Cloud Deploy、Cloud Logging 匯出。
• ADR 產出量與品質 — 每季被接受的 ADR 數量，加上同儕對「評估過的替代方案」段落的評分。
• 新人入職時間 — 在架構師設計的服務上，新人的 time-to-onboarding。
• 節省成本的歸因 — 把 Billing export 的成本異常解決連結到架構變更（例如「把 8 個批次工作從 GKE 搬到 Cloud Run jobs，每月省 4,200 美元」）。
• 被指導者的晉升 — 被該架構師正式指導的工程師之晉升與職涵擴展。

應避免的反 KPI

不要用撰寫的程式碼量、合併的 PR 數、參加的會議數來評估架構師。這些都會獎勵「瓶頸行為」。顧問角色的全部重點在於「槓桿」，不是「吞吐量」。

設計審查會議的節奏

可預期的設計審查節奏，是讓顧問角色能規模化的關鍵。

推薦節奏

• 每週 — 60 分鐘 服務設計審查 (Service Design Review)。 任何團隊都可以帶來工作量超過 1 個 sprint 的提案變更。預讀資料 48 小時前發出。產出：ADR 草稿或 PR 回饋清單。
• 每雙週 — 30 分鐘 上線就緒審查 (Production Readiness Review, PRR)。 任何服務在 Cloud Run、GKE 或 App Engine 上線前都必須完成。檢查清單：SLO 已定義、告警已接好、runbook 已寫好、IAM 已最小權限、secret 已放進 Secret Manager、Terraform state 已使用遠端後端。
• 每季 — 2 小時 Tech Radar 更新。
• 每季 — 90 分鐘 技術債檢視。 走過登錄簿，重新排序優先級。
• 每年 — 半天 架構高峰會 (Architecture summit)。 跨團隊回顧組織層級的模式。

會議衛生

• 每場會議都要有指名的決策者（不要「委員會式決策」）。
• 會議筆記與 ADR 放在同一個 repo。
• 如果一場會議常常沒有議程，就停掉它 — 只存在於行事曆上的會議是每位工程師的稅。

常見問題 — 開發團隊諮詢

Q1. 我該如何說服團隊從 VM 遷移到 Cloud Run？

強調運作上的簡潔性。Cloud Run 開箱即用就支援縮減到零的自動擴充、修補管理與負載平衡。告訴他們：「你們專注於程式碼，我會處理 Serverless 中的『伺服器』部分。」

Q2. 開發者想要正式環境專案的「Owner」權限，我該怎麼辦？

拒絕並給予建議。 解釋「最小權限原則」。與其給「Owner」，不如給「Viewer」用於疑難排解，並建立一個緊急存取 (break-glass) 程序，在緊急情況下暫時提升權限。

Q3. 我該如何處理「影子 IT (Shadow IT)」(團隊使用未經核准的工具)？

不要直接禁止這些工具。先了解為什麼他們會使用它們。如果核准的工具太慢或太複雜，請與基礎設施團隊合作改進官方方案，或為新工具建立一條「受支援」的路徑。

Q4. 最該追蹤的 DORA 指標是哪一個？

變更失敗率 (Change Failure Rate)。 它衡量發佈的品質。如果這個比例過高，您的 CI/CD 與測試流程需要立即關注。

Q5. 我該如何就「資料庫選擇」提供建議？

使用決策樹：

• 需要 SQL 嗎？ -> Cloud SQL / Spanner。
• 是全球性且規模巨大的嗎？ -> Spanner。
• 是彈性的 JSON 嗎？ -> Firestore。
• 是簡單的快取嗎？ -> Memorystore。

最後的架構師提示

在 PCA 考試中，遇到關於「提升部署頻率」或「降低人為失誤」的問題時，答案通常會牽涉到**「將 CI/CD pipeline 自動化」或「使用代管服務」。身為顧問，您的目標是讓基礎設施對開發者隱形**，使他們能專注於交付業務價值。