Khi một luồng tự động chạy sai, cách nhanh nhất để tìm lỗi là đi theo đúng đường dữ liệu đã đi: luồng có được kích hoạt không, dữ liệu vào trông thế nào, bước nào biến nó thành thứ sai, và đầu ra rơi vào đâu. Phần lớn người mới sửa bằng cách đoán rồi chỉnh thử chỗ này chỗ kia, và thường làm hỏng thêm một chỗ khác. Dò theo chặng thì chậm hơn vài phút ở đầu nhưng nhanh hơn nhiều ở cuối.
Bài này dành cho người tự dựng luồng trên công cụ kết nối kéo thả hoặc tính năng tự động hoá có sẵn trong ứng dụng văn phòng, bán hàng: chủ cửa hàng, nhân viên vận hành, người làm marketing. Không cần đọc mã, chỉ cần biết mở phần lịch sử lượt chạy mà hầu hết công cụ đều có, dù tên gọi và vị trí mỗi nơi một khác.
Trước khi sửa: mô tả lỗi thành một câu có thể kiểm được
Lời báo lỗi kiểu "luồng hỏng rồi" hay "khách kêu không nhận được thư" chưa đủ để bắt tay vào sửa. Việc đầu tiên là viết lại thành một câu có ba phần: chuyện gì đáng lẽ xảy ra, chuyện gì đã thật sự xảy ra, và xảy ra với trường hợp nào. Ví dụ giả định: "Khách đăng ký học thử lúc chín giờ sáng thứ Ba lẽ ra nhận thư xác nhận và có dòng mới trong bảng theo dõi; thực tế bảng có dòng mới nhưng khách không nhận thư."
Câu này đã loại bớt một nửa khả năng. Bảng có dòng mới nghĩa là luồng đã được kích hoạt và chạy qua ít nhất bước ghi bảng. Vấn đề nằm ở bước gửi thư hoặc sau đó. Nếu không viết ra như vậy, rất dễ mất nửa giờ kiểm biểu mẫu trong khi biểu mẫu hoàn toàn bình thường.
Câu mô tả còn giúp trả lời một câu hỏi quan trọng khác: lỗi xảy ra với mọi trường hợp hay chỉ một vài? Luồng sai với tất cả là dấu hiệu cấu hình hỏng hoặc kết nối bị ngắt. Luồng sai với một vài trường hợp là dấu hiệu dữ liệu của chính những trường hợp đó có gì khác thường: ô bị bỏ trống, tên có ký tự đặc biệt, địa chỉ thư gõ thừa dấu cách. Hai loại này sửa theo hai hướng rất khác nhau, nên xác định sớm là đỡ đi lòng vòng.
Bốn chặng của một lượt chạy và câu hỏi cho từng chặng
Mọi luồng tự động, đơn giản hay phức tạp, đều đi qua bốn chặng. Dò lỗi là hỏi lần lượt từng chặng, dừng ở chặng đầu tiên trả lời "không".
| Chặng | Câu hỏi cần trả lời | Xem ở đâu |
|---|---|---|
| Kích hoạt | Sự kiện đáng lẽ khởi động luồng có xảy ra không, và luồng có nhận ra không? | Lịch sử lượt chạy: có lượt nào ở đúng thời điểm đó không |
| Dữ liệu vào | Dữ liệu luồng nhận được có đủ trường, đúng định dạng như lúc dựng không? | Mở lượt chạy, xem phần dữ liệu đầu vào của bước đầu tiên |
| Các bước xử lý | Bước nào nhận dữ liệu đúng nhưng trả ra dữ liệu sai hoặc báo lỗi? | Đi qua từng bước trong lượt chạy, so đầu vào với đầu ra |
| Đầu ra | Kết quả có được ghi, gửi tới đúng chỗ, đúng người không? | Mở chính ứng dụng đích: bảng tính, hộp thư đã gửi, kênh nhắn tin |
Điều đáng chú ý là chặng "đầu ra" hay bị bỏ qua. Công cụ kết nối có thể báo lượt chạy thành công vì nó đã gửi được yêu cầu sang ứng dụng đích, nhưng ứng dụng đích lại lặng lẽ bỏ qua: thư bị đưa vào mục thư rác của người nhận, dòng mới được ghi vào một trang tính khác cùng tên, tin nhắn đi vào nhóm cũ đã không còn ai đọc. "Thành công" trong lịch sử lượt chạy chỉ có nghĩa là công cụ không gặp lỗi, không có nghĩa là việc đã xong đúng ý bạn.
Đọc lịch sử lượt chạy như đọc sổ giao ca
Hầu hết công cụ tự động hoá lưu lại từng lượt chạy kèm dữ liệu đi qua mỗi bước. Đây là nguồn chứng cứ quý nhất, nhưng phải đọc có thứ tự:
- Lọc lịch sử về đúng khoảng thời gian xảy ra lỗi. Nếu không thấy lượt nào ở thời điểm đó, lỗi nằm ở chặng kích hoạt và không cần xem các bước sau.
- Mở một lượt chạy bị lỗi và một lượt chạy bình thường gần nhất, đặt cạnh nhau. Cách so sánh này cho kết quả nhanh hơn đọc riêng lượt lỗi.
- Ở bước đầu tiên, so phần dữ liệu đầu vào của hai lượt. Tìm trường bị thiếu, trường rỗng, trường có giá trị lạ như ngày tháng viết kiểu khác.
- Đi tiếp từng bước. Ở mỗi bước, xem đầu ra có giống thứ bước sau đang chờ không. Bước đầu tiên mà đầu ra lệch so với lượt bình thường là nơi cần sửa.
- Đọc nguyên văn thông báo lỗi nếu có, kể cả khi nó bằng tiếng Anh và khó hiểu. Chép thông báo đó ra, che thông tin khách, rồi nhờ chatbot giải thích bằng lời đơn giản nếu cần.
- Ghi lại điều vừa tìm được trước khi sửa: lượt nào, bước nào, sai thế nào. Ghi chép này sẽ dùng lại khi viết tài liệu cho luồng.
Một lưu ý về dữ liệu: lịch sử lượt chạy thường chứa nguyên văn thông tin khách hàng. Khi chụp màn hình gửi đồng nghiệp hay dán vào chatbot để hỏi, hãy che tên, số điện thoại, địa chỉ thư trước. Nhiều công cụ cũng cho phép đặt thời gian lưu lịch sử; với luồng xử lý dữ liệu cá nhân, không nên giữ lâu hơn mức cần để dò lỗi.
Năm loại lỗi gặp nhiều nhất ở luồng không viết mã
Kết nối hết hạn hoặc bị thu hồi. Tài khoản dùng để nối ứng dụng bị đổi mật khẩu, bị khoá, hoặc người cấp quyền đã nghỉ việc. Dấu hiệu là mọi lượt chạy cùng hỏng từ một thời điểm, thông báo lỗi thường nhắc tới xác thực hoặc quyền truy cập.
Cấu trúc dữ liệu nguồn bị đổi. Ai đó đổi tên cột trong bảng tính, thêm câu hỏi vào biểu mẫu, đổi thứ tự trường. Luồng vẫn chạy nhưng lấy nhầm cột hoặc nhận ô trống. Đây là loại lỗi âm thầm nhất vì thường không có thông báo đỏ nào.
Định dạng không khớp. Ngày tháng kiểu ngày trước tháng sau bị hiểu ngược, số tiền có dấu chấm phân cách hàng nghìn bị đọc thành số thập phân, múi giờ của công cụ khác múi giờ Việt Nam nên lịch hẹn lệch bảy tiếng.
Điều kiện lọc viết sai. Bộ lọc "chỉ chạy khi trạng thái là Đã thanh toán" không khớp vì dữ liệu ghi "đã thanh toán" chữ thường, hoặc có dấu cách thừa ở cuối. Luồng không lỗi, chỉ đơn giản là không bao giờ đi qua bộ lọc.
Giới hạn của công cụ. Hết số lượt chạy trong tháng của gói đang dùng, vượt giới hạn số yêu cầu mỗi phút của ứng dụng đích, tệp đính kèm quá dung lượng. Lỗi kiểu này hay xuất hiện vào cuối tháng hoặc ngày cao điểm bán hàng.
Sửa một chỗ, thử lại một lượt, rồi mới bật cho chạy thật
Khi đã thấy chỗ sai, nguyên tắc là chỉ sửa đúng chỗ đó. Cám dỗ lớn nhất lúc này là nhân tiện dọn lại cả luồng: đổi tên bước, thêm một bộ lọc, chỉnh câu chữ thư. Mỗi thay đổi thêm vào là một khả năng gây lỗi mới, và nếu luồng vẫn sai thì bạn không còn biết thay đổi nào gây ra.
Trước khi sửa, lưu lại bản hiện tại nếu công cụ có chức năng sao chép luồng hoặc lưu phiên bản. Sau khi sửa, chạy thử với chính dữ liệu của lượt bị lỗi hoặc một bản giả lập giống nó. Phần lớn công cụ cho phép chạy lại một lượt cũ hoặc chạy thử một bước riêng lẻ. Cần lường trước tác dụng phụ: chạy lại một lượt có bước gửi thư nghĩa là khách nhận thêm một thư nữa. Với bước gửi ra ngoài, nên tạm đổi người nhận sang hộp thư nội bộ khi thử.
Chỉ khi lượt thử cho đúng kết quả ở cả bốn chặng mới bật luồng lại. Sau khi bật, theo dõi vài lượt chạy thật đầu tiên bằng mắt. Lượt thử dùng dữ liệu bạn chọn, còn dữ liệu thật luôn có những kiểu bạn chưa nghĩ tới.
Dùng AI hỗ trợ dò lỗi mà không giao luôn quyết định cho nó
Chatbot hữu ích ở hai việc trong quá trình dò lỗi: giải thích thông báo lỗi khó hiểu, và gợi ý những nguyên nhân có thể dựa trên mô tả luồng. Câu lệnh mẫu: "Luồng tự động của mình gồm ba bước: biểu mẫu đăng ký, ghi vào bảng tính, gửi thư xác nhận. Bảng có dòng mới nhưng thư không đi. Thông báo lỗi ở bước gửi thư là như sau, đã che địa chỉ người nhận. Hãy liệt kê các nguyên nhân có thể theo thứ tự hay gặp, và với mỗi nguyên nhân, nói cách kiểm trong lịch sử lượt chạy."
Câu trả lời nên được đọc như danh sách việc cần kiểm, không phải chẩn đoán. Chatbot không nhìn thấy cấu hình thật của bạn, và tên nút, vị trí cài đặt nó nhắc có thể đã đổi ở phiên bản hiện hành. Nếu nó khẳng định chắc nịch một nguyên nhân, vẫn phải kiểm trong lịch sử lượt chạy rồi mới sửa.
Không dán nguyên dữ liệu đầu vào chứa thông tin khách vào chatbot để nhờ tìm chỗ sai. Thay tên, số điện thoại, địa chỉ bằng giá trị giả nhưng giữ nguyên định dạng, chẳng hạn ngày tháng vẫn viết đúng kiểu cũ, vì lỗi định dạng thường nằm chính ở đó. Với luồng có bước AI ở giữa, việc dò lỗi riêng cho bước AI trả kết quả sai định dạng có bài riêng trong danh mục thêm bước AI vào luồng của trang.
Ba thói quen giúp lần sau dò lỗi nhanh hơn
Dò lỗi lần đầu luôn chậm vì bạn phải tìm hiểu luồng từ đầu. Những thói quen nhỏ dưới đây làm lần sau nhanh hơn nhiều, và phần lớn chỉ tốn vài phút lúc dựng luồng:
- Đặt tên từng bước bằng lời mô tả việc nó làm, như "Ghi đơn vào bảng theo dõi" hay "Gửi thư xác nhận cho khách", thay vì để tên mặc định kiểu Bước 3. Khi đọc lịch sử lượt chạy, bạn biết ngay mình đang ở đâu.
- Thêm một cột "mã lượt chạy" hoặc "thời điểm luồng ghi" vào bảng đích. Khi thấy một dòng sai, bạn tra ngược ra đúng lượt chạy đã tạo nó trong vài giây.
- Giữ một sổ sự cố đơn giản: ngày, triệu chứng, nguyên nhân, cách sửa. Sau vài tháng, sổ này cho thấy luồng nào hay hỏng và hỏng vì lý do gì, từ đó biết nên gia cố chỗ nào.
- Ghi lại ai là người có quyền sửa luồng và ai giữ tài khoản kết nối. Rất nhiều lần dò lỗi bị kẹt không phải vì khó, mà vì không ai biết mật khẩu của tài khoản dùng để nối ứng dụng.
- Khi một luồng hỏng do thay đổi ở ứng dụng nguồn, như đổi tên cột, thống nhất với cả nhóm một quy tắc: ai sửa cấu trúc bảng hay biểu mẫu đang nối với luồng thì báo người phụ trách luồng trước.
Không thói quen nào ở trên cần kỹ năng lập trình. Chúng chỉ cần một người chịu trách nhiệm cho luồng và chịu khó ghi chép. Với doanh nghiệp nhỏ, người đó thường là chính chủ cửa hàng hoặc một nhân viên vận hành, và vài dòng ghi chép của họ có giá trị hơn mọi tính năng giám sát đắt tiền.
Câu hỏi thường gặp
Luồng tự động báo chạy thành công nhưng kết quả không có, vì sao?
Thành công trong lịch sử lượt chạy chỉ nghĩa là công cụ gửi được yêu cầu sang ứng dụng đích. Kết quả có thể đã vào mục thư rác, một trang tính khác, hoặc nhóm nhắn tin cũ. Hãy mở chính ứng dụng đích để kiểm thay vì chỉ tin dấu tích xanh.
Không thấy lượt chạy nào trong lịch sử thì lỗi nằm ở đâu?
Lỗi nằm ở chặng kích hoạt: sự kiện không xảy ra, hoặc luồng không nhận ra nó. Kiểm luồng có đang bật không, kết nối với ứng dụng nguồn còn hiệu lực không, và sự kiện có đúng loại mà luồng đang chờ, ví dụ dòng mới chứ không phải dòng được sửa.
Có nên sửa luồng trực tiếp trong lúc nó đang chạy thật không?
Không nên. Hãy tạm dừng luồng, lưu bản sao, sửa và chạy thử với dữ liệu giả hoặc người nhận nội bộ, rồi mới bật lại. Sửa khi đang chạy dễ khiến khách nhận thư lỗi hoặc dữ liệu bị ghi dở dang giữa chừng.
Lỗi chỉ xảy ra với vài khách thì nên kiểm gì trước?
Kiểm dữ liệu của chính những khách đó: ô bị bỏ trống, ký tự đặc biệt trong tên, dấu cách thừa trong địa chỉ thư, ngày tháng viết kiểu khác. Lỗi lẻ tẻ gần như luôn do dữ liệu khác thường, còn lỗi hàng loạt thường do cấu hình hay kết nối.
Có thể nhờ chatbot sửa lỗi luồng tự động không?
Có thể nhờ chatbot giải thích thông báo lỗi và gợi ý danh sách nguyên nhân để kiểm. Nhưng nó không thấy cấu hình thật của bạn và tên nút có thể đã đổi, nên quyết định sửa gì vẫn phải dựa trên lịch sử lượt chạy. Nhớ che thông tin khách trước khi dán.
Sửa xong rồi có cần theo dõi thêm không?
Cần theo dõi vài lượt chạy thật đầu tiên bằng mắt. Lượt thử dùng dữ liệu bạn tự chọn nên dễ đúng, còn dữ liệu thật luôn có những kiểu chưa lường trước. Nếu sau vài ngày mọi lượt đều đúng mới coi như xong.