Hãy tưởng tượng một buổi sáng thứ Hai, website bán hàng của bạn đột nhiên không truy cập được. Khách gọi điện phàn nàn, đơn hàng dừng lại. Bạn nhắn cho bên kỹ thuật đang phụ trách, và nhận lại câu trả lời quen thuộc: "Để em xem đã." Nửa tiếng trôi qua, rồi một tiếng, rồi hai tiếng. Không ai nói cho bạn biết bao giờ mới xong, cũng không ai chịu trách nhiệm về khoảng thời gian bạn đang mất tiền.

Vấn đề ở đây không phải là "có sự cố". Phần mềm nào rồi cũng có lúc trục trặc. Vấn đề là không ai cam kết thời gian xử lý. Và đó chính là lúc bạn cần đến một thứ gọi là SLA.

SLA là gì?

SLA (Service Level Agreement, Thỏa thuận mức độ dịch vụ) là một bản cam kết bằng văn bản giữa bạn và bên cung cấp dịch vụ vận hành, ghi rõ chất lượng dịch vụ được đo bằng những con số cụ thể, chứ không phải bằng lời hứa chung chung.

Nói đơn giản, SLA giống như phiếu bảo hành của một chiếc điều hòa. Phiếu bảo hành không hứa "máy sẽ không bao giờ hỏng", điều đó là không thể. Nó cam kết những thứ đo được: bảo hành mấy năm, khi hỏng thì bao lâu có thợ tới, sửa trong bao lâu. SLA cho phần mềm cũng vậy: nó biến những kỳ vọng mơ hồ ("hệ thống chạy ổn định") thành các con số mà cả hai bên đều kiểm chứng được.

Không có SLA, mọi lời như "chúng tôi hỗ trợ nhanh" hay "hệ thống rất ổn định" đều vô nghĩa, vì không có thước đo nào để đối chiếu khi sự cố thật sự xảy ra.

Các chỉ số SLA quan trọng

Một SLA tốt thường xoay quanh ba con số cốt lõi mà chủ doanh nghiệp nên nắm:

1. Uptime (tỷ lệ thời gian hoạt động). Đây là phần trăm thời gian hệ thống của bạn luôn sẵn sàng phục vụ. Con số nghe rất trừu tượng, nhưng quy ra thời gian sập thực tế thì dễ hình dung ngay. Uptime 99.9% nghĩa là mỗi tháng hệ thống được phép "sập" tối đa khoảng 43 phút. Nếu cam kết lên 99.99%, con số đó chỉ còn khoảng 4 phút mỗi tháng. Chênh lệch một chữ số thập phân, nhưng chất lượng phục vụ khác hẳn.

2. Thời gian phản hồi (response time). Là thời gian tối đa kể từ khi bạn báo sự cố cho đến khi có người thật sự tiếp nhận và bắt đầu xử lý. Ví dụ: "phản hồi trong vòng 15 phút với sự cố nghiêm trọng." Chỉ số này quan trọng vì nó chấm dứt cảm giác "báo xong rồi rơi vào im lặng".

3. Thời gian khắc phục (resolution time). Là thời gian cam kết để đưa hệ thống trở lại bình thường. Thường được chia theo mức độ nghiêm trọng: sự cố khiến cả website sập sẽ có thời gian khắc phục ngắn hơn nhiều so với một lỗi nhỏ về hiển thị.

Các mức/bậc SLA: trong giờ hay 24/7?

Không phải doanh nghiệp nào cũng cần cùng một mức SLA, và mức cao hơn thì chi phí cũng cao hơn. Thường có hai bậc phổ biến:

  • SLA trong giờ hành chính: đội vận hành theo dõi và xử lý trong giờ làm việc (ví dụ 8h, 18h, các ngày trong tuần). Phù hợp với website giới thiệu công ty, hệ thống nội bộ. Nơi sự cố ngoài giờ không gây thiệt hại lớn.
  • SLA 24/7: có người trực và giám sát cả đêm, cuối tuần, ngày lễ. Bắt buộc với các hệ thống bán hàng online, ứng dụng có khách dùng liên tục, nơi một giờ sập lúc nửa đêm vẫn là tiền thật mất đi.

Điều quan trọng là chọn đúng bậc theo mức độ phụ thuộc của việc kinh doanh vào phần mềm. Không phải càng cao càng tốt, mà là đủ với rủi ro thực tế của bạn.

SLA bảo vệ doanh nghiệp thế nào?

SLA không phải là thủ tục giấy tờ, nó là công cụ bảo vệ bạn theo ba cách rất cụ thể.

Thứ nhất, nó chuyển rủi ro về đúng chỗ. Khi có cam kết bằng số, áp lực đảm bảo hệ thống chạy tốt thuộc về bên vận hành, không còn dồn hết lên vai bạn mỗi lần có sự cố.

Thứ hai, nó cho bạn cơ sở để đối chiếu. Bạn không cần rành kỹ thuật để biết dịch vụ có đạt hay không, chỉ cần nhìn báo cáo uptime và thời gian xử lý so với cam kết.

Thứ ba, nó tạo ra trách nhiệm rõ ràng. Một SLA nghiêm túc thường đi kèm điều khoản bồi thường hoặc điều chỉnh khi bên cung cấp không đạt cam kết, nghĩa là họ có động lực thực sự để giữ lời.

Kết

Sở hữu một phần mềm hay website đã là một khoản đầu tư đáng kể. Nhưng giá trị của khoản đầu tư đó chỉ được giữ vững khi có ai đó cam kết rõ ràng về việc vận hành nó. Bằng con số, chứ không bằng thiện chí.

Tại Siri9, chúng tôi tin rằng một SLA tốt phải minh bạch và dễ hiểu với cả những chủ doanh nghiệp không rành kỹ thuật: rõ uptime cam kết, rõ thời gian phản hồi, rõ trách nhiệm khi có sự cố. Nếu bạn đang tự hỏi hệ thống của mình thực sự được bảo vệ tới đâu, đó có lẽ là dấu hiệu nên bắt đầu cuộc trò chuyện về SLA.