SRE Cho Developer: Khi DevOps Chưa Đủ

Karify98 & Amy 🌸·
Cover Image for SRE Cho Developer: Khi DevOps Chưa Đủ
#sre#devops#monitoring#observability

Deploy Xong Rồi... Rồi Sao Nữa?

Developer thường đo success bằng "deploy thành công". Code lên production = xong. Nhưng production có thực sự chạy ổn không? Response time có tăng dần? Error rate có đang leo?

Đó là khoảng trống giữa DevOps và SRE. DevOps nói "deploy nhanh hơn". SRE hỏi "deploy xong có ổn không?".

Site Reliability Engineering — discipline do Google khởi xướng. SRE khác DevOps ở một điểm: SRE đặt mục tiêu đo lường được. Không phải "hệ thống ổn" — mà là "99.9% uptime, error budget còn 0.05%".

DevOps vs SRE — Không Phải Chọn Một

Nhiều người nhầm SRE là "bản nâng cấp" của DevOps. Thực tế, SRE là một cách thực hiện DevOps có cấu trúc hơn.

DevOps là văn hóa — phá vỡ silo giữa dev và ops. SRE là discipline — đặt ra các nguyên tắc cụ thể để duy trì reliability.

Mối quan hệ:

  • DevOps: "Chúng ta cần cải thiện velocity"

  • SRE: "Chúng ta có error budget, được phép deploy nếu vẫn trong budget"

  • DevOps: "Tự động hóa mọi thứ"

  • SRE: "Tự động hóa nhưng phải có rollback plan"

SLI, SLO, SLA — Ba Thuật Ngữ Phải Nắm

Đây là backbone của SRE. Không hiểu ba cái này, mọi thứ khác đều vô nghĩa.

SLI — metrik cụ thể đo performance. Ví dụ: latency của API, error rate, throughput. Đây là dữ liệu thực tế từ hệ thống.

SLO — mục tiêu đặt ra cho SLI. Ví dụ: "99.9% requests hoàn thành dưới 200ms". SLO là cam kết nội bộ.

SLA — cam kết với khách hàng. Nếu vi phạm SLA → penalty, refund. SLA luôn "lỏng" hơn SLO để có buffer.

Ví dụ thực tế:

  • SLI: "API response time trung bình 150ms"
  • SLO: "99.9% requests dưới 300ms"
  • SLA: "99.5% uptime mỗi tháng" (khách hàng được biết)

Developer thường chỉ thấy SLA (trong hợp đồng). SRE bắt đầu từ SLI — đo cái gì, đo ở đâu, threshold nào chấp nhận được.

Error Budget — Error Rate Là Tài Nguyên

Concept độc đáo nhất của SRE: error budget. Nếu SLO là 99.9% uptime, error budget = 0.1% thời gian downtime.

Error budget là "budget" có thể dùng để:

  • Deploy feature mới (risk cao hơn một chút)
  • Refactor code lớn (có thể gây downtime ngắn)
  • Thử nghiệm architecture mới

Khi error budget hết → dừng deploy, ưu tiên stability. Đây là cơ chế giúp dev và ops cùng chịu trách nhiệm, không ai đẩy cho ai.

Công thức đơn giản:

Error Budget = 1 - SLO

Nếu SLO = 99.9% → error budget = 0.1% = ~43 phút downtime mỗi tháng. Hết 43 phút đó → không được deploy nữa cho đến khi budget phục hồi.

On-Call Không Phải Torture

Developer thường ghét on-call. Nhưng SRE biến on-call thành systematic: có runbook, có escalation path, có postmortem không blame.

On-call hiệu quả cần:

  • Runbook — document từng bước xử lý incident cụ thể. Không phải "liên hệ team ops".
  • Escalation path — ai xử lý trước, ai xử lý sau, khi nào gọi manager.
  • Rotation công bằng — mỗi người share đều, không ai bị on-call nhiều hơn.
  • Blameless postmortem — incident xảy ra → phân tích root cause, không blame ai. Ai cũng có thể mắc lỗi, hệ thống mới là vấn đề.

Postmortem template đơn giản:

  • Tóm tắt incident
  • Timeline
  • Root cause
  • Action items (preventive + detective)
  • Follow-up date

Bắt Đầu Từ Đâu?

Không cần chuyển sang SRE role mới bắt đầu. Developer có thể áp dụng tư duy SRE ngay lập tức.

1. Đặt SLI cho service hiện tại

Service có đang measure latency không? Error rate có đang track không? Nếu chưa → thêm monitoring ngay. Prometheus + Grafana là combo phổ biến nhất.

2. Định nghĩa SLO

Bắt đầu với SLO "thoải mái" — 99% hoặc 99.5%. Sau đó thắt chặt dần khi hiểu hệ thống hơn. Đừng đặt SLO 99.99% ngay từ đầu — sẽ không đạt được, nản lòng.

3. Theo dõi error budget hàng tuần

Set alert khi error budget xuống dưới 50%. Set alert blocker khi budget gần hết. Đây là signal rõ ràng nhất để biết hệ thống có ổn không.

4. Viết postmortem sau mỗi incident

Không phải paperwork. Postmortem là cách học từ sai lầm. Viết đơn giản: xảy ra gì, tại sao, làm gì để không tái diễn.

5. Đọc "Site Reliability Engineering" của Google

Sách freely available tại sre.google/sre-book. Không cần đọc hết — bắt đầu với Chapter 1 (Introduction) và Chapter 4 (Service Level Objectives).

Kết Luận

SRE không phải role mới — nó là tư duy mới. Developer không cần bỏ coding để trở thành SRE. Chỉ cần thêm một lớp discipline: measure, set objectives, track error budget, learn from incidents.

Sự khác biệt giữa "team giỏi" và "team xuất sắc" không nằm ở code quality — nằm ở cách team responses khi things go wrong.

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.