Khi dịch vụ bên thứ ba bị lỗi, website nên tiếp tục các chức năng an toàn, tạm dừng những giao dịch chưa xác minh và giữ dữ liệu để đối soát. Điều này áp dụng khi website phải kết nối cổng thanh toán, CRM, dịch vụ email, bản đồ, vận chuyển hoặc các API (giao diện kết nối giữa phần mềm).
Vấn đề không chỉ là nhà cung cấp bị sập: phản hồi quá chậm, hết hạn mức gọi API hoặc lỗi xác thực cũng khiến khách không gửi được yêu cầu hay hoàn tất đơn hàng. Chủ website cần biết dịch vụ nào quan trọng, lỗi đó ảnh hưởng khách ra sao, ai nhận cảnh báo và phương án dự phòng đã được kiểm thử chưa.
Dịch vụ bên thứ ba ảnh hưởng website như thế nào?
Ví dụ, bản đồ địa chỉ không tải được không nên làm toàn bộ trang liên hệ biến mất. Nhưng nếu cổng thanh toán không xác minh được giao dịch, website không được tự báo “đã thanh toán” để giữ trải nghiệm. Nguyên tắc này được gọi là Third-party Dependency Reliability: giới hạn lỗi dây chuyền từ những hệ thống bên ngoài.
API Monitoring tập trung phát hiện lỗi; bài hiện tại hướng dẫn quyết định ứng xử khi đã có lỗi. Với một hệ thống nhiều bước và nhiều nơi lưu dữ liệu, cần xem thêm cách vận hành kết nối tổng thể ở phần cuối bài.
1. Dịch vụ nào lỗi thì website nên tiếp tục hay tạm dừng?
| Phần gặp lỗi | Cách xử lý phù hợp nếu đã thiết kế trước |
|---|---|
| Bản đồ và nội dung gợi ý | Vẫn hiển thị địa chỉ, điện thoại, danh mục sản phẩm hoặc nội dung mặc định có sẵn |
| CRM nhận thông tin | Nếu website có nơi lưu an toàn, lưu yêu cầu để đồng bộ sau; không báo đã nhận nếu chưa thực sự lưu |
| Email thông báo | Giữ bản ghi giao dịch và theo dõi thư cần gửi lại; không tự gửi trùng không kiểm soát |
| Đơn vị vận chuyển hoặc tồn kho | Thông báo tạm thời; không cam kết phí, tồn kho hoặc ngày giao chưa xác minh |
| Thanh toán hoặc kiểm tra gian lận | Giữ trạng thái chưa xác nhận, kiểm tra mã giao dịch và không bỏ qua bước bảo mật bắt buộc |
Không phải tính năng nào cũng có thể dùng phương án dự phòng. AWS khuyến nghị phân biệt phần bắt buộc và phần có thể hoạt động ở chế độ giới hạn trong hướng dẫn giảm chức năng có kiểm soát. Với website bán hàng, tính đúng của thanh toán và đơn hàng phải được ưu tiên hơn hiển thị thông báo thành công cho đẹp.
2. Bốn nguyên tắc hạn chế lỗi dây chuyền
Timeout: Không chờ một dịch vụ ngoài quá lâu
Timeout là giới hạn thời gian website chờ phản hồi. Nếu nhà cung cấp xử lý chậm, chờ mãi có thể khiến trang và các chức năng khác bị kéo chậm. Đội kỹ thuật cần chọn thời gian chờ dựa trên chức năng và tổng thời gian khách có thể chờ; không có một số giây đúng cho mọi hệ thống.
Retry: Chỉ gửi lại khi an toàn
Retry là thử gửi lại yêu cầu khi lỗi có khả năng tạm thời. Mạng chập chờn, một số lỗi máy chủ 5xx hoặc mã 429 (quá giới hạn) có thể thuộc nhóm cần thử lại có kiểm soát. Sai khóa API hoặc không có quyền 401/403 thường phải sửa nguyên nhân, không nên gửi lặp.
Đội kỹ thuật nên giới hạn số lần thử, giãn khoảng cách và tuân thủ Retry-After khi nhà cung cấp trả về. Tài liệu Microsoft về lỗi tạm thời cũng cảnh báo việc nhiều lớp cùng thử lại có thể khiến dịch vụ quá tải hơn.
Circuit breaker: Tạm ngừng gọi khi bên ngoài liên tục lỗi
Circuit breaker có nghĩa tạm chặn yêu cầu mới đến một dịch vụ đang lỗi liên tục, rồi kiểm tra thận trọng khi có dấu hiệu phục hồi. Cách này giúp phần còn lại không bị kéo chậm vì thử lại không ngừng. Xem hướng dẫn Circuit Breaker của Microsoft.
Fallback: Chỉ dùng cách thay thế không làm sai dữ liệu
Fallback là phương án dự phòng: bản đồ lỗi thì hiển thị địa chỉ bằng chữ; gợi ý sản phẩm lỗi thì vẫn cho xem danh mục. Nhưng không được sử dụng giá, quyền truy cập hoặc kết quả thanh toán cũ rồi coi là thông tin hiện tại.
Điểm quan trọng là idempotency, tức một thao tác có thể lặp lại mà không gây kết quả trùng không mong muốn. AWS nhắc rằng hết thời gian chờ không chứng minh bên nhận chưa xử lý yêu cầu. Vì thế, phải biết trạng thái giao dịch trước khi gửi lại; xem AWS về timeout và retry.
3. Ví dụ: Khách bấm thanh toán rồi gặp lỗi kết nối
Tình huống giả định: Khách đã bấm thanh toán, trình duyệt đợi rồi hiển thị lỗi. Có thể giao dịch chưa thực hiện; cũng có thể tiền đã được xử lý nhưng website mất phản hồi. Không nên thông báo chắc chắn “chưa trừ tiền” hoặc tự tạo một lần thanh toán mới.
Phương án hợp lý là giữ đơn ở trạng thái chờ xác minh, kiểm tra mã tham chiếu với cổng thanh toán và chỉ thông báo kết quả khi đã đối chiếu. Với nhà cung cấp hỗ trợ, khóa chống trùng giao dịch (idempotency key) cho phép gửi lại một yêu cầu mà không tạo thêm giao dịch ngoài ý muốn; Stripe giải thích cơ chế này trong tài liệu API. Không mặc định mọi cổng thanh toán có cùng cách hoạt động.
4. Sáu bước xử lý khi dịch vụ bên ngoài gặp sự cố
- Xác định lỗi: Tên dịch vụ, thời điểm, loại thông báo và chức năng bị ảnh hưởng. Đối chiếu giám sát API, nhật ký an toàn và thông báo nhà cung cấp nếu có.
- Đánh giá ảnh hưởng kinh doanh: Khách còn gửi liên hệ, đặt hàng, thanh toán được không? Phân công đầu mối làm việc với nhà cung cấp.
- Giới hạn lỗi lan rộng: Áp dụng giới hạn chờ và số lần thử phù hợp; không để website liên tục gọi lại một dịch vụ đang quá tải.
- Chuyển sang phương án đã thử: Giữ các phần an toàn hoạt động; tạm khóa thanh toán hoặc xác minh quan trọng khi chưa có kết quả đáng tin.
- Bảo toàn yêu cầu chờ: Nếu có hệ thống lưu và hàng đợi an toàn, giữ thông tin cùng mã nhận dạng để xử lý sau mà không trùng.
- Thông báo và đối soát sau phục hồi: Nêu phần nào đang bị hạn chế và hướng hỗ trợ, rồi so sánh đơn hàng, lead, giao dịch, email chưa gửi. Xem đối soát website, CRM, ERP.
Không nên hứa thời gian nhà cung cấp khắc phục khi chưa có xác nhận. Nếu một giao dịch chưa rõ thành công hay thất bại, cần hướng dẫn khách kiểm tra trạng thái thay vì khuyến khích thao tác lặp ngay.
5. Chuẩn bị gì trước khi nhà cung cấp gặp lỗi?
Doanh nghiệp nên có bảng nhà cung cấp — chức năng phụ thuộc — người chịu trách nhiệm — mức ảnh hưởng — cách nhận cảnh báo — phương án đã kiểm thử. Cũng cần theo dõi hạn mức API, thông tin dịch vụ, việc hết hạn giấy phép và kế hoạch khi đổi nhà cung cấp.
Khi xử lý tài khoản API hoặc chuyển nhà cung cấp, cần thu hồi khóa cũ đúng cách. Xem quản lý API key và thông tin bí mật. Không dán token, mật khẩu hoặc dữ liệu khách vào nhật ký chia sẻ công khai.
6. Chủ website cần nghiệm thu những gì?
| Hạng mục | Bằng chứng cần nhận |
|---|---|
| Danh sách phụ thuộc | Dịch vụ nào quan trọng và ai hỗ trợ khi lỗi |
| Giám sát | Cảnh báo mất kết nối, phản hồi chậm, lỗi và hết hạn mức |
| Kiểm soát lỗi | Kết quả thử timeout, retry giới hạn, circuit breaker nếu áp dụng |
| Phương án dự phòng | Chức năng an toàn tiếp tục chạy; chức năng chưa thể xác minh được tạm dừng rõ ràng |
| Dữ liệu và giao dịch | Đơn hàng, lead, mã thanh toán có thể đối chiếu và không tự thực hiện trùng |
| Sau phục hồi | Danh sách việc tồn, kết quả đối soát, người xác nhận và lỗi cần theo dõi tiếp |
Đối với hệ thống kết nối nhiều lớp, có thể cần thêm quy trình Website Integration Reliability. Bài hiện tại chỉ tập trung vào việc giảm tác động khi một dịch vụ bên ngoài chậm hoặc không dùng được.
Câu hỏi thường gặp
API bên thứ ba lỗi có phải tắt cả website không?
Không nhất thiết. Nếu các chức năng độc lập đã được thiết kế để tiếp tục an toàn, website có thể phục vụ phần còn lại. Nhưng không nên cho phép thanh toán hoặc kiểm tra bảo mật vượt qua bước xác minh.
Có nên tự động thử gửi lại tới khi được không?
Không. Cần giới hạn số lần, tuân thủ tín hiệu từ dịch vụ và kiểm tra khả năng thực hiện trùng. Thử vô hạn có thể làm lỗi nặng thêm.
Giám sát API đã đủ bảo đảm website không mất đơn?
Chưa đủ. Giám sát giúp phát hiện lỗi; giữ dữ liệu an toàn, phương án dự phòng và đối soát sau phục hồi mới giúp xác nhận tình trạng đơn hàng.
Kết luận
Không nhà cung cấp bên thứ ba nào được bảo đảm hoạt động mãi. Với website doanh nghiệp, ưu tiên là cô lập lỗi, bảo toàn thông tin khách và xác minh giao dịch, chứ không phải cố cho mọi nút bấm luôn hiện thông báo thành công.
Tài liệu kỹ thuật liên quan: Retry pattern của Microsoft và Circuit Breaker giúp đội kỹ thuật chọn cơ chế khi lỗi là tạm thời hay kéo dài.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.