SLA là gì? Service Level Agreement trong production

SLA (Service Level Agreement) là một cam kết chính thức giữa nhà cung cấp và khách hàng về mức service level tối thiểu, cách đo, phạm vi áp dụng, các trường hợp exclude, và hậu quả khi vi phạm.

Trong DevOps và SRE, SLA là ranh giới giữa vận hành kỹ thuật và cam kết kinh doanh, vì SLA thường gắn với service credits, penalty hoặc điều khoản hợp đồng.

Ví dụ: Một SaaS cam kết SLA availability 99.9% theo tháng cho API chính. Nếu availability trong tháng thấp hơn 99.9% sau khi áp dụng exclude, khách hàng được service credits theo bảng trong SLA.

SLA phản ánh lời hứa với khách hàng, nên cách định nghĩa và cách đo phải rõ ràng và có thể audit.

SLA cho biết điều gì?

SLA giúp trả lời nhanh các câu hỏi cơ bản:

Khách hàng được cam kết mức service level nào và trong phạm vi nào?
Service level được đo bằng metric nào và đo ở measurement point nào?
Vi phạm SLA dẫn tới service credits hoặc penalty như thế nào?

Tuy nhiên, cần lưu ý: SLA không phải công cụ vận hành hằng ngày. Team không nên dùng SLA làm mục tiêu nội bộ duy nhất, vì SLA thường thấp hơn mức bạn muốn đạt để user có trải nghiệm tốt.

SLA khác SLO và SLI ra sao?

SLA thường được hiểu cùng các khái niệm sau:

SLI: chỉ số đo service level, ví dụ availability, Latency, Error rate.
SLO: mục tiêu nội bộ cho SLI trong một window, dùng để vận hành và cải thiện reliability.
SLA: cam kết với khách hàng, có điều khoản và hậu quả khi vi phạm.

Gợi ý thực tế: nhiều team đặt SLO cao hơn SLA để có buffer. Ví dụ SLA 99.9% nhưng SLO nội bộ 99.95% hoặc cao hơn, tuỳ năng lực vận hành.

Cách hiểu SLA trong production

Một số nguyên tắc cơ bản khi xây SLA:

SLA phải định nghĩa rõ scope, ví dụ service nào, endpoint nào, region nào, plan nào.
SLA phải định nghĩa rõ cách đo, ví dụ uptime theo API Gateway hay theo service, tính theo minute hoặc theo request.
SLA phải định nghĩa rõ exclude, ví dụ planned maintenance, force majeure, lỗi do client misconfiguration, hoặc dependency do khách hàng quản lý.
SLA phải định nghĩa rõ cách áp dụng credits, ví dụ theo bậc availability và trần credits.

Ví dụ:

SLA theo availability nhưng không nói rõ exclude planned maintenance sẽ gây tranh cãi khi maintenance xảy ra.
SLA theo request success rate nhưng không định nghĩa 4xx hợp lệ hay không sẽ dễ bị hiểu sai.

SLA thường được đo ở đâu?

Tuỳ metric, SLA thường được đo ở các điểm sau:

Load balancer / Ingress / API Gateway: phù hợp cho SLA gắn với user facing behavior.
Synthetic monitoring: phù hợp khi bạn muốn đo từ góc nhìn bên ngoài, nhưng phải định nghĩa location và tần suất.
Service level telemetry: phù hợp cho kiểm soát nội bộ, nhưng có thể khác với trải nghiệm thực tế của khách hàng.

Trong thực tế, SLA nên ưu tiên measurement point dễ audit và phù hợp với trải nghiệm khách hàng, đồng thời ghi rõ trong SLA để tránh tranh luận.

Những yếu tố có thể làm SLA trở thành rủi ro

Một số nguyên nhân khiến SLA trở thành rủi ro vận hành và pháp lý:

SLA target quá cao so với năng lực reliability hiện tại.
SLA scope quá rộng, gộp cả feature chưa ổn định hoặc dependency khó kiểm soát.
SLA thiếu exclude hoặc exclude viết mơ hồ.
SLA credits không có trần, dẫn đến penalty không kiểm soát khi có incident lớn.
SLA không khớp với SLO, khiến team không có cơ chế vận hành để tránh vi phạm.

Vì vậy, SLA cần được xây dựa trên dữ liệu lịch sử, có buffer bằng SLO, và có policy rõ về maintenance và incident.

SLA được dùng để làm gì trong DevOps?

Ở mức cơ bản, SLA thường được dùng cho:

Làm cam kết với khách hàng và tạo niềm tin trong B2B.
Tạo khung để xử lý vi phạm, service credits và communication.
Là đầu vào cho việc đặt SLO nội bộ cao hơn để giảm rủi ro vi phạm SLA.
Kết nối với postmortem để giảm recurring incident và giảm downtime.

Kết luận

SLA là cam kết chính thức với khách hàng về service level, cách đo, phạm vi và hậu quả khi vi phạm.

Để SLA không trở thành rủi ro, bạn cần định nghĩa rõ scope, measurement point, exclude và credits, đồng thời vận hành bằng SLO nội bộ cao hơn để có buffer. Đây là cách thực tế để cân bằng giữa reliability và cam kết kinh doanh.