真實案例：一覺醒來帳單暴增 2,500 倍

澳洲開發者的 25,000 澳幣慘劇

澳洲 AI 顧問 Jesse Davies 在 LinkedIn 和 Reddit 分享了他的親身經歷。

他在 Google AI Studio 做了一個小測試專案，用「Deploy to Cloud Run」一鍵部署到雲端，之後就沒再理它。

帳戶預算通知設定是 10 澳幣（約新台幣 210 元）。

某天早上起床，信用卡已經被扣了 10,000 澳幣。

他立刻聯絡 Google 客服。但在等待回覆的過程中，帳戶又被多刷了 15,000 澳幣。

最終帳單是 25,672.86 澳幣，折合約 18,391 美元（新台幣 58 萬左右）。

攻擊者做了什麼？他們根本沒有偷走 API 金鑰。

他們只是找到 Jesse 部署在 Cloud Run 上的公開網址，直接朝這個網址送請求。

Cloud Run 容器裡以明碼形式存放的 API 金鑰，就會幫攻擊者一筆一筆簽好請求，送到 Vertex AI 上去跑。

短短一個晚上，攻擊者送出了超過 60,000 次請求。

最後 Google 同意撤銷這筆費用，但這個過程讓 Jesse 整整驚嚇了好幾天。

原始貼文如下：

Google Cloud 自動升級消費上限的隱藏機制

這個案例裡還有一個關鍵細節，很多人不知道。

Davies 的帳戶原本是 Tier 2，消費上限大約是 2,000 美元。

Google Cloud 的帳單/用量層級可能會依帳戶歷史消費與資格自動提升；在某些案例中，Tier 2 帳戶累積消費達到門檻後，可能被提升到更高層級，對應上限可達 20,000 至 100,000 美元以上。

雖然不是「偷偷加額度」，但確實代表預設風控不足時，帳單風險會被放大 。

注意 Google 的 AI Studio 帳戶建立超過 30 天、且終生消費達 1,000 美元的帳戶，系統可能自動將可用消費額提高至 100,000 美元。這個機制設計初衷是讓正常業務不中斷，但在 GCP 帳單爆炸的情境下，它反而成為放大損失的燃料。

詳情可以查看以下連結：

https://ai.google.dev/gemini-api/docs/rate-limits?hl=zh-tw

後來 Google 就在 AI Studio 加入每月專案支出上限設定，一旦專案的支出超過上限，系統將在約 10 分鐘內暫停該專案的請求。

但也因為這個延遲，在這段期間內仍可能產生超額費用，並且還是由使用者自行負擔。

為什麼 GCP 帳單爆炸這麼容易發生？

GCP 帳單爆炸之所以容易發生，是因為 Google Cloud 的預設設定把 9 項安全機制全部關閉、消費上限設計成可自動升級，而開發者往往在測試後忘記關閉公開服務。三個條件同時成立，帳單爆炸就只差一個攻擊者。

API 金鑰公開在前端的致命風險

API 金鑰（API Key）是一組用來識別呼叫者身份的字串，當它出現在公開的前端程式碼或 URL 中，任何人都能用它以你的身份呼叫付費服務。

Google Maps API 金鑰數年前被設計成允許放在前端使用，因為當時 Maps API 的計費邏輯相對友善。

但後來 Gemini、Veo 等高價模型加入之後，這個設計就變成潛在漏洞：如果同一把 API 金鑰被賦予存取 Gemini 的權限，任何拿到這把金鑰的人都能用它呼叫 Gemini，費用算在你頭上。

資安公司 Truffle Security 在 2026 年 2 月已公開警告這個問題，詳情可以看這篇文章。

Cloud Run 部署後忘記關閉的代價

Cloud Run 是 GCP 的容器化服務執行平台，讓你可以把應用程式打包成容器並部署到雲端對外提供服務，預設為公開可存取。

問題在於：你的服務有一個公開的 HTTPS 網址，任何人都可以發請求給它。如果你的容器裡有 API 金鑰（特別是明碼形式存放的），每一次外部請求都會觸發真實的 API 呼叫，並產生費用。

很多開發者在測試完之後，只是停用服務，沒有完整刪除。

只要網址還在、API 還沒停掉，攻擊者只要找到這個網址，就能開始刷費用。

GCP 預設關閉的 9 項安全機制是什麼

Davies 在事後整理發現，Google Cloud 內建了 9 項安全機制，可以有效阻擋這類攻擊。

但它們全部預設關閉，需要你自己進設定頁面逐一啟用。

這 9 項機制包含：

• API 金鑰的 HTTP referrer 限制
• IP 位址限制
• Cloud Audit Logs 稽核日誌
• Cost Anomaly Detection 成本異常偵測
• Cloud Armor 防護規則
• VPC Service Controls
• Budget Alert 預算警報
• Cloud Run 的身份驗證要求
• IAM 最小權限原則

後面的步驟章節會逐一說明如何啟用其中最關鍵的幾項。

防止 GCP 帳單爆炸：Step 1 保護你的 API 金鑰

API 金鑰是整個問題的核心。把它保護好，GCP 帳單爆炸的機率就降低 80% 以上。

不要把 API 金鑰以明碼形式放進環境變數

明碼環境變數（Plaintext Environment Variable）是指直接把 API 金鑰字串寫進容器設定或程式碼的做法，這樣做會讓任何能存取容器的人直接讀到金鑰值，是造成 GCP 帳單爆炸最常見的根本原因之一。

這樣做有 2 個根本問題：

1. 任何能存取容器的人（包含攻擊者）都能直接讀到金鑰值
2. 金鑰跟著容器映像一起存在，就算你之後想換金鑰，舊的映像版本裡還是有原本的金鑰

正確的做法是改用 GCP Secret Manager 或短期憑證來取代長期金鑰。

使用 GCP Secret Manager 管理敏感憑證

GCP Secret Manager 是 Google Cloud 提供的機密管理服務，讓你可以把 API 金鑰、密碼、憑證等敏感資料集中存放，並透過 IAM 權限控制誰可以讀取。

Secret Manager 的基本設定步驟

1. 在 GCP Console 搜尋「Secret Manager」，進入服務頁面
2. 點擊「建立密鑰」（Create Secret），輸入名稱（例如 gemini-api-key）
3. 在「密鑰值」欄位貼上你的 API 金鑰，點擊「建立密鑰版本」
4. 進入 IAM 頁面，只賦予你的 Cloud Run 服務帳號「Secret Manager Secret Accessor」這個角色
5. 在 Cloud Run 的程式碼中，改用 Secret Manager SDK 動態讀取金鑰，而不是從環境變數讀取

設定完成後，你的 API 金鑰不再存放於容器內部。就算攻擊者拿到容器映像，也讀不到金鑰內容。

搭配服務帳號短期 Token 取代長期金鑰

更進一步的做法是完全不使用 API 金鑰，改用服務帳號（Service Account）搭配短期 Token（OAuth 2.0 access token，一種有時效限制的身份驗證憑證）。

短期 Token 的有效期間最長為 3,600 秒（1 小時），到期後自動失效。

就算被攻擊者截取，也只有在有效期間內能被使用，損失窗口遠比長期 API 金鑰小得多。

設定方式：讓你的 Cloud Run 服務以特定服務帳號身份運行，並透過 Workload Identity 機制自動取得短期 Token，不需要手動管理任何長期憑證。

防止 GCP 帳單爆炸：Step 2 關閉或刪除閒置服務

就算你的 API 金鑰保護做得再好，只要有一個公開的服務端點還在運行，就是潛在的攻擊入口。

如何找出帳號內所有公開的 Cloud Run 服務

1. 進入 GCP Console，在左側選單點擊「Cloud Run」
2. 選擇你要檢查的專案，查看所有已部署的服務列表
3. 對每個服務點擊進入，查看「觸發條件」（Triggers）和「安全性」（Security）分頁
4. 確認「需要驗證」（Require authentication）是否已勾選，未勾選代表該服務完全公開
5. 如果你不確定這個服務還有沒有在用，查看「指標」（Metrics）分頁，若過去 30 天請求數為 0，直接刪除

建議每季做一次這個檢查，把所有不再使用的服務清掉。

這些服務沒在使用時，沒有機器也沒有費用產生，但設定和網址仍然保留，你點擊一下網址它們就恢復運行。

除非你直接刪除，要不然隨時都會有被啟動的風險。

如果你擔心刪除後需要回復，可以先把部署設定（Cloud Run YAML 或 Terraform 設定）存到版本控制系統，之後需要時重新部署即可。

App Engine 和 Cloud Functions 的相同風險

Cloud Run 不是唯一有這個問題的服務。App Engine 和 Cloud Functions 也有相同的風險：

1. App Engine 的版本（Version）在停用後，對應的 URL 在某些情況下仍然可存取
2. Cloud Functions 的 HTTP 觸發函式預設也是公開的
3. 這 2 個服務都需要同樣的定期清查動作

原則一樣：凡是超過 90 天沒有收到任何請求的服務，就直接刪除，不要只是停用。

防止 GCP 帳單爆炸：Step 3 設定消費上限與預算警報

API 金鑰保護和服務管理是預防攻擊，預算設定是當攻擊發生時的最後一道防線。

在 Google Cloud Console 建立預算通知

預算通知（Budget Alert）是 GCP 提供的消費警報機制，當你的消費達到設定門檻時，會發送 Email 通知。

設定步驟：

1. 進入 GCP Console，點擊左側選單的「帳單」（Billing）
2. 選擇「預算與快訊」（Budgets & alerts）
3. 點擊「建立預算」（Create budget）
4. 設定預算名稱和涵蓋範圍（可以只針對特定專案）
5. 設定預算金額（例如新台幣 500 元）
6. 在「快訊門檻」至少設定 50%、75%、100% 三個通知點
7. 在「通知方式」填入你的 Email，或設定 Pub/Sub 主題以觸發自動化動作

PS. 你也可以像我這麼極端，我的通知門檻是「每多 1 USD 就直接通知 1 次」，雖然常看到通知信很煩，但能確保時時都能收到通知。

重要提醒：預算通知不會自動停止計費，它只發送通知。要真正截斷消費，你需要額外設定自動化動作（見下方步驟）。

了解 GCP 自動升級帳戶等級的觸發條件

這是 Davies 案例中讓損失放大 50 倍的關鍵機制，你一定要了解。

1,000 美元門檻與 100,000 美元上限的來龍去脈

根據 Google 官方說明，GCP 帳戶有信用額度分層機制：

1. 新帳戶（建立未滿 30 天）：消費上限約在 2,000 美元
2. 舊帳戶（建立超過 30 天）且終生消費達 1,000 美元：系統可能自動將上限提高至 20,000 至 100,000 美元
3. 這個升級動作完全自動，不需要使用者確認，也不一定會發送通知

換句話說，你在不知情的狀況下，帳戶的實際可消費金額已經是你預期的 50 倍。

如何手動鎖定帳戶消費上限

GCP 目前沒有提供「硬性消費上限」功能（Hard Cap），只能透過以下 3 種方式控制：

1. 透過預算快訊 + Cloud Pub/Sub + Cloud Functions 建立自動化截斷機制：當消費達到設定金額時，自動停用指定的 API 或服務 (要注意這個自動停用的 Cloud Functions 程式，還是要自己寫)
2. 在個別 API 的 Google Cloud Console 設定中查看「配額」（Quota），把每日請求數限制在可接受的範圍
3. 聯絡 Google Cloud 支援，要求在帳戶層級設定更嚴格的消費限制

這是目前最接近「硬性上限」的做法。需要一點工程工作，但一次設好就能長期保護你。

2026 4 月開始，AI Studio 可以設定上限

請先到 Google AI Studio Dashboard 選單的 Spend，再點擊 Set spend cap

設定 Gemini API 的每月花費上限

防止 GCP 帳單爆炸：Step 4 啟用 GCP 內建的安全機制

GCP 內建了 9 項安全機制，但全部預設關閉。這一節帶你把最關鍵的 3 項打開。

9 項預設關閉的安全設定在哪裡找

這 9 項設定散落在 GCP Console 的不同位置，沒有統一入口。你需要逐一進入各個服務的設定頁面手動啟用。

最快的方法是使用 GCP 的「安全性指揮中心」（Security Command Center，一個集中管理 GCP 安全問題的控制台）。

進入 GCP Console，搜尋「Security Command Center」，點擊「漏洞」（Vulnerabilities）分頁。

這裡會列出你帳號中偵測到的安全問題，包含沒有啟用身份驗證的 Cloud Run 服務、過於寬鬆的 IAM 權限等。

Security Command Center 的詳情可以查看這篇文章。

API 金鑰限制：綁定 HTTP referrer 與 IP 位址

如果你的 API 金鑰無法立刻換成 Secret Manager，至少要做這件事：限制 API 金鑰的使用範圍。

設定步驟：

1. 進入 GCP Console，搜尋「API 和服務」（APIs & Services）
2. 點擊「憑證」（Credentials）
3. 找到你要保護的 API 金鑰，點擊進入編輯
4. 在「應用程式限制」（Application restrictions）選擇「HTTP referrer（網站）」，填入你的網域（例如 https://yourdomain.com/*）
5. 在「API 限制」（API restrictions）選擇「限制金鑰」，只勾選這把金鑰真正需要使用的 API
6. 點擊「儲存」

完成後，就算有人拿到你的 API 金鑰字串，在非你網域的環境下使用它，GCP 會直接拒絕這個請求。

設定只能呼叫哪些 API

啟用 Cloud Audit Logs 追蹤異常呼叫

Cloud Audit Logs（雲端稽核日誌）是 GCP 記錄所有 API 呼叫行為的機制，讓你在事後追查「誰在什麼時間呼叫了什麼 API」。

預設只有管理活動日誌（Admin Activity Logs）是開啟的。

資料存取日誌（Data Access Logs）預設關閉，但這才是追蹤異常 API 呼叫最重要的日誌。

啟用方式：

1. 進入 GCP Console，搜尋「IAM 與管理員」（IAM & Admin）
2. 點擊「稽核日誌」（Audit Logs）
3. 找到你要啟用的服務（例如 AI Platform、Cloud Run），勾選「資料讀取」和「資料寫入」
4. 點擊「儲存」

啟用之後，你就能在 Cloud Logging 中查詢：過去 24 小時內，所有 Gemini API 的呼叫次數、來源 IP、使用的金鑰。在異常發生時，你有完整的事後追查能力，也能把日誌資料提供給 Google 客服作為退款申請的佐證。

防止 GCP 帳單爆炸：Step 5 建立異常偵測與即時告警

前面 4 個步驟都是預防，這個步驟是監控——讓你在帳單失控的前 30 分鐘就收到通知，而不是睡一覺起來才發現。

Cost Anomaly Detection 的設定方式

Cost Anomaly Detection（成本異常偵測）是 GCP 的自動化機制，會分析你的歷史消費模式，當消費突然偏離預期時，發送警報 Email。

啟用方式：

1. 進入 GCP Console，點擊「帳單」（Billing）
2. 選擇「異常狀況」（Cost anomalies）分頁
3. 點擊「管理異常狀況」，設定要自動產生門檻，或手動自己設定
4. 在「通知設定」填入你想接收警報的 Email 地址

但要記住 AWS 那個案例的教訓：Cost Anomaly Detection 只涵蓋直接計費的服務。如果你透過 Marketplace 或第三方管道計費，這個偵測在那些項目上無效。記得確認你所有 GCP 服務的計費路徑。

為什麼光靠預算通知還不夠

預算通知有 2 個根本限制：

1. Email 通知有延遲，GCP 帳單的計算週期不是即時的，有時候通知寄到的時候，費用早就超標了
2. 預算通知只有在你的帳戶達到設定門檻時才發送，如果攻擊在短短幾小時內讓費用從 0 衝到 5,000 美元，中間你不會收到任何通知

這就是為什麼需要加上 Cloud Monitoring 的即時 Alerting Policy。

結合 Cloud Monitoring 設定即時 Alerting Policy

Cloud Monitoring（雲端監控）是 GCP 的指標監控服務，可以讓你針對任何 GCP 指標設定即時警報。

設定步驟：

1. 進入 GCP Console，搜尋「Monitoring」，進入 Cloud Monitoring
2. 點擊「警報」（Alerting），再點擊「建立政策」（Create Policy）
3. 在「選取指標」中，搜尋 serviceruntime.googleapis.com/api/request_count（API 請求次數）
4. 設定觸發條件：例如「過去 10 分鐘內，Gemini API 的請求次數超過 1,000 次」
5. 在「通知管道」設定你的 Email 或 Slack 通知
6. 點擊「儲存」

完成後，當有人在 10 分鐘內對你的 API 發出超過 1,000 次請求，你的手機就會立刻收到警報，而不是隔天早上才看到帳單。

常見問題：帳單已經爆了，現在怎麼辦？

如果你看到這篇文章時，帳單已經在爆炸了，這個章節是給你的。動作越快，損失越小。

立刻停用金鑰和服務的操作順序

按照這個順序執行：

1. 進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有 API 金鑰，點擊刪除或停用
2. 進入「Cloud Run」，找到所有公開服務，點擊「刪除」
3. 進入「IAM 與管理員」，找到異常的服務帳號，點擊「停用」
4. 進入「帳單」，查看「本月消費明細」，確認是哪個服務在產生費用
5. 直接停用該服務對應的 API（進入「API 和服務」→「已啟用的 API 和服務」，找到對應的 API，點擊停用）

整個流程在 10 分鐘內應該可以完成。每晚一分鐘，就多幾美元的損失。

如何向 Google Cloud 申請帳單減免

Davies 的案例最後有退款，但這不是自動的，需要你主動申請。

申請步驟：

1. 進入 GCP Console，點擊右上角的「支援」（Support）圖示 （要注意你有購買 Google 官方的技術支援方案）
2. 選擇「建立案例」（Create case）
3. 在問題類型選擇「帳單」（Billing）
4. 詳細描述事件：攻擊發生的時間、你發現的方式、你已採取的緊急措施
5. 附上 Cloud Audit Logs 的截圖或匯出資料，作為攻擊行為的佐證
6. 明確要求「費用撤銷」（Credit request 或 Billing adjustment）

Google 不保證一定退款。但根據公開案例，在能提供明確攻擊證據、且帳號本身沒有不當行為的情況下，退款機率相當高。

隱藏密技，從這裡點選就不需要先購買技術支援方案。

被扣款後帳號被鎖定，怎麼取回日誌權限

這是 Davies 案例中最令人抓狂的環節：因為帳單欠款，GCP 帳號被限制，他一度無法進入 Cloud Logging 查看攻擊日誌。

如果你遇到這個狀況：

1. 先嘗試透過 Google Cloud Console 的帳單頁面補繳欠款，部分情況下補繳後帳號限制會立刻解除
2. 如果無法補繳（例如信用卡已被鎖定），直接聯絡 Google Cloud 支援，說明你正在收集攻擊佐證，需要暫時恢復日誌存取權限
3. 要求 Google 客服協助匯出你帳號的 Audit Logs，這是他們技術上可以做到的事
4. 同步提出費用撤銷申請，兩件事可以一起處理

結語：GCP 帳單爆炸不是你的錯，但防護是你的責任

GCP 的預設設定就是把 9 項安全機制全部關掉，把消費上限設計成會自動升級。這確實是平台設計的問題。

但等 Google 改好設計，可能要等很久。

防止 GCP 帳單爆炸，你能做的就是這 5 件事：保護 API 金鑰、刪除閒置服務、設定預算上限、啟用安全機制、建立即時監控。每一步都花不到一小時。但少做任何一步，都有機會讓你睡一覺起來帳單多出台幣 58 萬。

現在就去 GCP Console 打開那 9 項設定吧。

常見問題（FAQ）

Q1：GCP 預算通知設定後，消費真的會被自動停止嗎？ A：GCP 帳單爆炸最常見的誤解就是這個——預算通知只發 Email，不會自動停止計費。要實現自動截斷，需要額外設定 Cloud Pub/Sub 加上 Cloud Functions，讓警報觸發自動停用服務的程式。這個架構需要一點工程工作，但做一次就能保護所有專案。

Q2：我只是用 GCP 跑實驗，金額很小，需要這麼麻煩嗎？ A：需要。Davies 的案例就是從「只是跑個實驗」開始的。攻擊者不管你的帳戶是否在活躍使用，只要 Cloud Run 網址存在、API 金鑰有效，就是攻擊目標。實驗完成後，刪除服務是最小成本的防護動作，花不到 2 分鐘。

Q3：Secret Manager 收費嗎？費用大概是多少？ A：收費，但金額很小。根據 GCP 官方定價，Secret Manager 每 10,000 次存取操作收費 0.03 美元，每個活躍密鑰版本每月收費 0.06 美元。對大多數開發者來說，每月費用會在 1 美元以下，比起 GCP 帳單爆炸的風險，這筆錢完全值得。

Q4：我有多個 GCP 專案，每個都要做一遍嗎？ A：金鑰保護和服務清查需要在每個專案個別執行。但預算設定可以在帳單帳戶（Billing Account）層級設定，一次涵蓋所有專案。Cost Anomaly Detection 也可以在帳單帳戶層級啟用，不需要逐一設定。

Q5：如果我用的是 Firebase，也有同樣的風險嗎？ A：有。Firebase 專案底層就是 GCP 專案，Firebase 的 API 金鑰同樣可以用來呼叫 GCP 的付費服務。如果你在 Firebase 專案中啟用了 Gemini API 或其他付費服務，一樣需要做 API 金鑰的限制設定。

Q6：Cloud Armor 是什麼？它能防止帳單爆炸嗎？ A：Cloud Armor 是 GCP 的 Web Application Firewall（Web 應用程式防火牆），可以封鎖特定 IP、地區或請求模式。它能減少惡意請求的數量，但不能直接限制消費金額。建議把 Cloud Armor 當作補充防護，而不是主要防線，且它需要額外費用，適合已有穩定流量的正式服務。

Q7：Google Maps API 金鑰和 Gemini API 金鑰是同一把嗎？ A：在 GCP Console 裡，同一個專案的 API 金鑰預設可以存取該專案啟用的所有 API。如果你在同一個專案裡同時啟用了 Maps API 和 Gemini API，你的 Maps API 金鑰在技術上也能呼叫 Gemini。正確做法是在 API 金鑰設定中明確指定這把金鑰只能用於哪些 API。

Q8：我已經把 API 金鑰換掉了，舊金鑰還需要特別處理嗎？ A：需要立刻刪除舊金鑰。進入 GCP Console，點擊「API 和服務」→「憑證」，找到所有舊的 API 金鑰，點擊「刪除」而不是只是停用。停用的金鑰在特定條件下可能被重新啟用；刪除才能確保舊金鑰永久失效，是防止 GCP 帳單爆炸的必要步驟。

Q9：攻擊者是怎麼找到我的 Cloud Run 網址的？ A：常見的途徑有 3 種：在 GitHub、GitLab 或 Bitbucket 的公開 repo 中搜尋 Cloud Run 網址（攻擊者有自動化工具掃描這些平台）；透過搜尋引擎索引到公開的 API 文件或設定檔；從 Google AI Studio 的部署紀錄或相關社群貼文中找到。任何 Cloud Run 網址都不要出現在公開的程式碼或文件裡。

Q10：除了 GCP，其他雲端服務（AWS、Azure）也有同樣的問題嗎？ A：有，而且 AWS 還有額外的盲點。透過 AWS Marketplace 計費的 Bedrock 服務不在 AWS Cost Anomaly Detection 的偵測範圍內。Azure 的 API Management 服務有類似的公開端點風險。每個雲端平台的預設安全設定都不夠嚴格，原則相同：任何公開端點加上任何付費 API 的組合，都需要額外的保護機制。

The post GCP 帳單爆炸防護指南：5 個步驟讓你不再睡醒崩潰 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 實戰講師.

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

因為同樣是虛擬機器，內部的操作是一樣的，
內部指的是 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 實戰講師.

GitOps方法論是什麼？

GitOps是一種現代的軟體部署和運維方法論，核心理念是使用Git作為單一事實來源(Single Source of Truth)，所有系統設定和基礎設施都以程式碼形式存儲在Git倉庫中，以宣告式語法來描述整個系統狀態。

主要特點

1. 自動化同步：系統會自動將Git倉庫中的期望狀態與實際運行環境同步
2. 版本控制：所有更改都有完整的版本歷史記錄
3. 可稽核性：每個變更都可以追踪誰在什麼時候做了什麼修改
4. 回滾能力：可以輕鬆回退到任何之前的版本

優點如下：

1. 提高部署一致性和可靠性
2. 減少人為錯誤
3. 更容易進行協作和審查
4. 簡化復原流程

常用工具包含：Flux、ArgoCD、Jenkins X、Config Connector (Google Cloud 專屬)。

GitOps特別適合管理Kubernetes環境，因為Kubernetes本身就是基於聲明式配置的系統。這也是為什麼在GKE環境中，Config Connector配合GitOps方法論會是一個理想的選擇。

撇開 GKE，Flux 和 ArgoCD 就是兩個業界常用的 GitOps 工具

Flux:

• 像是一個勤奮的管家,會定期檢查 Git 程式碼庫有沒有更新
• 如果發現更新了,就會自動把新的設定套用到系統
• 特別適合單一團隊使用,設定相對簡單

ArgoCD:

• 功能比較豐富,有圖形化介面可以看系統狀態
• 可以管理多個專案和團隊
• 提供更多進階功能,例如可以設定部署的順序和條件

這兩個工具的主要差別在於:

• Flux 比較輕量化,適合小型專案
• ArgoCD 功能比較完整,適合大型組織使用
• Flux 通常整合在系統內,ArgoCD 則是獨立運作的服務

你要選擇哪一個,主要看:

1. 團隊規模大小
2. 是否需要圖形化介面
3. 需要的進階功能有哪些
4. 維護的難易程度

GitOps的工作流程是什麼？

1. 開發階段

• 開發人員在本地開發功能或修改
• 將所有設定檔（包括應用代碼、基礎設施配置）存儲在 Git 倉庫 (Repository)，例如 Github。
• 創建 Pull Request（PR）提交更改

2. 審核階段

• 其他團隊成員審查代碼變更
• 自動化測試運行檢查
• CI（持續整合）流程驗證更改
• 審核通過後合併到主分支 (Main Branch)

3. 同步階段

• GitOps 操作器（如 ArgoCD 或 Flux）持續監控 Git 倉庫
• 自動檢測到主分支的新變更
• 比較目標環境與 Git 中定義的期望狀態

4. 部署階段

• 操作器自動將變更同步到目標環境
• 執行必要的部署和配置更新
• 確保實際狀態與 Git 中定義的狀態一致

5. 監控與修正

• 持續監控部署狀態
• 如果檢測到偏差，自動進行修正
• 將實際狀態調整回 Git 中定義的期望狀態

6. 回滾機制

• 如果發現問題，可以快速回滾
• 只需將 Git 倉庫回退到之前的穩定版本
• 操作器會自動將環境同步到回滾後的狀態

整個流程的核心是：

• 所有更改都通過 Git 進行
• 自動化工具負責同步和部署
• 持續確保系統狀態與 Git 定義保持一致

這種工作流程特別適合：

• Kubernetes 環境管理
• 微服務架構
• 大規模分布式系統
• 需要嚴格變更控制的環境

The post [GKE 教學] GitOps 方法論是什麼東東？GitOps的工作流程是什麼？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

為什麼不用 VM 就好？你可以直接跳到最後一段！

一、Dataflow 是什麼？

想像你是一間工廠的管理者，每天都要處理大量的原物料（資料）。這些原物料需要經過各種加工程序，最後變成成品。

GCP 的 Dataflow 就像是一個全自動的生產線系統，你只要設定好要怎麼處理這些原物料，它就會自動幫你完成所有工序，而且還會自動調整工人（運算資源）的數量。

二、Dataflow 舉例說明

當然這樣子講還是有點模糊，舉個實際的例子來說：假設你需要處理每天的銷售資料，Dataflow 可以自動幫你：

1. 收集各個分店的銷售資料
2. 清理不正確的資料
3. 計算各種統計數字
4. 把結果存到資料庫

三、Dataflow 跟 Apache Beam 有什麼關係？

Apache Beam 是 Dataflow 的原型，GCP 只是把跟 Apache Beam 做一些加值的優化，放在 GCP 上，這樣你就不用自己在地端安裝和設定 Apache Beam，節省很多準備環境 (尤其是機器的安裝設定) 的時間。

Apache Beam 就像是一套標準的工廠作業規範。它定義了一些基本的處理方式，讓你可以用同一種方式來描述你想要的資料處理流程，不管最後是要在哪裡執行。

四、Apache Beam 的組成元件

讓我們來看看它的主要組成元件：

1. Pipeline（管線）： 這就像是整個工廠的生產線規劃圖，定義了資料要如何從原料變成成品，經過哪些步驟。

2. PCollection（資料集合）： 把它想像成工廠裡的輸送帶，上面放著要處理的原料或半成品。每次資料經過一道處理程序，就會形成新的一條輸送帶。

3. Transform（轉換）： 這就是工廠裡的各種加工設備，例如：

• ParDo：像是一個工作站，可以對每件原料進行客製化處理
• GroupByKey：就像是分類站，把相同種類的產品集中在一起
• Combine：類似於組裝線，把多個零件組合成一個成品

4. I/O Transforms（輸入輸出轉換）： 就像工廠的原料進貨口和成品出貨口，決定資料要從哪裡讀入，最後要存到哪裡去。

5. Window（時間窗口）： 假設你想要每小時統計一次生產數量，Window 就是幫你把資料按照時間切分的工具。

6. Trigger（觸發器）： 就像是工廠的警報系統，當某些條件達成時（比如收集到足夠的數據），就會觸發特定的處理程序。

最重要的是，這整套系統的特色是：

• 全自動化：設定好後就會自動運作
• 可擴展性：需要處理更多資料時，會自動增加處理能力
• 容錯能力：即使某部分出問題，系統也能自動恢復
• 即時處理：能夠處理即時流入的資料，也能處理已存在的資料

關於 Apache Beam 詳細說明可以參考這份文件。

五、從具體的角度再解釋一次 Apache Beam 的組成元件

1. Pipeline（管線）

從技術角度來看，Pipeline 是整個數據處理的骨幹，它包含了所有的處理步驟和邏輯。

# Pipeline 的基本架構
pipeline = beam.Pipeline()
result = (pipeline 
    | "讀取資料" >> ReadFromText('input.csv')
    | "處理資料" >> Process()
    | "寫入結果" >> WriteToText('output.txt'))

例子：處理網站日誌文件，從讀取原始日誌、解析內容、到產生報表的整個流程。

2. PCollection（資料集合）

這是 Beam 中最基本的資料結構，可以存放任何型別的資料，而且是不可變的（immutable）。每次轉換都會產生新的 PCollection。

# 一個包含用戶訪問記錄的 PCollection
visits = pipeline | beam.Create([
    {'user': 'A', 'page': '/home', 'time': '2024-01-01 10:00'},
    {'user': 'B', 'page': '/products', 'time': '2024-01-01 10:05'}
])

例子：存放使用者的點擊記錄，每筆記錄包含用戶ID、訪問頁面、時間戳等資訊。

3. Transform（轉換）

轉換是對 PCollection 進行操作的處理單元。主要類型包括：

(1) ParDo（並行處理）：

# 解析每一行日誌並提取重要資訊
class ParseLog(beam.DoFn):
    def process(self, element):
        user, action, timestamp = element.split(',')
        return [{
            'user': user,
            'action': action,
            'timestamp': timestamp
        }]

logs | beam.ParDo(ParseLog())

例子：將原始的日誌文字轉換成結構化的資料格式。

(2) GroupByKey（分組）：

# 依照用戶ID分組，統計每個用戶的訪問次數
user_visits = (visits 
    | beam.Map(lambda x: (x['user'], 1))
    | beam.GroupByKey()
    | beam.Map(lambda x: {x[0]: sum(x[1])})
)

例子：統計每個用戶在不同頁面的停留時間。

(3) Combine（合併）：

# 計算每個頁面的總訪問次數
page_visits = (visits
    | beam.Map(lambda x: (x['page'], 1))
    | beam.CombinePerKey(sum)
)

例子：計算網站每個頁面的總瀏覽量。

4. I/O Transforms（輸入輸出轉換）

# 從多個來源讀取資料
logs = pipeline | beam.io.ReadFromText('logs/*.txt')
# 寫入到資料庫
results | beam.io.WriteToMongoDB(uri='mongodb://localhost:27017')

例子：從 S3 讀取日誌檔案，處理後寫入到 BigQuery。

5. Window（時間窗口）

# 每5分鐘統計一次訪問量
windowed_counts = (visits
    | beam.WindowInto(window.FixedWindows(300))  # 5分鐘
    | beam.GroupByKey()
    | beam.Map(count_visits)
)

例子：統計每小時的活躍用戶數，或計算每分鐘的交易金額。

6. Trigger（觸發器）

# 當收集到100筆資料或等待時間超過1分鐘時觸發處理
early_results = (data
    | beam.WindowInto(
        window.GlobalWindows(),
        trigger=trigger.Repeatedly(
            trigger.AfterCount(100) | 
            trigger.AfterProcessingTime(60)
        ),
        accumulation_mode=trigger.AccumulationMode.DISCARDING
    )
)

例子：即時監控系統，當檢測到異常訪問模式時立即觸發警報。

六、Apache Beam 實際應用整合範例

# 完整的網站訪問分析pipeline
def analyze_website_logs():
    with beam.Pipeline() as pipeline:
        results = (pipeline
            | "讀取日誌" >> beam.io.ReadFromText('logs/*.txt')
            | "解析日誌" >> beam.ParDo(ParseLog())
            | "加上時間窗口" >> beam.WindowInto(window.FixedWindows(3600))
            | "依頁面分組" >> beam.Map(lambda x: (x['page'], 1))
            | "計算訪問量" >> beam.CombinePerKey(sum)
            | "格式化輸出" >> beam.Map(format_output)
            | "寫入結果" >> beam.io.WriteToText('results.txt')
        )

這個例子展示了如何使用這些組件來建立一個完整的數據處理流程：

1. 讀取多個日誌文件
2. 解析每條日誌記錄
3. 設定每小時的分析窗口
4. 按頁面分組並計算訪問量
5. 格式化輸出結果
6. 將結果寫入文件

這樣的資料處理管道可以處理任意大小的資料集，而且能夠自動擴展和容錯。

需要注意的是，這些程式碼都是在本地端執行，如果要在 GCP Dataflow 上運行，只需要修改 Pipeline 的執行器設定即可，程式碼邏輯不需要改變。

七、為什麼不自己在 VM 上寫 Python 來處理資料就好？為何要用 Dataflow？到底差在哪裡？

讓我用實際的例子來說明在 VM 上自己寫 Python 處理資料，與使用 Dataflow 的差異。

情境：處理每日 100GB 的使用者點擊日誌 Log

(一) 在 VM 上自己寫 Python 的程式碼大概長這樣子：

# 在單一 VM 上運行的 Python 程式碼
def process_logs():
    with open('huge_logs.txt', 'r') as file:
        for line in file:
            user_data = parse_log(line)
            # 處理記憶體不足的問題
            if memory_usage > threshold:
                save_temporary_results()
                clear_memory()
            
            # 處理單機運算慢的問題
            processed_data = complex_calculation(user_data)  # 可能要跑很久
            
            # 處理機器當機的問題
            try:
                save_to_database(processed_data)
            except ConnectionError:
                retry_save(processed_data)  # 需要自己寫重試機制 (retry)

可能會遇到的問題：

1. 記憶體限制
   • VM 記憶體用完就崩潰
   • 需要自己寫程式分批處理
   • 要自己管理暫存資料
2. 運算效能
   • 單機處理 100GB 可能要跑一整天，花錢
   • CPU 滿載可能影響其他程式
   • 擴充需要自己開更多 VM、寫分散式程式，管機器太累了
3. 錯誤處理
   • 程式崩潰要從頭重跑
   • 網路斷線要自己處理
   • VM 當機就前功盡棄
4. 監控和維護
   • 要自己寫 Log
   • 要自己監控 CPU/記憶體
   • 要自己處理備份

(二) 使用 Dataflow 的情況

# Dataflow 程式碼
with beam.Pipeline(options=PipelineOptions()) as pipeline:
    results = (pipeline 
        | 'ReadLogs' >> ReadFromText('gs://bucket/huge_logs.txt')
        | 'ParseLogs' >> beam.ParDo(ParseLogFn())
        | 'CalculateResults' >> beam.ParDo(ComplexCalculationFn())
        | 'WriteToDB' >> WriteToDatabase()
    )

不覺得看起來簡單很多嗎？接下來看一下 Dataflow 自動處理的部分：

1. 自動擴展（Auto-scaling）
   • 自動偵測資料量
   • 自動增加/減少運算資源
   • 不用擔心記憶體爆掉
2. 平行處理（Parallel Processing）
   • 自動分散工作到多台機器
   • 100GB 資料可能 1 小時就處理完
   • 有效利用 Google 的運算資源
3. 錯誤恢復（Fault Tolerance）
   • 某台機器掛掉會自動重試
   • 網路問題自動處理
   • 不會從頭重跑，從上次中斷點繼續
4. 監控和維護
   • 完整的監控儀表板
   • 即時查看處理進度
   • 系統層級的 Log

(三) 何時用 Dataflow 或 VM？

什麼時候選擇 Dataflow：

1. 資料量大（>10GB）
2. 需要即時處理（Streaming）
3. 處理邏輯複雜
4. 需要可靠的錯誤處理
5. 需要自動擴展
6. 預算允許（雖然比 VM 貴，但省下很多人力跟時間）

什麼時候用 VM 就夠：

1. 資料量小（<1GB）
2. 單次處理就好
3. 處理邏輯簡單
4. 不急著要結果 (你可以使用 Spot VM 享受 60%~90% Off 的折扣)
5. 預算有限

重點是：Dataflow 不只是一個執行環境，而是一個完整的資料處理平台。雖然前期學習成本較高，但在處理大量資料時，會省下更多開發和維護的時間。

這就像是比較「自己蓋房子」和「請建商蓋房子」的差異 – 雖然請建商比較貴，但他們有完整的團隊、標準流程和品質保證，最終反而更有效率。

以上先簡單介紹一下，之後再深入介紹技術細節和實際操作。

The post [Dataflow 教學] Dataflow 是什麼？跟 Apache Beam 有什麼關係？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

如果能好好運用，ChatGPT 可以成為幫助你培養嚴謹思維和清晰寫作能力的強大工具，

協助他們理解想法、掌握複雜概念，並獲得寫作回饋。

但是，也有一些使用 ChatGPT 的方式會適得其反，

例如直接讓它產生整篇文章而不是自己寫作。

這樣做會讓你失去練習、提升技能和深入思考的機會。

對於想要成為更好的作者和思考者的人來說，

以下是一些運用ChatGPT來深化學習過程的方法：

1. 讓ChatGPT處理引用文獻的繁瑣工作

AI 非常擅長自動化處理格式化引用文獻這類耗時的工作。

只要記得核對所有來源資料的細節是否正確即可。

讓ChatGPT處理這些繁瑣工作，你就能專注在最有趣的部分：

發揮創意、提出原創想法，以及建立無懈可擊的論點。

2. 快速了解新主題

ChatGPT 可以幫助你快速建立對某個主題的基礎認識。

3. 取得相關資源的指引

ChatGPT可以推薦相關學者、資料來源和搜尋關鍵字，為你的研究提供方向。

但請記住：雖然它能指引方向，但不能取代閱讀原始資料和同儕審查的文章。(就是你要再去交叉核對的意思)

由於語言模型可能產生不準確的資訊，務必要仔細查證所有事實。

4. 透過具體提問完善理解

ChatGPT可以幫你串連概念，填補複雜主題中的知識空白，

回答其他資源可能忽略或埋藏在章節深處的問題。

5. 透過結構回饋改善文章流暢度

當你寫好大綱後，ChatGPT可以檢視結構並針對想法的流動提供建議。

6. 運用反向大綱測試邏輯

反向大綱是一種評估文章結構的技巧，主要是找出每個段落的重點。一眼就能看出結構，有助於你退一步評估想法的邏輯流程。

什麼叫反向大綱？

反向大綱是一種在完成初稿後用來檢查文章結構的方法。

不同於一般在寫作前先擬大綱，反向大綱是在寫完文章後「倒著來」的分析方法。

具體步驟是：

(1) 讀完一個段落後，用一句話總結這個段落的主要論點或重點

(2) 對每個段落都進行同樣的操作

(3) 將所有總結串起來，形成一個「事後大綱」

舉個例子：
假設你寫了一篇關於「咖啡對健康的影響」的文章：

第一段：「咖啡因可以提升注意力和工作效率」
第二段：「適量飲用咖啡可以預防某些疾病」
第三段：「但過量攝入會導致失眠和焦慮」
第四段：「所以建議每天攝入量不要超過400毫克」

透過反向大綱，你可以清楚看到：

• 文章是否有清晰的邏輯發展
• 每個段落是否都有明確的重點
• 是否有重複或離題的段落
• 段落之間的轉換是否順暢
• 論點的排列順序是否合理

你也可以請ChatGPT幫你做反向大綱分析，它可以：

1. 為每個段落提供簡短摘要
2. 指出邏輯連接是否順暢
3. 建議可能需要調整的地方

這個技巧特別適合用來檢查長篇文章，因為它能幫助你「跳出來」用更宏觀的視角檢視整篇文章的結構和邏輯流程。

7. 透過蘇格拉底式對話發展想法

就像蘇格拉底對他的對話者做的那樣，ChatGPT可以扮演智識上的對手，與你對話來幫助你闡明和改進想法。

蘇格拉底式對話（Socratic Dialogue）是什麼？

蘇格拉底式對話是一種透過系統性提問來引導思考的方法。這個方法是以古希臘哲學家蘇格拉底的教學方式命名的。他不會直接告訴學生答案，而是通過持續提問來幫助學生自己發現真理。

讓我用一個例子來說明：

假設你正在寫一篇關於「是否應該禁止學生使用手機」的文章：

學生：我認為學校應該禁止學生使用手機。

ChatGPT（使用蘇格拉底式提問）：
- 你為什麼會有這個想法？
學生：因為手機會分散學生的注意力。

ChatGPT：
- 所有的分心都是負面的嗎？
學生：也不是，有時候適當的休息也是需要的。

ChatGPT：
- 那麼，問題是出在手機本身，還是使用的方式？
學生：嗯...可能更多是使用方式的問題。

ChatGPT：
- 如果是使用方式的問題，完全禁止和教導正確使用，哪個方案可能更有效？
學生：說得對，可能教導學生如何正確使用手機會比完全禁止更實際...

這種對話方式的特點是：

1. 不直接給答案，而是引導思考
2. 通過連續性的提問深入探討
3. 幫助發現自己想法中的盲點
4. 培養批判性思考能力
5. 從表面的觀點深入到本質

使用ChatGPT進行蘇格拉底式對話的建議：

1. 請它扮演提問者的角色
2. 告訴它你的初步想法
3. 讓它通過提問來：
   • 挑戰你的假設
   • 要求你澄清概念
   • 探討可能的反例
   • 思考更深層的含義

這種方法特別適合：

• 釐清複雜的概念
• 發展論文論點
• 檢視自己的思維邏輯
• 發現新的思考角度

使用蘇格拉底式對話的好處是，它不只是幫你得到答案，更重要的是幫助你學會如何思考。

這也是為什麼它是一個很好的學習和寫作工具。

8. 要求提供反駁論點來測試你的論點

為了使你的論點更加紮實，試著請ChatGPT挑戰你的邏輯、

指出弱點，並提出你可能忽略的反駁論點。

9. 與歷史上的偉大思想家比較想法

你也可以請ChatGPT扮演你正在研究的思想家的角色

– 讓你能與康德討論知識論、與魯米辯論神秘之愛，或是與西蒙·波娃探討女性主義的細節。

10. 透過反覆回饋提升寫作水準

ChatGPT可以持續提供建議來強化你的寫作，

讓你在繳交作業前能夠進行多輪改進。

11. 使用進階語音模式作為閱讀夥伴

除了提供書面回答外，ChatGPT還有進階語音模式，

可以即時回答問題或解釋難懂的段落。

在閱讀時開啟語音模式，可以在不打斷閱讀節奏的情況下提供背景說明。

12. 不要只是應付了事 – 要磨練技能

學校作業不只是為了拿分數，更是培養能力的機會。
與其只想著如何完成，不如請ChatGPT建議如何培養批判性思考和清晰寫作的能力。

保持透明 – 註明你的對話

最後一點：當你使用ChatGPT來加深理解、發展想法，

或是獲得原本不會有的見解時，這些都應該在可接受的學術實踐範圍內。

但由於 ChatGPT 也可能被用於不道德的方式，

如果教授能夠確切看到它是如何幫助你思考的，他們可能會更放心。

學術工作的一部分就是要對資料來源保持透明。

這就是為什麼大學強調適當引用的重要性，

確保你承認那些影響你理解的思想家。

同樣地，公開你如何使用ChatGPT也很重要。

最簡單的方式是產生可分享的連結，並將它們列入參考書目。

主動讓教授能夠審查你使用AI的情況，表明你重視學術誠信，

並證明你使用它不是為了逃避工作，而是作為支援學習的工具。

The post 使用 ChatGPT 寫作指南 first appeared on 東東 GCP 教學 - GCP 實戰講師.

想像一下，你寫了一個程式，但還沒有實際執行它。

SAST 工具就像是一個很厲害的「程式碼檢查員」，

它會先讀你的程式碼,然後幫你找出可能有安全問題的地方。

舉個生活例子:

• 這就像是請一個建築檢查員在房子蓋好之前，先看你的設計圖
• 他會說:「喂!這個地方的樑太細了可能會塌」或「這扇窗戶設計得不夠安全，小偷很容易爬進來」

SAST 工具也是這樣:

• 它會找出像是「這裡的密碼存法不夠安全」
• 或是「這段程式碼可能會被壞人利用來攻擊」
• 甚至「這裡可能會洩漏使用者的個人資料」

最棒的是:

1. 不用真的執行程式就能找到問題
2. 很早就能發現並修正問題，省時又省錢
3. 電腦自動檢查，不會漏掉細節

現在做雲端開發，應用程式的安全性絕對是首要考量。

SAST 工具可以幫助開發人員在程式碼撰寫階段就檢查出安全漏洞。

但目前 Google Cloud Platform（GCP）並沒有原生的 SAST 工具可用。

這篇文章會帶您了解 SAST 工具的需求，分析 GCP 上的現有選擇，

並介紹幾款受歡迎的第三方 SAST 工具，幫助您在 GCP 上維護應用程式的高安全性。

原生 SAST 工具的意義與需求

SAST 工具的重要性

SAST 工具的重點就是，它能夠在開發階段就找出程式碼中的安全漏洞。

可以降低修復成本和風險，讓程式碼在上線之前就經過嚴格檢查，這樣就更放心了。

如何區分 SAST、DAST 及其他安全工具

SAST（靜態應用安全測試）跟 DAST（動態應用安全測試）不同。

SAST 是針對靜態程式碼的分析，檢查程式碼本身的安全性；

DAST 則是針對執行中的應用程式進行檢測，也就是測試已經在運行的環境中的漏洞。

兩者通常搭配使用，可以提供更全面的保護。

GCP 中的原生靜態應用安全測試現狀

GCP 有提供原生 SAST 工具嗎？

目前 GCP 並沒有真正的原生 SAST 工具。

雖然 GCP 提供了 Web Security Scanner，

但這主要是針對線上運行中的網頁應用程式進行掃描，

並非針對程式碼進行靜態分析。

簡單說，Web Security Scanner 無法檢查程式碼本身的問題，

只能掃描已經上線的應用程式。

所以，想要進行靜態安全測試的話，這個工具不太適合。

所以，如果想在 GCP 上進行 SAST，還是得考慮第三方工具。

常用的第三方 SAST 工具推薦

SonarQube：企業級的程式碼安全解決方案

SonarQube 是一款開源的程式碼檢查工具，支援多種程式語言。

它可以自動掃描程式碼中的潛在問題，並產生詳細的報告。

SonarQube 特別適合需要長期進行靜態檢查的企業，

可以透過 Docker 容器版本與 GCP 整合，輕鬆加入 CI/CD 流程。

詳細教學可以參考這篇文章。

Snyk 與 GitHub Code Scanning：專業與整合的選擇

Snyk 是一款注重檢查開源程式庫與容器安全的工具，詳細教學可以參考這篇文章。

而 GitHub Code Scanning 支援 SAST 功能，特別適合與 GitHub Actions 整合。

這兩個工具對於那些已經在 GitHub 上開發的團隊特別實用。

NeuVector：補充 Docker Image 漏洞的工具

NeuVector 專門針對 Docker Image 中的漏洞進行檢查。

對於需要更細緻的 Docker Image 分析需求，NeuVector 能彌補 SonarQube 等傳統 SAST 工具在這方面的不足。

如何在 GCP 上整合第三方 SAST 工具

使用 Cloud Build 搭配 SAST 工具

GCP 的 Cloud Build 支持許多第三方工具的整合，包括 SAST 工具。

可以在 Cloud Build 配置檔案中加入 SonarQube 或 Snyk 的步驟，

讓每次提交程式碼後自動進行靜態分析，確保程式碼的品質和安全性。

網上有篇很棒的文章可以參考《Cloud Build- 使用 private connect 進行 Sonarqube 原始碼檢測》。

設定排程掃描與自動化安全檢查

每次 CI 觸發的掃描流程

在 CI/CD 流程中，建議在每次程式碼提交時自動執行 SAST 工具。這樣一來，每段新程式碼的安全性都能即時得到保障，減少安全風險。

每日或每月的排程掃描建議

對於那些已經不再頻繁更新的應用程式，建議可以設定每日或每月的定期掃描，以檢查是否有新的安全漏洞。

這樣就不怕遺漏更新時會有風險。

雲端環境下程式碼安全的未來發展方向

AI 驅動的安全檢測技術

隨著 AI 技術的發展，未來的 SAST 工具可能會更加智能化，具備自我學習和預測潛在漏洞的功能。

這將使得程式碼的分析更精準，有助於提早發現問題。

自動化與持續整合安全掃描的趨勢

隨著 DevOps 的推廣，未來安全掃描將無縫整合至開發流程中，成為每次程式碼提交時的基本步驟。

這種自動化的安全檢測方式將能顯著提升應用程式的整體安全水準。

結論

雖然 GCP 沒有內建的 SAST 工具，但通過搭配第三方工具（如 SonarQube、Snyk 等），

並與 GCP 的 Cloud Build 整合，可以實現高效的程式碼安全檢查。

隨著技術進步，未來的 SAST 工具將更加自動化和智能化。

我們建議依據團隊需求選擇合適的工具，並設定自動化安全檢查流程，以因應不斷變化的安全需求。

常見問題解答（FAQ）

1. GCP 有原生的 SAST 工具嗎？ 目前 GCP 沒有提供原生 SAST 工具，但可以整合第三方工具來實現靜態安全檢查。
2. GCP 的 Web Security Scanner 可以當作 SAST 工具使用嗎？ 不行，Web Security Scanner 屬於 DAST 工具，僅能檢查運行中的應用程式，而不是程式碼本身的安全性。
3. 哪些 SAST 工具適合在 GCP 上使用？ 推薦 SonarQube、Snyk 和 GitHub Code Scanning 等，都可以方便地整合至 GCP。
4. 應該多久進行一次 SAST 掃描？ 針對頻繁更新的專案，建議每次 CI/CD 執行時觸發 SAST；而不常更新的應用程式則可設定每日或每月掃描。
5. SAST 與 DAST 可以同時使用嗎？ 可以，SAST 和 DAST 的搭配使用可以提供更全面的安全保障，適合對安全性要求較高的項目。

以上文章感謝各位網友參與討論，才能整理成上述完整的內容！

The post SAST 工具是什麼？GCP 上有類似工具嗎？該選擇哪一種？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

一、在本地端解析網網域名稱

你輸入的網址 (如 www.bytebytego.com) 電腦是看不懂的，

需要轉換成電腦能理解的地址，也就是 IP 位址 (如172.67.73.33)。

瀏覽器首先會在不同的「快取」(cache，是暫時儲存資料的地方) 中尋找：

• 瀏覽器自己的快取

• 電腦作業系統的快取

• 本地網路 (你家、辦公室或學校) 的快取

• 網路服務商 (ISP) 的快取

快取的內容到底包含什麼東西呢？

就像是一本通訊錄，記錄著網址和 I P位址的對應關係。

如果這些地方都找不到，就會向DNS (網域名稱系統，像是網路世界的電話簿) 詢問。

二、向外查詢 IP 位址

DNS 系統包含多個 DNS 伺服器，它們會互相詢問，直到找到正確的IP位址。

詢問的順序如下：

1. 你的設備會詢問本地 DNS 解析器。

像中華電信的DNS 解析器 IP 為 168.95.1.1、168.95.192.1，

Google 的 DNS 解析器 IP 為 8.8.8.8 和 8.8.4.4。

2. 如果本地解析器沒有答案，它會詢問根網域伺服器。

根網域 (Root Domain) 伺服器是網際網路 DNS 層級結構中最高層級的 DNS 伺服器，

它們儲存所有頂級網域（如 .com、.org、.net 等）的 DNS 伺服器資訊。

3. 根伺服器會指引到相應的頂級網域伺服器。

當根伺服器收到查詢時，它們會指向適當的頂級網域伺服器 (Top-Level Domain Server)，

根網域伺服器不直接知道 bytebytego.com 的 IP 地址，

但它知道 .com 頂級網域伺服器的位置。

根伺服器會說：「我不知道 www.bytebytego.com 的 IP，

但我知道負責 .com 的伺服器在哪裡，去問問它們吧。」

4. TLD 伺服器會指引到負責特定網域的權威網域伺服器

權威網域伺服器 (Ahthoritative Name Server) 管理的，

這通常是由該網域所屬公司 (例如：bytebytego)，

或其選擇的 DNS 服務提供商 (例如可能是 Namecheap) 來維護。

這個過程叫做「遞迴 DNS 查詢」，就像是在多個部門間傳遞訊息，直到找到答案。

三、建立連線並發送請求

知道 IP 位址後，瀏覽器就會向該位址發送請求。

為了安全，現在大多使用 HTTPS 協定，你會在網址前看到一個小鎖頭圖示。

像是這樣 (現在要點開才能看到鎖頭)：

建立安全連線的過程包括：

1. TCP 三方交握 (像是在握手確認彼此身份)

a. 第一次握手

客戶端(也就是瀏覽器)：「嘿！伺服器，你在嗎？我想和你說話！」

技術上：客戶端發送一個 SYN（同步）封包。

b. 第二次握手

伺服器：「嗨客戶端！我在這兒。你能聽到我嗎？」

技術上：伺服器回應一個 SYN-ACK（同步-確認）封包。

c. 第三次握手：

客戶端：「太好了，我聽得很清楚。讓我們開始聊天吧！」

技術上：客戶端發送一個 ACK（確認）包。

現在，雙方都確認可以聽到對方，建立了連結。

2. 交換加密金鑰 (像是交換只有雙方知道的密碼)

這就像兩個人想秘密交談，但擔心周圍有人偷聽：

a. 伺服器出示證書：

伺服器：「看，這是我的身份證（SSL證書）。你可以相信我。」

這個證書包含伺服器的公鑰。

b. 客戶端驗證證書：

客戶端檢查證書是否有效，就像檢查身份證的真偽。

c. 客戶端生成會話金鑰 (Session Key)：

客戶端：「好的，我相信你。我們來用這個特殊的密碼本吧。」

客戶端創建一個隨機的會話金鑰（相當於密碼本），指的是加密的方法。

d. 加密傳送會話金鑰：

客戶端用伺服器的公鑰加密會話金鑰。

就像把密碼本放在只有伺服器能打開的盒子裡。

e. 伺服器解密會話金鑰：

服務器用自己的私鑰打開”盒子”，獲得會話金鑰。

f. 開始加密通訊：

雙方：「太好了，現在我們可以用這個特殊的密碼本安全地交談了！」

之後的所有通信都用這個會話金鑰加密。

這確保了你和網站之間的通訊是加密的,別人無法竊聽或篡改。

四、處理回應

(一) 網站回應 (Response)

網站伺服器收到請求後，會處理並發送回應。

回應通常包含三部分：

1. HTML (網頁的基本結構)

就是告訴瀏覽器：

這裡放個標題，那裡放段文字，這邊擺張圖片。

它就像是在紙上畫房子的平面圖。

2. CSS (控制網頁外觀)

CSS就是告訴瀏覽器：

這個標題要大一點、藍色的；

段文字要靠右邊、加個底線。

它就像是一個裝潢師，負責讓整個網頁看起來漂亮。

3. JavaScript (控制網頁行為)

JavaScript讓網頁變「聰明」了，它能理解你的操作並作出反應。

比如，你在購物網站點了「加入購物車」，

不需要重新載入整個頁面，購物車的數字就會立即更新，

這就是JavaScript在工作。

(二)、瀏覽器動作

瀏覽器接收這些資料後，會進行以下步驟：

1. 解析 HTML 生成 DOM 樹 (Document Object Model Tree)

DOM 樹就是這個網頁的組織結構，它顯示不同元素之間的關係，

第一層是網頁的 <html> 標籤，

第二層是 <body> 標籤，

第三層是<div> 或其他容器標籤。

DOM 樹就是將網頁結構變成瀏覽器能理解的格式。

2. 解析 CSS 生成 CSSOM 樹

CSSOM 樹（CSS Object Model Tree）是與 DOM 樹相對應的另一個重要概念。

CSSOM 樹是瀏覽器對網頁所有 CSS 樣式的內部表示。

它與 DOM 樹平行存在，共同決定網頁的最終呈現。

簡單說就是，將樣式資訊轉換成瀏覽器能理解的格式。

3. 結合 DOM 和 CSSOM 生成渲染樹 (Render Tree) 

渲染樹是用來決定每個元素應該如何顯示

就像是在精心策劃一場時裝秀，

將「誰要出場」(DOM) 和「穿什麼衣服」(SSSOM) 的訊息結合起來，

形成一個清晰的「演出計劃」。

4. 根據渲染樹繪製網頁

如前段的「演出計劃」，告訴瀏覽器究竟該在螢幕上畫出什麼，怎麼畫。

這個過程看似複雜，但瀏覽器都自動完成了，

讓我們能夠看到美觀且功能完整的網頁。

就是讓瀏覽器把網頁畫出來給你看的意思。

這整個過程通常在幾秒內完成，

涉及網路通訊、資料加密、以及複雜的瀏覽器渲染機制。

雖然背後技術複雜，但對使用者來說，

只是輸入網址後稍等片刻，網頁就呈現在眼前了。

The post [轉職IT必修課] 瀏覽器原理：你用瀏覽器輸入網址後，背後發生什麼事？DNS、三方交握、加密通訊等概念簡介 first appeared on 東東 GCP 教學 - GCP 實戰講師.

Data Engineer 證照是什麼？

Google Cloud Professional Data Engineer 是 GCP 推出的證照之一，

Data Engineer 就是針對 GCP 資料處理各項服務，

對它們的使用方法、資料處理流程、資料管道 (Data Pipeline)、

最佳實務和解決方案的相關知識所推出的證照。

而證照的有效期限只有兩年，所以快到期了，必須要趕快去考，

我是 9/18 到期，它有給予一個月的寬限期，所以趕在 9/23 去考，

目前第三次考過 Date Engineer，這是證照的公開連結。

為什麼要考這 Data Engineer 證照?

我之前一直都在 GCP 代理商擔任雲端架構師，

幫客戶執行各種上雲專案、教育訓練、技術支援和解決方案的建議，

其中也有不少關於資料方面的需求，所以對代理商而言，是一張很重要的證照。

現在我自己出來教 GCP，為了維持知識的更新，就繼續考來延長有效期。

近年來大數據、雲端和 AI 的蓬勃發展，資料的重要性不言而喻，

如果你的公司也在用 GCP，你的工作又和資料相關，

則這張證照一定是必備的。

Data Engineer 考試資格

沒有資格限制。

官網希望你至少有 3 年產業經驗，包含 1 年使用 GCP 設計解決方案的經驗，

有經驗去考會比較有感覺，至少你知道題目都在問什麼，

如果對 GCP 的資料各項服務都不懂，直接去考，

就像是在背題目跟答案，考完學到的不多。

PS.其實你根本背不完，還不如乖乖回去研讀相關知識。

Data Engineer 到底在考什麼？

常見的考試情境如下：

1. 資料建模

資料應該放在哪裡？怎麼放比較便宜？

效能比較好？看到的資料比較新？

2. 批次和即時資料處理

用什麼工具抓資料？多久抓一次？

資料有問題怎麼處理？如何確保資料不會掉？

3. 機器學習

機器學習的基本概念，資料放哪裡適合做機器學習？

資料要整理成什麼樣子？什麼情境之下，該用什麼模型？

4. 資料管道建立

地端資料如何上 GCP？其他雲端資料如何抓過來？

怎麼傳速效能比較快？比較便宜？比較安全？

GCP 的資料如何放到 BigQuery？

Data Engineer 各服務出題比例

先看這張圖就對了：

你可以看得出幾個重點：

1.核心服務

(1) BigQuery 

資料倉儲和分析工具，它一直保持資料一哥的地位，你也可以說它是雲端界陳浩南。

(2) Dataflow 

資料處理最重要的自動化工具，是原生的 Apache Beam，

寫 Java 或 Python 程式讓它可以自動處理資料，還能夠依照資料量大小 Autoscale。

(3) Pubsub 

接住串流資料最重要的工具，如果你的串流資料來源，流量大小不固定，

有時1秒1筆，有時1秒10萬筆，就可以用 PusSub 幫你把資料接住，不會漏掉。

這三個弄熟就可以當選總統掌握 40% 的考試了，未來應該還是持續佔據很大的比例。

2.機器學習知識

因為資料是 AI 跟機器學習的原料，所以機器學習的基礎知識都納入考試，

也包含機器學習相關服務 BigQueryML、AutoML、Dialogflow。

奇怪怎麼沒有 Vertex AI？最近生成式 AI 的興起，Google 大推 Vertex AI 開發平台，

各種 AI 應用工具例如 Agent Builder、Model Builder 和 Model Garden 推陳出新。

不過，這些服務 Google 自己也一直改來改去的，功能和命名都一直改，還沒穩定下來，

我猜是這樣的原因，所以都還沒納入考題，也好，不然考了之後，服務又改名或下架，就太尷尬了。

3.基本資料服務

Cloud SQL – 雲端版的 MySQL、Postgre SQL、SQL Server

Dataproc – 雲端版的 Hadoop、Spark、Pig、Hive 等資料處理工具

Bigtable – 雲端版低延遲的 NoSQL 資料庫

Cloud Storage – 無限大的雲端檔案儲存空間和 API 服務

Spanner – 全球即時同步的關聯式資料庫

Cloud Composer – 資料管道管理與編排，可以控制整個資料的旅程，

從資料的產生、處理到分析都可以納入管理，近年來考題越來越多。

4.資料搬遷

各種情境題，像是：

地端資料如何搬上雲端？

怎麼傳比較快？或比較便宜？

其他雲端的資料怎麼傳到 GCP？

GCP 的其他服務，怎麼倒入 BigQuery？

資料放哪裡比較便宜？

這種題目蠻需要你對各種工具和服務都很了解，才有辦法回答正確。

5.資安跟資料治理

在這部分當中，Cloud KMS (加密金鑰管理) 和 Cloud DLP (資料外洩防護) 一直都會考，

最近又出了像是 Dataplex、Analytics Hub、Data Catalog 和 Dataform 比較新的服務。

就是因為公司的資料太多，然後到處放，沒有管好怕會造成外洩，

所以這些服務就是要幫助公司管好資料，未來這塊考題應該會越來越多，

我也是因為考試才碰到這些東西，有機會一定要實際操作看看。

官方宣布的考試範圍可以參考這個連結，以前有考 Case 題組，

就是一個 Case 考個 3~5 題，大概考 1~3 個 Case，

你可以從官網先了解公司的背景，考試的時候就不用從頭開始看。

但 2024 年又沒考了，所以不用再讀 Case。

準備方式

官方資源

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

但是文件非常多，是「非常非常非常多」，所以你只要大概知道每個服務大概在做什麼就好，

你可以讀像是：

Overview 和 Introduction： 大概了解用途。

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

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

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

你可以上這個 Skillbost ，裡面有一個 Data Engineer Learning Path：

它除了免費提供線上課程之外，

課程中還有免費的 Lab，至少都做一下，

這樣你學東西才會有感覺，不會都在死記硬背，學不到東西。

官網還有提供範例考題，一定要做，不要送分題都拿不到。

網路資源

說真的，有些服務在台灣的企業，真的很少用到，

除非你是在專門做資料分析的公司，或是技術領先的公司。

要不然，很多考試的內容，在工作上很難用到。

所以官方文件大概看過之後，

你就直接搜尋 “google cloud data engineer questions” 找到相關資源，例如 Exam Topic。

要注意的是，內容「非常多」，而且 Google 一直都在更新考試內容，

像我今年第三次考，發現跟上次 2022 年比起來，根本就是大改，

這段時間我 K 書 K 到懷疑人生，難度指數從 4 顆星升到 5 顆星。

考試規則和題型

單選題和多選題，50 題，2 個小時考完。

進考場前所有東西都要給考場人員保管，手機要關機，手錶要拿下來。

中途可以上廁所，但時間會繼續算。

冷氣有點冷，可以帶件外套。

考完會馬上告訴你 Pass 或 Fail，官方是說需要人工確認後再發正式 Email 給你，

另外這個考試結果，不會講分數，不會跟你說哪一題做錯，

我猜他們要看考試的監控影片，看你有沒有作弊。

報名考試

註冊帳號與報名考試

直接從這個網站報名，先註冊帳號，記得姓名要用護照名稱喔！

我以前用一般的英文名字，跟護照羅馬拼音的名字不同，

結果到考場被拒絕，盧了半天才能進去考試，讓我有夠緊張。

我當天考完馬上聯絡客服，請他們幫我改成護照名稱 (因為自己無法改)。

然後點擊 “Register For An Exam”：

找到你要考的科目，選擇你要遠端 (Remote) 還是去考場 (Onsite) 考，

我一律建議去考場，因為遠端你要安裝軟體，然後在家找一個安靜的地方，

對方還會在線上看你考試，確認你有沒有異常的舉止。

萬一考試那天網路不通，或是你家的貓咪突然攻擊你，你就無法專心完成考試了。

選好就可以選擇考場，像我都去恆毅資訊考試，

因為恆毅資訊有喝到飽的快樂肥宅水，

考前喝一杯，考完開心再喝一杯，不香嗎？

對了不要喝太多，不然考試中會很想上廁所。

考試費用

像上面選擇科目的時候，它跟你說要 200 美金，但你真的要付款的時候，

它又自動打 6 折，所以才 120 美金。

而且它還有 Coupon/Voucher Code，後面會跟你說如何取得。

但要注意沒考過的話，

第一次沒考過，要 14 天後才能重考，

第二次沒考過，要 60 天後才能重考，

第三次沒考過，要 365 天後才能重考，

重考都要重新付費喔！詳情看這份官方的重考政策。

列印考試確認單

報名刷卡完成之後，你會收到一封 Email，

上面有考試相關資訊，

更重要的是 Test Taker Authorization Code，考場要比對這個 Code，

強烈建議你印出來，不然考場人員無法讓你進去考試喔！

考完試之後會收到什麼福利？

收正式通知信

我這次是 9/23 去考試的，然後在 9/25 收到下面這封信，

這才是正式確認你有成功考過。

註冊 Credly 帳號並下載證照 PDF 檔

如果你是第一次考到 GCP 證照，請先去 Credly 註冊一個帳號，

先點擊第一個連結：

然後你可以參考這篇，我當初花半小時才找到下載的地方，

所以特別寫了這篇分享，方便你投履歷表或跟公司報帳。

取得考過禮物和考試折扣券

往下看有一條很重要，

這一條是給你拿考試禮物和考試折扣券的地方。

PS.如果你是第一次考證照，強烈建議每一個連結都點進去，

有很多重要權益可能是你想要的喔！

點擊 “Account” 之後，會進到 https://cp.certmetrics.com/google/en/benefits/program 

這時點擊 Claim benefit：

你會拿到一個折扣碼，再點擊 Access Benefit：

(前後兩張圖不一樣，因為原本的圖沒截到)

補充一下，像左邊的 Exam Discount，就可以讓你下次報名考試的時候，

輸入折扣碼，取得半價優惠，也就是已經 120 美金的費用，再變成 60 美金，所以根本沒有到 6000 台幣那麼貴。

我們再回來，點擊 Access Benefit，會跳出新的視窗，

你會進入 Google 的商店，你可以免費選一個禮物：

把折扣碼貼上之後，就進入選禮物的頁面。

像我就選了一件外套：

最後再填寫一下地址，記得都要用英文喔，

你可以去郵局網站來翻譯成英文地址：

完成囉！接下來就靜候 Google 從國外發貨到你家！

證照持有者目錄

還有一個我覺得很有趣，有點類似證照名人榜的東西，

你可以在這裡查到你自己的名字。

你可以用下面的 Search Directory，用證照篩檢考過的人有哪些：

像我把我 6 張證照都加入篩選，看看有多少人跟我一樣，結果竟然有 531個人。

我再加一個過濾條件 Location 選台灣看看，結果台灣還有 16 個人至少 6 張證照以上，

可見人外有人，天外有天啊！！

可見台灣這麼小的地方，還是臥虎藏龍，高手在民間！

我要持續努力，不可以此自滿！

以上分享到這裡，謝謝大家！

The post GCP 證照 Data Engineer 介紹、考試心得、準備方式和考過福利分享 first appeared on 東東 GCP 教學 - GCP 實戰講師.

生成式 AI 是一種人工智慧技術，可產生各種類型的內容，

包括文字、圖片、聲音訊和合成資料。

那人工智慧又是什麼？

人工智慧是電腦科學的一個分支，專門研究如何創造一個「幫你做事的人」，

也叫智慧代理人 (Intelligence Agent)，它可以自己推理、學習和行動。

所以人工智慧會研究如何讓機器可以自己思考和行動。

二、機器學習

在人工智慧中，機器學習是一個小分支。

它是一支程式，會根據輸入的資料，來訓練出一個模型。

當你訓練好這個模型，它可以根據新輸入的資料，做出預測。

這樣的話，你就不用自己寫程式來判斷，而是讓它自己學習。

想像一下你給小嬰兒，看動物圖片或繪本，

拿著一張又一張的狗或貓的照片給他看，

對它說「這是狗勾」、「這是貓貓」。

當你給小嬰兒看了多張照片，你就可以拿新的照片問他，「這是狗還是貓？」

他就可以回答正確，而他能辨識出來的前提，

就是因為他看了夠多狗貓的照片，所以才能辨識出來。

回到機器學習，就代表你要準備大量的狗貓的照片，

給你的機器學習程式來訓練模型。

你可能會想說，這麼麻煩，那還不如人工辨識就好了？

但重點是「規模化」的問題，

今天給你 500 張照片來辨識，你可能還吃得消，

如果給你 50000 張照片呢？你應該會受不了。

但機器學習可以「非常快速」辨識完成，

而且又不會像你一樣喊累，動不動說要離職。

這就是它可以取代你的地方，嗯我是說它可以輔助你提高效率。

而機器學習又有細分成「監督式學習」(Supervised Learning)

和「非監督式學習」(Unsupervised Learning)。

監督式學習是用有標籤的資料來訓練，

例如媽媽拿著一堆貓的照片跟小孩說「這是貓」，

「貓」就是「標籤」，而「照片上看到的東西」就是「特徵」。

小孩看了很多貓的照片，就是在了解這些照片有什麼共同的「特徵」，

進而推斷下一張照片是不是貓，

如果小孩猜錯，媽媽會再糾正，讓小孩知道如何分辨，

也就是重新訓練模型，讓判斷的錯誤縮到最小。

而非監督式學習則是「沒有標籤」，

例如媽媽拿著一堆貓和狗的照片給小孩，然後說「自己看！」

讓小孩自己歸類照片中的動物，然後判斷新的照片。

當然現實中不會這樣，以電子商務為例，

你手上有 10 萬筆消費者交易資料，

傳統上用人口統計變數(姓名、年齡、收入)分類可能不夠精準，

無法光用年齡就能預測他們會買什麼東西，

你就可以使用非監督式學習，依照消費者的屬性或行為，

把消費者分成不同的族群， 就可以更精準地推薦商品。

三、深度學習

另外還有深度學習，又是機器學習的分支，

使用人工神經網路，能處理比機器學習更複雜的模式。

人工神經網路的靈感來自於人腦，它們由許多互連的節點或神經元組成，

可以透過處理資料和進行預測來學習執行任務。

深度學習模型通常具有多層神經元，

這使得它們能夠學習比傳統機器學習模型更複雜的模式。

而神經網路有一個特色，可以使用「有標籤的資料」和「沒有標籤的資料」。

也叫做「半監督式學習」(Semi-Supervised Learning)。

它只需要一點點「有標籤的資料」，和大量「沒有標籤的資料」，就可以訓練模型。

「有標籤的資料」可以讓神經網路學習基本的概念，

而「沒有標籤的資料」則幫助神經網路「泛化」到新的例子。

就像媽媽給小孩看 10 張有註明是貓和 10 張有註明是狗的照片，

其他 100 張貓和 100 張狗沒有註明，叫小孩自己看，

但小孩自己有機會能判斷出來。

四、生成式 AI

而 生成式 AI 是深度學習的一個子集，所以它也使用人工神經網絡，

可以使用監督、非監督和半監督方法處理「有標籤的資料」和「沒有標籤的資料」。

而大型語言模型也是深度學習的子集。

它可以創造新的內容，像是文字、圖片、聲音等。它跟一般的 AI 模型不太一樣:

一般 AI 模型可能只會分類東西，

例如：「這是不是垃圾郵件」或「這是貓、那是狗」

生成式AI則可以創造全新的東西，例如：寫一篇文章、畫一張圖

生成式 AI 是怎麼運作的呢？

1. 它會先學習大量的資料
2. 從中找出規律和模式
3. 然後根據你給的提示 (Prompt)，創造出新的內容

例如你問它「貓是什麼？」，

它會綜合它學過的所有關於貓的知識或圖片，給你一個回答。

而目前生成式 AI 有幾種主要類型：

1. 文字生成 (Text-to-Text)

例如翻譯、寫文章、寫故事、講笑話。

目前巿面上知名的模型包含 Open AI 的 ChatGPT、Google 的 Gemini、微軟的 Copilot、Anthropic 的 Claude 和 Perplexity 出的 Perplexity。

2. 圖片生成 (Text-to-Image)：

根據文字描述畫圖，可以產生接近真實的照片，或卡通圖片。

像是你在上面看到的貓和狗的圖片，就是我用 Copilot 來生成的。

還有知名的模型例如 Midjourney 和 Stable Diffusion 都是圖片生成模型。

3. 影片生成 (Text-to-Video)

根據文字製作影片，像 Sora 就是 Open AI 使用 DALL-E 開發出來的，

不過目前尚未開放大眾使用 (怕功能大強大導致無法控制的局面)。

4. 任務執行 (Text-to-Task)

根據指令執行特定任務，例如 AutoGPT。

使用者不用一直下指令，AutoGPT 可以自動完成任務，

不需要人工干預，只要給它一個最終目標，

AutoGPT 就能自動產生完成任務的每個指令，

這種概念被稱為「AI 代理」( AI Agent)，

而 GCP 供了幾種工具來使用生成式 AI：

1. Vertext AI Studio

讓開發者快速試用和客製化AI模型。

2. Vertex AI Agent Builder

不用寫程式就能創建AI應用

3. Gemini API

讓開發者使用 Google 的大型語言模型，

做出以 Gemini 為基礎的 AI 應用程式。

最後，生成式AI雖然功能強大，

但有時也會產生一些奇怪或錯誤的內容，

這叫做「幻覺」(Hallucination)，

所以在使用時要小心驗證，不要盲目相信 AI 喔！

The post 生成式 AI 是什麼？跟機器學習差在哪裡？ first appeared on 東東 GCP 教學 - GCP 實戰講師.