想走雲端架構師這條路？先準備作品與面試

想往雲端架構師走，常會先問：「我還要學多少服務，才有資格投履歷？」但職缺很少是在找一個背得出所有產品名稱的人。它更想知道：需求不完整時，你怎麼釐清？方案有好幾種時，你怎麼取捨？上線後出事，誰能接手？

這篇會從看職缺、做作品、寫履歷、練面試，一路談到收到 Offer 後該問清楚什麼。不必等全部技能都學完才開始；先挑想做的工作，再決定要補哪一塊。

同樣叫架構師，工作可能差很多

先找三到五個你真的會投的職缺，別只看標題。雲端架構師可能偏售前：和客戶討論需求、做提案與概念驗證；也可能偏平台：管理網路、權限、IaC 和內部服務；還可能要處理遷移、值班或事故。這些工作都用得到架構能力，但履歷和面試要拿出的證據不同。

我會把職缺要求拆成四欄：

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

這張表也能幫你判斷自己要不要投。如果職缺主要做售前簡報，你卻只想維運平台，不必因為職稱漂亮就勉強自己。反過來，缺一兩項工具不等於不能投；先看那是不是工作真正的核心。

薪資也要用同樣的方法比較。可以參考 104 薪資情報和當下的實際職缺，但要把地區、年資、職責、值班、底薪與變動獎金分開看。海外遠端職缺尤其要確認雇用地區、時區、福利與資料存取條件；只換算外幣年薪，常會漏掉關鍵差異。

技能不是工具購物清單

Google 對 Professional Cloud Architect 的描述，包含業務目標、架構設計、遷移、安全、成本與營運。你不必把每個工具都學到同樣深度，但要能沿著一個服務的生命週期，說清楚以下幾件事：

• 建得出來：熟悉一個主力雲端平台的網路、身分、運算與資料服務。能從空專案建出可用環境，也能拆掉。
• 管得起來：懂部署、監控、備份、權限和成本。方案不能只在架構圖上運作。
• 說得清楚：知道兩個方案各犧牲什麼，例如受管服務省維運，但可能增加單位費用或限制客製化。
• 能和人協作：確認需求由誰決定、事故由誰處理、變更要怎麼審查。技術答案通常只是整個決策的一部分。

如果目標職缺要求 IaC，Terraform 是值得做出實際作品的工具。Google Cloud 的 IaC 說明強調可重複、可版本化的基礎設施；Terraform 官方工作流程則把工作分成 write、plan、apply。面試時只說「我會 Terraform」不夠，最好能展示一次變更如何經過 plan、審查、部署與驗證。

Kubernetes 也不是架構師作品集的必備入場券。若你想投的平台團隊天天管理 GKE，就做一個能展示部署、擴縮與排錯的專案；如果目標是小型應用或偏售前的職位，先用範圍更小的服務把需求、成本與可靠度講清楚，通常比硬塞 GKE 更有說服力。

一個能被追問的作品，比一排服務圖示有用

作品集可以從一個很小的情境開始：例如「客服建立工單後，要寄送通知；通知服務暫時故障時，工單不能跟著遺失」。先寫需求，再決定用同步呼叫還是佇列、資料放哪裡、誰能讀工單，以及怎麼知道通知失敗。你可以選 Cloud Run、Pub/Sub、Firestore 等服務實作；也可以選別的組合，只要能解釋選擇理由。

專案的 README 不必寫得像產品白皮書，但至少應回答：

1. 這個系統解決什麼問題？成功與失敗怎麼判定？
2. 架構圖上的每個元件負責什麼？為什麼不用另一種更簡單的做法？
3. 別人如何部署、測試、清理資源？需要哪些權限，會產生哪些費用？
4. 你測過哪種故障？看了哪些日誌或指標？恢復流程是什麼？
5. 還有哪些沒做、但正式上線必須補的事？

尤其不要在 README 裡寫「可用性 99.95%」「每月只要 50 美元」，除非有測量範圍、估價假設與紀錄支持。示範專案有意縮小範圍沒關係，誠實寫出限制，反而能讓面試官看出你的判斷。

公司專案若不能公開，也可以做匿名化的架構決策紀錄，或另外建一個不含公司資料的縮小版範例。重點是能說明自己的責任，不是把機密程式碼搬到公開 GitHub。

履歷別用「負責維護雲端系統」打發自己

履歷上的一條經歷，最好有問題、你的行動和結果。「負責 GCP 環境維護」看不出你做了什麼；「把手動開通環境改成經審查的 Terraform 流程，減少設定不一致」就比較有畫面。如果有部署紀錄能證明前後時間差，再補實際數字。沒有量過，就不要憑印象填「效率提升 87%」。

STAR（Situation、Task、Action、Result）可以當整理筆記的方法，但履歷不必把四個英文字母都寫出來。面試追問時要說得出：當時的限制是什麼、哪些決定由你做、結果如何驗證，以及有什麼沒解決。

技術部落格也不必每週硬產一篇。寫一次「原本怎麼設計、遇到哪個問題、最後為何改法」，就能讓人看到你的思考。文章裡若只有服務介紹和漂亮架構圖，卻沒有測試或取捨，和作品集一樣容易流於表面。

證照可以幫你補齊知識，也可能是某些職缺的條件；它不是作品的替代品。若正在準備 ACE 或 PCA，可接著看認證學習路線，再決定投入順序。

面試練的不是背標準答案

面試大致會碰到架構設計、事故處理與經驗回顧。三種題目都可以先講清楚你知道什麼、還不知道什麼，不必在第一分鐘就把所有雲端產品排滿白板。

架構題：先追問限制

如果題目是「促銷時流量可能暴增，怎麼設計網站？」先問使用者在哪裡、尖峰是平常的幾倍、哪個操作最重要、資料能否延遲同步，以及允許多久不可用。接著畫出入口、應用、資料的第一版，再挑最可能塞住或壞掉的地方補強。

例如靜態圖片可以考慮快取，但訂單內容不能隨意共用快取。應用層能擴容，也不代表資料庫會跟著變快。若方案需要跨區域，還得說明資料一致性與切換方式，而不是把「多區域」直接當作可靠度保證。最後回到原本的需求，說明一個你沒有選的替代方案和原因。

Google 的 Well-Architected Framework可用來檢查可靠度、安全、效能、成本和營運面向；它是檢查清單，不會替你回答這家公司最重視哪一項。

事故題：先看使用者受影響多少

「凌晨三點 CPU 到 95%，使用者說很慢」不代表第一步一定是擴 VM。先確認延遲和錯誤率是否真的上升、影響哪些服務和地區，以及剛才是否部署過新版本。接著選風險最低的緩解方式：有時是回滾，有時是擴容、限流或停掉異常工作；做完要看指標是否恢復。根因分析放在止血之後，再把時間線與證據留下來。

回答成本題也一樣。若面試官說「帳單太高」，先拆專案、服務和 SKU，找用量變化，再討論關閒置資源、調規格或折扣。不知道基線用量就先買長期承諾，可能只是把不必要的支出鎖住。

行為題：講你真的做過的事

準備兩三段真實故事就好：一次處理故障、一次與不同角色達成決定、一次做錯後修正。每段故事先用一兩句交代背景，接著說你負責什麼、如何判斷、最後怎麼驗證結果。不要把團隊的所有成果都寫成自己一人完成；也不要為了好看，編出「三天把可用性從 90% 提升到 99.95%」這種難以查證的數字。

如果不能公開公司指標，可以說明量測方式與改善方向，或用不涉及機密的範圍描述影響。面試官追問時能把限制和取捨說清楚，比背一段完美故事更重要。

收到 Offer，先把工作條件看完整

比較 Offer 時，除了底薪，還要把獎金是否保證、股票歸屬條件、值班與補償、出差、遠端政策、學習預算和職級期待放在一起。兩份名義年薪相近的工作，實際工時和責任可能差很多。

有不清楚的地方就直接問，例如：「這個職位需要輪值嗎？事故時誰是主要負責人？值班補償怎麼計算？」或「獎金中固定與依績效浮動的部分各是多少？」把重要承諾寫進正式文件，再決定是否接受。

提出期望薪資時，用相近職責的職缺和可查的薪資資料建立範圍，並確認自己的可接受下限。若工作內容和原先理解不同，可以明白指出差異，討論薪資、職級或值班安排；不必套用網路上的制式談判台詞。

如果今天開始準備

不用替自己排一張每週都滿格的十二週表。先照實際可用時間做四件事：

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

沒有面試邀請，就回頭看職缺定位、履歷摘要和作品首頁是否對得上；進了面試卻常在設計題卡住，就補需求澄清與取捨練習。這比規定自己「第十一週一定要投十份」更能反映真實進度。

想先看認證準備，可讀 ACE-303：GCP 認證怎麼準備？；想接著看技術方向，再讀 ACE-305：2026 雲端趨勢。