雲端架構師（Cloud Architect）是規劃和設定雲端環境 （GCP、AWS、Azure） ，讓系統可以在雲端上順暢地跑起來的人。

也是根據公司要運作程式的需求（例如：想要架設電商網站），提出雲端解決方案（例如：自動擴充搭配負載平衡） 的人。

你可以把雲端架構師想像成「雲端世界的建築師」——一般建築師設計房子，雲端架構師設計的是一棟棟跑在雲端上的數位建築物。

雲端架構師的核心職責

雲端架構師的日常工作，主要包含以下幾個面向：

1. 評估需求：與業務單位溝通，了解系統規模、流量、安全需求
2. 設計架構：規劃雲端網路（Virtual Private Cloud; VPC）、Kubernetes 叢集、資料庫佈署方式
3. 成本管理：透過預算、長期的承諾使用折扣 （Committed Use Discount）、短期的續用折扣（Sustained Use Discount） 等機制降低雲端使用成本
4. 資安規劃：設定 Cloud IAM 權限和角色、防火牆、金鑰管理服務（KMS）設定加密、Security Command Center 監控雲端環境
5. 技術支援：協助開發團隊解決各種雲端疑難雜症
6. 維運監控：建立 Cloud Monitoring、Cloud Logging 警告機制

雲端架構師 vs 一般軟體工程師的差異

很多人會問：「雲端架構師跟工程師哪裡不一樣？」

最簡單的區分方式是：軟體工程師「寫程式解決問題」，雲端架構師「設計環境讓程式可以穩定運行」。工程師關注的是程式的各項功能運作，架構師關注的是基礎設施和整體系統架構。

兩者的互動是：工程師寫好程式，但不知道如何放到雲端上跑，由雲端架構師把環境設定好，然後幫工程師把程式放上去。

在薪資上，架構師普遍高於同年資的開發工程師，這也是為什麼許多工程師選擇往雲端架構師方向發展的主要原因。

2024年台灣雲端架構師薪水行情

根據台灣 1111 人力銀行、104 人力銀行、CakeResume 及 LinkedIn 等平台的職缺資料，台灣雲端架構師月薪範圍約落在 8 萬到 20 萬新台幣之間，年薪含獎金可達 120 萬到 250 萬元，具備多雲認證者更有談判高薪的籌碼。

以下依照資歷分三個等級說明：

初階雲端架構師薪資（0～3 年雲端經驗）

初階雲端架構師通常來自系統工程師、網路工程師或軟體工程師轉職而來。這個階段的工作以「執行」為主，配合資深架構師的規劃進行實作。

初階薪資提升關鍵： 拿到第一張雲端 Associate 等級認證後，月薪通常可立即提升 5,000 至 15,000 元，對應聘資格影響非常大。

中階雲端架構師薪資（3～8 年雲端經驗）

這個階段的架構師已經能獨立主導專案，開始帶領小團隊，並且有能力與客戶直接溝通技術方案。如果你同時具備兩張以上 Professional 等級認證，薪資談判空間會更大。

資深雲端架構師薪資（8 年以上 / 特殊專長）

資深架構師的薪水往往不只來自技術能力，更來自「業務開發能力」——能不能幫公司拿到大型雲端專案，直接決定你的市場價值。

很多高薪的雲端架構師，其實就是售前（Presales），主要職責就是協助公司推廣雲端產品，拿到雲端開發或建置案，除了能賺取專案的人力費用，客戶每個月使用雲端產生的被動收益，也是公司的主要收入來源。這種能夠幫公司賺錢的雲端架構師，薪水就遠遠超過只是操作內部系統的雲端架構師。

台灣雲端架構師的薪資天花板遠高於一般工程師職位。初階月薪 6～9 萬，中階 9～15 萬，資深可達 15～25 萬，年薪突破 200 萬並非少見。具備 GCP Professional Cloud Architect、AWS Solutions Architect 等 Professional 等級認證，是突破薪資瓶頸最直接有效的方式。

全球雲端架構師薪水比較

如果你有考慮出國工作或遠端接案，以下是各主要市場的薪資對比：

美國、日本、新加坡薪資比較

從這份比較表可以看出，台灣雲端架構師的薪資雖然相對美國偏低，但如果跟台灣其他 IT 職位相比，仍屬於高薪族群。尤其新加坡市場對台灣雲端架構師的需求相當高，是值得關注的出海選項。

像我個人也曾經收到要去新加坡建置大型雲端架構的案子，客戶會願意為此進行大筆投資。

影響雲端架構師薪水的關鍵因素

同樣是雲端架構師，為什麼薪水可以差到兩倍以上？以下是最關鍵的幾個因素：

GCP / AWS / Azure 認證的薪資加乘效果

雲端認證是影響架構師薪資最直接的因素之一，如果你沒有證據證明你在雲端的能力和經驗，持有證照就是唯一客觀的評估標準。持有 GCP Professional Cloud Architect 認證的工程師，平均薪資比未持有認證者高出 20%～40%。若同時持有 GCP + AWS 雙認證，在台灣的求職市場幾乎是「有求必應」的狀態。

主要認證對薪資的影響如下：

GCP 系列認證：

• Associate Cloud Engineer：月薪提升 5,000～15,000 NTD
• Professional Cloud Architect：月薪提升 15,000～30,000 NTD
• Professional Data Engineer / Security Engineer：額外加給 10,000～20,000 NTD

AWS 系列認證：

• AWS Solutions Architect – Associate：月薪提升 8,000～18,000 NTD
• AWS Solutions Architect – Professional：月薪提升 20,000～40,000 NTD

關鍵提醒： 認證只是敲門磚，沒有實戰經驗搭配的認證說服力有限。最理想的狀況是邊工作邊考證，讓認證為你的實戰能力背書。

產業別薪資差異

不同產業對雲端架構師的需求和出價也有明顯差異：

如何成為雲端架構師？轉職路徑完整說明

從非技術背景轉職的真實案例

我自己的經歷就是一個很好的例子。我大學念統計系、研究所念企管，完全沒有資工背景，後來卻成為 GCP 的雲端架構師，現在在 YouTube 和部落格上教別人 GCP。

我的轉職路徑大概是這樣：

1. 2008年：花十萬元自費學習 Windows Server + SQL Server，考取 MCSA、MCDBA、RHCE 證照
2. 2009年：進入系統整合商，實際接觸政府 IT 系統，寫過 C# 和 Java
3. 2013年：透過前主管介紹，進入 Google 合作夥伴公司做 Presales
4. 2014年：GCP 在台灣開始大力推廣，轉型為 GCP 雲端架構師
5. 2023年：跳出來做自媒體「東東 GCP 教學」，分享 GCP 知識

轉職雲端架構師不一定需要資工本科背景。許多成功的雲端架構師來自系統工程師、網路管理員、甚至非技術職位（如 IT Presales、專案經理）。關鍵在於「取得認證 + 累積實戰案例 + 持續學習」這三個同步進行的動作，缺一不可。

接近 40 歲的時候，我也非常擔心機會越來越少。但事實證明，只要在一個特定的技術領域持續深耕，即使非本科也能建立別人難以取代的競爭優勢。

需要哪些技能與證照？

成為雲端架構師需要的技能可以分成「硬技能」和「軟技能」兩大類：

硬技能（技術能力）：

1. 網路基礎：TCP/IP、DNS、VPC、防火牆規則
2. Linux 系統管理：基本指令操作、權限管理、Log 分析
3. 容器技術：Docker、Kubernetes（GKE）
4. IaC（基礎設施即程式碼）：Terraform、Kubernetes YAML 撰寫
5. 資安概念：IAM 設計、加密金鑰管理、Zero Trust 架構
6. 資料庫：Cloud SQL、BigQuery、Spanner 的使用情境
7. 監控：Cloud Monitoring、Cloud Logging、告警設定

軟技能（非技術能力）：

1. 溝通能力：能把技術翻譯給非技術主管聽
2. 問題分析：面對客戶疑難雜症時的邏輯思維
3. 成本意識：設計架構時要同步考量 ROI
4. 文件撰寫：架構圖、技術提案、RFP 回覆

建議取得的認證順序（以 GCP 為例）：

1. 第一步：GCP Associate Cloud Engineer（建立基礎）
2. 第二步：GCP Professional Cloud Architect（主力認證）
3. 第三步：依照工作方向加考 Professional Data Engineer 或 Professional Security Engineer

雲端架構師薪水成長策略

光知道「雲端架構師薪水高」還不夠，你需要一套具體的薪資成長策略：

如何用 GCP 認證快速提升薪資

策略一：先考再談，用證照打開門

很多公司對認證持有者有加薪機制，甚至有證照獎金（有些公司每張證照獎勵 1 萬到 3 萬不等）。拿到認證後，跳槽或內部升遷都有更多籌碼。

策略二：做出可量化的成果

在面試時，「我幫公司把雲端帳單降低 30%」比「我有三年雲端架構師經驗」有力得多。每做完一個專案，一定要記錄下來：做了什麼、節省多少成本、解決什麼問題。

策略三：建立個人品牌

我自己從 2023 年開始做「東東 GCP 教學」，透過 YouTube 頻道、部落格（dongdonggcp.com）、Linked-in、和 Threads 分享 GCP 知識。這不只帶來了額外的收入來源，更讓我在行業內建立了可信度。

對雲端架構師來說，公開展示自己的技術知識，是目前最有效的個人品牌策略之一。

策略四：專精一個垂直領域

與其成為「什麼都懂一點」的泛用型架構師，不如在某個特定領域（如金融雲、醫療雲、AI 基礎設施）成為領域專家。垂直深度往往比水平廣度更能帶來薪資溢價。

雲端架構師要有效提升薪資，最快的方法是：取得 Professional 等級認證（立即增加談判籌碼）、記錄可量化的成果（降低帳單、提升穩定性的具體數字）、以及在特定垂直產業建立深度專業。這三個動作同步進行，年薪提升 30%～50% 是可預期的。

雲端架構師薪水 FAQ 常見問題

Q1：沒有資工背景可以成為雲端架構師嗎？

A： 完全可以。許多優秀的雲端架構師來自非資工背景，包括統計、企管、甚至人文科系。關鍵是你願不願意主動考取認證、累積實戰經驗。台灣確實有很多成功案例，從統計系、商科出身轉職為 GCP 架構師的人並不少見。重要的是要有系統地學習：先從 GCP Associate Cloud Engineer 認證入門，邊學邊做，循序漸進。

Q2：雲端架構師和 DevOps 工程師的薪水哪個比較高？

A： 在台灣市場，雲端架構師的平均薪資略高於 DevOps 工程師，尤其在資深等級差距更明顯。因為 DevOps 工程師雲端架構師月薪區間約 8 萬～20 萬，DevOps 工程師約 7 萬～16 萬。不過兩者界線越來越模糊，很多公司的雲端架構師職位本身就包含 DevOps 工作，具備 CI/CD pipeline 設計能力的架構師，薪資競爭力會更強。

Q3：GCP 認證和 AWS 認證，哪個對薪資幫助更大？

A： 以台灣市場來看，AWS 認證的市場認知度略高，職缺數量也稍多；但 GCP 認證在特定產業（尤其是媒體、廣告科技、AI 應用）有明顯優勢，而且考試難度相對較高，持有者的含金量也相對較高。最理想的狀況是同時持有 GCP Professional Cloud Architect + AWS Solutions Architect，雙認證的組合在談薪水時最有底氣。

Q4：轉職雲端架構師大約需要多久？

A： 有技術基礎（如系統工程師、網路管理員）的人，通常 1～2 年可以完成轉型；從非技術職位（如 IT Presales、PM）轉職則需要 2～3 年。關鍵不是時間長短，而是「是否有機會接觸真實的雲端專案」。即使沒有，也可以透過 Google 官方的 Cloud Skills Boost 平台刷題目、做 Lab，累積實戰感。如果你覺得自學太慢了，可以加入雲端架構師養成班，藉由完整的學習和實作，加快考取證照並成功轉職的速度。

Q5：台灣雲端架構師的未來發展前景如何？

A： 非常樂觀。隨著台灣企業數位轉型加速、AI 應用崛起（Vertex AI、Gemini API 的整合需求），以及半導體產業上雲趨勢持續，雲端架構師的需求預計在未來 5 年內仍持續成長。特別是具備 AI/ML 基礎設施規劃能力的架構師，將成為市場上最搶手的人才之一。

結論：雲端架構師是值得投資的職涯方向

雲端架構師是目前台灣 IT 市場薪資成長最快的職位之一，年薪 120 萬到 250 萬的機會對有認證、有實戰的人來說相當實際。轉職門檻雖然存在，但並非不可跨越——只要系統性學習、取得認證、累積可量化成果，即使是非本科背景，也能在 2～3 年內完成轉型。

我自己從完全不懂 GCP，到成為雲端架構師、再到現在透過「東東 GCP 教學」分享這些知識，走了超過十年。這條路不一定要走那麼久——因為現在的學習資源、認證體系、社群支持都比十年前豐富太多了。

如果你對轉職雲端架構師有興趣，或者已經在雲端領域工作但想要加速薪資成長，歡迎來 dongdonggcp.com 看看我整理的 GCP 實戰教學，或是訂閱「東東 GCP 教學」的 YouTube 頻道，我們一起在雲端世界找到自己的位置。

如果還有什我疑問，也可以加 Line: @754xlakm 直接與我聯絡，透過線上諮詢來了解你的情況，並提供你適合的發展方向。

The post 雲端架構師薪水完整指南：薪資行情、加薪技巧與轉職攻略 first appeared on 東東 GCP 教學 - GCP 實戰講師.

【新書上巿】《Google Cloud 從雲端小白到黑帶高手》正式發表 ！

書籍簡介

經過一年的努力撰寫，我把 10 年 GCP 實戰經驗精華寫進這本書裡…

本書專門針對想自學 GCP 的朋友，提供「完全從零開始」的手把手教學，即使你完全不懂 GCP，只要跟著本書實作，一樣能夠架設 GCP 雲端服務。

讓你讀完本書，會發現原來自己也懂了 GCP。

本書特色

・從零開始：連註冊帳號、申請試用都教你，完全不怕沒基礎
・手把手實作：每個步驟都有詳細截圖和說明，跟著做就對了
・大白話解釋：把艱澀的技術名詞變成生活化比喻
・核心服務實戰：虛擬機器、自動擴充、負載平衡⋯通通實作給你看
・進階服務導覽：大數據 BigQuery、機器學習、生成式 AI、GKE⋯讓你掌握完整生態系
・帳單管理：使用雲端最怕不小心花太多錢，教你保護你的荷包
・雲端架構師簡介：工作角色與職責、職涯發展建議和轉職攻略
・雲端架構師考證指南：提供學習資源與準備方式，讓你能靠自學並考取證照
・企業上雲指南：教你幫助公司，踏出上雲的第一步

最後，如果想自行購買支持：

實體書

天瓏電腦書局 78 折 (可直接預購, 不用加入會員)
https://www.tenlong.com.tw/products/9786264142984

博客來 79 折
https://www.books.com.tw/products/0011031431

Momo 79 折
https://www.momoshop.com.tw/goods/GoodsDetail.jsp?i_code=14401840

誠品 88 折
https://www.eslite.com/product/10072302132683040876002

PCHome 24H 購物 79 折
https://24h.pchome.com.tw/books/prod/DJAA2V-A900JCTT4

墊腳石 9 折
https://www.tcsb.com.tw/SalePage/Index/11102660?lang=zh-TW

電子書

博客來
https://www.books.com.tw/products/E050300444

Momo
https://www.momoshop.com.tw/goods/GoodsDetail.jsp?i_code=14670384

PCHome
https://24h.pchome.com.tw/books/prod/DJBQ2S-D900JG07Q

讀墨 Readmoo
https://readmoo.com/book/210428103000101

Pubu
https://www.pubu.com.tw/ebook/628771

Kobo
https://www.kobo.com/tw/zh/ebook/google-cloud-1

目錄

第一章 | 認識雲端與 Google Cloud
1-1 雲端運算是什麼？為什麼要使用雲端？
1-2 Google Cloud 是什麼？核心服務與優勢介紹
1-3 Google Cloud 的發展

第二章 | 雲端架構師的角色與職責
2-1 什麼是雲端架構師？
2-2 雲端架構師的日常工作
2-3 成功雲端架構師的關鍵能力

第三章 | 啟用你的 Google Cloud 環境
3-1 使用 Google Cloud 的帳號準備
3-2 申請 Google Cloud 300 美元試用環境
3-3 Google Cloud 的初始畫面介紹
3-4 Google Cloud 的帳單和預算設定
3-5 Google Cloud 的資源層級結構
3-6 Google Cloud 權限與角色管理工具 Cloud IAM
3-7 免費的雲端測試機 Cloud Shell
3-8 在地端操作 Google Cloud 的 Cloud SDK

第四章 | Compute Engine 虛擬機器平台簡介
4-1 Compute Engine 是什麼？
4-2 建立並連線到虛擬機器
4-3 在虛擬機器上架設一個 Apache 網站
4-4 給虛擬機器建立快照備份並還原
4-5 映像檔和機器映像檔
4-6 執行個體範本

第五章 | Google Cloud 的維運和監控
5-1 使用 Cloud Monitoring 監控虛擬機器的效能
5-2 設定監控警告通知
5-3 使用 Cloud Logging 查詢虛擬機器的記錄

第六章 | Google Cloud 的網路基礎知識
6-1 Vitual Private Cloud（VPC）和 Subnet 介紹
6-2 防火牆規則
6-3 安全連線到虛擬機器的三種方法（SSH Key、gcloud、Cloud IAP）

第七章 | Google Cloud 的儲存服務
7-1 雲端檔案儲存 Google Cloud Storage 介紹與基本操作
7-2 雲端資料庫 Cloud SQL 介紹與基本操作
7-3 其他資料儲存服務簡介

第八章 | 打造高可用與自動擴展的雲端架構
8-1 建立自動擴充的執行個體群組
8-2 建立負載平衡器並啟用 Cloud CDN
8-3 網路攻擊防禦 Cloud Armor
8-4 其他網路服務介紹

第九章 | 無伺服器平台與 CI/CD 服務
9-1 上傳程式碼就能跑——Google App Engine 和 Cloud Run Function
9-2 容器相關服務 Artifact Registry、 Cloud Run 和 GKE
9-3 CI/CD工具 Cloud Build

第十章 | 大數據、機器學習和 AI
10-1 大數據工具介紹
10-2 機器學習服務
10-3 生成式 AI 服務

第十一章 | Google Cloud 的資安服務
11-1 Google Cloud 的重要資安概念
11-2 組織治理與監控
11-3 資料保護與加密

第十二章 | 企業使用 Google Cloud 的相關議題
12-1 將系統搬上 Google Cloud 的評估考量
12-2 主機搬遷上雲的執行方法
12-3 Google Cloud 的帳單分析與成本管控

第十三章 | Google Cloud 認證之路
13-1 Google Cloud 認證考試介紹
13-2 準備 Google Cloud 認證考試的策略

第十四章 | 雲端架構師的職涯規劃與發展
14-1 IT 人員到 Google Cloud 架構師的轉型之路
14-2 雲端架構師轉職與面試技巧
14-3 Google Cloud 的細分職業路線
14-4 產業趨勢與架構師角色演進

附錄 A：相關參考資源——Google Cloud 重要參考資源列表

讀者好評

The post 新書上巿 Google Cloud 從雲端小白到黑帶高手 正式發表 first appeared on 東東 GCP 教學 - GCP 實戰講師.

好消息是——這個限制，其實沒你想像的嚴重。

我將完整解析「非工程背景者」是否能轉職為雲端架構師，並提供清晰的學習路線與轉職策略。

雲端架構師是做什麼的？職責全面解析

雲端架構師是企業轉型雲端的關鍵推手，他可以依照企業的需求，負責設計可擴展、高可用、具備安全性的整體雲端系統架構。

「可擴展」，指的是能夠擴充資源。

因為地端的資源受限於你買的機器數量，但在雲端，你可以隨時依照公司的需求，或是突然飆升的用戶流量，即時擴充資源來應付廣大的需求。

「高可用」是什麼呢？

高可用是一個「結果」，指的是服務能夠保持運作的時間比例很高。

要做到高可用，並不是說要開一台規格很高或效能很好的主機 (因為單台主機可能因維護而被重開) 。

而是善用雲端上各種資源搭配，組合成強壯的系統架構，不管發生什麼事，都不會因為單個功能故障，讓整個服務無法運作。

例如建立一群機器，讓負載平衡器在最前面幫忙分流，即使有一台機器故障，負載平衡器也能把流量導向正常運作的主機。

或是資料庫有問題，馬上自動 Failover (容錯移轉)，讓 Stand by 的主機出來頂替， 保持整個服務正常。

所以雲端架構師會知道怎麼做出「可擴展」、「高可用」」且「安全」的雲端架構，這就要先了解雲端的各項功能了！

為什麼雲端架構師這麼搶手？

數位轉型已是企業標配

隨著全球企業數位轉型的浪潮不斷加速，雲端服務早已從「可選項」變成「必要條件」。

現在的新創公司，不可能一開始就花大錢建置機房並購買機器設備，幾乎都是買一台筆電就開始寫程式、打造產品。

那程式寫好放哪裡？當然是直接上傳雲端啊！直接下一個 git commit 就能上傳到雲端，甚至能夠自動部署上線對外服務。

大企業的話，因為地緣政治風險，有不少公司早已經採用「多雲策略」，因為雞蛋不會放在同一個籃子裡，不會把核心系統 100% 都放在某個雲端上。

可能各放 30%，甚至還留一些到地端。也不會集中在單一國家，可能把服務分散到日本、東南亞，甚至留一些服務到歐美去。

傳統產業，可能採用雲端的速度是最慢的，但由於近年來 AI 高度發展，逼得各個公司為了投入 AI，也開始紛紛上雲。

為什麼用 AI 要上雲呢？

因為你直接買機器和 GPU 太貴了！動輒幾十萬，買了也不會一直開著。

用雲端的話，只有要訓練模型時，才會短暫用到 GPU 和相關運算資源，用完就關掉，訓練 8 小時也才 1000 台幣，非常划算。

所以各行各業都在思考如何上雲，達成更高的效率、更強的彈性與更低的成本。

而在這個過程中，雲端架構師正是那位為企業「指路」的專業顧問。

企業急需懂得架構設計的人才

企業不再滿足於只會操作雲端平台的技術人員，他們更需要具備系統整合與架構設計能力的人才，能夠根據業務需求規劃出安全、可擴展且高可用的雲端解決方案。這樣的角色不只要懂技術，還要懂得與內外部團隊溝通，將業務與技術串聯起來。

多雲、混合雲環境日益複雜

再加上現在企業多採用「多雲」（multi-cloud）或「混合雲」（hybrid cloud）策略，也就是同時使用 GCP、AWS、Azure 等不同平台，或將本地系統與雲端資源整合。這讓整體架構更加複雜，需要有能力跨平台思考、規劃與管理的架構師。因此，雲端架構師的價值不斷攀升，成為 IT 領域最炙手可熱的職位之一。

雲端架構師與其他職位有何不同？

必須要會寫程式嗎？破解常見迷思

「不會寫程式就不行」的觀念從哪來？

多數人將「技術職位」與「寫程式」劃上等號，實則雲架構師更偏重架構規劃與整合，寫程式只是工具之一。

雲端架構師實際工作中需要寫多少程式？

• 少量腳本（如 Terraform、Cloud Shell）
• 理解 API 結構與部署流程
• 協助團隊整合 CI/CD 流程

基礎程式能力 v.s. 專職開發能力

具備程式基礎會是加分項，但不需達到軟體工程師的水準。更重要的是——你能否整合不同系統、解決架構瓶頸。

成為雲端架構師的關鍵技能有哪些？

系統設計與架構思維

能否依據需求設計出高可用、高效能、具備擴展性的架構，是核心關鍵。

雲端平台操作（GCP、AWS、Azure）

建議選定一個平台深入，如 GCP 的 Compute Engine、Cloud Run、BigQuery 等。

資訊安全與法規遵循

熟悉 IAM、資料加密、法規（如 GDPR、ISO 27001）等，是專業的重要體現。

溝通能力與專案協作

懂技術不夠，還得懂得與開發、主管、甚至客戶溝通架構設計邏輯。

不會寫程式的人該如何轉職？可行路線解析

起點建議：從雲端平台認證開始

• Google Cloud Digital Leader（零程式基礎也能考）
• AWS Cloud Practitioner
• 這些證照強調架構與平台基礎概念

銜接課程與學習資源推薦

• 選擇「非開發導向」的雲端架構課程
• 像是《東東 GCP 教學》提供的入門到架構師路線

找到轉職跳板的策略

• 先從雲端專案協作角色（如 PM、顧問、技術支持）切入
• 慢慢累積架構設計經驗

真實案例分享：他們都不是工程師出身！

MIS 主管轉職雲架構師的心路歷程

「我原本只會部署防火牆、設定備份，但開始接觸 GCP 後，才發現我可以不靠寫程式，也能設計一整套混合雲架構。」

專案經理成功進入雲端領域的轉折點

「我專長是專案管理，當我熟悉 GCP 的產品與整合策略後，我現在負責帶領跨國團隊打造多區架構。」

優勢與挑戰並存：非工程背景的強項在哪？

• 跨領域溝通能力強
• 站在使用者角度思考系統設計
• 懂流程、懂業務的人更容易設計實用架構

給未來雲架構師的五點建議

1. 選定一個雲端平台，深入學習
2. 建立技術部落格或學習筆記
3. 多參加實戰專案，累積架構經驗
4. 搭配證照驗證專業能力
5. 保持學習熱忱，並勇敢踏出第一步！

常見問題 FAQ

1. 需要考哪些證照才有機會轉職？

推薦先從入門證照開始，如 Google Cloud Digital Leader，再進一步挑戰 Architect 級別。

2. GCP 跟 AWS 哪一個比較好學？

GCP 的介面與邏輯較清楚，適合初學者；AWS 生態完整，但曲線略陡。

3. 非本科系可以嗎？

完全沒問題，重點是你的學習力與實作經驗。

4. 英文不好也能學嗎？

能，現在有大量中文教材與圖解式資源可用，但英文仍建議逐步增強。

5. 需要有雲端專案經驗才能轉職嗎？

不用。你可以先參與模擬專案、自學實作，逐步累積作品與信心。

The post 不會寫程式，可以轉職雲端架構師嗎？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

雲端和地端其實是不同的世界，
如果你只碰過地端，還沒學過雲端任何東西，
那就直接從虛擬機器開始。

因為同樣是虛擬機器，內部的操作是一樣的，
內部指的是 Linux 指令、作業系統、套件安裝、檔案編輯等等。
外部就有點不同，例如 新建一個 Disk、設定外部 IP、串接 GCP 其他服務等。

所以至少你先開出一台虛擬機器，如果能夠寫一個 Hello Word 網頁更好。
先讓你有感覺，不再害怕雲端有多複雜。

至於備份的話，如果你可以給你的主機做一個快照，
再從快照還原成主機，就當你通過第一階段了。

像加掛 Disk 這種比較煩雜的東西，和雲端架構關係不大，可先不學，
但不代表永遠不用學，如果你的工作跟維護有關，遲早還是要面對它喔！

GCP 第二階段：了解 GCP 環境

接下來是正課，你了解的是專案、機構、帳單、權限和角色。
這些東西和架構沒有直接關係，
但如果你搞不懂的話，以後設定各項功就會錯誤百出，
這些是 GCP 的基本常識，所以不懂不行！

再來又更深一點，VPC 網路、Subnet 和防火牆。
這就是 GCP 架構的底層邏輯，百分之百要會的東西，
這一段非常無聊，卻也非常重要，
你不能因為無聊就跳過它。
如果你連切個網段都有問題，以後怎麼建立架構？
(如果你只用 default VPC 網路的話，好吧你暫時可以先不用學 VPC)

防火牆除了資訊安全的議題之外，
也是 Troubleshooting 的好夥伴，
各種網路不通，除了 Flow Log，也可以用 FW Log 來調查。

回到 VM，如果你要管好 VM 的話，
Disk、Image、Snapshot 的用途和差異都要了解，
因為 VM 故障的時候會用到，
相關概念不懂的話，你會很慌，
我以前就常接到客戶十萬火急地求救，
如果你懂的話，你處理起來就整個從容不迫。

GCP 第三階段  了解資料儲存

至於 Cloud Storage，各家公司用途不同，
最基本就是分擔主機負載，或是備份資料用的。

你最起碼要會建立一個 Bucket，上傳一個檔案，然後下載它。

至於保留政策、版本控管、生命周期、Signed URL 等等比較細的功能，
有用到的時候再了解就好。

而資料庫的部分，至少會開一個 Cloud SQL 資料庫，
然後可以從你本機的 Client 端去連線。

然後 SQL 語法不熟可以慢慢學，至少學會 Select * From Table 也好。

其他資料庫，Spanner、Filestore、Bigtable 只有考試會用到，中小企業用不到。

Firestore 則是當公司有在用 Firebase 開發才會用到，如果沒有，也是考試才會碰到。

第四階段 了解維護和運作

再來是監控工具，你不再需要在作業系統那一層監控，
GCP 的 Monitoring 和 Logging 已經幫你收集相關資訊，
也讓你能設定各種警示。

你至少要會知道去哪裡查 CPU 使用率。

如果主機有問題，至少知道怎麼查詢主機的記錄。
(誰建機器、誰關機、誰開機)

如果要監控記憶體和硬碟，至少要會安裝 OPs Agent，
設定效能警示通知 (例如記憶體滿了)。

第五階段 負載平衡與自動擴充

再來要準備發揮雲端的彈性，
針對 LB 和 Instance Group 細部參數，
至少知道最少幾台、最多自動擴充到幾台，還有擴充門檻會設定，
以及 Health Check 會區分 TCP 和 HTTP 的差別。

還有 SSL 憑證、Cloud CDN、Internet NEG 等等，
如果都熟悉的話，你已經可以跟大家說你懂一點雲端了喔！

其他參數太細不懂，就先用預設值吧！

第六階段  了解各種網路功能

如果不只要懂「雲端」，還要懂「網路」的話，
那各種網路功能就不得不學了。
和地端比起來，雲端的功能靈活得多，
如果要做好外部的防禦，那 Cloud Armor 和 Cloud NAT 必學。
如果你公司要用混合雲，則 Cloud VPN 和 Cloud Interconnect 必學。

第七階段 雲端資訊安全

GCP 的資安功能非常多，真的很多，
算是你在 GCP 英雄之旅的大魔王，
但是你也不一定要全部都會，看公司要求。

至少要先會 Organization Policy，最簡單也最重要的資安控管，
如果可以，Security Command Center 最好也了解一下。

如果是要做存取控制，那就學好 BeyondCorp 相關功能，
如果要做資料加密，就學好 Cloud KMS，
擔心資料外洩，那就學習 Cloud DLP。

接下來就是各細分領域：

無伺服器、微服務與容器平台

前面學到這裡，我們的程式還都在 VM 上，
如果公司比較偏向新創或遊戲公司，
就一定會走向無伺服器或微服務架構，
這才是「現代化的應用程式」，你用起來會覺得很「潮」，
所以 GAE、Cloud Run、Cloud Function 和 GKE 都要會。

而 GKE 之前要先懂 Kubernetes，Kubernetes 之前要懂容器，
所以 GKE 對初學者而言，算是另一個世界，
這段要走完會比較辛苦，走完之後你會覺得自己雲端功力大增。

資料庫、資料倉儲與資料分析

只要公司需要分析資料，
就一定要用到 BigQuery，它有蠻多特殊的概念，
不能當成一般資料庫來看。

至於其他的資料服務例如 Dataflow、Dataproc、Datafusion、Cloud Composer，
公司有在做資料處理再說，要不然它們只有在考試中出現而已。

Pub/Sub 有機會可以了解一下，它可以取代 MQTT 的功能，
也可以用來專門觸發其他服務，做自動化流程蠻方便的。

AI、機器學習和生成式 AI

我本來不想提的，因為它跟雲端架構比起來，
算是另一個領域了。

如果真的要懂一點，就至少要知道 Pre-Trained API、AutoML (Model Builder)，
Vertex AI 的 Agent Builder 和 Model Garden。

就是大概知道 AI 相關的環境在哪裡就好，通常會有專門開發 AI 的工程負責。

主要場景大概是：

有人問現成的 Notebook (AI 開發環境)，你可以開出來。

有人問 GPU，你知道去哪裡開。

有人想要在 GCP 上開發 Deepseek，你至少知道要去哪裡用。

到這裡，你已經算是稱職的雲端架構師了。

當然，如果你是代理商的雲端架構師，最好還是全部學完。

如果你對課程有興趣，就點此預約課程諮詢：

若有任何問題，也可以加 Line: @754xlakm 與我聯絡，謝謝你看到這裡！

The post GCP 學習路徑 Learning Roadmap 和八大關卡 first appeared on 東東 GCP 教學 - GCP 實戰講師.

Dataproc 是什麼？

Dataproc 是 GCP 的一個全代管的大數據處理服務，它支援開源的大數據生態系統工具，如 Apache Spark、Hadoop、Hive 等。

簡單說，Dataproc 幫你把資料處理這件事，變得又快又簡單，就像把一座沉重的工廠裝進自動販賣機，按一下就能開工。

為什麼選擇 Dataproc？四大優勢

1. 快速啟動與彈性擴展：只需幾分鐘就能啟動叢集，根據工作負載自動擴縮。

2. 與 GCP 生態系整合：無縫串接 BigQuery、Cloud Storage、Vertex AI 等工具。

3. 精準付費、節省成本：按秒計費、支援自動關閉機制，有效降低閒置成本。

4. 使用你本來就會的技能： Dataproc 包含 Hadoop、Spark、Hive、Pig 等 Open Source 的工具，不用重新學習。

Dataproc 的應用場景

大數據處理

無論是 ETL（Extract, Transform, Load）處理，還是資料清洗、彙整，都可以用 Dataproc。

結合 Spark 進行機器學習訓練

Dataproc 支援 Spark MLlib，你可以直接在叢集上進行分散式訓練，大幅提升訓練速度與模型精度。

搭配 Jupyter Notebook 做互動分析

開發者可透過 Jypyter Notebook 與叢集互動，實現即時查詢與分析，彷彿在大型資料倉庫裡漫步，探索資料的可能性。

Dataproc 的架構設計概念

叢集（Cluster）與節點角色說明

Dataproc 叢集主要包含兩種節點角色：Master 與 Worker。就像一個工廠，Master 是主管，Worker 是執行員工。

而節點其實就是 Compute Engine 的虛擬機器，因為我們是對整個 Cluster 操作，不針對某一台 VM，所以我們才稱它們叫 Node。

Master 節點與 Worker 節點的差異

• Master：負責指派任務、監控進度、管理資源。

• Worker：實際執行 Spark Job 與 Hadoop Task。

如何選擇正確的 VM 類型？

n2-standard 適合大多數應用。

e2-medium 適合成本敏感的小型專案。

可依工作負載選擇是否搭配 GPU 或高記憶體，但如果是初學者，建議不要開太大的機器喔！

Spark、Hadoop、Hive 在架構中的定位

• Spark：主力計算框架，支援即時與批次任務。

• Hadoop HDFS：用於資料儲存與分散處理。

• Hive：提供 SQL 介面查詢 HDFS 中的資料。

實際操作：如何建立一個 Dataproc Cluster (叢集)

在 GCP Console 上建立步驟

進入 Dataproc => Cluster。

選擇 Compute Engine。

給 Cluster 命名，選擇 Region 和 Zone，我是照 《Dataproc: Qwik Start – Console》 這個 Lab 做的，所以就跟它一模一樣，你也可以選擇台灣 asia-east1 喔！

先設定 Manager Node，我還是習慣叫 Master Node。

這裡要注意，剛開始你可能會找不到 N1、N2 或 E2 的主機，你要先把 Disk 改成 Standard 的，這幾個型號就會出現了。

一樣的做法再設定 Worker Node。

在 IP 的部分，原本 「Internal IP only」是有勾選的，要把它取消喔，

如果只有內部 IP，是不容易從部外連進去的，

它會先勾選，我想是為了安全性的問題，怕任何人都可以連到 Dataproc，

但我們是初學者，玩一下就會馬上把它刪掉(記得喔)，所以沒關係！

接下來等大概五分鐘左右，它就準備好了。

同時你也可以在 Compute Engine 頁面上看到真的有機器開出來，一台 Master Node，兩台 Worker Node。

接下來有兩種操作場景。

第一種是直接連到 Dataproc Master Node 的 Command Line

(本部份取自網路上的 YouTube 影片：GCP Dataproc Cluster creation | HDFS and Hive)

先 SSH 連到 Master Node，然後上傳一個要分析的檔案。

進入 Hive 建立資料庫名叫 “vehicle”。

建立表格 “vehicle_sold”，並查詢表格結構。

接下來使用語法來查詢資料，看到能正常顯示剛上傳的資料。

你會在上半部看到效能數據，如果資料量很大，可以查看是否需要調整主機規格來優化效能。

其中 Map 1 是什麼意思？

“1” 是第一階段，Map 是映射任務，資料被分割成多個小塊，每個小塊由一個 Map 任務處理。

把資料轉成 key-value 格式，例如 (Venue, 302), (Ertiga, 123)。

最後來下一個加總語法，查詢各類汽車銷售數量。

“Reducer2” 是第二階段 – 歸納任務，Reducer 接收 Map 任務輸出的 key-value，然後將相同 key 的 value 合併。

例如相同 Creta 的 336 和 265 加總起來為 601。

以上是第一種使用場景，就是讓你可以用下指令的方式，跟 Dataproc 互動操作。

第二種場景是提交你寫好的 Job 程式碼給 Dataproc 自動執行

(本部分是我操作 Skillboost Lab：Dataproc: Qwik Start – Console 的截圖)

接下來去 Jobs，我們要準備提交一個 Job。

在這個 Lab 我們要用一支程式去計算圓周率，所以要引入一個 org.apache.spark.examples.SparkPi 這個 Class，

然後再給它執行 Job 細節的程式碼檔案：file:///usr/lib/spark/examples/jars/spark-examples.jar

這個程式使用蒙地卡羅方法（Monte Carlo Method）來估算圓周率（Pi）的值，

參數 1000 代表程式將生成的 x,y 座標點對的數量，生成的點對越多，估算的圓周率值就越精確。

所以，當你在 Arguments 欄位中輸入 1000 時，您實際上是在告訴 SparkPi 程式生成 1000 個隨機點來估算 Pi 值。

如果您輸入更大的數字（例如 10000 或 100000），估算會更精確，但計算時間也會更長。

最後我們會在 Job Details 看到它算出來的圓周率，你會看到它有點不準。

我們記得 Pi 是 3.1415926……，但它算出來竟然是 3.14193…….

因為它只算 1000 個點，所以沒那麼準，如果算更多個點，一定比我們記憶的還準。

Dataproc 和 Dataflow 很像？到底有何差異？

當你在 Dataproc 上執行 Spark Job 時，確實會有一些操作方式上的相似點：

• 兩者都能執行預先編譯好的程式（JAR 檔案、Python 腳本等）
• 兩者都能處理批次和串流資料
• 兩者都能自動分散工作負載到多個節點

但根本差異仍然存在。

Dataproc 執行 Spark 程式時：

• 你要先建立和維護 Dataproc Cluster
• 使用 gcloud dataproc jobs submit spark 或通過 Web UI 提交 JAR 檔
• Spark 程式會在你開好的 Cluster 上執行
• 叢集資源是固定的（除非手動調整）
• 叢集在任務完成後繼續存在（除非配置為自動刪除）

Dataflow 執行 Apache Beam 程式時：

• 不用預先建立 Cluster
• 提交程式後，Dataflow 會自動建立和管理執行環境
• 資源會根據工作負載 Autoscale
• 任務完成後，所有資源會自動釋放 (刪除 Cluster)

簡言之，Dataproc 執行 Spark 程式時，你仍需管理基礎架構 (Cluster)，而 Dataflow 則完全幫你管理這一層面。

這就是為什麼在某些使用案例中，兩者看起來很相似，

都是提交預先寫好的程式來處理資料，但底層的資源管理和架構哲學是不同的。

Dataproc 和 Dataflow 比較表

工作流程範本 Dataproc Workflow Template

自動化任務排程的關鍵利器

Workflow Templates 用來設定和管理一系列相依的 Dataproc 作業 (Job)，

例如 A Job 必須完成之後，再開始 B Job。

就像食譜，你只需設定好步驟與材料，系統會自動幫你依序完成資料處理任務。

注意建立範本後，Dataproc 不會建立 Cluster 或開始運作。只有在建立機器後才會開始工作。

工作流程範本的種類

代管叢集 Managed Cluster

當你手上沒有運作中的 Cluster，工作流程會建立一個「臨時」Cluster 來運行作業，完成時刪除該 Cluster。

叢集選擇器 Cluster Selector

當你手上有幾個運作中的 Cluster，你可以下標籤來指定做事的 Cluster，有點像 Kubernetes 那種管理方法。

每個 Cluster 都可以設標籤，是 key-value 的結構，例如你有 3 個 Cluster：

cluster-1 的標籤  analytics=ig

cluster-2 的標籤  analytics=fb

cluster-3 的標籤  web=click

你指定 analytics=fb，cluster-2 就會開始做事。

它會選具有完全相同標籤的 cluster 來工作，而且會找具有最多 YARN 可用記憶體的叢集來運行所有工作流程作業。

但工作完，Cluster 會持續存在，不會把你的 Cluster 刪掉。

Dataproc 與其他 GCP 工具整合

結合 BigQuery 快速查詢分析結果

Dataproc 可以使用 BigQuery 連接器在 Spark 或 Hadoop 作業中直接讀寫 BigQuery 資料。

處理完的結果可直接匯入 BigQuery，進行後續報表分析與視覺化。

如果經常使用 Dataproc、Cloud Storage 和 BigQuery，建議使用 Avro 格式的資料，因為完全相容。

與 Cloud Storage 無縫資料串接

傳統上 Hadoop 用 HDFS 在資料的永久儲存，確保資料在系統關閉或重啟後仍然存在。

在 Dataproc 上使用 Cloud Storage 連接器時，可以讓 Dataproc 直接讀寫儲存在 Cloud Storage 上的資料，

無需使用 HDFS。(因為 Dataproc 通常用完就會刪掉環境，上面的 Disk 跟著刪除)

而且 GCS 還比 Disk 便宜。

你可以再搭配 GCS 的物件生命週期管理 Object Lifecycle，有效控管儲存成本。

成本管理與效能最佳化技巧

如何利用預留節點與自動關機功能省錢

使用 Preemptible VM（可搶占節點）節省 80% 成本，但這種主機可能隨時被終止。

建議你用在容錯性高的批次處理工作（可以隨時停下來、即使失敗也可以重試、有備份機制），

也就是「不緊急不重要的工作」。

建議搭配重試機制和優雅停用 (Graceful Decommissioning) 設定，確保正在進行的工作在節點移除前完成。

使用 Cloud Logging 監控資源與效能

透過指標追蹤 CPU、Memory 使用率，找出瓶頸，優化叢集配置。

Dataproc 常見錯誤與排除方式

排查任務失敗的三個關鍵檢查點

• 驗證 Cluster 資源是否足夠，像記憶體是不是快爆了。
• 檢查程式碼是否有錯誤。
• 檢查輸入資料路徑是否正確。

如何讀懂 Job Logs 與錯誤訊息

進入 Job Logs，根據錯誤訊息回推失敗原因，例如記憶體不足、格式錯誤、路徑遺失等。

你也可以直接錯誤的 Log 拿去問 ChatGPT。

適合導入 Dataproc 的企業情境

金融業：批次風險模型計算

金融機構常需夜間批次執行大量風控模型，Dataproc 正好適合這種短時高負載任務。

零售業：銷售資料彙總與推薦引擎訓練

從 POS 資料中彙總趨勢、訓練推薦模型，Dataproc 可有效協助行銷與庫存預測。

當然，可以做批次處理的工具都可以，像上面提到的 Dataflow，取決於你對哪個比較熟悉。

結語：Dataproc 是否適合你的團隊？

如果你的團隊正在處理大量資料，需要彈性資源、自動化流程，

或正從傳統平台轉型到雲端，那麼 Dataproc 將會是你強而有力的幫手。

它不只是工具，更是未來資料基礎建設的基石。

常見問答（FAQ）

Q1：Dataproc 可以不寫程式嗎？
A：可以透過 Workflow Template 搭配 SQL、Hive 指令，降低程式依賴。（所以還是要拿下指令）

真的要不寫程式，可以考慮用 Dataprep，它是互動式並且視覺化的操作界面，可以設定資料處理規則讓它自動執行。

Q2：Dataproc 和 BigQuery 哪個適合分析？
A：BigQuery 適合即時分析，Dataproc 則擅長處理大量轉換、清洗、模型訓練等流程，Dataproc 的分析，主要是拿來探索用的，就是讓你大概看一下資料長怎樣，不方便做大規模而且複雜的分析。

Q3：有支援 GPU 計算嗎？
A：有，可以在 Worker 節點指定使用 GPU 運算資源。

Q4：Dataproc 支援 Python 嗎？
A：完全支援，Spark 任務可用 PySpark 寫成，也可整合 Notebook 開發環境。

Q5：部署後多久能用？
A：幾分鐘內即可建立好叢集，立即上線處理任務。

The post Dataproc 是什麼？四大優勢與使用方法介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

(一) 證照背景與 Google Cloud Platform 的發展

Google Cloud Platform (簡稱 GCP) 是 Google 的雲端平台，提供各種伺服器、負載平衡、資料庫、數據分析和 AI 各種工具，讓你可以架站、部署電子商務平台、做大數據分析和開發 AI 應用。

Cloud Architect 證照是 GCP 第一張推出的證照，比 Associate Cloud Engineer 雲端助理工程師證照還早很多年。

(二) GCP Cloud Architect 認證的核心技能

1. 熟悉整個 GCP 各種常見的服務
2. 根據客戶需求，從 GCP 挑選服務，組合成適合的方案
3. 設計 GCP 的雲端架構
4. 針對主機或資料搬遷上雲的方法評估
5. 優化成本並提高效能

二、為什麼要考 GCP Cloud Architect 認證？

(一) 轉職雲端架構師

如果你沒做過雲端相關工作，必考這張證照，可以做為你求職的敲門磚。畢竟，沒有證照又沒有經驗的你，如何證明你懂 GCP？

如果你是要在 GCP 代理商工作，這張只是基本條件。

那 Associate Cloud Engineer 雲端助理工程師證照不夠嗎？

ACE 證照只代表你會操作 GCP，但在操作之前，你要知道為什麼要執某個操作，就是要懂得思考。例如為什麼要用 BigQuery 而不是 Cloud SQL，為什麼要用 Cloud Armor 而不是防火牆等等。

那不用先考 ACE 證照，才能考 Cloud Architect 嗎？

不用，沒有規定你要先考 ACE，你可以直接考 Cloud Architect。

(二) 增強職場競爭力

對於非 IT 背景的人來說，例如高階主管、行政單位或客戶，你跟他們說你 GCP 很強，他們不知道什麼叫「很強」。

但是你證照拿出來，他們至少會認同這是一個客觀的評價，好歹你是有考過試的人，再怎麼樣也不會差到哪裡去。

(三) 提高薪資潛力

很多公司有對 GCP 證照提供薪資的加給，對於你當前工作，或未來跳槽都很有幫助。

(四) 充份掌屋 GCP 各項服務

如果你沒考過 Cloud Architect，你只會針對你常用的功能熟悉，但你不知道可能有更好用的功能。

考 Cloud Architect 就是要強迫你把整個 GCP 都了解一遍，讓你碰到各種不同情境時，都能找到相對應的解決方案。

三、GCP Cloud Architect 認證適合誰？

(一) 雲端從業人員

證明你真的懂雲端，或至少給外行人看，像政府標案投標，一定是先看你有沒有證照再說。

(二) IT 專業人士

如果你突然被交待要了解 GCP，幫公司搬遷上雲，趕快考取證照是一個強迫你快速學習的方法。

(三) 想轉職雲端產業的人

如果你沒做過雲端相關工作，這張證照可以做為你求職的敲門磚。

四、準備 GCP Cloud Architect 證照的方法

證照考試介紹

考試是 50 題選擇，時間兩個小時，你可以去恆逸資訊或資展國際考試，也可以遠端考試。

考試用費訂價 200 美金，目前都是優惠價 120 美金 (Renew 證照還有優惠喔)。

考試時間則是自己選的，當你選好考場，你就可以找一天考場有開的寺間去考試，但是如果考試近了，你還沒準備好，可以趕快去改時間。

如果你在考試前 72 小時才改，可能會被多收錢，我是沒試過啦。

當你考完之後，這張證照有兩年期限，每次我從 2018 年考過之後，最近是第四次考，這是證照的公開連結。

你可以先去證照的官網查看相關資訊，它會提供考試指南，就是大概會考哪些東西，讓你心裡有個底。

它還有提供範例題目，必看，而且它有詳細的題目解析，不要連送分的都沒掌握到喔！

考試範圍與準備方法

我個人整理的各項服務出題比例依照大類排名如下：

Compute Engine 就是虛擬機器相關，包含 VM、Disk、Image、Snapshot、Instance Template、Instance Group，因為用的人最多，所以考題也最多。

再來是架構綜合性問題，沒有特別針對哪一個服務，就是要考你有沒有架構師的 Sense，什麼時候應該怎麼做，算是觀念類型的問題。

資安則包含身份驗證、Secret Manager、加密、Cloud DLP、Service Control、Org Policy 等等。

DevOps 也是偏向一些觀念和原則，不針對特定服務去考。

然後 GKE 和 BigQuery 也是 GCP 的主力服務，一定要會的。

如果我們再細分成小類，你會發現每個主題，考得「非常平均」。

所以並沒有「只要唸哪一部分就能考過」這種想法，就是「整個 GCP 都要唸過一遍」就對了。

另外，根據業界人士消息，因為生成式 AI 發展快速，導致 GCP 許多服務都整合 AI 的功能，預計今年 Cloud Architect 考題要大改版，但幾月幾日？不知道。

只能說，趕快去考吧！

官方 GCP 學習資源

如果要真的懂 GCP 的各項資料服務，還是先以官網文件為準。

但是文件非常多，而且是「非常非常非常多」，所以你只要大概知道每個服務大概在做什麼就好，不然是不可能讀完的。

你可以讀像是：

Overview 和 Introduction： 大概了解每個服務到底在做什麼。

Best Practice：應該怎麼用比較快、效能比較好、比較便宜、比較安全等等。

Troubleshooting：有問題時應該怎麼處理，要檢查什麼地方。

不要求你看完全部的文件，因為根本看不完。

其實 Google 官方文件很難閱讀，寫得文謅謅的，看不懂就複製貼到 ChatGPT 幫你寫成白話一點的文字，幫助理解。

另外，你也可以上 Google 免費的線上課程，還有免費 Lab 可以做喔！這樣比較有感覺，不然你可能會不知道你到底在讀什麼。

https://www.cloudskillsboost.google/paths/12

如果你對 GCP 已經有基本的了解，那建議你直接找題目來看就好，不要再浪費時間看文件。

有人直接在網路上分享題目，各位請點擊下面這篇文章，裡面有提到相關內容，分享給大家：
https://medium.com/chouhsiang/%E5%BF%85%E9%81%8E%E7%A7%98%E8%A8%A3-%E4%B8%89%E5%A4%A9%E9%80%9A%E9%81%8E-google-cloud-professional-cloud-architect-524405687711

對於這位大神的標題「三天通過」，我建議大家看看就好，像我當年第一次、第二次考 Cloud Architect 都沒過，直到考第三次才過，三次加起來的準備時間也快一年。

即使我現在要再考 Cloud Architect 證照，絕對不是只要花三天就夠了，這是我當初考很多次才過關的證據。

每個人的學歷背景、學習狀況和際遇各有不同，不要看人家很會考就懷疑自己的能力。各位按照自己的步調來準備就好，不要被他影響。

反過來說，如果你是缺乏驅動力，經常拖延的人，那也有一個辦法，就是先報名考試，卡刷下去，你就會開始積極準備考試了 XD。

當然你也可以報名我的 GCP 課程 來學習比較快，置入一下 XD。

Google Cloud Architect 證照考試報名方法

考試報名的網站：

https://cp.certmetrics.com/google/en/home/dashboard

你在註冊時要注意，姓和名要用「護照名稱」，不要用小名像是 Peter 或 Helen 這種，要不然無法核對護照，不給你進考場喔！

這個網站裡面有一個 Access Webassessor，就是去報名考試的地方：

https://webassessor.com/googlecloud

當你進入網站之後，點擊 Register For An Exam，選得要選英文的喔。

然後不要選 Pilot and Beta Exam，它通常是針對「即要大改版的」證照所提供的考試。對 GCP 很熟悉的人才適合去考，像我也不太敢考 XD。

接著選你要去考場考試，或遠端考試。

如果是考場考試，你要把報名完成通知單印出來，還有身份證跟護照，給考場人員檢查。

如果你選遠端考試，你要在你的電腦安裝一個考試軟體，它不是只有出題目而已，它會拍你的考試畫面，避免你作弊。

接下來選考場

然後選擇考試時間，要注意，盡量不要在 12 月到 1 月之間考試，因為……他們都休假去了！！

這是我 2024/12/23 要報名時看到的畫面：

因為我已經讀完了，不可能讓我一直拖到 1/14，所以我就被迫第一次用遠端考試。

當我切成遠端，能選的時間就變多了。

接下來就是付款了，你會看到如果你是要 Renew 延長證照的話，CertMetrics 網站有提供優惠碼，讓你半價就可以考試。

更重要的是，你的姓跟名不要打錯位置，我有一次打錯 (Chrome自動填入)，它刷卡後直手接跳回首頁，沒跟我說我報名成功還是失敗。

當時沒注意到我姓跟名打相反，前後按了三次，第四次才發現我打錯，趕快改回來再刷卡，結果我前三次一樣被扣款，總共扣了四次。

害我後來跟考試網站的客服人員，以及銀行客服人員花好幾天，前後盧了十幾個小時，才終於拿回退款。

最後回到首頁，安裝考試軟體。

開始遠端考試

考前進入網站，剛開始考試連結還不會出現，等就對了，15 分鐘前才會有連結讓你點進去考試：

接下來就不秀畫面了，那些算是機密的範圍。

它會有一個對話視窗，除了驗證身份，還要你舉起電腦的 Web Cam，拍攝你考試場地的四周，確保你的環境很乾淨，沒有其他人，沒有作弊嫌疑。建議各位提早驗證，因為……非常耗時，我弄了半個多小時才真正開始考試。

遠端考試中途不能去上廁所，考場考試可以但時間會照算。

考完會告訴你 Pass 或 Fail，但不會告訴你幾分，也不會跟你說哪題對哪題錯。

過兩天 Google 會再發一封正式的信，確認你真的考過了。

以上分享，祝你考試順利！！

The post [GCP 證照] 轉職必備 Google Professional Cloud Architect 雲端架構師證照介紹、考試心得與準備方式 first appeared on 東東 GCP 教學 - GCP 實戰講師.

一、前言：為何要將主機搬遷上 GCP？

其實將主機搬遷上雲的理由和好處很多，這裡提供三個最重要的理由如下：

(一) 降低成本

GCP 是每月依使用量計費，每月付款，企業可以從一次性大額採購的「資本支出」，轉變成每月的「費用支出」，減低現金流的壓力。

此外，實體機要考慮機房、水電相關設備的建置和維護成本，在管理上也是耗費不少心力。

而公司採用雲端，等於就是把基礎建設外包給專業的 Google，你可以省下許多寶貴的時間，然後專注在開發公司產品或提供服務，為公司創造更大的價值。

(二) 彈性擴充

在地端，你的機器數量是固定的，如果碰到活動期間，需要緊急擴充機器，往往要走採購流程包含詢價、議價、選商，以及後續的安裝建置，等到機器準備好了，活動都結束了。

而在雲端上有所謂的自動擴充 (Autoscale)，你可以在 GCP 主控台上設定擴充的功能，指定要擴充的數量，接著 GCP 會依照當前主機的負載，如果主機太過於忙碌，GCP 會立即增加主機來對外服務。當活動結束，人潮退去時，機器也能自動縮減，不會讓它閒置導致額外的花費。

(三) 創新整合

和其他公有雲相比，Google 的強項就是大數據分析與人工智慧。如果你的系統在 GCP 上運作，可以輕易導出資料到 BigQuery 來分析，發現洞察。你也可以將資料用來訓練模型，開發 AI 應用程式。不需要尋找外部工具，從頭到尾都在 GCP 做完。

當你開發完成，也可以直接在 GCP 上部署 AI 應用，或是做為  API 讓外部來呼叫，這些都是 GCP 內建的功能，讓你從收集資料、開發模型、測試模型到部署 AI 應用，都可以透過 GCP 來達成。

從商業的角度來看，就是加速你回應市場的速度，當市場上有新的技術或是新的商機出現，你就可以快速的在 GCP 取得各種創新資源，讓你可以快速的開發出應用程式，提供給廣大的使用者。 

以上只列出常見的上雲理由，如果你想知道更多，可以參考《企業上雲的10大理由、15個評估面向與6大好處》和《上雲比較貴？雲端和地端的成本詳細比較》這兩篇文章。

二、主機搬遷類型

將主機搬遷上雲有很多方法，我們可以依照系統的狀況 (例如好不好搬遷)，和公司的時間表 (有沒有急迫性或是足夠的人力) 來選擇適合的搬遷類型，這裡分別介紹如下： 

(一) 更換主機 (Rehost)：照原來樣子搬遷 (Lift And Shift)

這種搬遷方式就像是單純的搬家，把所有東西從舊環境搬到新環境，期間只做最少必要的調整。就像是把傢俱從舊房子搬到新房子，只需要因應新房子的格局做一些微調而已。

當你的系統可以直接在新環境運作，或是當業務上沒有需要對系統做太多更改，又或者當你需要快速完成搬遷時，這種方式就特別適合。

這種方式的優勢在於執行起來最簡單，團隊可以繼續使用熟悉的工具和技能，而且支援現成的軟體，最重要的是搬遷速度最快。

但這種方式也有其侷限性，系統無法充分發揮雲端環境的優勢，也無法善用 GCP 的特殊功能，包括自動擴充的能力、更靈活的計費方式。這就像是把老房子整棟搬到新地點，雖然可以快速入住，但無法享受新社區提供的現代化設施。

不過企業會因為各種因素，不得不採用這種方式，例如程式碼太老舊或複雜而不容易修改，或是重新編譯程式很困難，又或者必須持續維持系統運作而沒辦法停機重做。

(二) 更換平台 (Replatform)：重新優化 (Lift And Optimize)

想像一下，這不只是單純的搬家，而是搬家時順便整修。就像是搬到新房子時，不只是搬運傢俱，還會順便更換一些老舊的設備，或是重新規劃空間跟裝潢，讓新家更好用。

把主機內的系統搬到 GCP 上，讓它能用上更新、更有效率的工具和服務。這種搬遷方式最適合那些希望充分運用雲端核心功能的組織，包括彈性運算能力、系統備援、提升效能和加強安全性等優勢。

舉例來說，你可以將應用程式轉移到 GCP，以便使用 Google Kubernetes Engine 提供的微服務架構或容器服務。這樣一來，系統在雲端運行時就能發揮更好的效能和效率。

不過呢，這種搬家方式當然會比單純搬家麻煩許多。因為新環境的設備和系統都不太一樣，所以需要多花時間測試、調整，確保所有東西都能完美運作。就像是要學習使用新家裡的各種 AI 電器，需要一段適應期一樣。

(三) 重構 (Refactor)：徹底改造升級 (Move And Improve)

重構這種搬遷方式就像是趁搬家時，不只是簡單改裝，而是徹底翻新改造，讓系統能充分運用雲端的各種優點，已經不是針對「主機」來搬遷了。你可以針對效能、功能、成本和使用體驗，把每個部分都改造得更好。

這個改造工程可以選擇在搬到雲端時一起進行，也可以提前先做好。就像是裝修房子，如果你是第一次做大規模裝修，可能會想等搬家時再一起處理。但如果你有經驗，就能提前規劃好需要改造的部分，讓系統更好地運用雲端的功能。

有時候你會被迫選擇重構，因為舊系統的架構可能無法直接在新環境中運作。又或者是趁這個機會，你想要對系統做一次大規模的更新和改進。

重構的好處是你的系統可以充分運用雲端平台的特色，例如自動擴充 (Autoscale) 的功能，或是提高系統的穩定性。你還可以讓系統變得更容易在不同平台間轉移。

不過呢，重構需要花比較多時間，畢竟要把整個系統重新改造一番。而且你的團隊可能需要學習新的技術和工具，就像是要學習使用全新的裝修工具和材料一樣。

(四) 重新設計架構 (Re-architect)：全面改頭換面 (Continue To Modernize)

這種搬遷方式和前面說的重構有點像，但更加徹底。它不只是改變系統程式碼的運作方式，而是完全重新設計整個系統的運作模式。

這就像是不只是翻修房子，而是把整棟房子拆掉重建，讓它能充分運用新環境的優點，像是更好的擴充性、安全性和靈活度。

最經典的例子就是從單體式架構（Monolithic）轉換成微服務（Microservices）架構。單體式架構就像是一間大型百貨公司，所有部門（功能）都在同一棟大樓裡，所有服務都綁在一起，任何一個小改動都要動到整個系統。並且擴充時必須整個系統一起擴充，如果有一個地方出問題可能影響整個系統。

而當我們改成微服務架構後，就像是把大百貨拆分成許多專賣店，每個服務都是獨立的小系統，可以個別更新和維護，當需要擴充時，可以只擴充需要的服務。

某個服務出問題時不會影響其他服務，不同的服務可以使用最適合的技術，不一定都要使用虛擬機器，有的可以用 Cloud Run，有的可以用 GKE。

不過要注意的是，這種全面改造比一般的重構更複雜，需要投入更多時間和心力。而且在重建的過程中，可能會不小心引入一些程式錯誤或安全漏洞。

因此，需要進行多次測試，確保新系統的每個部分都能完美運作，就像是新蓋好的房子需要仔細檢查每個管線和設備是否安全可靠。

(五) 重建 (Rebuild)：完全推倒重來 (Remove and Replace or Rip and Replace)

重建就是重寫，就是先把現有的系統停用，然後重新設計並開發一個完全針對雲端優化的全新系統。

什麼時候會選擇重建呢？通常是在這些情況：

• 當你覺得舊系統已經不值得繼續維護
• 當其他改造方式的成本太高
• 當舊系統根本無法在 GCP 上運作

重建的好處是，新系統可以完全發揮 GCP 的優點，像是自動擴充、完整的雲端服務支援，以及超高的系統穩定性。而且因為是從頭開始，你不用被舊系統的技術包袱拖累。就像蓋新房子可以使用最新的建材和設計，不用被舊房子的格局限制。

但是呢，重建需要最多的時間，比其他方式都久。而且因為要重寫整個系統，所以不適合用在現成的軟體上。你需要把重新設計和重寫的時間都算進整個專案的生命週期裡。

另外，你的團隊可能需要學習全新的技術和工具，因為要用新的工具來設定環境並部署系統。這就像是要學習使用全新的建築工法和工具來蓋房子一樣。

(六) 重新購買 (Repurchase)

這種方式最簡單，就像是不想修理舊電器，直接去買新的雲端服務來用，其實就是不搬遷了，直接買新的來用。

舉例來說，與其維護公司自己的郵件系統和檔案系統，不如直接改用 Google Workspace (就是 Google 的企業版 Gmail、雲端硬碟等服務)。

從資源投入的角度來看，這種方式比重構、重建或重新設計架構簡單多了。就像是比起修理老舊的冰箱，直接去買一台新的智慧冰箱來用比較不費心。

不過要注意的是：

• 這種方式的花費可能比較高，因為要持續付費使用服務
• 你可能無法完全掌控系統，因為是用人家現成的服務，就像是租用別人的設備，雖然方便，但無法像自己的設備那樣隨意改造和調整，自由度比較低。而且有可能會被綁住，沒有辦法輕易更換系統，或是匯出資料。

綜上所述，我們可以把各種搬遷類型整理如下：

如果想完整了解搬遷類型，可以參考這份文件。

三、主機搬遷步驟

根據 GCP 官方部落格提到，搬遷的步驟如下圖：

(一) 盤點 (Assess)

在進行搬遷之前，請評估您的應用程式以及它們對 GCP 的適合程度。

需要考慮的事項包括 (但不限於) 硬體和效能需求、使用者、授權、合規性需求和應用程式相依性。

一般來說，應用程式大概分種三種：很好搬、很難搬和不能搬。通常建議先選最好搬的，或是測試中的系統，或是較不重要的應用程式，因為搬遷中碰到問題，畢竟不是核心系統，對公司影響較小。

(二) 測試 (Pilot)

這步驟主要是讓你在搬遷過程中熟悉整個操作流程和 GCP 的搬遷介面，對於複雜的系統也可以測試，尤其是有授權議題的主機，如果搬遷有問題也可以試著回溯 (Roll Back)，確保到時候正式搬遷會有一個 (Plan B) 備用計畫。

(三) 搬遷資料

根據Google官方的說法，建議先搬遷資料到 GCP，再搬遷應用程式，因為你的應用程式要能正常運作，必須要先存取到資料，否則應用程式即使搬上去，因為它撈不到後端的資料，還是會出問題。

在下一段會先分享搬遷主機的方法，你可以先試著搬遷不需要連接外部資料庫的主機，確認都沒問題的話，再搬遷資料庫，最後再搬遷應用程式。

(四) 搬遷應用程式

正式搬遷的時候，盡量保持用最簡單的流程和方法，並且執行最少的操作。 

(五) 優化

在搬遷完成之後，你可以考慮讓你的系統運作的更好。例如增加可用性 (HA)，或是使用自動擴充 (Autoscale) 以及使用監控程式 (OPs Agent)，或是把靜態資料放在 Cloud Storage。

而在實務上，我們通常不會等到搬遷完成才開始優化，而是在搬遷之前，就會依照應用程式的特性，來判斷他適合在什麼樣的 GCP 服務上面運作。前面規劃的越多，後面花在調整的時間越少。 

如果想完整了解搬遷步驟，可以參考這份文件。

四、主機搬遷具體方法

由於大多數使用者在地端運作的系統，都是單台虛擬機器的形式，本段針對大家最常用的「更換主機」 (Rehost) 這一類型，依照使用的工具，分成 Migrate to Virtual Machines 和 VMware HCX 來說明如下。

(一) Migrate to Virtual Machines

Migrate to Virtual Machines 是一個代管的服務，就是一個網頁介面，讓你可以直接在網頁上操作並監控整個搬遷的過程，操作起來非常簡單。

你可以直接匯入主機的映像檔，也可以讓主機平行運作，就是讓地端主機還在運作的同時，複製主機的資料到 GCP 上，複製並確認完後再進行切換動作。

如果你有大量主機要搬遷，你不用一台一台機器手動設定搬遷，你可以把多台主機設定為同一批次，讓他們同時複製資料到 GCP。

不過要注意的是，並非任何作業系統的主機都可以搬遷，目前支援各種 Linux 和 Windows Server 作業系統的 64 位元 x86 虛擬機器，另外也支援 Oracle Linux 作業系統。

但是要注意版本，像是太舊的版本像是 CentOS 6 雖然可以搬上 GCP，但是主機有問題，GCP 是無法提供技術支援的喔！對於支援的作業系統完整清單，可以參考這份文件。

以下分別描述 Migrate to Virtual Machines 各種搬遷方法：

1. 匯入主機檔案

(1) 匯入虛擬機磁碟映像檔 (Virtual Disk Images)

如果你手上有現成的虛擬機磁碟映像檔，可以直接匯入，完成之後可以馬上用這個映像檔，在 GCP 建立和地端一樣的虛擬機器。

虛擬機磁碟映像檔支援的格式包含：VMDK、VHD、VHDX、VDI、QCOW、QCOW2、QED 等，也支援 .tar.gz 檔案，你要確保壓縮檔案包含名為 disk.raw 的單一檔案。

不過要注意的事，這個虛擬機磁碟映像必須要先儲存在 Cloud Storage，所以你必須要先上傳檔案，然後再去 Migrate to Virtual Machines 的主控台上匯入它。

而在匯入之前，由於 Migrate to Virtual Machine 這個服務背後是有一個 Service Account 在運作，而它目前沒有權限去 Cloud Storage 存取任何檔案，所以我們就先去給它賦予權限。

我們進入「IAM 與管理」=>「身分與存取權管理」=>再勾選「包含 Google 提供的角色授予項目」：

接著視窗往下滑，會你看到像這樣的 Service Account：

service-xxxxxxxxxx@gcp-sa-vmmigration.iam.gserviceaccount.com

接著點擊 VM Migration 服務代理右邊的鉛筆圖示：

接下來就可以把你準備好的 VMDK 檔案上傳到 Cloud Storage：

上傳完成之後，你就可以點擊 Compute Engine 的 Migrate to Virtual Machines。接下來可以點擊「映像檔匯入作業」：

接著再點擊「建立映像檔」：

接著它就會進入建立映像檔的畫面，首先就是在 Cloud Storage 選擇要匯入的檔案，接著由於虛擬機映像檔會轉換成 GCP 格式的映像檔，所以我們要另外選擇儲存的位置，看你要多區域 (例如 Asia) 或是單一區域 (例如 asia-east1) 都可以：

當我們選好檔案跟儲存位置後，再選擇要儲存映像檔的專案，因為你手上可能有不只一個專案，它讓你不一定只能使用現有的專案，可以選擇匯入到其他你有權限的專案。

但你點擊下拉選單之後，你會發現沒有目標專案可以選，因為它必須要事先勾選起來，才會在這個畫面看到可以選擇的專案。但是沒關係，我們也可以在這裡直接設定，點擊「管理目標專案」：

點擊之後，它會開啟新的視窗，我們再點擊「新增目標專案」：

接下來它會彈出一個視窗，讓你勾選目標專案，我們勾選後就按下新增：

接著畫面會跳轉到目標專案，你可以再確認一次：

再回到原來的分頁，按下「重新整理」：

等待幾秒之後，專案就秀出來了，選擇這次要建立映像檔的目標專案：

上述相關欄位設定好之後，會看到像這樣的結果。其中還有兩個選項需要注意。

(1) 略過 OS 調整作業：

指的是為了讓你在地端的主機可以在雲端上運作，它需要做一些調整，才能讓它在 GCP 上開起來。包含：

・Serial Console (讓你在SSH無法連線時還能操作主機)

・網路設定 (讓主機可以連到 VPC 內的主機、其他 API 和上網) 

・Cloud SDK (讓你可以下 gcloud 指令操作 GCP的資源)

如果你匯入的映像檔不是拿來當作開機碟，那可以勾選「略過 OS 調整作業」，如果是，就不能勾選，要不然主機會無法在 GCP 成功開啟。更多細節可以參考這份文件。

(2) 一般化：

通常是針對 Windows 作業系統，因為 Windows 作業系統會有一些「針對該主機的識別資訊」，例如 SID (Security Identifier)，勾選「一般化」可以將其識別資訊洗掉，以便部署到其他地方，才不會有識別碼衝突的問題，而 Linux 沒有這方面的問題，不用勾選。更多細節可以參考這份文件。

如果都沒問題的話，可以按下「建立」：

接下來畫面跳轉到 Migrate to Virtual Machines 主頁，看到正在匯入映像檔的訊息：

我們等待一下，因為這個動作都在 GCP 上進行，我們可以關掉視窗，稍後再回來查看即可。

接著我們就看到 VMDK 檔案已經匯入成功，看到它已經成為 Compute Engine 的 Image 了。

接下來我們可以直接點擊箭頭圖示，直接轉到 Image 的頁面：

然後點擊「建立執行個體」，把它開成一台 GCP 的主機：

就跟一般建立機器的步驟一樣，我們給主機取名字，並選定規格：

其他參數可依照你的需求設定，沒問題就可以按下「建立」。

過幾秒後看到主機建立完成，我們點擊 SSH 按鈕：

看到 SSH 視窗成功開啟，代表我們從地端匯入 VMDK 檔案成功囉！

如果你的機器能開機，但是連不進去的話，先不要慌，你還是可以透過 Serial Console 調整一下主機，可以參考這份文件。

(2) 匯入機器映像檔 OVF, OVA

這個方法跟前一個幾乎一樣，都是先把檔案上傳到 Cloud Storage。但不同的地方是，前段的映像檔只有開機磁碟而已，如果你的主機有加掛磁碟的話，你就必須再匯入另一個映像檔，等到兩個映像檔都匯入完成，再用第一個映像檔來開機，再手動掛載另一個映像檔的磁碟。

機器映像檔則是直接包含一台主機所有的磁碟，如果你匯入機器映像檔，你就不用手動匯入多個檔案了。

首先我們點擊「建立機器映像檔」：

我們一樣設定作業名稱、來源、部署區域、目標專案等等，沒問題就按下建立：

接著就等它開始作業，我們可以在畫面上確認機器映像檔匯入的進度：

確認匯入成功後，一樣進入機器映像檔管理控制台，用機器映像檔來建立機器：

我們在主機列表看到機器成功建立，接著點擊 SSH 按鈕：

接下來就看到 SSH 連線成功的畫面，確認匯入成功。

關於匯入映象檔或是機器映象檔，還有一個更簡便的方法，不過它是使用 gcloud 指令來操作 你可以參考這份文件。 

上述方法最容易卡住的地方，就是我們要匯入的檔案有問題，可能是作業系統或是檔案格式的問題，造成匯入失敗的機率很高，所以請再匯入之前多確認映像檔的內容。

2. 從地端 VMware 環境搬遷主機或 Disk

這個方法的前提是你在地端必須要有一個 vSphere 資料中心，然後再搬遷之前會有一系列的前置作業，讓你的地端和雲端可以連接在一起，之後才能開始搬遷，如下圖：

雖然比較麻煩，但是它可以針對大批的主機一口氣快速搬遷，而不是像上述方法一台一台操作。

此外，因為主機是在 VMware 環境，搬遷到 GCP 有比較高的相容性，所以這個方法成功率高很多。 如果你在地端有大量的主機需要搬遷，強烈推薦使用這種方法。

搬遷的前置作業分述如下：

(1) 挑選一個主要專案 (Host Project)

如上圖，我們在雲端上有多個 GCP 的專案，你可以挑選一個主要的專案 (Host Project) 來負責執行搬遷工作，但是你搬上來的主機不一定要部署在這個專案上，你也可以部署到另外一個專案上去。

(2) 啟用相關的 API
由於搬遷過程中會呼叫 GCP 各種不同的 API，所以我們要事先啟用，這裡提供一個快速的指令，讓你可以直接複製貼上，然後在 Cloud Shell 或是你有安裝 gcloud CLI 的電腦執行：

gcloud services enable vmmigration.googleapis.com servicemanagement.googleapis.com servicecontrol.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com compute.googleapis.com

(3) 授權給相關人員

如果有許多人員要參與搬遷，你可以授權這兩個角色給相關的人員：

VM Migration Administrator：是給執行搬遷的人員使用。

VM Migration Viewer：如果其他的人想要查看搬遷的相關資訊，不直接動手操作。

(4) 在 vCenter 建立使用者帳號

因為我們會在 vSphere 建立一台主機，並且安裝 Migrate Connector，而這個 Migrate Connector 需要有一個使用者的帳號，並且要擁有相關權限，才能夠呼叫  vCenter的API，去把 VMware 主機的資料拉出來並且搬到雲端上。

(5) 在 GCP 準備一個使用者帳號和服務帳戶

這個使用者帳戶必須要有權限，才能註冊 VMware 上的 Migrate Connector 主機到 GCP。它只有在註冊的那一刻需要相關的權限，只須執行一次性的註冊動作。

而在 GCP 上面也要有一個服務帳戶，用來存取 19 項 GCP 資源，來完成搬遷的動作。 如下圖：

(6) 設定網路存取

在 GCP 這邊，因為都是開放的 API，比不需要特別再去設定，反而是地端那台 Migrate Connector 主機，要確保網路流量可以存取得到 vCenter、vSphere 和上網存取 GCP 相關服務。如下圖：

如果防火牆也有限制，要記得開放存取到 *.googleapis.com 和 gcr.io 這兩個網域喔！

(7) 建立連線到 Migrate Connctor 所需的 Key

為了要安全的連到 Migrate Connctor ，你必須建立一組金鑰，等到這台機器建立完成，你就要透過這個金鑰連線進去操作。你可以在任何地方使用 ssh-keygen -t rsa 這個指令來建立金鑰，如下圖我們是用 Mac 本機電腦來建立的：

(8) 安裝 Migrate Connctor
接下來環境切換到 vSphere，點擊 Deploy OVF Template 然後貼上 Migrate Connector 機器映像檔的網址：

接下來等它安裝完成，看到主機的資訊如下：

(9) 連線到 Migrate Connector 主機並註冊到 GCP 

我們使用 SSH 連到 Migrate Connector 主機之後，輸入 m4c register 開始註冊，經過一連串的互動操作，可以看到註冊成功的畫面：

我們回到 Console 上就會看到地端的機器列表，這時我們就可以選定要搬遷的主機：

雖然是將主機一模一樣的搬到 GCP，但是我們並不一定要使用一模一樣的規格，我們可以設定部署的規格跟環境：

接下來就開始進行資料複製的動作，等到複製完成，我們可以先點擊「Test-Clone」，來觀察資料是否都複製完成，它會建立一台測試機，讓你進去檢查。如果確定都沒問題的話，我們再點擊「Cut-Over」 ：

最後我們可以在 Console 上看到主機切換完成的相關訊息：

這裡要注意的是，它的「切換」會把原來的地端主機「直接關機」，如果你不希望機器被關，目前的方法就是再手動把它開起來。 

很多使用者會藉由這個功能，執行雲地資料同步的動作，不過不算正規方法，所以沒有備份的保證喔！只是因為做起來很方便，單純分享給各位參考！

(二) VMware HCX 

GCP 本身可以建立一個純粹的 VMware 環境在雲端，叫做 VMware Engine，而這個環境可以和地端的 VMware 環境連結在一起。既然兩邊都是 VMware，就可以使用 VMware 本身的 HCX 將地端的主機無縫的搬遷到雲端上，但不是 Compute Engine 主機的形式，而是 VMware 格式的主機。

所以它具體的搬遷方法是由 VMware 所發展的， GCP 就只是提供基礎建設，讓 VMware 可以在 GCP 上面順利運作，整合概念圖如下：

而這樣的服務要在 GCP 上開起來，必須要使用通過 VMware 認證的主機，我們可以從「VMware Engine」進入「私有雲」，然後點擊「建立私有雲」 ：

接下來你會發現台灣 (asia-east1) 並沒有提供這樣的環境，VMware Engine 離台灣最近的資料中心在新加坡 (asia-southeast1)：

另外我們在設定節點數量的時候，系統會要求至少要三個節點以上，而每個節點的規格是 72 個 vCPU和 768 GB 的記憶體，以及1.92 TB 的 Disk 空間，可以知道它的費用不低，有一定規模的跨國企業才有機會使用這樣的服務：

我們在 YouTube 看到有人示範 HCX 操作的畫面，功能和 Migrate to Virtual Machines 很像，首先就是勾選要搬遷的主機：

接著我們就設定主機要搬遷的目的地：

在設定的過程當中，也可以設定目的地的主機規格和環境參數，你還可以設定搬遷的排程，例如在幾月幾號的幾點開始搬遷。

開始搬遷之後，你也可以在畫面上看到搬遷的進度：

關於更多 HCX 的操作細節，可以參考這份文件。

另外這樣的規模通常都不小，我們可以聯絡代理商或是 Google 原廠，來提供相關的技術服務喔！

五、結論

最後我們總結從地端搬遷主機到 GCP 的方法，整理比較表如下：

不管你是哪一種企業規模或是場景，都建議你先從匯入映像檔的方式開始，不是真的要你在正式搬遷都用這個方法，而是要你藉由這個動作，去熟悉整個搬遷的流程、細部操作和相關的注意事項，讓你了解搬遷過程的全貌。

這樣才能在正式搬遷之前，做好完整的評估和規劃，和搬遷失敗的處理方式，讓你確保在公司系統照常運作，影響最小的前提之下，讓搬遷順利成功。

本文同時刊登於：

【東東老師 X 思想科技】地端主機如何搬上 GCP？（上）

【東東老師 X 思想科技】地端主機如何搬上 GCP？主機搬遷具體方法（下）

The post [GCP 教學] 地端主機如何搬上 GCP？各種方法和步驟詳解 first appeared on 東東 GCP 教學 - GCP 實戰講師.

你可以管理這個專案中的所有資源，愛怎麼用就怎麼用。

但如果你今天是在一家公司裡，一個專案可能會跟同事或其他部門的人一起使用， 如果企業夠大，有專業分工，甚至會有管理網路的、管理主機的、管理負載平衡的、還有專門管理帳單的人。 

所以我們就必須切分成不同的權限，讓大家各司其職的同時，不影響其他人的操作，也能兼顧資訊安全，這就是為什麼我們要了解 Cloud IAM。

一、Cloud IAM 簡介

(一) Cloud IAM 是什麼？

Cloud IAM，全名 Cloud Identity and Access Management，直譯為身份和存取管理。

就是 GCP 的角色和權限管理系統，管理「誰」可以進入「某個區域」做「什麼事情」。

由此可知它有三個元素：

1. 「誰」指的就是一個身份

又叫做「主體」(Principal)。

2. 「某個區域」就是「資源」

像是 VM、Disk 或 Cloud Storage Bucket 都是資源。

3. 「什麼事情」指的是具體的操作行為

也就是細分的權限，例如建立 VM、修改 VM 參數、讀取 VM、刪除 VM 等等。

所以 Cloud IAM 就像是 GCP 的門禁系統，確保「對的人」可以存取「對的資源」，並且只能進行「被允許的操作」。

(二) Cloud IAM 有什麼前提？

這裡指的是 Cloud IAM 可以管理的帳號，分成以下幾種狀況：

如果你本來就是使用 Gmail 或是 Google Workspace，當你啟用 GCP 的環境，你的帳號就可以直接用在 Cloud IAM。 

如果你使用的不是 Google 的帳號，例如你可能使用微軟的 M365，或是其他的郵件系統，你會看到像這樣的錯誤訊息：

代表這並不是一個 Google 帳號，你就必須要申請 Cloud Identity，讓你能夠建立 Google 的帳號， 這樣就可以使用 Cloud IAM 了。

而可以被授權 Cloud IAM 角色的對象我們稱為主體 Pricipal，而這個主體並不是只有帳號，還包含了 Google Group (群組)，還有 Service Account (服務帳號) 跟網域，這些都是都是可以在 Cloud IAM 裡面，被賦予角色權限的對象。 

二、Cloud IAM 的角色與權限的介紹與運作方式

(一) Cloud IAM 的角色與權限的關係

在 GCP 的專案環境中，每一個對資源的操作，有可能包含一個以上的權限，像是建立一台 VM，可能至少包含以下權限：

• compute.instances.create  (建立 VM)
• compute.disks.create (建立開機磁碟)
• compute.networks.use (讓 VM 連接到某個 VPC)
• compute.subnetworks.use (讓 VM 連接到某個 Subnet)
• compute.images.useReadOnly (使用一個作業系統的 Image，例如 Ubuntu)

而目前在一個 GCP 專案中，截止目前 (2024年11月21日)，已經有超過 10000 個細分權限，如果我們直接設定這 10000 個權限分配，應該會設定到懷疑人生。

而且這個權限數量，還隨著 GCP 新推出的服務持續增加當中。以專案擁有者，幾乎擁有全部的權限數量如下：

為了簡化管理，GCP 把相關的權限群組起來，依照使用的場景或是執行的操作， 劃分成不同的「角色」 ，這樣我們就能方便地管理大家的權限。 

補充一下，GCP 的帳單角色，不直接屬於專案，而是和帳單帳戶 (Billing Account) 綁定的，運作方式有些不同，未來會再專文討論。

(二) Cloud IAM 的角色類型

Cloud IAM 的角色有三大類，分述如下：

1. 基本角色 (Primitive Roles)

之所以叫「基本」，就是以簡單粗暴的方式來劃分權限，許多小公司或個人使用者都是用這類的權限，就是因為簡單，我們從權限由大到小說明如下：

(1) 擁有者 (Owner)

當你第一次進入 GCP 主控台，GCP 會用你的身份來建立一個專案，而你就是專案的擁有者。

你擁有在這個專案裡全部的權限，看得到所有資源和資料，也可以任意更改，你也能夠管理任何帳號被分配的角色和權限。

(2) 編輯者 (Editor)

編輯者能看到專案內所有資源的內容，也都能修改，像是開機器、關機器、建立負載平衡器，這些都做得到。

編輯者和擁有者的權限很接近，就差在不能管權限，你沒有辦法授權別人進來這個專案，或者是把某個成員踢掉。

(3) 檢視者 (Viewer)

檢視者在這個專案裡面的東西，你全部都可以看，可是你不能改，但是全部都看得到，權限也是蠻大的。

你可以看到專案內開了幾台機器、所有的 Cloud Storage Bucket 都能點進去看儲存了哪些檔案、 BigQuery 裡面有哪些表格和裡面的資料，全部都看得到，甚至可以下載到你的電腦上。

(4) 瀏覽者 (Browser)

瀏覽者的權限是最小的，它只能讓你知道，手上有一個專案叫做 dong-dong-gcp-4-cloud，並且能夠進入資訊主頁，看到這個專案的基本資訊，僅此而已，但裡面所有資源的內容都完全看不到。

2. 預先定義的角色 (Predefined Roles)

由於基本角色的權限劃分比較簡單粗暴，方便好用，但這種方式給出的權限都有一點太大了。

對於公司規模較大，在部門專業分工的情境下，就可以使用預先定義的角色。 這種角色就是依照使用者在公司賦予的任務之下，授權相對應的權限。 

例如：

(1) 只管虛擬機器的人，就可以給他執行個體管理員 (Compute Instance Admin)；

(2) 管理 VPC 和 Subnet 的人，可以授予 Compute Network 管理員；

(3) 管理防火牆的人可以授予 Compute Security 管理員； 

(4) 管理上述全部的人，可以直接授予 Compute 管理員；

(5) 而管理整個專案資訊安全的人，卻又不管理虛擬機器和網路的人，可以授予 Security 管理員。 

這樣感覺很複雜，我們整理如下表：

你可以看出，每個權限都可以縱向擴充 (網路相關權限包含資安)，或是橫向擴充 (資安相關權限包含網路)。

而且不是只有管理員，GCP 的每一個服務也都能再細分成編輯者和檢視者。

而且上述只針對虛擬機器和網路，GCP 還有各種服務如 Cloud Storage、Cloud SQL 和 BigQuery，各自又區分出不同的角色。由此可見，角色區分地非常細。 

只要公司有對於權限或資安有較高的標準和規劃， 都可以依照分工和職責去給予不同的角色。 但反過來說，也會需要專人來負責管理權限劃分，以免造成授權混亂的情形。

3. 自訂角色 (Custom Roles)

因為預先定義的角色是用服務或屬性來劃分每個角色擁有的權限， 但是如果一個人的職責橫跨不同的服務，例如他同時管理虛擬機器和 Cloud SQL 資料庫，你就必須同時給予兩種角色，或是使用一個自訂角色配上相關的權限。 

這種方式可以對每個人的權限做最細緻的管理，做到「剛好必要」的權限分配。但這就需要一個專門的人員，除了了解 GCP 的每一項操作產生的結果，也要知道該行為涉及哪些權限。

因為當這個制定角色開通並且授權出去之後 ，使用者可能會在過程中會發現提出某個功能的操作權限不足，然後再回報給自訂角色管理人員， 來來回回重複確認和測試，並且調整權限，過程會很耗時。 

而且這個過程很有可能是會持續發生的，隨著使用者對於 GCP 的操作越來越深入或廣泛， 所以會持續提出增加權限的需求。 

同時  GCP 的服務也會持續的成長，每個服務的功能也會越切越細，導致新的權限不斷產生，然後再持續調整授權。 如果沒有專屬的角色管理人員來處理的話， 很容易讓權限管理變得混亂。 

因此通常建議使用預先定義的角色就好，除非公司專業分工到了極致，再考慮使用自訂角色。

(二) Cloud IAM 的基本授權操作

主選單有一個 IAM 與管理，進去後會直接顯示「身分與存取權管理」的頁面，它會列出在一個 GCP 專案內，所有帳號授權的角色有哪些，如果要授權給新的帳號，就點擊「授予存取權」。

接著在「新增主體」欄位輸入要授權的帳號，選擇要指派的角色，因為角色非常多，要慢慢找，或著是先去「角色」頁面看好要授權的角色，把名字複製起來，貼在角色的搜尋欄位裡面。

有一點要注意的是，如果你今天是授權專案擁有者給別人，系統會發信通知對方，但是其他角色的授權不會發信通知。

所以當你授權其他角色之後，你就把專案的網址直接傳給對方，讓對方方便進入你的專案操作。 

(三) Cloud IAM 角色和權限的繼承機制

上述只提到專案和資源的範圍，而在整個 GCP 的組織架構裡，總共分成 機構 (Organization)、資料夾 (Folder)、專案 (Project) 和資源 (Resource) 四個層級。

權限會從上而下繼承，代表在機構層級授予的角色，會應用到所有資料夾、專案和專案內的資源。

如上圖，如果你在 Team B 資料夾層級授權 Viewer 給同事，他就可以看到 Project 1 和 Product 2 底下所有的專案，以及專案之下所有的資源。

如果你在 Production Project 又授權 Editor 給同事，因為 Editor 角色涵蓋的權限比 Viewer 多，所以會覆蓋原本 Viewer 的權限，同事在專案就擁有 Editor 角色的所有權限。

在專案層級，如果你是在 Test 專案授權 Compute Instance Admin 給同事，他就可以連到 Test 專案裡所有的虛擬機器。

那假如只想給同事連到其中一台機器怎麼辦？

在 IAM 授權的介面中，還有一個條件 (Conditions)，這裡可以設定到最細的資源對象，甚至連授權的時間都可以規範，不過要注意目前還是 Preview 階段，建議多反覆測試再使用，詳細的說明可以參考這份文件。

三、Cloud IAM 設定中常見的注意事項

(一) 遵守最小權限原則 (Principle of Least Privilege)

1. 最小權限原則主要三個基本原則

(1) 使用者只能擁有完成其工作所需的最小權限，也就是剛好必要的權限。

(2) 如果可以的話，權限的範圍和時間都應該最小化。

(3) 預設拒絕所有權限，只開放必要的存取

2. 最小權限原則的比喻

可以想像成一個飯店的房卡系統：

(1) 住客的房卡只能開啟自己的房間。

(2) 清潔人員的房卡有時效性限制，例如從退房期限開始 (中午 12:00) 到新客入住之前 (下午 15:00)。

(3) 經理雖然是主管，但是他也只能進入辦公室區域，不能進入住客的房間。

3. 最小權限原則在 GCP 的正式做法

(1) 優先使用預先定義的角色或自訂角色

(2) 除非真的別無選擇，否則盡量不要用基本角色

(3) 可以使用 GCP 的「角色建議」和「政策模擬」來找出最適合的角色

角色建議 (Role Recommendations) 功能，它是由 IAM Recommender 所產生的，它會主動提示目前授予的角色，是否包含太多權限，確保你能夠遵守最小權限原則，詳細說明可以參考這份文件。

我們在 IAM 的主畫面就可以看到，它提示了某個授權設定包含 9003 個超額權限。

當我們點擊它所提示的超額權限之後，它會秀出建議替換的角色，並且分析權限數量的變化。

政策模擬器 (Policy Simulator) 功能則是讓你在變更某個帳號的角色時，讓你預先確認變更前後的差異。如下圖我把一個帳號從 Secret Manager 密鑰存取者改成Secret Manager 密鑰管理員：

若我們按下測試變更，會看到它模擬變更後會有什麼結果：

要注意它列出來的存取權變更，是根據前面 90 天的操作記錄來分析，如果你像我一樣，90 內曾經刪除過某些資源的話，它就會顯示「狀態不明或發生錯誤的存取權」，所以如果可以的話，最好能夠逐條確認變更後的影響。

(二) 個人帳號務必啟用兩步驟驗證

如果駭客今天不是駭入你的主機或程式，而是直接破解你的密碼，那它就有可能做出任何毀滅性的事情，例如瘋狂開你的機器來挖礦，或開啟殭化電腦去攻擊其他系統，所以這是根本且必要的步驟。

如果可以的話，最高管理員請使用 Security Key，長得有點像隨身碟，以後兩步驟驗證的第二步驟，就可以插入金鑰來驗證。

(三) 設置兩個最高管理員

如果你目前只有專案層級，那就是設定兩位擁有者，為什麼呢？

曾經發生過一家中小企業，老闆要工程師使用 GCP，但工程師用自己的 Gmail 來申請 GCP，而且沒有授權給老闆。有一天工程師離職了，沒有交接 GCP 的專案，直接人間蒸發，老闆從頭到尾都沒有被授權 GCP 專案，等於員工直接帶走公司的重要系統和資料。

如果為此向 Google 提交技術支援申請，Google 基於本身的條款，不會介入任何 GCP 的操作，就是不可能直接把那個專案還給老闆並且把工程師踢掉。

所以第一個方法就是至少要有兩位擁有者，第二個方法則是，不要用 Gmail，而是使用 Cloud Identity 來創建一個機構，如果工程師在專案是擁有者，老闆是機構管理員，還可能把專案的權限拿回來。

同理，如果你是已經有 GCP 的機構層級，那也要設定兩位機構管理員，一方面防止上述情形發生，另一方面則是防止帳號被駭客盜走，至少另一個帳號還有機會阻止駭客。

(四) 善用稽核記錄 (Audit Logs)

GCP 預設會自動記錄每個使用者的操作，如果有人做了什麼異常的行為，都會被記錄起來，但有些 Data Access Logs 預設沒有開啟，你可以評估有哪些重要服務要開啟記錄功能。

要注意額外開啟的 Log 會佔用 Cloud Logging 的儲存空間，如果想要節省費用，可以匯出到其他地方保存。

(五) 在機構層級管理跨專案存取的 IAM 政策

如果你有多個專案，在機構層級設定 IAM 的話，你只要設定一次就好，而不用每個專案都設定一次，如果公司常常新增或刪除 GCP 專案，這樣可以避免有哪一個專案沒設定到。

另外，可以針對部門成員建立群組 (Google Group)，這樣就可以透過群組統一授權，也能避免人員異動，而沒有被授權到相關權限。

最好的方式就是，各個部門都有各自的資料夾，資料夾底下就是部門自己擁有的 GCP 專案，然後資料夾直接分配授權給部門群組，或是主管，這樣就能更方便地管理全公司的 IAM。

四、 Service Account (服務帳戶) 簡介

Service Account 是一種特殊的 Google 帳戶，設計用來代表應用程式或服務，而不是人類使用者。它能夠執行指定的任務並存取必要的資源。

和人類使用的帳號比起來，Service Account 的使用頻率更高，像我們人類平日會上下班，假日會休息，而 Service Account 是和程式綁在一起，全年無休 24小時運作的，因此它更顯得重要，本文特別拉出來單獨說明。

(一) Service Account 的功能和特色

1. 提供應用程式授權，以操作 GCP 資源

Service Account 的主要任務之一是提供授權給應用程式，允許它們存取和操作 GCP 資源。

無論是存取 Cloud Storage 中的檔案，還是對 BigQuery 的表格查詢，Service Account 都能做為應用程式的「身份」，確保只有經授權的應用程式能與資源互動，避免未經允許的存取行為。

2. 基於身份和角色的存取控制

Service Account 在 Cloud IAM 中也是被授權的「主體」，你可以授予任何需要的角色來取得權限，讓 Service Account 能操作 GCP 的資源。

例如，某個 Service Account 可以被授權僅限讀取 Cloud Storage 資料，而另一個 Service Account 能被授權操作 Compute Engine 資源 (例如給 VM 開機或關機)，這種細微的權限控制提高了整體的安全性。

另一方面，上述提到的自訂角色，設定給一般使用者，由於使用者操作 GCP 所需的權限較多，實際執行起來有點麻煩。

但是如果是給 Service Account 使用自訂角色，反而是好的，因為你可以真的只給 1~2 條必要的權限，真正符合最小權限原則的精神。

3. 提供安全的 API 呼叫和資源操作方式

我們人類在 GCP 的任何操作，背後都是 AP 在運作的。而應用程式需要透過 API 與 GCP 服務互動時，Service Account 會以它的身份進行授權並簽署 API 請求。這樣能確保通訊的安全性，避免敏感資料在傳輸過程中被駭客攔截。

而且，Service Account 的 Key 還能進一步加密對 API 的呼叫，提供額外的保護。

(二) Service Account 的運作流程

如下圖所示，Service Account 的運作流程可分為以下四個步驟：

1. 應用程式保存著 Service Account Key 的 Json 格式金鑰檔案，裡面包含 GCP Project ID、Service Account ID 和 Key 的內容。

2. 當需要存取 GCP 服務時，應用程式使用這個 Json Key 來呼叫 GCP 的 API 進行身份驗證。

3. GCP 驗證金鑰的有效性，並確認對應的 Service Account。

4. 驗證成功後，應用程式可以使用該 Service Account 被賦予的角色和權限存取 GCP 服務。

(二) Service Account 的常見使用情境

1. 自動化工作流程

GCP 提供的 CI/CD 工具如 Cloud Build 和 Cloud Run，能幫助開發人員簡化軟體的編譯、測試與部署流程。

這些工具在運作過程中，通常需要訪問其他 GCP 資源，例如讀取 Cloud Storage 中的設定檔，或寫入結果至 BigQuery，此時就必須要使用 Service Account。

Service Account 為這些工具提供授權，確保它們能安全地訪問資源，同時避免人為操作的繁瑣與潛在錯誤。這不僅提高了工作效率，也降低了安全風險。

2. 跨系統間的安全通訊

應用程式通常需要在各個服務之間通訊或傳輸資料，例如從 Cloud Storage 中讀取資料，並透過 BigQuery 分析處理。而通訊必須以安全為首要考量，否則可能導致敏感資料洩露出去。

Service Account 可以充當服務之間的信任橋樑，透過授權的 API 呼叫，Service Account 確保只有經過允許的服務才能執行特定操作。

此外，它還能限制操作範圍，避免過多的權限導致潛在風險，這點非常重要。這樣的安全機制，不僅保護了資料的完整性，也簡化了跨服務整合的流程。

3. 第三方應用整合

在許多情境下，企業需要將 GCP 資源與第三方應用程式串接。例如，某些外部程式需要訪問您的 Cloud Storage 或監控你的虛擬機器的效能指標。為了保障安全，為這些第三方應用創建專屬門的 Service Account 是最好的方法。

專門的 Service Account 能夠以最小權限原則給予角色，只讓它存取必要的資源。同時，這種設計方式也能確保第三方應用與內部服務之間的存取控制是清晰且可管理的。

一旦某個第三方應用不再需要訪問資源，刪除其對應的 Service Account 就可以立即撤銷其權限，提升整體安全性。

(三) 如何建立和管理 GCP Service Account

1. 建立 Service Account

主選單「IAM 與管理」的「服務帳戶」，點擊「建立服務帳戶」。

接下來給 Service Account 命名，建議取一個容易了解的名字，或是設定一個命名原則，在說明欄也寫清楚這個 Service Account 的用途，讓其他人都看得懂。接下來按「建立並繼續」。

接者設定要授予 Service Account 的角色，這個動作在 IAM 的主畫面也可以設定，GCP 在這裡是給你方便一起設定，如果還不確定要授予什麼角色，也可以先跳過。

如果你按「繼續」，下一步驟是把 Service Account 的存取權給使用者，這一步請跳過！！直接按下完成。

你可能會覺得奇怪，這個步驟在做什麼？為什麼要跳過？

因為這個動作是把 Service Account 的使用權給使用者，使用者會取得這個 Service Account 的所有權限，例如使用者原本只有 Compute Instance Admin 角色，只能管理虛擬機器，結果他拿到一個 Service Account 的存取權限，而這個 Service Account 可以存取 BigQuery 所有的資料，等於這個使用者也能看到 BigQuery 的資料。

所以這個動作會讓使用者的權限範圍擴大，違反最小權限原則。

除此之外，使用者透過 Service Account 存取資料，會繞過正常的權限管理機制。因為系統日誌只會記錄 Service Account 存取資料的記錄，追蹤不到實際的操作者是誰，如果發生資安事件，也會阻礙調查。

就像你是大樓的管理員，Service Account 就像是公司的門禁卡，使用者小明是員工，GCP 的服務就像是大樓裡的不同房間。

小明只能進入一樓茶水間和三樓的辦公室，結果你把你的門禁卡給了小明，小明突然可以進入所有樓層，包括機密檔案室！

而大樓的監視器只會拍到「有人用公司門禁卡進出」，但不會知道用門禁卡的人是誰。如果小明把資料帶出大樓，或是銷毀，沒有人會知道是小明做的。

所以這個動作，除非你熟悉會有什麼後果，如果不懂最好不要授權給使用者。

按下完成之後，你可以點擊 Service Account 的名稱，進入它的詳細資訊頁面。

在這裡你會看到專屬 ID，如果你再展開下方進階設定，還會看到用戶端 ID，這些都是機密資訊，不要隨便分享。

尤其是「網域層級委派」，這是一個在 Google Workspace 中的「超級無敵大權限」，它可以看到公司內所有人的雲端硬碟檔案，如果不懂絕對不要設定。

2. 建立 Service Account Key

如果你的 Service Account 是要讓外部的應用程式存取 GCP，就要再建立 Service Account Key。這時我們再點擊「金鑰」頁籤。

下方會看到「新增鍵」，這是 Google 翻譯得不好，其實就是「新增金鑰」，然後再「建立新的金鑰」。

點擊之後會彈出一個視窗，問你 Service Account Key 的檔案要下載成什麼格式，通常我們都用 Json 格式。

按下「建立」之後，會自動下載金鑰檔案到你的本機電腦。

這裡要注意，我們只有在建立金鑰的這一刻，是唯一能下載金鑰檔案的機會，如果這次下載後，金鑰檔案弄丟了，那你是無法再次下載金鑰的。你只能再建立另一個新的金鑰，同時刪除舊的金鑰，以免舊的金鑰檔案被駭客取得。

下載完後，我們可以用文字編輯器打開檔案，像我是用 Firefox 瀏覽器打開，它能夠以 Json 格式呈現檔案的內容。

你會看到這個金鑰檔案包含 Project ID、Key ID、Key 的內容、Service Account 的 Email 等相關資訊，這些資訊就是應用程式要去呼叫 GCP 的 API 時，做身份驗證要提供的內容。

所以當你擁有這個金鑰檔案，你就有能力存取 Service Account 能存取的各項資源了。

這也代表你必須好好保管這個檔案，要注意「非常非常多用戶」因為沒保管好金鑰檔案，導致檔案被駭客拿走，在 GCP 的專案裡大肆破壞你的環境，或是開一堆機器在挖礦， 一天之內造成上百萬元的 GCP 帳單，是由你幫駭客買單，不可不慎！

(四) 什麼時候要使用 Service Account？

Google 在官網有提供一個決定是否要用 Service Account 的決策過程如下：

1. 你是否在單一使用者開發環境 (如個人電腦、Cloud Shell、個人用的虛擬機器、虛擬桌面)？

像這樣的環境通常已經有使用者登入，你可以直接使用個人的憑證，例如你可能就是專案擁有者，權限也夠大，所以在開發或測試時較為彈性，不會動不動就因為權限不足而卡住。

・是，往問題 4，因為可能有更簡單的驗證方式。

・否，往問題 2，可能是生產環境或共享環境，會影響到這些環境的正常運作，所以可能要使用 Service Account，能確保它的權限不會太大，影響到其他部分的運作。

2. 你是否在 GCP 中運作程式？

因為 GCP 有特殊的驗證機制，可以直接使用內建的身份驗證，不一定真的要用 Service Account。

・是，往問題 3，確認是否使用容器服務，如果是，遇有其他方法可以使用。

・否，往問題 5，程式可能在本機或其他雲端的外部環境，可能真的要用 Service Account。

3. 是否在 GKE 或 Anthos 中執行容器 (Container) 應用程式？

GKE (Google Kubernetes Engine) 是 GCP 的容器管理服務，它把原生的 Kubernetes 直接做在 GCP 上，底層交由 GCP 直接來管理維護，並做出各種加值應用，比原生的 Kubernetes 更為方便強大。Anthos 則是讓地端也能夠執行 GKE。

・是，使用 Workload Identity Federation for GKE，這是 GKE 專門的身份驗證機制，比 Service Account 更安全。

・否，直接使用 Service Account。

4. 你的情境是否真的需要 Service Account？

它是問你是否需要在所有環境中統一驗證的方式，需要特殊的權限組合，或是自動化的操作。

・是：使用使用者憑證 (User Credentials) 模擬 (Impersonate) Service Account，因為這個動作必須要先做使用者身份驗證，事後可以追蹤到是誰在使用，而且它會產生短期憑證，會自動過期，比較安全。詳細內容可以參考這份文件。

・否：使用使用者憑證，就是使用者本人親自驗證。

5. 你的工作負載 (Workload；就是你在運作的程式) 是否支援 (Workload Identity Federation)？

它指的是 Workload Identity Federation 可以支援像是 AWS IAM 或 Azure AD 所提供的身份，這樣的話就不用額外建立和管理 Service Account 和金鑰，更安全也更方便。

・是：是：設定 Workload Identity Federation。

・否：建立 Service Account Key，已經沒有其他更好的方式了。

(五) 預設的 Service Account 

1. 為什麼會有預設的 Service Account？

你可能會發現，在 Cloud IAM 的畫面中，經常看到兩個預設的 Service Account： Compute Engine default service account 和 App Engine default service account。

這些 Service Account 是 GCP 自動創建的，主要用於特定服務的運行授權。當 Compute Engine VM 或 App Engine 應用程式運行時，GCP 會自動為它們提供一個安全的「內部身份驗證代碼 」(Identity Token)，這些代碼用來代表預設的 Service Account 進行身份驗證和授權。

2. 預設的 Service Account 的特點如下

・無需手動管理密鑰檔案：不需要產生、下載 Service Account 金鑰檔案。

・安全性更高：避免了因金鑰洩露導致的資安風險。

・簡化操作：應用程式可以直接使用 Google 提供的函式庫 (例如 Google Cloud SDK 或 Cloud Client Libraries) 進行授權，這些程式庫會自動檢測並使用預設的身份。

以下分述兩個預設的 Service Account：

(1) Compute Engine Default Service Account

Compute Engine Default Service Account 是當您在專案中啟用 Compute Engine API 時自動生成的 Service Account，它的格式會長這個樣子：

[project-number]-compute@developer.gserviceaccount.com

你可能會想，你什麼時候啟用這個 API？其實當你建立好一個新的專案，接著要準備建立你第一台虛擬機器時，它就會自動啟用 Compute Engine API 了。

由於虛擬機器在 GCP 裡面也可能要呼叫其他服務，所以這個 Service Account 會授權虛擬機器存取 GCP 資源，例如讀取 Cloud Storage 中的資料或與 Cloud SQL 進行互動。

預設情況下，此 Service Account 通常具有 Editor 角色 (Role)，即允許對專案中的所有資源進行讀寫操作。然而，這種設置在安全性上存在潛在風險，詳細內容可以參考這份文件。

你可能會很緊張，擔心如果機器被駭客入侵，那駭客不就拿到 Editor 角色的權限了？

其實當我們在建立機器時，雖然 GCP 預設使用 Compute Engine Default Service Account，但是它受到「存取權範圍」的控制。如果你當時切換到「針對各個 API 設定存取權」，可以看到它原始的設定如下圖：

它的預設設定包含：Storage 和 Service Management 的唯讀存取權、Stackdriver Logging 和 Monitoring 的寫入權限，以及 Service Control 的讀取/寫入權限。所以它的權限是比較小的，不用太過擔心。

假如你對這一點有充份了解，那就建議你以後建立虛擬機器時，不要使用 Compute Engine Default Service Account，而是用你自訂的 Service Account，然後採用最小權限原則，根據 VM 的具體需求調整其角色。

例如，只賦予存取必要資源的權限，而非整個 GCP 專案所有服務的讀寫權限。還要注意要設定 Logs Writer 和Monitoring Metric Writer，這樣虛擬機器才能夠把 Log 和效能指標寫入 GCP 喔！

(2) App Engine Default Service Account

這是當您啟用 App Engine 應用程式時，GCP 自動創建的 Service Account，它的格式會長這個樣子：

[project-id]@appspot.gserviceaccount.com

它會授權 App Engine 的應用程式存取 GCP 資源，例如呼叫其他 GCP 服務的 API 或存取資料庫。

這個 Service Account 也有 Editor 角色，允許應用程式對專案內的資源進行各種讀寫操作。它和 Compute Engine default service account 一樣，預設權限過高可能導致安全性問題。

建議你手動把它的 Editor 角色改成更小權限的角色，等到它存取其他服務，卡住的時候再逐步開放也不遲。

如果你的機構 (Organization) 是在 2024 年 5 月 3 日以後建立的，它有一個機構政策「停用自動為預設服務帳戶授予 IAM 的功能」，是預設會強制執行的，那就不用擔心。(注意你要切換到機構角度，不是專案角度)

像我是的機構是之前就建立的，該政策並沒有強制執行，就請務必透過「管理政策」來改成「強制執行」。

(五) Service Account 注意事項

在 GCP 官方文件提供的 Service Account 注意事項非常多，這裡整理幾個最簡單也最重要的要點給大家：

1. 將 Service Account 視為資源管理

因為它的使用方式，跟一般的使用者帳號差很多，所以要定期觀查每個 Service Account 的使用情形，如果有程式不再運作，就要跟著停用對應的 Service Account 和金鑰。

2. 建立單一用途的 Service Account

遵守最小權限原則，Service Account 只做一件事，使用最小剛好用到的權限，不要使用預設的 Service Account。

3. 建立並遵守命名原則

讓大家一看就知道 Service Account 用在什麼地方，甚至在說明欄位記錄聯絡人和文件連結，以後如果要異動，能夠找到對應的負責人員聯絡，避免誤刪造成系統無法運作。

4. 識別並停用未使用的 Service Account

你可以使用 Activity Analyzer 檢查使用情況，查看最近 Servcie Account 和金鑰的驗證記錄，具體操作可以查看這份文件。

5. 在刪除前先停用

先停用一段時間再決定是否刪除 Service Account，或先刪除金鑰，觀查是否有影響到某個程式的運作，避免太快誤刪造成系統維護的麻煩。

6. 不要用預設的 Service Account

如上述所談，權限太大了。虛擬機器也不要用預設的 Service Account，盡量用專屬的 Service Account 配上專屬的角色。

7. 不要使用網域授權 (Domain-wide Delegation)

這個權限太大了，會讓 Service Account 模擬組織中的任何使用者，也容易被駭客拿來破壞。或是必須設定權限到期日，不要讓它的權限一直存在。 

8. 不要讓任何人可以直接存取 Service Account

如果一個使用者可以存取 Service Account，他就有可能用 Service Account 的權限做更多事情，甚至利用 Servcie Account 的權限 (像是 iam.serviceAccounts.setIamPolicy)，再間接取得更多權限。

9. 在沒有其他選擇時才使用 Service Account 金鑰

使用金鑰做所份驗證時，你沒有辦法追蹤誰使用了金鑰。此外也不要把金鑰檔案儲存在公開的程式碼儲存庫 (如 GitHub)。還有定期輪替金鑰，防止過期或洩露帶來的風險。  

10. 善用稽核記錄 (Audit Logs)

某些 GCP 服務 (例如 Compute Engine) 在Audit Logs 中會包含 serviceAccountDelegationInfo 欄位，這個欄位會顯示Service Account 是否被模擬使用，以及是誰在模擬這個 Service Account。

但不是所有服務都會記錄模擬的詳細資訊，需要額外啟用某些 API 的資料存取記錄，否則可能會遺漏重要的追蹤資訊。因此還要再啟用 Data Access Logs： 

(1) Identity and Access Management (IAM) API，能夠追蹤 Service Account 的詳細使用情況。

(2) Security Token Service API，會記錄 Token 的請求和發放，追蹤身份驗證的過程。

還有很多更細節的注意事情，有需要再參考這份文件。

五、結論

你會發現，本文前半部在開始介紹 IAM 還蠻簡單的，後面隨著牽涉到的範圍越廣也越深。因為整個 GCP 環境內的所有動作，沒有一個和權限無關，就算是 GCP 本身例行性的維護和運作，雖然沒有經過你的操作，你也都能夠查到相關的記錄和使用的權限，而不會直接隱藏不讓你知道。

所以 Cloud IAM 就是 GCP 運作的底層邏輯之一，如果這部分能夠充分了解，對你以後操作 GCP 和故障排除時會很有幫助，也能夠確保整個環境的資訊安全，避免內部人員越權或駭客入侵造成嚴重的後果。

本文同時刊登在思想科技官方網站：

【東東老師 X 思想科技】Google Cloud IAM 的角色與權限控管介紹

【東東老師Ｘ思想科技】Google Cloud IAM Service Account 基本介紹和設定

The post GCP 的 Cloud IAM – 角色與權限控管介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

前陣子周杰倫演唱會售票系統面對超過 89 萬人同時搶票的情況，售票系統方很自豪地說，系統能夠承載如此大的流量，不會掛掉的同時，還能順利地把票賣完。

雖然能夠推持住系統不會崩潰，但該系統的售票頁面不斷出現「轉圈圈」的狀況，讓許多歌迷無法順利購票，關於使用者體驗這一點，似乎還有可以再優化的空間。

本文將從技術角度深入分析售票系統架構，並探討各種可能的優化方案。

一、現有AWS架構的問題分析

根據 AWS 官方指出，售票系統就是架設在 AWS 雲端上。不過啊，這張圖是2020年的，現在的架構應該優化更多了，但目前只找到這張，我們就以這架構來分析看看吧！

首先來看一下售票系統的架構圖：

接下來以個人淺見來看看該架構是否有可以更好的地方：

(一) 系統架構層面

1. 負載平衡

想像一下，就像是一個只有三個服務窗口的車站，突然間來了九十萬人要買票。即使每個窗口再怎麼快，也無法應付這麼多人。

雖然有基本的負載平衡器 (Elastic Load Balancing) 來分配人流，但就像是交通指揮只會把人平均分配到三個窗口，沒有更聰明的疏導方式。系統需要的是更像春節期間的車站管理，有預約、分流、排隊等多重措施。

2. 資料庫設計問題

現在的資料庫就像是一本大帳本，所有人都要搶著在同一本帳本上記錄。當九十萬人同時要在這本帳本上寫東西，自然會打架。

DynamoDB 雖然很強大，但難以處理高併發，如果只用一個資料庫來處理所有請求，就像是再厲害的收銀員，同時間也只能服務有限的客人。

我們需要的是資料分片策略，就像是多個專門的小帳本，分別處理不同的資料，就像大賣場會開很多收銀台一樣。

3. 擴展性限制

EC2 主機的擴充速度可能趕不上需求，等擴展完成可能大部分客人已經等得不耐煩走人了。這就需要更智慧的預測和更快的擴充機制，就像餐廳會預先觀察訂位情況來準備桌位。

(二) 使用者體驗問題

1. 缺乏透明度

目前的系統就像是把用戶關在一個黑盒子裡，只能看到一個永遠轉不完的圈圈，不知道自己排在第幾位，還要等多久。

這種體驗就像是排隊但看不到前面有多少人，也不知道隊伍有沒有在動。這會造成用戶焦慮，也容易讓人懷疑系統是否還在正常運作。

2. 系統響應問題

當系統過載時，用戶看到的就是無止盡的載入畫面，不知道到底是成功了還是失敗了。這就像是在自動販賣機投錢後，機器既不出貨也不退錢，讓人不知所措。

系統需要明確告訴用戶當前的狀態，即使是失敗也要讓用戶知道原因和下一步該怎麼做。

也就是說，買票的粉絲可能太晚買票了，至少讓他們知道前面還有多少人在買，大概要等多久，當他們看到人數太多，也有可能乾脆就不買了，讓真正死忠的粉絲繼續排隊買票。

二、改進方案分析

(一) 資料庫架構優化

1. 為什麼需要改進資料庫架構？

現有的單一資料庫架構就像是一個超大的倉庫，所有人都要從同一個門進出。當人太多時，自然會造成擁擠。

改進的方案就像是把一個大倉庫分成多個小倉庫，每個倉庫負責不同的區域或功能，這樣就能更有效率地服務更多人。

如果使用多個不同資料庫，把一個大資料庫切分成多個小資料庫，就像是一個服務櫃台變成多個服務櫃台，自然能夠服務更多人，也降低了某個櫃台故障時影響所有人的風險。

2. 可能會有的缺點

想像一下，如果今天有個客人要同時買 A 區和 B 區的票，但這兩個區域是分別由不同資料庫管理的。這時系統就必須同時和兩個資料庫溝通，確保兩邊都要成功購票，才算交易完成。

這種跨資料庫的交易變得很複雜，就像是要同時在不同櫃台辦理業務。而且每個資料庫的資料都要保持同步，比如說座位狀態、購票紀錄等，

這會讓系統變得很複雜，也需要投入更多資源來維護這些資料庫。

3. 推薦做法

與其完全切分成獨立的資料庫，不如採用「分片」的方式。分片就像是同一個大資料庫的不同分部，它們共用相同的管理方式，但各自負責不同的資料。

再搭配分散式的快取系統，可以先把熱門的資料（例如座位狀態）存在記憶體中，這樣就不用每次都去資料庫查詢。

最後，對於跨區域的購票需求，可以使用訊息佇列來處理，讓系統能夠更有條理地處理這些複雜的交易。這樣的設計既保持了系統的簡單性，又能應付大量的購票需求。

(二) 實名制驗證機制

1. 實名驗證的好處

實名制最直接的好處就是能大幅降低黃牛票的問題，因為每張票都綁定實際觀眾的身分證，黃牛就無法大量囤票轉售。

這也讓整個交易變得更有保障，因為買票的人就是要進場看表演的人，票券的來源更有保障。

另外，當有人需要退票或換票時，主辦單位也能很容易確認這個要求是來自原始購票者，不會有人冒用他人身分來退票，整個售後服務變得更好管理。

當然，這點所有的人都理解，但並不是那麼容易做到。

2. 實名驗證的缺點

實名制最明顯的缺點是會拉長整個購票流程。想像一下，除了選位置、付款之外，還要額外填寫身分證字號、姓名等資料，而且可能還需要系統和政府資料庫做驗證，這些都會增加購票時間。

對售票系統來說，也需要建立更複雜的程式邏輯，要處理身分驗證、確認真實性、處理例外狀況等。

最重要的是，系統現在要處理大量的個人資料，不只要符合個資法的規範，還要有足夠的資安防護，以免發生資料外洩，這些都是很大的挑戰。

3. 建議做法

最理想的做法是讓使用者「提前」完成身分驗證。就像是網路銀行開戶，先在平常時間完成所有驗證程序，到真正要搶票時就不用再重新驗證，可以大幅縮短購票時間。

建議採用分散式的身分驗證服務，這樣就不會所有驗證請求都擠在同一個地方。系統可以同時使用多種驗證方式，例如身分證字號、手機號碼認證、金融卡驗證等，讓使用者可以選擇最方便的方式。

重要的是要在便利性和安全性之間取得平衡，既不能讓驗證程序太複雜而影響購票體驗，又要確保身分驗證的真實性。這樣的設計才能真正發揮實名制的優點，同時降低它帶來的負面影響。

4. 和劉德華演唱會實名制的做法比較

(1) 採用「登記抽選制」而非即時搶票

這完全避免了系統崩潰的風險。因為在15天的時間窗口內（8/25-8/30），人們可以從容地登記資料，系統負載被分散到更長的時間。

(2) 有清楚的分流機制

卡友優先購票時段（11:28-13:28）和一般民眾登記時段（15:28後），這樣的設計可以有效管理系統負載。

身分資料修改機制很人性化：給予5天的時間（8/25-8/30）供人們修正資料錯誤，而且提供了明確的修改介面（「查看詳情」修正資料）。

(3) 對特殊情況有完整的配套

・生僻字可以用護照英文名稱取代
・身心障礙者和陪同者必須同時登記
・明確區分本地居民和海外人士的證件要求

與我們原本建議方案的主要差異：

我們建議的「預先驗證」機制著重在搶票前就完成身分驗證，但劉德華演唱會採用的是「登記後慢慢驗證」的方式。這種方式雖然較不即時，但因為有抽選機制，所以時間不是那麼關鍵。

我們建議的分散式驗證服務主要是為了處理高併發的即時驗證需求，但在登記抽選制下，這種複雜的架構反而顯得多餘。

所以劉德華演唱會的做法其實更優秀，因為它徹底改變了遊戲規則 – 從「比快」變成「抽籤」。這種方式有幾個關鍵優勢：

・完全消除了系統崩潰的風險
・給予購票者更多時間確認和修正資料
・降低了黃牛票的投機空間（因為無法透過技術手段提高中籤機會）
・整體成本更低（不需要建置複雜的高併發架構）

這個案例告訴我們，有時候與其用技術解決問題，不如從商業邏輯層面改變遊戲規則。這種「登記抽選」的方式，既解決了技術問題，又提供了更好的使用者體驗，是一個值得借鑑的範例。

(三) 智慧排隊系統

1. 排隊機制的運作原理

想像一下，就像是遊樂園的快速通關系統，每個人進入隊伍時會拿到一個號碼，系統會告訴你大概什麼時候可以入場，你不用一直站在那裡等。在線上售票系統中，這表示用戶可以知道自己的位置，預估等待時間，甚至可以做其他事情同時等待。

2. 具體實做方式描述

(1) 即時狀態顯示

我們使用 API Gateway 的 WebSocket API 來建立與使用者的即時連線，這個連線資訊會被存放在 DynamoDB 中。

當使用者的排隊狀態有任何更新時，系統就會立即透過這個 WebSocket 連線推送最新狀態給使用者，讓他們能即時看到自己在隊伍中的位置和預估等待時間。

說到這個，我想到我用手機買郭富城演唱會門票時，至少它有告訴我要等多久。

(2) 排隊機制

排隊機制的實現則依賴於 DynamoDB 的分散式計數器功能。當使用者加入隊伍時，系統會在 DynamoDB 中建立一筆排隊記錄，並使用計數器來取得這位使用者在隊伍中的確切位置。

這些排隊資訊會被送入 SQS 佇列中等待處理，確保系統能夠有序地處理每一個排隊請求，不會因為大量湧入的請求而崩潰。

(3) 分批放行

分批放行的處理是透過 Lambda 函數來完成的。系統會定期觸發 Lambda 來處理一定數量的排隊用戶，這個數量是根據系統當前的負載狀況和處理能力來決定的。

當一批用戶被選中可以進入購票流程時，系統會同時通知這批用戶，讓他們開始選位和付款的流程。這種分批處理的方式可以有效控制系統負載，避免所有人同時湧入造成系統癱瘓。

(4) 超時處理

為了處理逾時的情況，我們使用 CloudWatch Events 來定期觸發檢查機制。

如果有用戶在規定時間內沒有完成購票流程，系統會自動將他們標記為逾時，釋放相關的資源（如暫時保留的座位），並通知後面的使用者前進。

這個機制確保了隊伍能夠持續流動，不會因為個別用戶的延遲而影響整體效率。

(5) 防欺詐機制

防欺詐機制則是整個系統的安全防護網。系統會檢查是否有重複排隊的情況，驗證每個用戶的身份，並且限制單一用戶在特定時間內能夠進行的操作次數。

這些機制共同確保了排隊過程的公平性，防止有人利用技術手段破壞正常的排隊秩序。

這整套系統需要多個 AWS 服務的配合才能順利運作。API Gateway 處理所有的即時通訊需求，DynamoDB 負責資料的儲存，SQS 確保訊息的可靠傳遞，Lambda 處理各種業務邏輯，CloudWatch Events 負責定時任務的觸發，而 ElastiCache 則用於提供快取服務以提升系統效能。

這些服務相互配合，打造出一個可擴展、可靠且高效的智能排隊系統。

這樣的架構設計不僅能夠處理大量的並發連接，還能確保整個購票過程的公平性，同時為使用者提供即時的狀態更新，並能自動處理各種異常情況。

最重要的是，它提供了良好的使用者體驗，讓使用者清楚知道自己的排隊狀態，不會因為系統的不透明而感到焦慮。

(四) 概念示意圖

1.入口層

系統的第一道防線是 CloudFront 全球內容分發網路（CDN）。它負責將靜態內容快取在全球各節點，大幅降低使用者的存取延遲。

當大量用戶同時湧入時，CDN 可以有效分散流量，避免直接衝擊後端伺服器。

在 CDN 之後，應用程式負載平衡器（ALB）進一步分配流量到不同的前端服務節點。

2.前端層

使用 ECS Fargate 運行前端應用程式，採用無伺服器架構可以根據實際流量自動擴展。這層主要處理使用者介面渲染和基本的業務邏輯，像是表單驗證、頁面導航等。

由於使用容器化技術，可以快速部署和擴展，且無需管理底層基礎設施。

3.排隊層

當用戶進入系統後，首先進入排隊層。這層使用 API Gateway 的 WebSocket 服務維持與用戶的即時連線，讓系統能夠即時推送排隊狀態更新。

排隊狀態存儲在 DynamoDB 中，確保高併發存取性能。使用 SQS 訊息佇列來管理排隊隊伍，確保公平性和系統穩定性。

4.身分驗證層

輪到用戶時，進入身分驗證層。REST API 接收驗證請求，Lambda 函數執行實際的驗證邏輯。

用戶資料存儲在 DynamoDB，而驗證結果快取在 ElastiCache 中以提升效能。

這層的設計重點是安全性和效能的平衡，確保驗證過程既安全又快速。

5.訂票層

通過身分驗證後，用戶進入實際的訂票流程。ECS Fargate 運行訂票服務，處理座位選擇和訂單創建。

座位狀態快取在 ElastiCache 中，確保快速響應。最終的訂單資料寫入 Aurora 資料庫，提供強大的交易保證和數據一致性。

6.資料流向

用戶從 CloudFront 進入系統，經過排隊系統獲得順序號，通過身分驗證後進入訂票流程，最後完成訂單創建。

每一步驟都有相應的快取和備份機制，確保系統的可靠性和效能。

這種分層的架構設計，不僅讓系統容易擴展和維護，也提供了良好的用戶體驗。

三、GCP優化架構方案

接下來，我們來看看，售票系統在 GCP上可以怎麼做。

(一) 核心服務

我們的售票系統核心架構是建立在六個關鍵的 GCP 服務上。

1. Cloud CDN 負責處理所有靜態資源的分發

包括網站的 JavaScript、CSS 文件、圖片等。這些資源會被快取在全球各地的節點上，大幅降低延遲時間，讓世界各地的用戶都能快速載入網頁。

系統會自動偵測使用者位置，連接到最近的 CDN 節點，確保最佳效能。

2. Global Load Balancer 扮演著全球流量調度的角色。

它能夠智慧地判斷使用者的地理位置和網路狀況，自動將請求導向最適合的資料中心。

尤其它跟 AWS 的 ALB 比起來，還不用預熱 Pre-Warm。

當某個區域的負載較高時，可以自動將流量導向其他區域，確保系統的穩定性。

而且它還具備智慧路由功能，可以根據後端服務的健康狀況來分配流量。

3. Cloud Run 用於部署前端應用

這個無伺服器的平台能根據流量自動擴展，當訪問量突然增加時，系統會自動建立更多的容器實例來處理請求。

閒置時則會自動縮減資源，既確保了效能又能節省成本。

4. GKE（Google Kubernetes Engine）處理核心業務邏輯。

我們將不同的功能（如訂單處理、座位管理、付款服務等）拆分成獨立的微服務，部署在 GKE Cluster 中。

這種微服務架構讓我們能夠獨立擴展每個服務，也讓系統更容易維護和更新。

5. Cloud Spanner 資料庫保證資料的一致性

這對於處理座位預訂這類需要精確性的操作特別重要。

它能夠在全球範圍內保持資料同步，同時支援大規模的並發操作，完全滿足大型演唱會售票的需求。

6. Pub/Sub 訊息佇列系統用於處理非同步任務

例如當用戶提交訂單時，系統會發送消息到 Pub/Sub，由後端服務依序處理，避免系統過載。

它也用於服務間的通訊，確保訊息能可靠傳遞。

(二) 高可用性設計 (High Availability)

1. 多區域部署

系統同時部署在多個地理位置的資料中心，即使某個區域發生故障，其他區域仍能繼續提供服務。

每個區域都配置了完整的服務架構，並通過 Global Load Balancer 進行流量分配。

2. Autoscale

Autoscale 機制是建立在 GKE 和 Cloud Run 的基礎上。系統會根據 CPU 使用率、記憶體使用量、請求數等指標自動調整資源配置。

例如，當檢測到存取量增加時，會自動增加容器主機數量；當負載降低時，則會自動縮減資源以節省成本。

3. 故障自動轉移

故障自動轉移機制確保了系統的穩定性。

當檢測到某個服務主機故障時，系統會自動將流量導向健康的主機，同時啟動新的主機來替補。這個過程對使用者來說是完全透明的。

4. 分散式快取

分散式快取系統使用了多層次的策略，包括瀏覽器快取、CDN 快取、應用層快取等。

我們使用 Memorystore 來儲存熱門資料，如座位狀態、活動資訊等，大幅減少資料庫的存取壓力。

(三) 監控與維運

1. Cloud Monitoring

負責收集各種系統指標，包括伺服器效能、網絡流量、API 回應時間等。

這些資料會以直觀的儀表板呈現出來，幫助維運團隊快速掌握系統狀態。

2. Cloud Logging

集中管理所有服務的 Log，支援複雜的查詢和分析。維運人員可以輕鬆追蹤問題，了解系統行為。

而且它還支援長期儲存，有助於後續的分析和稽核。

3. Cloud Trace

提供了詳細的 Request 追蹤功能。它可以追蹤一個 Request 在不同服務之間的傳遞過程，幫助我們找出效能瓶頸，就是看出 Latency 高到底是卡在哪裡。

特別是在微服務架構中，這個功能對於問題診斷極為重要。

4. 即時警報系統

當系統出現異常時（如錯誤率升高、回應時間變長），會立即通過 Email、簡訊等方式通知相關人員。不同層級的問題有不同的通知策略，確保運維團隊能及時處理各種情況。這個警報系統也與事件處理流程整合，能夠自動創建工單 (Ticket)，追踪問題解決過程。

四、結論

打造一個優秀的售票系統不僅需要穩定的技術架構，更需要良好的使用者體驗設計。關鍵改進點總結如下：

(一) 系統架構層面

• 1. 多層次快取策略
• 2. 智慧負載平衡
• 3. 資料分片處理
• 4. 異步處理機制

(二) 使用者體驗層面

• 1. 透明的排隊機制
• 2. 即時狀態更新
• 3. 清晰的錯誤提示
• 4. 合理的重試機制

(三) 運營管理層面

• 1. 完善的監控系統
• 2. 靈活的擴展策略
• 3. 有效的成本控制
• 4. 安全防護機制

這些層面的改進點環環相扣，缺一不可。好的系統架構是基礎，但如果沒有良好的使用者體驗設計，用戶仍然會感到挫折。

同樣，沒有完善的運營管理機制，再好的系統也可能因為無法及時發現和處理問題而導致服務中斷。只有將這三個層面都做好，才能打造出真正優秀的售票系統。

The post [GCP 教學] 周杰倫演唱會 AWS 售票系統架構解析 – 系統穩和 vs 使用者體驗，哪個重要？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

我以前也不懂為什麼會有 Cloud Deploy 這個東西，因為原本 DevOps 相關的工具已經夠多了，後來看到這個 Release 才懂，它的確有其必要性。

具體來說：

Release 的組成部分包含如下：

• 容器映像檔（Container image）
• 部署設定檔（如 Kubernetes 清單）
• 部署相關的中介資料（metadata）
• 環境特定的設定

Release 的特點：

• 不可變性（Immutable）：一旦創建就不能修改
• 可追蹤性：每個 release 都有唯一的標識符
• 可重複使用：同一個 release 可以部署到不同環境

創建 Release 的方式：

gcloud deploy releases create release-001 \
  --delivery-pipeline=my-pipeline \
  --region=asia-east1 \
  --source=/path/to/source

Release 的生命週期：

• 創建（Create）：打包應用程式和配置
• 部署（Deploy）：部署到目標環境
• 推進（Promote）：將相同的 release 推進到下一個環境

Release 的優點：

• 確保一致性：相同的 release 在所有環境中保持一致
• 版本控制：每個 release 都有版本記錄
• 回滾能力：可以輕易回滾到之前的 release
• 稽核追蹤：可以追蹤每個 release 的部署歷史

Cloud Deploy Release 實際應用例子：

Release-001
├── 容器映像: gcr.io/my-project/my-app:v1.0.0
├── 部署配置: 
│   ├── deployment.yaml
│   ├── service.yaml
│   └── configmap.yaml
└── 中繼數據:
    ├── 創建時間
    ├── 創建者
    └── 描述信息

Cloud Deploy Release 與環境的關係：

• 開發（Dev）環境：初始部署和測試
• 暫存（Staging）環境：整合測試
• 生產（Production）環境：最終部署
  每個環境可能需要不同的配置，但基礎映像和應用邏輯保持一致。

使用 Release 的好處

通過使用 release，團隊可以：

• 確保部署過程的可重複性
• 維護清晰的部署歷史
• 在問題發生時快速回滾 (Rollback)
• 實現更安全和可控的部署流程

這種方式最能保證部署的一致性和可靠性。

The post [GCP DevOps] Cloud Deploy 的 Release 是什麼東東？ first appeared on 東東 GCP 教學 - GCP 實戰講師.