Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA của một công ty fintech ở TP.HCM. Sản phẩm của bạn tích hợp với một cổng thanh toán bên thứ ba để xử lý giao dịch. Một sáng thứ Hai đầu tháng, cổng thanh toán đó "chết" trong 40 phút. Khách hàng không thanh toán được, bộ phận chăm sóc khách hàng ngập trong cuộc gọi, sếp gọi bạn lên hỏi: "Hợp đồng với họ cam kết uptime bao nhiêu? Lần này mình được bồi thường không? Mình có quyền chuyển nhà cung cấp không?". Nếu bạn ấp úng không trả lời được, đó chính là lúc bạn nhận ra mình đã bỏ qua một thứ tưởng nhỏ mà cực kỳ quan trọng: SLA — Service-level Agreement.
SLA không phải là chuyện kỹ thuật thuần túy của dev hay DevOps. Nó nằm đúng giao điểm giữa kinh doanh, pháp lý và kỹ thuật — và đó chính là sân chơi của BA. Khi bạn tích hợp một API bên ngoài (payment, SMS, SSO, bản đồ, AI...), SLA quyết định bạn cam kết được gì với khách hàng của mình. Khi công ty bạn cung cấp API cho đối tác B2B, SLA là một phần của hợp đồng có giá trị pháp lý và ràng buộc tiền bạc.
Nắm vững SLA giúp bạn: đọc hiểu hợp đồng nhà cung cấp, đặt câu hỏi đúng khi đánh giá vendor, viết yêu cầu phi chức năng (non-functional requirements) rõ ràng, và bảo vệ doanh nghiệp khỏi những rủi ro vận hành tốn kém. Bài này sẽ giúp bạn làm chủ chủ đề đó.
Khái niệm cốt lõi
SLA là gì?
SLA (Service-level Agreement) là một cam kết chính thức — thường nằm trong hợp đồng — về cách một dịch vụ (ở đây là API) sẽ hoạt động. Nó trả lời câu hỏi: "Dịch vụ này cam kết tốt đến mức nào, và nếu không đạt thì sao?".
SLA thường xuất hiện trong hai bối cảnh:
- API ra bên ngoài (external/B2B): công ty bạn bán hoặc cung cấp API cho đối tác, và cam kết mức dịch vụ với họ. Ví dụ: VNPAY cam kết SLA với các merchant tích hợp cổng thanh toán.
- API nội bộ (internal): giữa các team trong cùng công ty cũng có thể có SLA (thường gọi là OLA — Operational Level Agreement) để team A biết team B đảm bảo dịch vụ của họ ổn định đến mức nào.
Phân biệt SLA, SLO và SLI
Đây là ba thuật ngữ rất dễ nhầm, BA bắt buộc phải phân biệt được:
- SLI (Service-level Indicator) — chỉ số đo lường thực tế. Ví dụ: "tỷ lệ request thành công trong tháng vừa rồi là 99,93%". Đây là con số bạn đo được từ hệ thống.
- SLO (Service-level Objective) — mục tiêu nội bộ. Ví dụ: "chúng tôi đặt mục tiêu 99,95% request thành công". SLO thường nghiêm ngặt hơn SLA một chút, là vạch đích team kỹ thuật tự đặt ra.
- SLA (Service-level Agreement) — cam kết với khách hàng kèm chế tài. Ví dụ: "chúng tôi cam kết tối thiểu 99,9%; nếu thấp hơn, khách hàng được giảm 10% phí tháng đó".
Các chỉ số (metrics) phổ biến trong SLA
1. Availability (Tính sẵn sàng / Uptime)
Đây là chỉ số nổi tiếng nhất, thường biểu diễn bằng "số chín". Nó đo phần trăm thời gian dịch vụ hoạt động bình thường. Điều quan trọng BA hay bỏ sót: mỗi "số chín" thêm vào là một mức độ khắt khe gấp ~10 lần về downtime cho phép:
- 99% ("hai số chín"): cho phép down tới ~7 giờ 18 phút/tháng.
- 99,9% ("ba số chín"): cho phép down ~43 phút 49 giây/tháng.
- 99,95%: cho phép down ~21 phút 54 giây/tháng.
- 99,99% ("bốn số chín"): cho phép down ~4 phút 23 giây/tháng.
- 99,999% ("năm số chín"): cho phép down ~26 giây/tháng.
2. Latency / Response time (Độ trễ)
Thời gian API phản hồi. Lưu ý: SLA tốt không bao giờ dùng số trung bình (average), vì trung bình che giấu các trường hợp tệ. Thay vào đó dùng percentile:
- p50 (median): 50% request nhanh hơn ngưỡng này.
- p95: 95% request nhanh hơn ngưỡng này.
- p99: 99% request nhanh hơn ngưỡng này.
3. Error rate (Tỷ lệ lỗi)
Tỷ lệ request bị lỗi, thường tính theo lỗi phía server (status code 5xx). Ví dụ: "tỷ lệ lỗi 5xx dưới 0,1%". Lưu ý phân biệt: lỗi 4xx (do client gửi sai) thường không tính vào SLA của nhà cung cấp, vì đó là lỗi của người gọi.
4. Throughput / Rate limit
Số lượng request hệ thống cam kết phục vụ trong một đơn vị thời gian. Ví dụ: "đảm bảo xử lý tối thiểu 1.000 request/giây". Vượt quá ngưỡng này, nhà cung cấp có quyền từ chối (liên quan đến rate limiting đã học ở bài trước).
5. Support response time (Thời gian phản hồi hỗ trợ)
Không phải về API chạy, mà về con người xử lý sự cố. Thường gắn với mức độ nghiêm trọng:
- Sự cố nghiêm trọng (P1, hệ thống ngừng hoàn toàn): phản hồi trong 15 phút.
- Sự cố trung bình (P2): phản hồi trong 2 giờ.
- Sự cố nhẹ (P3): phản hồi trong 1 ngày làm việc.
Những thành phần khác của một SLA hoàn chỉnh
Một SLA chuyên nghiệp không chỉ có con số. BA cần kiểm tra các phần sau:
- Measurement window (cửa sổ đo lường): tính uptime theo tháng hay theo quý? Tính trên tất cả endpoint hay chỉ endpoint chính?
- Exclusions (loại trừ): phần này rất quan trọng và hay bị bỏ qua. Nhà cung cấp thường loại trừ "scheduled maintenance" (bảo trì có thông báo trước), sự cố do bên thứ ba, hoặc force majeure (thiên tai, mất điện diện rộng). Nếu phần loại trừ quá rộng, SLA gần như vô nghĩa.
- Service credits (tín dụng dịch vụ): chế tài khi vi phạm — thường là hoàn/giảm phí, chứ ít khi là bồi thường tiền mặt cho thiệt hại kinh doanh.
- Reporting & monitoring: ai đo, đo bằng công cụ gì, báo cáo ra sao, khách hàng có được xem dashboard không.
- Quy trình claim (yêu cầu bồi thường): thường khách hàng phải chủ động gửi yêu cầu trong một khoảng thời gian (ví dụ 30 ngày), nếu không sẽ mất quyền.
Tình huống thực tế
Tình huống 1: Cổng thanh toán và bài học về "số chín"
Một sàn thương mại điện tử giả định tên ShopViet ký hợp đồng với một cổng thanh toán cam kết SLA uptime 99,9%/tháng, service credit là hoàn 10% phí giao dịch của tháng nếu vi phạm.
Tháng 11, đúng đợt sale 11/11, cổng thanh toán down tổng cộng 55 phút. Vì 99,9% chỉ cho phép down ~44 phút/tháng, nhà cung cấp đã vi phạm SLA. ShopViet đòi service credit và nhận lại 10% phí tháng đó — khoảng 30 triệu đồng.
Nhưng đây mới là bài học đau: trong 55 phút đó rơi đúng giờ cao điểm, ShopViet ước tính mất hơn 2 tỷ đồng doanh thu vì khách bỏ giỏ hàng. Service credit 30 triệu chẳng thấm vào đâu.
Bài học rút ra: SLA credit hầu như không bao giờ đền bù được thiệt hại kinh doanh thực tế. BA cần hiểu rằng SLA là công cụ quản trị rủi ro, không phải bảo hiểm thiệt hại. Với những thời điểm trọng yếu (mùa sale), giải pháp đúng không phải là đòi bồi thường nhiều hơn, mà là thiết kế fallback — tích hợp cổng thanh toán dự phòng thứ hai để tự động chuyển hướng khi cổng chính lỗi. BA chính là người phải nêu yêu cầu này.
Tình huống 2: Khi loại trừ (exclusion) nuốt trọn cam kết
Một startup logistics ở Hà Nội tích hợp API định vị bản đồ từ nhà cung cấp B. Hợp đồng ghi to đẹp: "cam kết uptime 99,95%". Đội kinh doanh rất hài lòng và ký.
Ba tháng sau, dịch vụ chập chờn liên tục vào ban đêm. Khi BA mở lại hợp đồng đọc kỹ phần exclusions, mới phát hiện một dòng: "scheduled maintenance được thông báo trước 24 giờ không tính vào downtime, và nhà cung cấp có quyền bảo trì tối đa 8 giờ/tuần". Tức là về lý thuyết họ có thể "tắt" dịch vụ 8 tiếng mỗi tuần mà vẫn không vi phạm 99,95%.
Bài học rút ra: Con số uptime vô nghĩa nếu không đọc kèm phần loại trừ và cửa sổ đo lường. Lần sau, trong checklist đánh giá vendor, BA này luôn thêm câu hỏi: "Maintenance window tối đa bao nhiêu giờ, vào khung giờ nào, và có tính vào uptime không?". Một vendor tốt sẽ cam kết bảo trì vào khung giờ thấp điểm và giới hạn rõ ràng.
Tình huống 3: Khi công ty bạn là người đưa ra SLA
Một công ty SaaS Việt Nam tên FinaCloud cung cấp API kế toán cho các đối tác B2B. Khách hàng lớn yêu cầu cam kết SLA 99,99% uptime và p99 latency dưới 200ms.
BA của FinaCloud ngồi cùng team kỹ thuật và phát hiện vấn đề: hạ tầng hiện tại chỉ ổn định ở mức ~99,9%, và để lên 99,99% (giảm downtime cho phép từ 44 phút xuống chỉ còn ~4 phút/tháng) cần đầu tư multi-region, auto-failover, đội trực 24/7 — chi phí tăng vài tỷ đồng/năm. Trong khi đó hợp đồng này chỉ trị giá vài trăm triệu.
BA đã làm đúng vai trò của mình: thay vì hứa liều, anh đề xuất một SLA theo tầng (tiered). Gói tiêu chuẩn cam kết 99,9%; gói Premium (giá cao hơn) mới cam kết 99,99% kèm hỗ trợ ưu tiên. Khách hàng chọn gói phù hợp ngân sách.
Bài học rút ra: SLA không phải càng cao càng tốt. Mỗi mức cam kết đều có cái giá của nó. BA giỏi là người cân bằng được kỳ vọng khách hàng với năng lực thực tế và chi phí, và biết biến mức dịch vụ thành đòn bẩy thương mại (tiered pricing).
Hướng dẫn từng bước
Khi bạn phải đánh giá hoặc soạn một SLA cho API, hãy đi theo trình tự sau:
Bước 1 — Xác định bối cảnh. Bạn đang ở phía nào? Là người tiêu thụ API (đánh giá SLA của vendor) hay người cung cấp API (soạn SLA cho khách hàng)? Hai vai trò này đặt câu hỏi rất khác nhau.
Bước 2 — Liệt kê các metric cần cam kết. Tối thiểu nên có: availability, latency (theo percentile, không phải average), error rate. Tùy dịch vụ mà thêm throughput hoặc support response time.
Bước 3 — Đặt ngưỡng dựa trên nhu cầu thực tế, không phải theo "cho oai". Hỏi: nếu dịch vụ này down 1 giờ thì hậu quả kinh doanh thế nào? Câu trả lời quyết định bạn cần "ba số chín" hay "bốn số chín". Đừng yêu cầu 99,999% cho một tính năng phụ.
Bước 4 — Định nghĩa rõ cách đo. Cửa sổ đo (tháng/quý), đo trên endpoint nào, công cụ đo nào, ai chịu trách nhiệm báo cáo.
Bước 5 — Soi kỹ phần exclusions. Đây là nơi cam kết bị "rút ruột". Đảm bảo maintenance window có giới hạn và vào giờ thấp điểm.
Bước 6 — Xác định chế tài (service credit). Mức credit là bao nhiêu, áp dụng thế nào, quy trình claim ra sao, thời hạn claim.
Bước 7 — Thiết kế phương án dự phòng cho phía mình. Dù SLA tốt đến đâu, hãy luôn hỏi: "Nếu dịch vụ này chết, hệ thống của ta xử lý ra sao?". Đây là phần BA hay quên nhất nhưng lại cứu doanh nghiệp nhiều nhất.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm uptime cao với rủi ro thấp. Nhiều BA thấy "99,9%" là yên tâm ký. Hãy luôn quy đổi ra thời gian down thực tế (43 phút/tháng) và tự hỏi: 43 phút đó nếu rơi đúng giờ vàng thì sao?
Lỗi 2: Dùng average thay vì percentile cho latency. Trung bình 100ms nghe đẹp, nhưng nếu p99 là 5 giây thì cứ 100 khách có 1 người chờ tắc nghẽn. Luôn yêu cầu cam kết theo p95/p99.
Lỗi 3: Bỏ qua phần exclusions. Như tình huống 2, đây là cái bẫy phổ biến nhất. Đọc hợp đồng phải đọc cả phần "in nhỏ".
Lỗi 4: Tưởng service credit là tiền bồi thường thiệt hại. Credit thường chỉ là hoàn vài phần trăm phí, không liên quan đến doanh thu bạn mất. Đừng coi SLA là tấm khiên tài chính.
Lỗi 5: Cam kết SLA vượt năng lực hạ tầng. Nếu bạn ở phía cung cấp, hứa 99,99% khi hệ thống chỉ chạy được 99,9% là tự đặt mìn dưới chân.
Mẹo 1: Luôn đặt SLO nội bộ cao hơn SLA hợp đồng. Vùng đệm này giúp bạn phát hiện sớm khi sắp vi phạm.
Mẹo 2: Yêu cầu vendor cung cấp dashboard hoặc status page công khai. Minh bạch về số liệu là dấu hiệu của nhà cung cấp đáng tin (ví dụ kiểu status.stripe.com).
Mẹo 3: Đưa SLA vào ngay từ giai đoạn yêu cầu phi chức năng (non-functional requirements), đừng để đến lúc ký hợp đồng mới bàn.
Bài tập thực hành
- Quy đổi số chín: Một API cam kết uptime 99,5%/tháng (tháng 30 ngày). Tính xem mỗi tháng dịch vụ được phép down tối đa bao nhiêu phút? (Gợi ý: 0,5% của tổng số phút trong tháng.)
- Phân biệt khái niệm: Cho ba phát biểu sau, hãy gán nhãn SLI / SLO / SLA cho từng cái:
- Soi exclusions: Bạn nhận được hợp đồng API từ một vendor SMS, cam kết uptime 99,9% nhưng phần loại trừ ghi: "không bao gồm downtime do nhà mạng viễn thông gây ra". Hãy viết 3 câu hỏi bạn sẽ gửi lại cho vendor để làm rõ rủi ro.
- Tình huống thiết kế: Công ty bạn cung cấp API gửi OTP cho ngân hàng. Khách hàng yêu cầu p99 latency dưới 1 giây và uptime 99,99%. Hãy liệt kê 4 câu hỏi bạn cần đặt cho team kỹ thuật trước khi đồng ý cam kết, và đề xuất một phương án SLA theo tầng.
- Phản biện: Một đồng nghiệp nói: "SLA 99,99% thì chắc chắn an toàn, mình cứ ký đi". Hãy viết một đoạn ngắn phản biện, chỉ ra ít nhất 2 yếu tố ngoài con số uptime mà anh ấy đang bỏ qua.
Tóm tắt
- SLA (Service-level Agreement) là cam kết có chế tài về cách một API hoạt động, thường gắn với hợp đồng B2B hoặc API external. Nó nằm ở giao điểm kinh doanh — pháp lý — kỹ thuật, đúng vùng trách nhiệm của BA.
- Phân biệt ba khái niệm: SLI (số đo thực tế) — SLO (mục tiêu nội bộ) — SLA (lời hứa với khách kèm chế tài). Luôn đặt SLO cao hơn SLA.
- Các metric cốt lõi: availability (số chín — nhớ quy đổi ra phút down thực tế), latency (dùng percentile p95/p99, không dùng average), error rate, throughput, support response time.
- Một SLA hoàn chỉnh phải có: cửa sổ đo lường, exclusions (đọc thật kỹ!), service credit, cơ chế báo cáo và quy trình claim.
- Ba bài học vàng từ thực tế: service credit không đền bù được thiệt hại kinh doanh nên luôn thiết kế fallback; con số uptime vô nghĩa nếu phần loại trừ quá rộng; và SLA không phải càng cao càng tốt — mỗi mức cam kết đều có cái giá của nó.