Lộ trình
Google CloudAssociateTuần 4: Tối ưu & vận hànhBài 26 / 30

Ngày 26: Case study vận hành

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
gcp-acengày 26
hoàn thành26 / 30 bài
Bối cảnh bài học

Giải case study vận hành GCP end-to-end: chọn compute, theo dõi scale, chẩn đoán incident, bảo vệ identity/cost và chứng minh recovery.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Giải case study vận hành GCP end-to-end: chọn compute, theo dõi scale, chẩn đoán incident, bảo vệ identity/cost và chứng minh recovery.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Phân tích tình huống: chọn dịch vụ compute phù hợp
  • Thực hành xử lý một tình huống scale ứng dụng
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

API tăng latency khi traffic spike, một zone có backend unhealthy, log cost tăng và deploy mới dùng service account quá rộng. Người học phải ưu tiên theo user impact, chọn control đúng, rollback an toàn và lập follow-up thay vì thêm tài nguyên tùy ý.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Architecture decision phải nối workload contract với compute platform, network path, data store, identity, observability và cost.
  • Incident priority theo user impact/safety/data integrity; mitigation tạm thời khác root-cause fix và follow-up.
  • Autoscaling/health check/LB/backend/state/DB dependency cần kiểm tra theo evidence, không chỉ nhìn CPU hoặc instance count.
  • Change rollback cần version/revision/template/state evidence và blast-radius control.

Case operating loop

Dùng loop impact → hypothesis → evidence → mitigation → verify → root cause → follow-up. Bắt đầu từ user/API impact và dependency path; phân biệt symptom (latency/5xx), control (health check/autoscaler/IAM) và resource (VM/service/database).

Ticket rubric

Mỗi ticket phải có severity, evidence, action owner, rollback và success criteria. Ví dụ backend unhealthy cần health/path/firewall evidence; DB connection issue cần pool/metric/log; log cost surge cần filter/retention/cardinality; bad deploy cần revision/traffic.

Bài tập

Hoàn thành 8 ticket timed, viết timeline và architecture decision record. Pass khi actions an toàn, có evidence đo được, recovery được chứng minh và follow-up không còn ownerless.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
gcloud run services describe SERVICE_NAME --region=REGION --project=LAB_PROJECT_ID --format="yaml(status,traffic,spec.template)"
gcloud compute backend-services get-health BACKEND_SERVICE --global --project=LAB_PROJECT_ID
gcloud monitoring policies list --project=LAB_PROJECT_ID --format="table(displayName,enabled)"
gcloud projects get-iam-policy LAB_PROJECT_ID --format="yaml(bindings)"
Hands-on lab

Thực hành theo scenario

  1. Đọc case packet: API Cloud Run/GKE hoặc MIG, Cloud SQL, Cloud Storage, VPC/LB, IAM và monitoring; vẽ dependency/request/data path.
  2. Xử lý 8 operational tickets theo thứ tự: latency spike, zone backend fail, 5xx, DB connection exhaustion, IAM deny, log cost surge, bad deploy và orphan resource.
  3. Mỗi ticket ghi severity, hypothesis, evidence command/signal, immediate mitigation, rollback, owner và success criteria.
  4. Kết thúc bằng architecture decision record, incident timeline, gap list và cleanup inventory; không thao tác production.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Có dependency/flow diagram và requirement assumptions.
  • 8 ticket có priority, evidence và action.
  • Mitigation/rollback không mở public hoặc cấp quyền rộng.
  • Success criteria đo được và có follow-up owner.
  • Case kết thúc bằng recovery, cost và cleanup evidence.
Transfer to exam / production

Bẫy thường gặp và trade-off

ACE scenario cần ưu tiên requirement và evidence. Đừng scale trước khi biết bottleneck; đừng rollback mù khi chưa xác định revision/state và blast radius.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Latency tăng và một backend unhealthy trong khi CPU bình thường. Bước đầu tiên có chất lượng nhất là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2