SLA phản hồi: thời gian phản hồi khác thời gian khắc phục

SLA phản hồi là cam kết về thời gian để có người tiếp nhận và bắt đầu xử lý sự cố; SLA khắc phục là cam kết đưa hệ thống trở lại bình thường. Hai con số đo hai việc khác nhau, và nhầm lẫn giữa chúng gây ra phần lớn tranh chấp.

Tóm tắt nhanh

• Thời gian phản hồi kết thúc khi có người tiếp nhận thật, không phải khi hệ thống gửi email xác nhận tự động.
• Cần tách ba mốc: phản hồi, khắc phục tạm, và khắc phục hoàn toàn. Gộp ba mốc thành một cam kết là cách nhanh nhất để không ai chịu trách nhiệm.
• Đồng hồ chỉ công bằng khi mốc khởi động được ghi nhận tự động ở cả hai phía.
• Ba lý do tạm dừng hợp lệ là chờ khách cung cấp thông tin, chờ môi trường của khách, và chờ bên thứ ba có xác nhận.
• Phân hạng sự cố sai làm mọi con số sau đó vô nghĩa, vì mọi việc đều có thể bị xếp vào hạng thấp nhất.

Hai đồng hồ đo hai nghĩa vụ khác nhau

Thời gian phản hồi trả lời câu hỏi: sau bao lâu thì có người thực sự nhìn vào vấn đề của bạn. Nó không nói gì về việc vấn đề đã được sửa hay chưa. Một cam kết phản hồi trong 15 phút có thể được thoả mãn bằng một tin nhắn "chúng tôi đã ghi nhận và đang kiểm tra".

Thời gian khắc phục trả lời câu hỏi khác: sau bao lâu thì hệ thống chạy lại được. Nó phụ thuộc vào bản chất lỗi, không phụ thuộc vào ý chí của nhà cung cấp. Vì vậy cam kết khắc phục luôn nên chia theo hạng sự cố, và luôn nên có một mốc trung gian là khắc phục tạm.

Khắc phục tạm là đưa hệ thống về trạng thái dùng được bằng cách vòng qua nguyên nhân: tắt một chức năng, chuyển sang máy dự phòng, hoặc chặn một luồng dữ liệu. Nó quan trọng vì phần lớn sự cố nghiêm trọng được xử lý theo cách này trước khi tìm ra nguyên nhân gốc.

Ba cam kết này phải được viết thành ba dòng riêng trong hợp đồng, mỗi dòng có cách đo riêng. Khi chỉ có một dòng "thời gian xử lý", hai bên sẽ hiểu khác nhau ngay từ sự cố đầu tiên.

Đồng hồ bắt đầu chạy từ lúc nào

Đây là điều khoản bị đọc lướt nhiều nhất và cũng là điều khoản quyết định phần lớn tranh chấp. Bảng dưới liệt kê bốn mốc khởi động thường gặp và rủi ro của từng mốc.

Mốc tốt nhất là mốc được tạo tự động ở phía nhận và hiển thị lại cho phía gửi. Khi khách nhận được mã vé kèm thời điểm tạo, cả hai bên dùng chung một mốc và không còn chỗ để tranh luận.

Cần quy định rõ giờ làm việc nếu hợp đồng tính theo giờ làm việc: thứ mấy, từ mấy giờ đến mấy giờ, xử lý ngày lễ theo lịch nào. Hợp đồng ghi "giờ hành chính" mà không nêu múi giờ và lịch nghỉ là hợp đồng sẽ phải sửa sau sự cố đầu tiên.

Phân hạng sự cố quyết định mọi con số

Không có bảng phân hạng thì mọi cam kết thời gian đều có thể bị lách bằng cách xếp sự cố vào hạng thấp. Bảng dưới là ví dụ về cách phân hạng theo tác động, kèm bốn mốc thời gian cho mỗi hạng.

Các con số trong bảng là ví dụ để so sánh cấu trúc, không phải cam kết của một nhà cung cấp cụ thể. Điều quan trọng là cấu trúc: mỗi hạng có bốn mốc, và mỗi mốc có người chịu trách nhiệm.

Cần thêm một điều khoản chống lạm dụng phân hạng: nếu khách không đồng ý với hạng do nhà cung cấp gán, có cơ chế nâng hạng tạm thời trong lúc xử lý và chốt lại sau. Không có điều khoản này, việc phân hạng trở thành điểm tranh chấp thay vì công cụ điều phối.

Tạm dừng đồng hồ: ba lý do hợp lệ và hai lý do không

Tạm dừng đồng hồ là cơ chế cần thiết, nhưng phải có điều kiện. Ba lý do hợp lệ: đang chờ khách cung cấp thông tin không thể suy ra từ hệ thống, đang chờ quyền truy cập vào môi trường của khách, và đang chờ bên thứ ba xác nhận sự cố từ phía họ.

Hai lý do không hợp lệ dù rất hay được dùng: "đang chờ phân công người" và "đang chờ lịch phát hành". Cả hai đều là việc nội bộ của nhà cung cấp, không phải nguyên nhân nằm ngoài tầm kiểm soát.

Mỗi lần tạm dừng phải để lại ba thông tin: thời điểm bắt đầu, lý do, và việc cần làm để tiếp tục. Nếu thiếu một trong ba, lần tạm dừng đó nên bị tính là thời gian xử lý bình thường. Đây là quy tắc đơn giản nhưng loại bỏ phần lớn tranh chấp về sau.

Một sự cố đi qua bốn mốc thời gian

Ví dụ dưới đây cho thấy cùng một sự cố tạo ra bốn con số khác nhau, và mỗi con số phục vụ một mục đích quản trị riêng. Các mốc là giả định để minh hoạ cách tính.

Nếu hợp đồng chỉ có một con số "thời gian xử lý 4 giờ", sự cố này vi phạm cam kết dù hệ thống đã dùng được sau 55 phút. Ngược lại, nếu chỉ có cam kết phản hồi 15 phút, sự cố này đạt cam kết dù khách mất gần bảy giờ. Cả hai kết luận đều đúng theo hợp đồng và đều không phản ánh điều khách quan tâm.

Điều cần rút ra: chọn mốc theo thiệt hại. Với hệ thống bán hàng, mốc khắc phục tạm quan trọng hơn mốc khắc phục hoàn toàn, vì doanh thu dừng lại khi hệ thống không dùng được. Với hệ thống kế toán, mốc khắc phục hoàn toàn quan trọng hơn, vì dữ liệu sai còn tệ hơn dữ liệu chậm.

Điều khoản nên viết và nên tránh

Nên viết: bảng phân hạng kèm ví dụ cho từng hạng, bốn mốc thời gian cho mỗi hạng, kênh tiếp nhận chính thức duy nhất, quy tắc tạm dừng đồng hồ, và chế tài khi vi phạm. Nên viết thêm một câu về cách xử lý khi hai bên bất đồng về hạng.

Nên tránh: cam kết một con số duy nhất cho mọi sự cố, cam kết "xử lý trong vòng X giờ" mà không định nghĩa "xử lý", và cam kết phản hồi bằng email tự động. Ba cách viết này tạo cảm giác an toàn nhưng không tạo nghĩa vụ nào kiểm chứng được.

Một điểm thực tế: cam kết càng chặt thì cần dữ liệu càng tốt. Nếu bạn không có hệ thống ghi nhận thời điểm tự động, hãy chọn cam kết lỏng hơn một chút nhưng đo được, thay vì cam kết đẹp nhưng phải tranh luận mỗi tháng.

Câu hỏi thường gặp

Thời gian phản hồi có tính cả ngoài giờ làm việc không?

Tuỳ hợp đồng. Nếu tính theo giờ làm việc, một vé gửi lúc 20 giờ thứ Sáu có thể bắt đầu được tính từ 8 giờ thứ Hai. Cần ghi rõ múi giờ, lịch nghỉ lễ và cách xử lý sự cố nghiêm trọng ngoài giờ, vì đó là nhóm thường được cam kết riêng.

Email xác nhận tự động có được tính là đã phản hồi không?

Không nên tính. Xác nhận tự động chứng minh hệ thống nhận được tin, không chứng minh có người đọc. Nếu tính, cam kết phản hồi trở thành cam kết về máy chủ email và mất hoàn toàn ý nghĩa với người dùng.

Vì sao cần cả thời gian khắc phục tạm và thời gian khắc phục hoàn toàn?

Vì hai việc có chi phí và rủi ro khác nhau. Khắc phục tạm nhanh nhưng có thể che lỗi và tạo nợ kỹ thuật; khắc phục hoàn toàn chậm nhưng loại bỏ nguyên nhân. Cam kết riêng cho từng mốc giúp khách biết khi nào dùng được hệ thống và khi nào vấn đề thực sự được đóng lại.

Nếu nhà cung cấp phát hiện sự cố trước khách thì tính từ lúc nào?

Nên tính từ lúc hệ thống giám sát tạo cảnh báo, và ghi rõ điều đó trong hợp đồng. Cách này công bằng hơn cho cả hai: khách không bị thiệt vì phát hiện muộn, còn nhà cung cấp không bị tính thời gian trước khi biết sự cố tồn tại.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Nội dung được rà soát theo cách diễn giải cam kết dịch vụ thường gặp trong hợp đồng bảo trì phần mềm. Bảng phân hạng và các mốc thời gian là ví dụ minh hoạ cấu trúc, không phải cam kết của một nhà cung cấp cụ thể.

Khi bạn cần một quy trình tiếp nhận và xử lý sự cố có mốc thời gian rõ ràng, WinSell nhận vận hành sau bàn giao theo phạm vi đã chốt. Báo giá sau khi chốt phạm vi.

Bài viết liên quan: giám sát hệ thống là gì, giám sát hệ thống mạng, bảo trì phần mềm là gì và kiến trúc phần mềm là gì.