使用 Antigravity CLI 和 SRE 擴充功能調查 GKE 中斷事件，並建立精美的事後檢討報告

1. 簡介

856ff52e60953a92.png

上次更新時間：2026 年 5 月 13 日

使用 SRE 擴充功能調查 GKE 中斷事件，並建立精美的事後檢討報告

歡迎參加本SRE 研討會，瞭解如何在 Google Cloud 上試用 SRE 輔助工具！

本程式碼研究室將引導您完成下列操作：

  1. 根據知名的開放原始碼 microservices-demo 安裝 GKE 叢集。
  2. 以不同方式 (有些較為明顯，有些較為細微) 造成中斷，藉此建立中斷事件。
  3. 安裝並使用 Antigravity CLI (或類似的架構) + SRE 擴充功能，以進行後續步驟。
  4. 調查並修正服務中斷問題。
  5. 建立事後檢討報告。
  6. 運用繪圖技能生成有根據的圖表，讓觀眾瞭解發生了什麼事，以及發生時間。

本程式碼實驗室的逐步結構如下：

程式碼研究室結構圖

本研討會的目標如下：

  1. 展示 SRE 擴充功能的強大功能，並說明如何運用這項擴充功能：設定 OneMCP、安全執行器、調查、產生檢討報告、圖表和 CSV 摘要。
  2. 教導您調查自家 Google Cloud 情境的技能。

里程碑 1：環境設定和中斷模擬

這個里程碑的目標是在 GKE Autopilot 上設定 Kubernetes 示範應用程式、安裝 Antigravity CLI，並人為觸發 GKE 叢集故障情境，模擬實際工作環境事件。

里程碑 2：使用 SRE 擴充功能進行調查和緩解

破壞環境後，您將使用配備 SRE 擴充功能的代理程式 CLI 工具，有系統地探索基礎架構、會診問題、實作修正的安全執行模式，以及驗證叢集健康狀態。

里程碑 3：事後檢討和圖表生成

解決問題後，您將產生結構化事件事後檢討文件，並使用 GCM (Google Cloud Monitoring) API 擷取實際指標資料，建立視覺化圖表，記錄中斷事件發生的時間和方式。

建構項目

在本程式碼研究室中，您將使用 SRE 擴充功能調查並修正 GKE 中斷問題。您將學會以下內容：

  • 使用網路政策封鎖、有錯誤的 Canary 部署和防火牆規則更新，模擬 GKE 中斷。
  • 使用 SRE 擴充功能輔助的 CLI 助理，對叢集服務中斷進行分類。
  • 使用 Safe Executor 模式安全地實作修復步驟。
  • 生成詳盡的事後檢討文件。
  • 使用 Google Cloud Monitoring 時間序列查詢，繪製事件指標的圖表。

課程內容

  • 如何運用 SRE 擴充功能技能檢查 GKE Kubernetes 資源和政策。
  • 如何運用 Safe Executor 模式執行代理程式建議的指令，並進行適當的風險評估。
  • 如何使用 monitoring-graphs 技能，直接從 GCM 生成指標的基礎圖表。
  • 如何以結構化檢討報告格式記錄事件調查結果。

軟硬體需求

  • 已啟用計費功能的 Google Cloud 專案。
  • 指令列工具：gcloud、kubectl、terraform。
  • Antigravity CLI (安裝在本機或 Cloud Shell 中)。
  • IDE (例如 vscode、IntelliJ、RubyMine 或 Vim)。

為何要使用 SRE 擴充功能 + Agentic CLI？

生產環境中斷事件的處理速度很快，需要關聯多個子系統 (Kubernetes 資源、虛擬私有雲網路、Cloud Monitoring 指標、IAM 權限)。SRE 擴充功能可讓代理式 CLI 輔助工具 (例如 Antigravity CLI) 擔任自主副駕駛，執行預先編譯的應對手冊、查詢監控圖表，並建議安全修復方式，同時讓人類操作員參與其中。

2. 開始設定

選擇下列其中一個選項：自行設定環境 (如要執行這項操作)

在本機上執行程式碼研究室，或啟動 Cloud Shell，完全在雲端執行程式碼研究室。

自修實驗室環境設定

  1. 登入 Google Cloud 控制台，然後建立新專案或重複使用現有專案。如果沒有 Gmail 或 Google Workspace 帳戶，請先建立帳戶。

295004821bab6a87.png

37d264871000675d.png

96d86d3d5655cdbe.png

  • 專案名稱是這個專案參與者的顯示名稱。這是 Google API 未使用的字元字串。你隨時可以更新。
  • 專案 ID 在所有 Google Cloud 專案中都是不重複的，而且設定後即無法變更。Cloud 控制台會自動產生專屬字串，通常您不需要在意該字串為何。在大多數程式碼研究室中，您需要參照專案 ID (通常標示為 PROJECT_ID)。如果您不喜歡產生的 ID，可以產生另一個隨機 ID。你也可以嘗試使用自己的名稱，看看是否可用。完成這個步驟後就無法變更，且專案期間會維持不變。
  • 請注意，有些 API 會使用第三個值，也就是「專案編號」。如要進一步瞭解這三種值，請參閱說明文件。
  1. 接著，您需要在 Cloud 控制台中啟用帳單，才能使用 Cloud 資源/API。完成這個程式碼研究室的費用不高，甚至可能完全免費。如要關閉資源，避免在本教學課程結束後繼續產生費用，請刪除您建立的資源或專案。Google Cloud 新使用者可參加價值$300 美元的免費試用計畫。

啟動 Cloud Shell

雖然可以透過筆電遠端操作 Google Cloud，但在本程式碼研究室中，您將使用 Google Cloud Shell，這是可在雲端執行的指令列環境。

在 Google Cloud 控制台中，點選右上角工具列的 Cloud Shell 圖示：

啟用 Cloud Shell

佈建並連線至環境的作業需要一些時間才能完成。完成後，您應該會看到如下的內容：

Google Cloud Shell 終端機的螢幕截圖，顯示環境已連線

這部虛擬機器搭載各種您需要的開發工具，並提供永久的 5GB 主目錄，而且可在 Google Cloud 運作，大幅提升網路效能並強化驗證功能。您可以在瀏覽器中完成本程式碼研究室的所有作業。您不需要安裝任何軟體。

3. 先決條件 (安裝)

在本教學課程中，您需要安裝：

1. Python 和 uv

python 和 uv (Python 的套件管理員)。確認已安裝 uv：

$ curl -LsSf https://astral.sh/uv/install.sh | sh

為什麼要使用 uv？雖然您可以使用偏好的 Python 管理工具，但使用 uv 可確保您和 Antigravity CLI 的 Python ENV/PATH 設定相同，因此您的殼層體驗與 Antigravity CLI 的體驗大致相同。舉例來說，如果您使用 virtualenv，Antigravity CLI 就會強制執行「source .env/venv/bin/activate && my-original-command」等動作，模擬您的環境。

2. Antigravity CLI (agy)

如要安裝官方 Antigravity CLI (agy 指令)，請開啟終端機並執行啟動安裝程式：

macOS 和 Linux：

$ curl -fsSL https://antigravity.google/cli/install.sh | bash

Windows (PowerShell)：

irm https://antigravity.google/cli/install.ps1 | iex

這個指令碼會動態偵測您的 OS 和架構，並下載最新編譯的

agy

二進位檔，並設定 PATH。重新啟動終端機或重新載入殼層設定，變更才會生效。

efade99623113f1.png

驗證

您需要 Google AI Studio API 金鑰。

匯出 API 金鑰：

export GEMINI_API_KEY="your-api-key"

使用 gcloud 進行驗證：

export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
gcloud auth application-default login

設定工作環境並部署微服務示範應用程式

讓我們複製 microservices-demo 應用程式，並透過 Terraform 部署基礎架構和應用程式

此時您可以開啟 IDE (Visual Studio Code、IntelliJ、RubyMine 等)，然後開啟資料夾。

# 1. Find an empty directory, and download this repo.
git clone https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/terraform

# 2. Update project ID to your gcloud project ID
sed -i 's/<project_id_here>/YOUR_ACTUAL_PROJECT_ID/g' terraform.tfvars

# 3. Deploy the microservices-demo application in GKE autopilot
# If there is a prompt answer yes and continue. This step can take up to 10 mins for provision gke autopilot cluster and deploy microservices-demo application
terraform init
terraform plan
terraform apply

# 4. Verify the IP address of frontend-service to access the online-boutique application
kubectl get service frontend-external | awk '{print $4}'

# 5. Find an empty directory , and download this repo.
git clone https://github.com/palladius/sre-testing-suite.git
cd sre-testing-suite/test-scenarios/microservices-demo-gke/breakage-scenarios

如要測試設定，請存取 http://[IP ADDRESS] 並載入 online-boutique 應用程式

為 sre-antigravity-cli-extension 設定工作環境

# 1. Install the SRE Extension plugin globally
git clone https://github.com/gemini-cli-extensions/sre.git ~/.gemini/config/plugins/sre-extension

# 2. Launch the Antigravity CLI (agy)
agy  # This runs the CLI under your current breakage-scenarios folder.
# Login with your corporate or personal account when prompted.

# 3. Within the agy agent prompt, configure your MCP servers and GCP project
Use the gcp-mcp-setup skill to setup my GCP project "<gcp_project_id>" with email jane-doe-sre@credible-company.com

4. 步驟 1：模擬中斷 (中斷情境)

在這個步驟中，我們將刻意中斷已部署的 GKE 叢集，模擬實際工作環境的事件。你可以選擇三種情境 (或依序嘗試三種情境)：

情境 1：結帳服務網路封鎖 (標準/自動駕駛)

這個情境會套用 Kubernetes NetworkPolicy，模擬前端與結帳服務之間的連線中斷，該 NetworkPolicy 會充當流量「黑洞」。

  1. 前往情境資料夾：
    cd breakage1-checkout
  2. 觸發中斷：
    ./break.sh
    這會在 default 命名空間中建立名為 update-checkout-from-frontend 的 NetworkPolicy，拒絕前往 checkoutservice 的輸入流量，除非流量來自具有 app: frontend-checkout-test 標籤的 Pod (不存在)。
  3. 嘗試在 Online Boutique 前端購買商品。結帳頁面會停止回應或顯示 HTTP 500 錯誤。

情境 2：Canary 推出時發生錯誤 (Autopilot with Istio)

這個情境會模擬不良的部署作業，透過 Kubernetes 初期測試部署推出有錯誤的前端版本。

  1. 前往情境資料夾：
    cd ../breakage2-canary
  2. 觸發中斷：
    ./break.sh
    這會部署初期測試部署 frontend-canary，其環境變數有錯字：PRODUCT_CATALOG_SERVICE_ADDR 設定為 productcatalogservices:3550，而非 productcatalogservice:3550。
  3. 載入前端首頁。由於 Canary 服務無法解析產品目錄，因此偶爾會失敗 (視轉送權重而定)。

情境 3：VPC 防火牆叢集封鎖

這個情境會模擬虛擬私有雲防火牆設定錯誤，導致所有傳入 GKE 叢集的流量遭到封鎖。

  1. 前往情境資料夾：
    cd ../breakage3-firewall
  2. 觸發中斷：
    ./break.sh
    這會建立名為 frontend-ingress-v2 的虛擬私有雲層級防火牆規則，並以 priority=1 和動作 DENY 為目標，將輸入流量導向通訊埠 80、443 和 8080。
  3. Online Boutique 網站將完全無法連線，且要求會逾時。

5. 步驟 2：使用 SRE 擴充功能調查中斷情形

應用程式已停止運作，現在請使用 CLI 助理 (Antigravity CLI) 開始調查。

  1. 返回主要中斷情境資料夾，然後啟動 CLI 輔助程式：
    cd ..
agy
  2. 要求助理執行基礎架構探索和診斷檢查：
    Investigate my GKE cluster for outages. Are all services healthy?
  3. 代理的用途：
    • 這會啟用 investigation-entrypoint 和 gcp-playbooks 技能。
    • 並列出 Kubernetes Pod、部署作業和服務，以找出失敗的目標。
    • 檢查網路政策 (適用於情境 1)、部署設定 (適用於情境 2) 或防火牆規則 (適用於情境 3)。
  4. 在情境 1 中，代理程式應回報：🔴 發現事件：名為 NetworkPolicy 的項目正在隔離 checkoutservice Pod。update-checkout-from-frontend
  5. 在情境 2 中，服務專員應回報：🔴 Incident Identified：部署 frontend-canary 設定的服務端點無效，應為 productcatalogservice:3550，而非 productcatalogservices:3550。
  6. 在情境 3 中，代理程式應回報：🔴 已識別事件：虛擬私有雲防火牆規則 frontend-ingress-v2 拒絕連接埠 80、443 和 8080 的輸入流量。

6. 步驟 3：減輕並修正服務中斷問題

我們將使用 CLI 的 Safe Executor 模式修正服務中斷問題。

  1. 請 CLI 助理提議並套用修正內容：
    Propose a fix for the outage and apply it.
  2. Safe Executor 運作方式：
    • 執行指令建議前，SRE 擴充功能會使用 safe-sre-investigator 技能執行安全稽核。
    • 並顯示預計執行的確切指令，以及風險等級 (例如低、中、高)。
    • 如果是情境 1，系統會建議：
      kubectl delete networkpolicy update-checkout-from-frontend
    • 如果是情境 2，系統會建議：
      kubectl delete deployment frontend-canary
    • 情境 3 的建議如下：
      gcloud compute firewall-rules delete frontend-ingress-v2 --quiet
  3. 當 CLI 提示時，請確認執行指令。
  4. 重新整理 Online Boutique 首頁，確認網站已恢復運作且功能正常。
  5. 在殼層中，您可以執行對應的情境檢查指令碼，驗證健康狀態：
    ./breakage1-checkout/check.sh
# or ./breakage2-canary/check.sh
# or ./breakage3-firewall/check.sh

7. 步驟 4：產生事件後檢討報告

記錄事件是 SRE 生命週期中不可或缺的一環，有助於團隊從中學習。我們來使用 postmortem-create 技能自動執行這項操作。

  1. 在 CLI 助理中，要求撰寫事後檢討文件：
    Create a postmortem for the checkout service network policy outage.
  2. 服務專員會收集以下詳細資料：
    • 事件的開始時間 (從 CLI 指令記錄/記錄檔中擷取)。
    • 根本原因 (封鎖的 NetworkPolicy)。
    • 為減輕影響而採取的行動。
  3. 這會在工作區中寫入名為 postmortem.md 的新 Markdown 檔案。
  4. 開啟 postmortem.md 查看詳細資料。你會看到以下部分：
    • 事件摘要
    • 事件時間表
    • 根本原因分析 (RCA)
    • 行動項目 / 預防措施

8. 步驟 5：新增基礎指標圖表

為確保事後檢討的專業性，我們需要事件的影像證據。我們將使用 monitoring-graphs 技能從 Google Cloud Monitoring (GCM) 擷取時間序列資料，並產生 PNG 圖表，顯示錯誤尖峰。

  1. 要求 CLI 輔助程式生成圖表，並將其新增至事後檢討報告：
    Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md.
  2. 引擎蓋下：
    • 代理程式會呼叫 monitoring-graphs Python 指令碼來查詢 Cloud Monitoring。
    • 擷取指標 (例如 kubernetes.io/container/restart_count 或 loadbalancing.googleapis.com/https/request_count)。
    • 並使用 matplotlib 繪製圖表，然後儲存為 incident_metrics.png。
    • 這個指令會插入圖片連結，藉此更新 postmortem.md 檔案：
      ![Incident Metric Graph](incident_metrics.png)
  3. 開啟產生的 incident_metrics.png 檔案，即可查看圖表，瞭解叢集停止運作的確切時間，以及流量恢復正常的確切時間。

9. 步驟 6：清除

為確保 Google Cloud 帳戶不會產生不必要的費用，請清理已部署的基礎架構。

  1. 前往 Terraform 資料夾：
    cd ../../microservices-demo/terraform
  2. 執行 destroy 指令：
    terraform destroy -auto-approve
  3. 確認所有 GCP GKE 資源都已成功刪除。

10. 恭喜！

您已完成「GKE 叢集故障和中斷調查」程式碼研究室！

涵蓋內容：

  • 將 10 層的 Online Boutique 微服務示範部署至 GKE。
  • 模擬三種真實的 SRE 中斷情形 (網路政策拒絕、有錯誤的 Canary 推出、虛擬私有雲防火牆規則拒絕)。
  • 使用 Antigravity CLI 的 SRE 擴充功能，找出並診斷中斷情形。
  • 運用 Safe Executor 模式審查及執行修復指令。
  • 製作專業的 Markdown 事後檢討報告。
  • 查詢 Cloud Monitoring 指標，自動生成並嵌入有根據的事件圖表。

如要進一步瞭解如何擴充 CLI 代理程式，請參閱 SRE 擴充功能 GitHub 頁面。