1. บทนำ
Last Updated: 2026-05-13
ตรวจสอบการหยุดทำงานของ GKE ด้วยส่วนขยาย SRE และสร้างรายงานการวิเคราะห์สาเหตุที่สวยงาม
ยินดีต้อนรับสู่เวิร์กช็อป SRE สำหรับผู้ปฏิบัติงานที่ต้องการทดลองใช้ SRE Harness ใน Google Cloud
Codelab นี้จะแนะนำคุณเกี่ยวกับสิ่งต่อไปนี้
- ติดตั้งคลัสเตอร์ GKE โดยอิงตามmicroservices-demo แบบโอเพนซอร์สที่รู้จักกันดี
- สร้างการหยุดทำงานโดยทำให้เกิดการหยุดทำงานในรูปแบบต่างๆ (บางรูปแบบเห็นได้ชัดเจนกว่า บางรูปแบบก็ซับซ้อนกว่า)
- ติดตั้งและใช้ Antigravity CLI (หรือ Harness ที่คล้ายกัน) + ส่วนขยาย SRE สำหรับส่วนต่อไปนี้
- ตรวจสอบและแก้ไขการหยุดทำงาน
- สร้างรายงานหลังการดำเนินการ
- ใช้ทักษะการสร้างกราฟเพื่อสร้างกราฟที่อิงตามข้อมูลจริง ซึ่งจะช่วยให้ผู้ชมเข้าใจสิ่งที่เกิดขึ้นและเวลาที่เกิดเหตุการณ์
โครงสร้างแบบทีละขั้นตอนของ Codelab มีดังนี้
เป้าหมายของเวิร์กช็อปนี้คือ
- สาธิตความสามารถของส่วนขยาย SRE และแสดงให้เห็นถึงสิ่งที่คุณทำได้ด้วยส่วนขยายนี้ ได้แก่ การตั้งค่า OneMCP, Safe Executor, การตรวจสอบ, การสร้างรายงานหลังเกิดเหตุ, กราฟ และข้อมูลสรุป CSV
- สอนทักษะในการตรวจสอบสถานการณ์ Google Cloud ของคุณเอง
เหตุการณ์สำคัญ 1: การตั้งค่าสภาพแวดล้อมและการจำลองการหยุดทำงาน
เป้าหมายของเหตุการณ์สำคัญนี้คือการตั้งค่าแอปพลิเคชันเดโม Kubernetes ใน GKE Autopilot, ติดตั้ง Antigravity CLI และทริกเกอร์สถานการณ์คลัสเตอร์ GKE เสียหายโดยจำลองเพื่อจำลองเหตุการณ์ที่เกิดขึ้นจริง
เหตุการณ์สำคัญที่ 2: การตรวจสอบและการลดผลกระทบด้วยส่วนขยาย SRE
หลังจากทำลายสภาพแวดล้อมแล้ว คุณจะใช้เครื่องมือ CLI แบบเอเจนต์ที่ติดตั้งส่วนขยาย SRE เพื่อค้นพบโครงสร้างพื้นฐานอย่างเป็นระบบ จัดเรียงปัญหาตามลำดับความสำคัญ ใช้รูปแบบการดำเนินการที่ปลอดภัยสำหรับการแก้ไข และตรวจสอบสถานะคลัสเตอร์
เหตุการณ์สำคัญ 3: การวิเคราะห์หลังการดำเนินการและสร้างกราฟ
เมื่อแก้ไขแล้ว คุณจะสร้างเอกสารสรุปเหตุการณ์ที่มีโครงสร้างและใช้ GCM (Google Cloud Monitoring) API เพื่อดึงข้อมูลเมตริกจริง สร้างแผนภูมิภาพเพื่อบันทึกเวลาและวิธีที่เกิดการหยุดทำงาน
สิ่งที่คุณจะสร้าง
ใน Codelab นี้ คุณจะได้ตรวจสอบและแก้ไขการหยุดทำงานของ GKE โดยใช้ส่วนขยาย SRE คุณจะได้รับสิ่งต่อไปนี้
- จำลองการหยุดทำงานของ GKE โดยใช้การบล็อกนโยบายเครือข่าย การติดตั้งใช้งาน Canary ที่มีข้อบกพร่อง และการอัปเดตกฎไฟร์วอลล์
- จัดลำดับความสำคัญของคลัสเตอร์ที่หยุดทำงานโดยใช้ผู้ช่วย CLI ที่ขับเคลื่อนโดยส่วนขยาย SRE
- ใช้ขั้นตอนการแก้ไขอย่างปลอดภัยโดยใช้รูปแบบ Safe Executor
- สร้างเอกสารสรุปหลังการตรวจสอบที่ครอบคลุม
- สร้างกราฟเมตริกเหตุการณ์โดยใช้การค้นหาอนุกรมเวลาของ Google Cloud Monitoring
สิ่งที่คุณจะได้เรียนรู้
- วิธีตรวจสอบทรัพยากรและนโยบาย Kubernetes ของ GKE โดยใช้ทักษะส่วนขยาย SRE
- วิธีใช้ประโยชน์จากรูปแบบ Safe Executor เพื่อเรียกใช้คำสั่งที่เอเจนต์แนะนำพร้อมการประเมินความเสี่ยงที่เหมาะสม
- วิธีใช้ทักษะ
monitoring-graphsเพื่อสร้างแผนภูมิเมตริกที่อิงตามข้อมูลจริงจาก GCM โดยตรง - วิธีบันทึกผลการสืบค้นเหตุการณ์ในรูปแบบการวิเคราะห์หลังเกิดเหตุแบบมีโครงสร้าง
สิ่งที่คุณต้องมี
- โปรเจ็กต์ Google Cloud ที่เปิดใช้การเรียกเก็บเงิน
- เครื่องมือบรรทัดคำสั่ง:
gcloud,kubectl,terraform - ติดตั้ง Antigravity CLI ในเครื่องหรือใน Cloud Shell
- IDE (เช่น vscode, IntelliJ, RubyMine หรือ Vim)
เหตุใดจึงควรใช้ส่วนขยาย SRE + Agentic CLI
การหยุดทำงานของระบบที่ใช้งานจริงเกิดขึ้นอย่างรวดเร็วและต้องมีการเชื่อมโยงในหลายระบบย่อย (ทรัพยากร Kubernetes, เครือข่าย VPC, เมตริก Cloud Monitoring, สิทธิ์ IAM) ส่วนขยาย SRE ช่วยให้ผู้ช่วย CLI แบบ Agent (เช่น Antigravity CLI) ทำหน้าที่เป็นผู้ช่วยนักบินร่วมแบบอัตโนมัติได้ โดยจะดำเนินการตาม Playbook ที่คอมไพล์ไว้ล่วงหน้า ค้นหากราฟการตรวจสอบ และแนะนำการแก้ไขที่ปลอดภัยในขณะที่ยังคงให้ผู้ปฏิบัติงานที่เป็นมนุษย์อยู่ในวงจร
2. การเริ่มต้นใช้งาน
เลือกตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้ การตั้งค่าสภาพแวดล้อมแบบเรียนรู้ด้วยตนเอง หากต้องการเรียกใช้
Codelab บนเครื่องของคุณเอง หรือเริ่ม Cloud Shell หากต้องการเรียกใช้ Codelab นี้ในระบบคลาวด์ทั้งหมด
การตั้งค่าสภาพแวดล้อมแบบเรียนรู้ด้วยตนเอง
- ลงชื่อเข้าใช้ คอนโซล Google Cloud แล้วสร้างโปรเจ็กต์ใหม่หรือใช้โปรเจ็กต์ที่มีอยู่ซ้ำ หากยังไม่มีบัญชี Gmail หรือ Google Workspace คุณต้องสร้างบัญชี
- ชื่อโปรเจ็กต์คือชื่อที่แสดงสำหรับผู้เข้าร่วมโปรเจ็กต์นี้ ซึ่งเป็นสตริงอักขระที่ Google APIs ไม่ได้ใช้ คุณอัปเดตได้ทุกเมื่อ
- รหัสโปรเจ็กต์จะไม่ซ้ำกันในโปรเจ็กต์ Google Cloud ทั้งหมดและเปลี่ยนแปลงไม่ได้ (เปลี่ยนไม่ได้หลังจากตั้งค่าแล้ว) Cloud Console จะสร้างสตริงที่ไม่ซ้ำกันโดยอัตโนมัติ ซึ่งโดยปกติแล้วคุณไม่จำเป็นต้องสนใจว่าสตริงนั้นคืออะไร ใน Codelab ส่วนใหญ่ คุณจะต้องอ้างอิงรหัสโปรเจ็กต์ (โดยปกติจะระบุเป็น
PROJECT_ID) หากไม่ชอบรหัสที่สร้างขึ้น คุณอาจสร้างรหัสแบบสุ่มอีกรหัสหนึ่งได้ หรือคุณอาจลองใช้ชื่อของคุณเองและดูว่ามีชื่อนั้นหรือไม่ คุณจะเปลี่ยนแปลงรหัสนี้หลังจากขั้นตอนนี้ไม่ได้ และรหัสจะคงอยู่ตลอดระยะเวลาของโปรเจ็กต์ - โปรดทราบว่ายังมีค่าที่ 3 ซึ่งคือหมายเลขโปรเจ็กต์ที่ API บางตัวใช้ ดูข้อมูลเพิ่มเติมเกี่ยวกับค่าทั้ง 3 นี้ได้ในเอกสารประกอบ
- จากนั้นคุณจะต้องเปิดใช้การเรียกเก็บเงินใน Cloud Console เพื่อใช้ทรัพยากร/API ของ Cloud การทำตาม Codelab นี้จะไม่เสียค่าใช้จ่ายมากนัก หรืออาจไม่เสียเลย หากต้องการปิดทรัพยากรเพื่อหลีกเลี่ยงการเรียกเก็บเงินนอกเหนือจากบทแนะนำนี้ คุณสามารถลบทรัพยากรที่สร้างขึ้นหรือลบโปรเจ็กต์ได้ ผู้ใช้ Google Cloud รายใหม่มีสิทธิ์เข้าร่วมโปรแกรมช่วงทดลองใช้ฟรีมูลค่า$300 USD
เริ่มต้น Cloud Shell
แม้ว่าคุณจะใช้งาน Google Cloud จากระยะไกลในแล็ปท็อปได้ แต่ใน Codelab นี้คุณจะใช้ Google Cloud Shell ซึ่งเป็นสภาพแวดล้อมบรรทัดคำสั่งที่ทำงานในระบบคลาวด์
จาก คอนโซล Google Cloud ให้คลิกไอคอน Cloud Shell ในแถบเครื่องมือด้านขวาบน
การจัดสรรและเชื่อมต่อกับสภาพแวดล้อมจะใช้เวลาเพียงไม่กี่นาที เมื่อเสร็จแล้ว คุณควรเห็นข้อความคล้ายกับตัวอย่างต่อไปนี้
เครื่องเสมือนนี้มาพร้อมเครื่องมือพัฒนาซอฟต์แวร์ทั้งหมดที่คุณต้องการ โดยมีไดเรกทอรีหลักแบบถาวรขนาด 5 GB และทำงานบน Google Cloud ซึ่งช่วยเพิ่มประสิทธิภาพเครือข่ายและการตรวจสอบสิทธิ์ได้อย่างมาก คุณสามารถทำงานทั้งหมดใน Codelab นี้ได้ภายในเบราว์เซอร์ คุณไม่จำเป็นต้องติดตั้งอะไร
3. สิ่งที่ต้องดำเนินการก่อน (การติดตั้ง)
สำหรับบทแนะนำนี้ คุณต้องติดตั้งสิ่งต่อไปนี้
1. Python และ uv
python และ uv (เครื่องมือจัดการแพ็กเกจสำหรับ Python) ตรวจสอบว่าคุณได้ติดตั้ง uv แล้ว
$ curl -LsSf https://astral.sh/uv/install.sh | sh
ทำไมต้อง uv แม้ว่าคุณจะใช้ตัวจัดการ Python ใดก็ได้ตามต้องการ แต่การใช้ uv จะช่วยให้มั่นใจได้ว่าการตั้งค่า ENV/PATH สำหรับ Python จะเหมือนกันสำหรับคุณและ Antigravity CLI ดังนั้นประสบการณ์การใช้งาน Shell ของคุณจะเหมือนกับของ Antigravity CLI เป็นส่วนใหญ่ หากคุณใช้ virtualenv เช่น Antigravity CLI จะต้องดำเนินการต่างๆ เช่น "source .env/venv/bin/activate && my-original-command" เพื่อเลียนแบบสภาพแวดล้อมของคุณ
2. Antigravity CLI (agy)
หากต้องการติดตั้ง Antigravity CLI อย่างเป็นทางการ (คำสั่ง agy) ให้เปิดเทอร์มินัลแล้วเรียกใช้โปรแกรมติดตั้ง Bootstrap ดังนี้
สำหรับ macOS และ Linux
$ curl -fsSL https://antigravity.google/cli/install.sh | bash
สำหรับ Windows (PowerShell):
irm https://antigravity.google/cli/install.ps1 | iex
สคริปต์นี้จะตรวจหาระบบปฏิบัติการและสถาปัตยกรรมของคุณแบบไดนามิก ดาวน์โหลด
agy
ไบนารี และกำหนดค่า PATH รีสตาร์ทเทอร์มินัลหรือโหลดการกำหนดค่าเชลล์ซ้ำเพื่อให้การเปลี่ยนแปลงมีผล
การตรวจสอบสิทธิ์
คุณต้องมีคีย์ API ของ Google AI Studio
ส่งออกคีย์ 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
มาโคลนแอปพลิเคชัน 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 ที่ติดตั้งใช้งานแล้วหยุดทำงานเพื่อจำลองเหตุการณ์การผลิตในโลกแห่งความเป็นจริง คุณเลือกได้ 3 สถานการณ์ (หรือลองทั้ง 3 สถานการณ์ตามลำดับ) ดังนี้
สถานการณ์ที่ 1: การบล็อกเครือข่ายบริการชำระเงิน (มาตรฐาน/อัตโนมัติ)
สถานการณ์นี้จำลองการเชื่อมต่อที่ขาดหายไประหว่างฟรอนท์เอนด์และบริการชำระเงินโดยใช้ Kubernetes NetworkPolicy ซึ่งทำหน้าที่เป็น "หลุมดำ" ของการรับส่งข้อมูล
- ไปที่โฟลเดอร์สถานการณ์
cd breakage1-checkout
- ทำให้เกิดการหยุดทำงาน
./break.sh
update-checkout-from-frontendในเนมสเปซdefaultซึ่งปฏิเสธการรับส่งข้อมูลขาเข้าไปยังcheckoutserviceเว้นแต่จะมาจากพ็อดที่มีป้ายกำกับapp: frontend-checkout-test(ซึ่งไม่มีอยู่) - ลองซื้อสินค้าในส่วนหน้าของ Online Boutique หน้าชำระเงินจะค้างหรือแสดงข้อผิดพลาด HTTP 500
สถานการณ์ที่ 2: การเปิดตัว Canary ที่มีข้อบกพร่อง (Autopilot ที่มี Istio)
สถานการณ์นี้จำลองการติดตั้งใช้งานที่ไม่ดีซึ่งมีการเปิดตัวฟรอนท์เอนด์เวอร์ชันที่มีข้อบกพร่องผ่านการติดตั้งใช้งาน Canary ของ Kubernetes
- ไปที่โฟลเดอร์สถานการณ์
cd ../breakage2-canary
- ทำให้เกิดการหยุดทำงาน
./break.sh
frontend-canaryซึ่งมีข้อผิดพลาดในการพิมพ์ในตัวแปรสภาพแวดล้อม โดยPRODUCT_CATALOG_SERVICE_ADDRได้รับการกำหนดค่าเป็นproductcatalogservices:3550แทนที่จะเป็นproductcatalogservice:3550 - โหลดหน้าแรกของฟรอนท์เอนด์ ซึ่งอาจล้มเหลวในบางครั้ง (ขึ้นอยู่กับน้ำหนักการกำหนดเส้นทาง) เนื่องจากบริการคานารีไม่สามารถแก้ไขแคตตาล็อกผลิตภัณฑ์ได้
สถานการณ์ที่ 3: การบล็อกคลัสเตอร์ไฟร์วอลล์ VPC
สถานการณ์นี้จำลองข้อผิดพลาดในการกำหนดค่าไฟร์วอลล์ VPC ที่บล็อกการรับส่งข้อมูลขาเข้าทั้งหมดไปยังคลัสเตอร์ GKE
- ไปที่โฟลเดอร์สถานการณ์
cd ../breakage3-firewall
- ทำให้เกิดการหยุดทำงาน
./break.sh
frontend-ingress-v2ที่มีpriority=1และการดำเนินการDENYซึ่งกำหนดเป้าหมายการรับส่งข้อมูลขาเข้าที่พอร์ต80,443และ8080 - เว็บไซต์ Online Boutique จะเข้าถึงไม่ได้โดยสิ้นเชิง และคำขอจะหมดเวลา
5. ขั้นตอนที่ 2: การตรวจสอบการหยุดทำงานด้วยส่วนขยาย SRE
ตอนนี้แอปพลิเคชันหยุดทำงานแล้ว มาเริ่มการตรวจสอบโดยใช้ผู้ช่วย CLI (Antigravity CLI) กัน
- กลับไปที่โฟลเดอร์สถานการณ์การหยุดทำงานหลัก แล้วเปิดใช้โปรแกรมช่วย CLI
cd .. agy
- ขอให้ผู้ช่วยทำการค้นพบโครงสร้างพื้นฐานและตรวจสอบการวินิจฉัย
Investigate my GKE cluster for outages. Are all services healthy? - สิ่งที่ตัวแทนทำ
- ซึ่งจะเปิดใช้งานทักษะ
investigation-entrypointและgcp-playbooks - โดยจะแสดงรายการพ็อด การทำให้ใช้งานได้ และบริการของ Kubernetes เพื่อค้นหาเป้าหมายที่ล้มเหลว
- โดยจะตรวจสอบนโยบายเครือข่าย (สำหรับสถานการณ์ที่ 1) หรือการกำหนดค่าการติดตั้งใช้งาน (สำหรับสถานการณ์ที่ 2) หรือกฎไฟร์วอลล์ (สำหรับสถานการณ์ที่ 3)
- ซึ่งจะเปิดใช้งานทักษะ
- สำหรับสถานการณ์ที่ 1 เจ้าหน้าที่ควรรายงานว่า 🔴 พบเหตุการณ์:
NetworkPolicyชื่อupdate-checkout-from-frontendกำลังแยกพ็อดcheckoutservice - สำหรับสถานการณ์ที่ 2 เจ้าหน้าที่ควรรายงานว่า 🔴 พบเหตุการณ์: มีการกำหนดค่าการติดตั้งใช้งาน
frontend-canaryด้วยปลายทางบริการที่ไม่ถูกต้องproductcatalogservices:3550แทนที่จะเป็นproductcatalogservice:3550 - สำหรับสถานการณ์ที่ 3 ตัวแทนควรรายงานว่า 🔴 ระบุเหตุการณ์แล้ว: กฎไฟร์วอลล์ VPC
frontend-ingress-v2ปฏิเสธการรับส่งข้อมูลขาเข้าในพอร์ต80,443และ8080
6. ขั้นตอนที่ 3: บรรเทาและแก้ไขการหยุดทำงาน
มาใช้รูปแบบ Safe Executor ของ CLI เพื่อแก้ไขปัญหาการหยุดทำงานกัน
- ขอให้ผู้ช่วย CLI เสนอและใช้การแก้ไข
Propose a fix for the outage and apply it. - 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
- ก่อนที่จะดำเนินการตามคำแนะนำคำสั่ง ส่วนขยาย SRE จะทำการตรวจสอบความปลอดภัยโดยใช้
- ยืนยันการเรียกใช้คำสั่งเมื่อ CLI แจ้ง
- ตรวจสอบว่าเว็บไซต์กลับมาใช้งานได้อีกครั้งและใช้งานได้อย่างสมบูรณ์โดยการรีเฟรชหน้าแรกของ Online Boutique
- ในเชลล์ คุณสามารถเรียกใช้สคริปต์ตรวจสอบสถานการณ์ที่เกี่ยวข้องเพื่อยืนยันสถานะได้โดยทำดังนี้
./breakage1-checkout/check.sh # or ./breakage2-canary/check.sh # or ./breakage3-firewall/check.sh
7. ขั้นตอนที่ 4: สร้างรายงานการวิเคราะห์หลังเกิดเหตุการณ์
ส่วนสำคัญของวงจร SRE คือการบันทึกเหตุการณ์เพื่อให้ทีมได้เรียนรู้จากเหตุการณ์ดังกล่าว มาตั้งค่าให้ทำงานโดยอัตโนมัติโดยใช้ทักษะ postmortem-create กัน
- ในผู้ช่วย CLI ให้ขอเขียนเอกสารสรุปหลังเหตุการณ์
Create a postmortem for the checkout service network policy outage. - ตัวแทนจะรวบรวมรายละเอียดเกี่ยวกับสิ่งต่อไปนี้
- เวลาเริ่มต้นของเหตุการณ์ (ดึงข้อมูลจากประวัติคำสั่ง/บันทึก CLI)
- สาเหตุของปัญหา (NetworkPolicy ที่บล็อก)
- การดำเนินการที่ใช้เพื่อลดความเสี่ยง
- โดยจะเขียนไฟล์ Markdown ใหม่ชื่อ
postmortem.mdในพื้นที่ทำงานของคุณ - เปิด
postmortem.mdเพื่อตรวจสอบรายละเอียด คุณจะเห็นส่วนต่างๆ เช่น- สรุปเหตุการณ์
- ไทม์ไลน์ของเหตุการณ์
- การวิเคราะห์สาเหตุที่แท้จริง (RCA)
- สิ่งที่ต้องทำ / มาตรการป้องกัน
8. ขั้นตอนที่ 5: เพิ่มกราฟเมตริกที่อิงตามข้อมูล
เราต้องการหลักฐานที่เป็นภาพของเหตุการณ์เพื่อทำให้การชันสูตรพลิกศพเป็นไปอย่างมืออาชีพ เราจะใช้monitoring-graphsทักษะเพื่อดึงข้อมูลอนุกรมเวลาจาก Google Cloud Monitoring (GCM) และสร้างแผนภูมิ PNG ที่แสดงการเพิ่มขึ้นของข้อผิดพลาด
- ขอให้โปรแกรมช่วย CLI สร้างกราฟและเพิ่มลงในรายงานหลังเกิดเหตุ
Query GCM for frontend HTTP request error rates over the last 1 hour, generate a line chart, and embed it into postmortem.md. - กลไกภายใน:
- Agent จะเรียกใช้
monitoring-graphsสคริปต์ Python เพื่อค้นหา Cloud Monitoring - โดยจะดึงข้อมูลเมตริก (เช่น
kubernetes.io/container/restart_countหรือloadbalancing.googleapis.com/https/request_count) - โดยจะสร้างแผนภูมิโดยใช้
matplotlibและบันทึกเป็นincident_metrics.png - โดยจะอัปเดต
postmortem.mdไฟล์ด้วยการแทรกลิงก์รูปภาพดังนี้
- Agent จะเรียกใช้
- เปิดไฟล์
incident_metrics.pngที่สร้างขึ้นเพื่อดูแผนภูมิที่แสดงช่วงเวลาที่แน่นอนที่คลัสเตอร์หยุดทำงานและช่วงเวลาที่การเข้าชมกลับสู่ปกติ
9. ขั้นตอนที่ 6: การทำความสะอาดข้อมูล
มาล้างข้อมูลโครงสร้างพื้นฐานที่ติดตั้งใช้งานเพื่อไม่ให้บัญชี Google Cloud ของคุณถูกเรียกเก็บเงินโดยไม่จำเป็นกัน
- ไปที่โฟลเดอร์ Terraform
cd ../../microservices-demo/terraform
- เรียกใช้คำสั่งทำลาย
terraform destroy -auto-approve
- ยืนยันว่าได้ลบทรัพยากร GKE ใน GCP ทั้งหมดเรียบร้อยแล้ว
10. ยินดีด้วย
คุณทำ Codelab การตรวจสอบการหยุดทำงานและการหยุดให้บริการของคลัสเตอร์ GKE เสร็จแล้ว
สิ่งที่คุณได้เรียนรู้
- ทำให้การสาธิตไมโครเซอร์วิส Online Boutique แบบ 10 ระดับใช้งานได้ใน GKE
- จำลองการหยุดทำงานของ SRE ในโลกแห่งความเป็นจริง 3 ครั้ง (การปฏิเสธนโยบายเครือข่าย การเปิดตัว Canary ที่มีข้อบกพร่อง การปฏิเสธกฎไฟร์วอลล์ VPC)
- ใช้ส่วนขยาย SRE สำหรับ Antigravity CLI เพื่อค้นหาและวินิจฉัยการหยุดทำงาน
- ใช้รูปแบบ Safe Executor เพื่อตรวจสอบและเรียกใช้คำสั่งการแก้ไข
- สร้างรายงานหลังการปฏิบัติงาน (Postmortem) แบบมาร์กดาวน์ระดับมืออาชีพ
- เมตริก Cloud Monitoring ที่ค้นหาเพื่อสร้างและฝังกราฟเหตุการณ์ที่อิงตามข้อมูลโดยอัตโนมัติ
ดูรายละเอียดเพิ่มเติมเกี่ยวกับการขยายตัวแทน CLI ได้ที่หน้า GitHub ของส่วนขยาย SRE