SLA vận hành website là gì? Cách xác định mức độ sự cố và thời gian phản hồi

SLA – Service Level Agreement là thỏa thuận dịch vụ xác định một số cam kết có thể đo được giữa bên cung cấp và bên sử dụng. Với vận hành website, SLA hữu ích khi nó mô tả rõ phạm vi, cách phân loại sự cố, thời gian tính, điểm bắt đầu/kết thúc và phần loại trừ.

Một câu như “hỗ trợ 24/7” hoặc “xử lý nhanh” không đủ để trở thành SLA có thể kiểm chứng.

SLI/SLO là dữ liệu đầu vào, SLA là cam kết vận hành

Có thể hình dung theo chuỗi “đo lường → mục tiêu → cam kết”:

• SLI: chỉ số đo, ví dụ availability hoặc thời gian phản hồi.
• SLO: mục tiêu vận hành cho chỉ số đó.
• SLA: cam kết/thỏa thuận với khách hàng, có phạm vi và hệ quả theo hợp đồng.

Phần tính uptime/availability và downtime budget được tách riêng tại bài Uptime website là gì?. Bài này tập trung vào cách biến chỉ số thành cam kết vận hành có severity, response, restoration, resolution và phần loại trừ rõ ràng.

“Thời gian phản hồi” không phải “thời gian sửa xong”

Đây là lỗi phổ biến khi đọc bảng giá dịch vụ.

Nên phân biệt:

• acknowledgement: xác nhận đã nhận ticket/alert;
• response: bắt đầu tương tác hoặc điều tra;
• diagnosis: xác định nguyên nhân hoặc phạm vi sơ bộ;
• workaround: giải pháp tạm để giảm tác động;
• restoration: khôi phục dịch vụ chính;
• resolution: xử lý nguyên nhân/đóng sự cố.

Một lỗi có thể được response trong thời gian ngắn nhưng cần nhiều giờ hoặc phụ thuộc bên thứ ba mới resolution. Nếu SLA không nói rõ thuật ngữ, hai bên dễ kỳ vọng khác nhau.

Severity nên dựa trên impact và urgency

Một mô hình tham khảo nên bắt đầu từ impact và urgency, sau đó mới gán nhãn severity:

Mức	Ví dụ	Tác động
P1 Critical	website/checkout chính ngừng, compromise đang hoạt động	ảnh hưởng nghiêm trọng, không có workaround
P2 High	chức năng quan trọng lỗi	ảnh hưởng lớn nhưng có workaround hoặc phạm vi giới hạn
P3 Medium	lỗi chức năng phụ/hiệu năng	người dùng vẫn hoàn thành nhiệm vụ chính
P4 Low	yêu cầu thay đổi, lỗi cosmetic	không chặn hoạt động chính

Đừng sao chép nguyên các mức P1–P4 vào hợp đồng nếu chưa phù hợp với website và khả năng support thực tế.

SLA clock bắt đầu khi nào?

Cần định nghĩa:

• khi monitoring phát hiện;
• khi ticket được tạo;
• khi khách hàng gửi đủ thông tin;
• hay khi provider xác nhận severity.

Cũng cần nói rõ:

• business hours hay 24×7;
• ngày lễ;
• maintenance window;
• thời gian chờ khách hàng;
• thời gian chờ bên thứ ba;
• planned change.

Dependency bên thứ ba xử lý thế nào?

Website có thể phụ thuộc domain, DNS, CDN, payment, email, SaaS, API. Provider vận hành website không phải lúc nào cũng có quyền sửa dependency đó.

SLA nên nêu:

• dependency nào nằm trong phạm vi;
• provider có quyền admin hay chỉ phối hợp;
• cách escalation;
• clock có tạm dừng khi chờ third party không;
• ai cung cấp evidence.

Availability trong SLA: chỉ cam kết khi cách đo rõ

Nếu SLA có cam kết availability, cần biết:

• endpoint;
• probe location;
• tần suất;
• timeout;
• maintenance window;
• exclusions;
• cách tính;
• nguồn dữ liệu nào là authoritative.

Không nên dùng một con số uptime marketing rồi mặc định đó là SLA toàn bộ ứng dụng. Nếu cần đối chiếu các mức 99%, 99,9%, 99,99% và downtime tương ứng, xem bài Uptime website.

SLA cho request thay đổi có giống incident không?

Không. Incident khôi phục trạng thái mong đợi; change request tạo thay đổi mới.

Ví dụ “thêm banner”, “tạo landing page” hoặc “tích hợp API mới” không nên nằm cùng response target với website down. Nếu gộp, đội vận hành mất khả năng ưu tiên sự cố thật sự.

Báo cáo SLA nên có gì?

• số incident theo severity;
• response/restoration/resolution;
• uptime/SLO nếu áp dụng;
• recurring issue;
• dependency;
• change đã triển khai;
• incident vượt SLA và nguyên nhân;
• action item.

Không cần dashboard phức tạp nếu dữ liệu không dẫn đến quyết định.

Checklist trước khi ký SLA vận hành website

• Scope rõ.
• Severity rõ.
• Kênh tạo ticket rõ.
• Giờ dịch vụ rõ.
• Response/restoration/resolution tách riêng.
• Availability đo được.
• Maintenance window rõ.
• Dependency/exclusion rõ.
• Escalation rõ.
• Báo cáo và review cadence rõ.
• Nghĩa vụ của khách hàng rõ.
• Điều kiện thay đổi SLA rõ.

WebsiteHCM hiện có bài bảng giá bảo trì website với phạm vi và SLA và dịch vụ sửa lỗi website khẩn cấp để đối chiếu giữa maintenance định kỳ và incident.

Một SLA tốt không hứa mọi lỗi đều sửa “ngay lập tức”. Nó tạo ngôn ngữ chung để ưu tiên, đo lường và biết ai làm gì khi website gặp vấn đề.

Đọc thêm trong cụm Managed Website: Tiếp nhận website từ agency cũ; Quyền kiểm soát website; Dịch vụ quản trị và vận hành website.

Để đối chiếu cách WebsiteHCM mô tả phạm vi cam kết, nghiệm thu, chỉnh sửa, hỗ trợ và xử lý khi kết quả chưa đạt yêu cầu, xem Cam Kết Dịch Vụ, Nghiệm Thu Và Xử Lý Khi Chưa Đạt Yêu Cầu.