Xử lý khi luồng automation lỗi: cảnh báo, log và chạy lại

Nếu một luồng automation quan trọng chết lặng lẽ giữa đêm, không ai hay biết cho tới khi khách hàng gọi điện hỏi vì sao đơn của họ không được xử lý, thì đó là dấu hiệu hệ thống của bạn đang thiếu ba thứ cơ bản: cảnh báo kịp thời, nhật ký đủ chi tiết để tra lỗi, và một quy trình chạy lại an toàn không tạo dữ liệu trùng. Bài này hướng dẫn bạn dựng đủ ba lớp phòng thủ đó cho mọi luồng automation quan trọng, giúp bạn phát hiện sự cố trong vài phút thay vì vài ngày, và chạy lại đúng phần bị lỡ mà không lo tạo ra đơn hàng hay hoá đơn trùng lặp.

Vì sao luồng automation lỗi âm thầm lại nguy hiểm

Khi một quy trình còn làm thủ công, con người thực hiện nó tự nhiên biết ngay lúc có gì đó bất thường vì chính họ đang thao tác trực tiếp. Nhưng khi quy trình đó đã được tự động hoá, không còn ai theo dõi từng bước nữa, nên nếu luồng gặp lỗi (một API bên thứ ba tạm thời không phản hồi, một trường dữ liệu bất ngờ trống, một tài khoản hết hạn quyền truy cập) mà không có cơ chế cảnh báo, sự cố có thể âm thầm kéo dài nhiều ngày mà không ai biết cho tới khi hậu quả đã lan ra, chẳng hạn hàng loạt đơn hàng không được tạo, hàng loạt hoá đơn không được gửi, hoặc dữ liệu báo cáo bị thiếu mà không ai phát hiện.

Tuy không thể đảm bảo một luồng automation không bao giờ gặp lỗi (vì luôn có những yếu tố nằm ngoài tầm kiểm soát như một dịch vụ bên thứ ba tạm ngưng hoạt động), nhưng hoàn toàn có thể đảm bảo bạn biết ngay khi lỗi xảy ra và có cách khôi phục nhanh chóng. Đây chính là khác biệt giữa một hệ thống automation trưởng thành và một hệ thống mới dựng còn sơ sài, và cũng là lý do vì sao bước xử lý lỗi nên được thiết kế ngay từ đầu, không phải thứ để "làm sau khi có thời gian".

Ba lớp phòng thủ cần có cho mọi luồng quan trọng

Các bước dựng cơ chế xử lý lỗi

1. 1

   Bật thử lại tự động cho các bước gọi API

   Hầu hết nền tảng automation phổ biến hiện nay, trong đó có n8n, đều hỗ trợ cấu hình thử lại cho từng bước gọi API với số lần thử tối đa và khoảng nghỉ giữa các lần thử, giúp luồng tự vượt qua các lỗi mạng chập chờn hoặc dịch vụ quá tải trong thời gian ngắn mà không cần con người can thiệp. Nên đặt khoảng nghỉ tăng dần giữa các lần thử (ví dụ 10 giây, rồi 30 giây, rồi 1 phút) thay vì thử lại liên tục ngay lập tức, để tránh làm dịch vụ đang gặp sự cố càng quá tải hơn.

2. 2

   Dựng một luồng lỗi riêng (error workflow)

   Ở nền tảng n8n, bạn có thể tạo một luồng riêng bắt đầu bằng nút Error Trigger rồi gán luồng này làm "luồng xử lý lỗi" trong phần cài đặt của luồng chính, để mỗi khi luồng chính gặp lỗi vượt quá số lần thử lại, hệ thống tự động chuyển sang chạy luồng lỗi này. Một luồng lỗi có thể dùng chung cho nhiều luồng chính khác nhau, giúp bạn không phải lặp lại logic cảnh báo ở từng luồng riêng lẻ.

3. 3

   Ghi log đầy đủ thông tin cần thiết để tra lỗi

   Mỗi lần lỗi xảy ra, ghi lại vào một bảng log riêng: thời điểm lỗi, tên luồng, bước nào gặp lỗi, thông điệp lỗi cụ thể, và dữ liệu đầu vào tại thời điểm đó (miễn là không chứa thông tin nhạy cảm cần che bớt). Log càng chi tiết, thời gian bạn cần để tìm ra nguyên nhân gốc rễ càng ngắn khi phải xử lý gấp lúc nửa đêm.

4. 4

   Gửi cảnh báo tới đúng người trực, đúng kênh

   Cảnh báo nên gửi vào một kênh mà người trực chắc chắn sẽ thấy nhanh (nhóm chat riêng cho cảnh báo hệ thống, hoặc tin nhắn trực tiếp nếu là lỗi nghiêm trọng), kèm đủ thông tin để người nhận hiểu ngay mức độ nghiêm trọng mà không cần mở thêm hệ thống khác để tra cứu thêm.

5. 5

   Đưa bản ghi lỗi vào hàng đợi để xử lý lại

   Thay vì để bản ghi bị lỗi biến mất, lưu nó vào một bảng "hàng đợi lỗi" kèm trạng thái "chưa xử lý", để sau khi khắc phục nguyên nhân gốc, bạn có thể chạy lại đúng những bản ghi này thay vì phải rà soát thủ công xem bản ghi nào đã bị bỏ sót.

Nguyên tắc chạy lại an toàn, không tạo dữ liệu trùng

Nỗi lo lớn nhất khi chạy lại một luồng đã lỗi giữa chừng là tạo ra dữ liệu trùng lặp, ví dụ tạo lại một đơn hàng đã được tạo thành công trước khi luồng gặp lỗi ở bước sau đó, hoặc gửi lại một email đã gửi thành công. Để tránh tình trạng này, nguyên tắc quan trọng nhất cần áp dụng là thiết kế mỗi bước ghi dữ liệu quan trọng theo hướng "idempotent", nghĩa là chạy lại nhiều lần với cùng dữ liệu đầu vào vẫn cho ra đúng một kết quả, không tạo thêm bản ghi mới.

Cách làm phổ biến để đạt được điều này là luôn kiểm tra xem bản ghi đã tồn tại chưa (dựa trên một mã định danh duy nhất như mã đơn hàng hoặc mã hoá đơn) trước khi tạo mới, nếu đã tồn tại thì bỏ qua bước tạo mà chỉ tiếp tục các bước sau đó chưa hoàn thành. Đây là lý do vì sao mọi luồng automation quan trọng nên có một mã định danh duy nhất đi xuyên suốt từ đầu đến cuối, giúp mọi bước sau này đều có thể kiểm tra lại chính xác bước nào đã hoàn thành, bước nào chưa, kể cả khi phải chạy đi chạy lại nhiều lần vì lỗi giữa chừng.

Phân loại lỗi để không báo động giả liên tục

Nếu mọi lỗi, dù nhỏ hay lớn, đều gửi cảnh báo giống nhau, người trực sẽ nhanh chóng mệt mỏi và bắt đầu lơ là những cảnh báo thật sự quan trọng, một hiện tượng thường gọi là "mệt mỏi vì cảnh báo". Nên phân loại lỗi thành ít nhất hai mức: lỗi nghiêm trọng cần xử lý ngay (ảnh hưởng trực tiếp tới khách hàng hoặc doanh thu, ví dụ đơn hàng không được tạo) và lỗi nhẹ có thể xử lý trong giờ hành chính (ví dụ một dòng dữ liệu phụ bị thiếu không ảnh hưởng tới luồng chính). Lỗi nghiêm trọng nên gửi cảnh báo ngay lập tức bất kể giờ giấc, còn lỗi nhẹ có thể gom lại thành một báo cáo tổng hợp gửi vào đầu giờ sáng hôm sau.

Lỗi thường gặp khi mới dựng cơ chế này

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

Cơ chế xử lý lỗi thường phát huy tác dụng rõ nhất ở những luồng có gọi API bên ngoài, nên nếu bạn chưa nắm chắc cách kết nối và xử lý phản hồi từ các API này, bài kết nối API bằng webhook và HTTP request trong automation sẽ giúp ích cho bước nền tảng này. Ngoài ra, vì log lỗi thường chứa dữ liệu nhạy cảm của khách hàng, đừng quên áp dụng đúng nguyên tắc phân quyền và mã hoá đã nêu ở bài bảo mật dữ liệu khi tự động hoá cho cả bảng log này. Đây đều là những mảnh ghép trong bức tranh lớn hơn về cách xây dựng và vận hành hệ thống automation trong doanh nghiệp một cách bền vững.