SLA là gì và tại sao chủ doanh nghiệp cần hiểu trước khi ký hợp đồng bảo trì IT? SLA (Service Level Agreement) là “bản cam kết” giữa bạn và nhà cung cấp dịch vụ IT — nhưng nếu không đọc kỹ, bạn có thể đang trả tiền cho một cam kết rỗng. Bài viết này giải thích SLA bằng ngôn ngữ đơn giản nhất, giúp bạn đọc hiểu và đàm phán hợp đồng bảo trì IT một cách thông minh.
SLA là gì?
Định nghĩa đơn giản
SLA (Service Level Agreement — Thỏa thuận mức độ dịch vụ) là một phần trong hợp đồng, quy định cụ thể và đo lường được:
- Nhà cung cấp cam kết gì (uptime, response time, support)
- Đo lường bằng gì (metrics, KPIs)
- Hậu quả nếu vi phạm (phạt, credit, bồi thường)
Ví dụ đời thường: SLA giống như cam kết giao hàng của Shopee — “Giao trong 2 ngày, nếu trễ hoàn tiền ship.” Rõ ràng, đo được, có phạt.
SLA khác gì hợp đồng thông thường?
| Hợp đồng thông thường | SLA |
|---|---|
| ”Bên B cung cấp dịch vụ bảo trì server" | "Bên B đảm bảo uptime 99.9%, response time <4 giờ cho P1 incident” |
| Mơ hồ, không đo được | Cụ thể, có metrics |
| Khó kiện khi vi phạm | Có penalty clause rõ ràng |
| ”Nỗ lực tốt nhất" | "Cam kết đạt con số cụ thể” |
Các chỉ số SLA quan trọng cần hiểu
1. Uptime / Availability (Thời gian hoạt động)
Định nghĩa: % thời gian hệ thống hoạt động bình thường trong 1 tháng/năm.
| SLA Uptime | Downtime/tháng | Downtime/năm | Level |
|---|---|---|---|
| 99% | 7.3 giờ | 3.65 ngày | Cơ bản |
| 99.5% | 3.65 giờ | 1.83 ngày | Trung bình |
| 99.9% | 43.8 phút | 8.77 giờ | Tốt |
| 99.95% | 21.9 phút | 4.38 giờ | Rất tốt |
| 99.99% | 4.38 phút | 52.6 phút | Premium |
Lưu ý quan trọng: Sự khác biệt giữa 99% và 99.9% nghe nhỏ nhưng thực tế rất lớn: 7.3 giờ vs 43.8 phút downtime/tháng.
Câu hỏi cần hỏi vendor:
- Uptime tính 24/7 hay chỉ giờ hành chính?
- Planned maintenance (bảo trì định kỳ) có tính vào downtime không?
- Uptime đo tại đâu? (Server, application, hay end-user experience?)
2. Response Time (Thời gian phản hồi)
Định nghĩa: Thời gian từ khi bạn báo sự cố đến khi nhà cung cấp bắt đầu xử lý (không phải giải quyết xong).
| Severity | Mô tả | Response Time phổ biến | Ví dụ |
|---|---|---|---|
| P1 — Critical | Hệ thống ngừng hoạt động | 15-60 phút | Server crash, website down |
| P2 — High | Feature chính bị lỗi | 2-4 giờ | Thanh toán không hoạt động |
| P3 — Medium | Feature phụ bị lỗi | 8-24 giờ | Report xuất sai format |
| P4 — Low | Cosmetic, request nhỏ | 1-3 ngày | Đổi logo, sửa text |
Phân biệt Response Time vs Resolution Time:
- Response Time: “Chúng tôi đã nhận ticket, đang xử lý” (bắt đầu)
- Resolution Time: “Sự cố đã được giải quyết” (kết thúc)
Cẩn thận: Nhiều vendor chỉ cam kết Response Time (phản hồi nhanh) nhưng không cam kết Resolution Time (giải quyết nhanh). Yêu cầu cả hai trong SLA.
3. Support Hours (Giờ hỗ trợ)
| Level | Giờ hỗ trợ | Chi phí | Phù hợp |
|---|---|---|---|
| Business hours | 8:00-17:00 T2-T6 | Cơ bản | Office app, internal tool |
| Extended | 7:00-22:00 T2-T7 | +30-50% | E-commerce, customer-facing |
| 24/7 | Mọi lúc | +80-150% | Mission-critical, fintech |
Câu hỏi: Website e-commerce có traffic chủ yếu tối và cuối tuần — support 8-17 T2-T6 có đủ không?
4. Escalation Process (Quy trình leo thang)
SLA tốt phải định rõ:
| Nếu… | Thì… |
|---|---|
| Ticket P1 chưa phản hồi sau 30 phút | Tự động escalate lên Team Lead |
| Ticket P1 chưa giải quyết sau 2 giờ | Escalate lên Manager |
| Ticket P1 chưa giải quyết sau 4 giờ | Escalate lên Director + gọi điện trực tiếp |
5. Penalty / Credit (Phạt / Bồi thường)
Đây là phần quan trọng nhất — SLA không có penalty = lời hứa suông.
| Vi phạm | Penalty phổ biến |
|---|---|
| Uptime < target (mỗi 0.1% dưới) | Credit 5-10% phí tháng |
| Response time P1 vượt SLA | Credit 5% phí tháng/incident |
| Resolution time P1 vượt SLA | Credit 10% phí tháng/incident |
| Downtime > 24 giờ liên tục | Credit 100% phí tháng hoặc quyền hủy hợp đồng |
Ví dụ tính penalty:
- Phí bảo trì: 20 triệu/tháng
- SLA uptime: 99.9%
- Thực tế tháng này: 99.5% (downtime 3.65 giờ thay vì 43 phút)
- Penalty: 0.4% dưới target × 10% credit/0.1% = 4 × 10% = 40% credit = 8 triệu VND hoàn lại
Cách đọc hợp đồng bảo trì IT: 10 điểm cần check
Checklist khi review SLA
| # | Điểm check | Red flag |
|---|---|---|
| 1 | Uptime % cụ thể | ”Nỗ lực tốt nhất” thay vì con số cụ thể |
| 2 | Response time theo severity | Không phân loại severity |
| 3 | Resolution time (không chỉ response) | Chỉ cam kết response, không cam kết resolution |
| 4 | Penalty clause cụ thể | Không có penalty khi vi phạm SLA |
| 5 | Cách đo uptime (monitoring tool nào) | Vendor tự đo, không cung cấp dashboard cho khách |
| 6 | Exclusions (ngoại lệ) | Quá nhiều exclusions → SLA thực tế rất thấp |
| 7 | Planned maintenance window | Không giới hạn maintenance window |
| 8 | Escalation process rõ ràng | Không có escalation, chỉ có email chung |
| 9 | Report hàng tháng | Không có SLA report định kỳ |
| 10 | Exit clause (điều khoản rút lui) | Lock-in 2-3 năm không có exit clause |
Red flags phổ biến trong hợp đồng bảo trì
Red flag 1: “Best effort” “Bên B sẽ nỗ lực tốt nhất để đảm bảo uptime…” → Không cam kết gì cụ thể. “Nỗ lực tốt nhất” không đo được, không phạt được.
Red flag 2: “Reasonable time” “Bên B sẽ phản hồi trong thời gian hợp lý…” → “Hợp lý” theo ai? 1 giờ hay 1 tuần đều có thể “hợp lý.”
Red flag 3: Exclusions quá rộng “SLA không áp dụng khi: … force majeure, lỗi phần cứng, lỗi phần mềm bên thứ ba, attack DDoS, maintenance, lỗi do khách hàng…” → Loại trừ quá nhiều → SLA chỉ áp dụng khi… không có sự cố nào.
Red flag 4: Penalty = “credit cho tháng sau” Credit cho tháng sau nghĩa là: bạn phải tiếp tục hợp đồng để nhận credit. Tốt hơn: refund tiền mặt hoặc giảm hóa đơn tháng hiện tại.
Cách đàm phán SLA có lợi cho SME
5 tips đàm phán
1. Yêu cầu SLA report hàng tháng: Vendor phải cung cấp báo cáo uptime, incidents, response time thực tế. Nếu vendor từ chối → red flag (có gì đó không muốn bạn biết).
2. Đàm phán Resolution Time, không chỉ Response Time: “Reply email trong 1 giờ” không có ý nghĩa nếu giải quyết mất 1 tuần. Yêu cầu: P1 resolution ≤ 4 giờ, P2 ≤ 24 giờ.
3. Yêu cầu monitoring dashboard real-time: Bạn có quyền xem uptime monitoring real-time (UptimeRobot, Grafana). Không để vendor tự báo cáo “tháng này uptime 99.99%” mà bạn không có cách verify.
4. Cap penalty nhưng có exit clause: Penalty thường cap ở 20-30% phí tháng. Nhưng thêm: “Nếu vi phạm SLA 3 tháng liên tiếp → quyền hủy hợp đồng không phạt.”
5. Định nghĩa rõ “downtime”: Downtime = hệ thống không truy cập được từ phía end-user (không chỉ server crash). Bao gồm: trang load >10 giây, error 500, timeout.
SLA tối thiểu cho SME
| Hạng mục | Tối thiểu nên yêu cầu |
|---|---|
| Uptime | 99.5% (business hours) hoặc 99.9% (24/7) |
| P1 Response | ≤ 1 giờ |
| P1 Resolution | ≤ 4 giờ |
| P2 Response | ≤ 4 giờ |
| P2 Resolution | ≤ 24 giờ |
| Maintenance window | Tối đa 4 giờ/tháng, ngoài giờ hành chính |
| Monthly report | Bắt buộc |
| Penalty | ≥ 5% credit per SLA violation |
| Exit clause | Hủy free nếu vi phạm ≥3 lần/quý |
Chi phí bảo trì IT theo SLA level
| SLA Level | Phù hợp | Chi phí/tháng (estimate) |
|---|---|---|
| Basic (99%, business hours) | Internal tool, non-critical | 5-15 triệu VND |
| Standard (99.5%, extended hours) | Website, e-commerce | 15-30 triệu VND |
| Premium (99.9%, 24/7) | SaaS, fintech, healthcare | 30-60 triệu VND |
| Enterprise (99.99%, 24/7, dedicated) | Banking, mission-critical | 60-150 triệu VND |
FAQ — Câu hỏi thường gặp
1. Vendor không chịu ký SLA cụ thể — có nên thuê không?
Nếu vendor từ chối cam kết uptime và response time cụ thể, đó là red flag nghiêm trọng. Vendor chuyên nghiệp tự tin vào dịch vụ của mình sẽ sẵn sàng cam kết SLA. Không có SLA = không có accountability = bạn đang trả tiền cho “may rủi.”
2. SLA 99.9% có đủ cho website e-commerce không?
99.9% = 43 phút downtime/tháng — đủ cho hầu hết e-commerce SME. Quan trọng là khi nào downtime xảy ra: 43 phút lúc 3h sáng khác rất xa 43 phút lúc 20h tối (peak time). Yêu cầu thêm: “Planned maintenance chỉ thực hiện từ 2h-5h sáng.”
3. Tự build hay outsource bảo trì?
Phụ thuộc quy mô. <5 servers + <50 triệu doanh thu IT/tháng → outsource cost-effective hơn (không cần thuê SysAdmin full-time 30-50 triệu/tháng). >10 servers hoặc yêu cầu đặc thù → hybrid (IT nội bộ + outsource cho chuyên môn sâu). Xem thêm phân tích chi tiết tại bài Thuê IT nội bộ vs Outsource bảo trì.
4. SLA có áp dụng cho cloud (AWS, GCP) không?
Có. AWS cam kết SLA 99.99% cho EC2, credit nếu vi phạm. Nhưng AWS SLA chỉ cover infrastructure — ứng dụng của bạn crash do code lỗi thì AWS không chịu trách nhiệm. Bạn cần SLA riêng với vendor bảo trì ứng dụng.
5. Đọc hợp đồng bảo trì IT — nên nhờ ai review?
Lý tưởng: IT consultant + luật sư. Nếu budget hạn chế: IT consultant review phần kỹ thuật (SLA metrics, exclusions, monitoring), bạn tự review phần thương mại (giá, penalty, exit clause). Liên hệ Trinh Digital để được tư vấn review hợp đồng bảo trì IT.
Kết luận
SLA không phải “phần phụ” trong hợp đồng — nó là bản cam kết đo lường được về chất lượng dịch vụ. Hiểu SLA giúp bạn: chọn vendor đúng, trả giá hợp lý, và có cơ sở yêu cầu bồi thường khi dịch vụ không đạt chuẩn.
Quy tắc đơn giản: Nếu không viết trong SLA = không được cam kết. Đừng tin lời hứa miệng — hãy yêu cầu viết thành SLA.