My Awesome Project

Appearance

Chapter 42: SRE Practices trên Google Cloud Platform ​

Tại sao SRE quan trọng ở scale production ​

Khi một ứng dụng phục vụ hàng triệu người dùng hoặc có tính chất mission-critical, việc duy trì độ tin cậy không còn là "tốt để có" mà trở thành yêu cầu kinh doanh cứng nhắc. Tuy nhiên, độ tin cậy không phải là 100% — đó là kinh tế học vô lý. Thay vào đó, SRE (Site Reliability Engineering) cung cấp framework để:

  1. Định lượng độ tin cậy — qua SLI, SLO, error budgets
  2. Quản lý risk deployment — thông qua error budget policies
  3. Phản ứng nhanh khi sự cố xảy ra — qua incident response practices
  4. Học từ thất bại — bằng blameless postmortems
  5. Chủ động kiểm tra độ mạnh mẽ — qua chaos engineering

Đây không phải về việc viết perfect code hay có perfect uptime — đó là không thể. Đây là về việc hiểu rõ rủi ro, quản lý trade-offs, và xây dựng hệ thống có thể phục hồi.

Sơ lược nội dung chapter ​

1. SLI, SLO, Error Budget — Mental Model chính xác ​

Chi tiết →

SLO không phải là "mục tiêu 99.99%". Nó là một lựa chọn kinh tế học: "Người dùng này sẵn lòng chấp nhận bao nhiêu downtime?" từ đó suy ra error budget — thời lượng cho phép mà hệ thống có thể không tuân thủ SLO.

Bạn sẽ hiểu:

  • Cách chọn SLI metric (latency, availability, error rate) phù hợp với user experience thực tế
  • Cách tính error budget và sử dụng nó để quyết định có deploy hay không
  • Vì sao SLO quá cao là lãng phí engineering effort, quá thấp là nguy hiểm

2. Error Budget Policy — Ngưng deployment khi ngân sách hết ​

Chi tiết →

Error budget không chỉ là con số trong dashboard. Nó phải được liên kết với quyết định deployment qua một policy rõ ràng:

  • Nếu error budget còn lớn → deploy bình thường
  • Nếu error budget hạn → phần bất được deploy features không quan trọng
  • Nếu error budget vừa vừa hoặc âm → pause non-critical deployments

Bạn sẽ hiểu:

  • Cách định nghĩa error budget policy với team
  • Cách thiết lập alerts khi error budget sắp hết
  • Cách balance giữa reliability vs velocity

3. Incident Response — Từ Detection đến Recovery ​

Chi tiết →

Khi sự cố xảy ra, bạn cần:

  • Clear escalation levels (L1, L2, L3)
  • Defined roles (Incident Commander, SME, Communications lead)
  • Machine-readable runbooks mà có thể thực thi dưới áp lực
  • Communication templates để update stakeholders

Bạn sẽ hiểu:

  • Cách tổ chức incident response team
  • Cách viết runbooks không phải là tài liệu dài dòng mà là executable steps
  • Cách quản lý thông tin liên lạc trong sự cố

4. Postmortems — Học từ failure mà không blame người ​

Chi tiết →

Blameless postmortem không phải là "không có người đó chịu trách nhiệm", mà là "tập trung vào hệ thống factors mà dẫn đến sự cố, không phải lỗi của cá nhân".

Bạn sẽ hiểu:

  • Root cause analysis techniques (5 Whys, fishbone diagram)
  • Cách phân biệt giữa immediate cause vs contributing factors
  • Cách chuyển bài học thành action items cụ thể
  • Cách xây dựng blameless culture trên team

5. Resilience Patterns — Graceful Degradation, Canaries, Circuit Breakers ​

Chi tiết →

Khi một dependency fails hoặc system overload, bạn không thể fix ngay lập tức. Vì thế bạn cần:

  • Graceful degradation — cung cấp reduced functionality thay vì total failure
  • Canary deployments — release feature cho small subset trước khi scale
  • Circuit breaker pattern — ngừng gửi requests đến failing service để cho nó recovery
  • Feature flags — disable features mà gây issue mà không cần deploy

Bạn sẽ hiểu:

  • Vì sao graceful degradation tốt hơn circuit breaking (availability vs fail-safe)
  • Cách sử dụng Istio virtualservices để implement canaries trên GKE
  • Cách design feature flags để không dẫn đến technical debt

6. Timeout & Retry Management — Ngăn chặn cascading failures ​

Chi tiết →

Một request slow không phải chỉ làm user chờ lâu. Nó có thể gây ra:

  • Thread pool exhaustion
  • Queue buildup
  • Cascading failures qua nhiều services

Bạn sẽ hiểu:

  • Cách thiết lập timeout hierarchies (client timeout < RPC timeout < service timeout)
  • Cách tính retry budgets để tránh exponential load surge
  • Cách implement exponential backoff + jitter
  • Vì sao constant timeout cho tất cả requests là sai

7. Load Shedding & Request Prioritization — Serve critical traffic khi overload ​

Chi tiết →

Khi system đang ở capacity limit, bạn không thể serve tất cả requests. Lựa chọn:

  • Serve tất cả customers với degraded experience (graceful degradation)
  • Serve critical customers fully, shed non-critical requests (load shedding + prioritization)

Bạn sẽ hiểu:

  • Cách implement server-side load shedding (reject requests khi queue quá dài)
  • Cách sử dụng request priority để protect critical paths
  • Trade-off giữa fairness vs availability

8. Failure Injection & Chaos Engineering — Chủ động kiểm tra độ mạnh mẽ ​

Chi tiết →

Bạn không thể fix bug nếu bạn không biết nó tồn tại. Chaos engineering là việc chủ động inject failures vào production để:

  • Phát hiện weak points trước khi customers phát hiện
  • Kiểm tra disaster recovery procedures thực sự hoạt động
  • Build confidence vào resilience architecture

Bạn sẽ hiểu:

  • Cách sử dụng Istio fault injection để inject latency/abort vào requests
  • Cách sử dụng Chaos Mesh trên GKE để crash pods, delay networks
  • Cách thiết kế chaos experiments phù hợp với application
  • Cách scale chaos từ single-service testing → cross-region DR testing

Tại sao chapter này được tổ chức như vậy ​

Thứ tự các topics không phải ngẫu nhiên:

  1. SLO → Error Budget — define what reliability means
  2. Policy & Incident Response — enforce discipline và respond to failures
  3. Postmortems — learn from failures
  4. Resilience Patterns — prevent failures beforehand
  5. Timeouts & Retries — prevent failure cascade
  6. Load Shedding — graceful degradation under overload
  7. Chaos Engineering — proactive resilience testing

Từ "what", "when", "how" đến "test it works".

Prerequisite knowledge ​

Chapter này giả định bạn đã hiểu:

  • Chapter 39 (Cloud Monitoring) — metrics, alerting, time-series data
  • Chapter 40 (Cloud Logging) — logs, structured logging, log analysis
  • Chapter 35 (Pub/Sub) — delivery semantics, at-least-once, idempotency
  • Chapter 5–7 (GKE networking & scheduling) — service communication, pod lifecycle

Nếu cần review phần đó, hãy quay lại.

Tiếp cận chapter này ​

Mỗi section được viết độc lập, nhưng các section vẫn có dependencies conceptual. Nếu muốn skip, hãy skip toàn bộ "resilience patterns" chứ không phải skip circuit breaker trong mid-chapter. Best practice: đọc theo thứ tự từ đầu đến cuối.

Mục lục Chapter ​

Bắt đầu từ SLI, SLO, Error Budget.