Sửa xong một luồng tự động bị lỗi mới là nửa việc; nửa còn lại là tìm và xử lý những bản ghi đã rơi hoặc bị làm sai trong khoảng thời gian luồng hỏng. Đơn hàng không vào bảng theo dõi, lịch hẹn không có tin nhắc, khách đăng ký không nhận thư xác nhận: những thứ này không tự quay lại khi luồng chạy đúng trở lại.
Bài này đi qua ba việc theo thứ tự: xác định khoảng thời gian bị ảnh hưởng, đối soát giữa nơi dữ liệu xuất phát và nơi nó đáng lẽ phải đến để tìm phần sót, rồi chạy bù sao cho không gửi trùng và không làm phiền khách thêm. Cuối bài là cách báo khách bị ảnh hưởng một cách gọn và thật.
Xác định khoảng thời gian bị ảnh hưởng
Điểm đầu của sự cố là lượt chạy sai đầu tiên, không phải lúc bạn phát hiện. Mở lịch sử lượt chạy, tìm lượt cuối cùng còn đúng và lượt đầu tiên sai. Nếu luồng gãy âm thầm vì đổi tên cột hay bộ lọc không khớp, lịch sử có thể toàn lượt xanh; khi đó xem dữ liệu đích, tìm dòng cuối cùng còn đầy đủ, hoặc xem lịch sử phiên bản của bảng, biểu mẫu để biết thay đổi gây lỗi xảy ra lúc nào.
Điểm cuối là lượt chạy đúng đầu tiên sau khi sửa. Giữa hai điểm này là cửa sổ sự cố. Ghi lại cả hai mốc thời gian, chính xác tới phút nếu được, vì mọi bước sau đều dựa vào chúng. Một lỗi hay gặp là lấy mốc theo múi giờ khác nhau: công cụ kết nối ghi giờ quốc tế, bảng tính ghi giờ Việt Nam, và cửa sổ bị lệch bảy tiếng làm sót cả một buổi.
Cũng nên xác định luồng bị ảnh hưởng theo kiểu nào trong cửa sổ đó: không chạy gì cả, chạy nhưng bỏ sót một số bản ghi, hay chạy nhưng ghi sai dữ liệu. Ba kiểu này cần ba cách xử lý khác nhau. Không chạy gì thì chỉ cần chạy bù. Bỏ sót thì phải đối soát để biết sót cái nào. Ghi sai thì phải sửa dữ liệu đã có, việc khó nhất trong ba.
Đối soát nguồn và đích: tìm chính xác phần sót
Đối soát là so danh sách ở nơi dữ liệu xuất phát với danh sách ở nơi nó đáng lẽ đến, trong đúng cửa sổ sự cố. Bảng dưới gợi ý nguồn và đích cho vài luồng hay gặp ở cửa hàng nhỏ.
| Luồng | Danh sách nguồn | Danh sách đích | So theo |
|---|---|---|---|
| Đơn mới vào bảng theo dõi | Danh sách đơn trong trang quản trị cửa hàng online | Bảng theo dõi đơn | Mã đơn |
| Đăng ký học thử, gửi thư xác nhận | Danh sách phản hồi của biểu mẫu | Bảng đăng ký và mục thư đã gửi | Mã phản hồi, địa chỉ thư |
| Nhắc lịch hẹn trước một ngày | Lịch hẹn trong ứng dụng đặt lịch | Nhật ký tin nhắc đã gửi | Mã lịch hẹn |
| Lưu hoá đơn đính kèm vào thư mục | Thư có tệp đính kèm trong hộp thư | Thư mục lưu hoá đơn | Tên tệp, ngày nhận |
Cách so đơn giản nhất với người không viết mã: xuất cả hai danh sách ra bảng tính, đặt hai cột mã cạnh nhau, dùng hàm tìm kiếm có sẵn để đánh dấu mã nào có ở nguồn mà không có ở đích. Đây là chỗ cột mã định danh mà bài về chạy trùng đã khuyên thêm vào trở nên vô giá; không có mã chung, đối soát phải so bằng tên, thời gian và rất dễ nhầm.
Chạy bù mà không gửi trùng, không làm phiền khách
Khi đã có danh sách phần sót, chạy bù theo trình tự sau để tránh tạo ra sự cố thứ hai:
- Kiểm luồng đã thật sự được sửa bằng bộ ca thử, và vài lượt chạy thật gần nhất đều đúng.
- Chọn cách chạy bù. Nhiều công cụ cho phép chạy lại một lượt cũ đã lỗi; nếu không, có thể tạo lại sự kiện bằng cách nhập lại bản ghi vào một bảng tạm mà một bản sao luồng đang nghe.
- Với bước gửi ra ngoài, quyết định trước có gửi bù hay không. Thư xác nhận đăng ký gửi trễ ba ngày có khi còn gây bối rối hơn là không gửi; tin nhắc lịch cho buổi hẹn đã qua thì chắc chắn không gửi.
- Chạy bù với một hai bản ghi trước, kiểm kết quả ở đích, rồi mới chạy phần còn lại.
- Sau khi chạy bù, đối soát lại một lần nữa. Danh sách sót phải về không, và không có dòng trùng mới.
- Ghi vào sổ sự cố: cửa sổ thời gian, số bản ghi sót, số đã chạy bù, số quyết định không chạy bù và lý do.
Nếu luồng có khoá chống trùng theo mã định danh, chạy bù an toàn hơn nhiều: lỡ chạy lại một bản ghi đã có, luồng sẽ tự bỏ qua. Nếu chưa có khoá, đây là lúc nên thêm, trước khi chạy bù.
Khi luồng không chỉ sót mà còn ghi sai
Sao lưu trạng thái hiện tại trước khi sửa. Xuất bảng đích ra tệp riêng, ghi rõ ngày. Nếu sửa nhầm, bạn còn đường quay lại.
Khoanh đúng những dòng sai. Lọc bảng theo cửa sổ thời gian sự cố, và nếu có cột "tạo bởi" hay mã lượt chạy, lọc theo luồng bị lỗi. Không sửa tràn ra ngoài cửa sổ.
Sửa từ nguồn, không sửa bằng trí nhớ. Dữ liệu đúng nằm ở nguồn: trang quản trị đơn hàng, phản hồi biểu mẫu gốc. Lấy lại từ đó thay vì đoán số điện thoại hay địa chỉ đúng là gì.
Kiểm hậu quả lan sang chỗ khác. Dữ liệu sai có thể đã được luồng khác đọc và dùng: báo cáo doanh số tuần đã gửi, số tồn kho đã trừ, tin nhắn đã gửi tới sai người. Liệt kê và xử lý từng chỗ.
Nếu dữ liệu cá nhân bị gửi nhầm người, xử lý như sự cố dữ liệu. Một tin nhắn chứa tên và địa chỉ khách A gửi nhầm cho khách B là sự cố lộ dữ liệu cá nhân, dù nhỏ. Báo người phụ trách, ghi lại, và làm theo quy trình của công ty cùng quy định hiện hành về bảo vệ dữ liệu cá nhân.
Nhờ AI hỗ trợ đối soát mà không đưa dữ liệu khách ra ngoài
Khi danh sách dài vài trăm dòng và hai bên ghi lệch định dạng, như một bên ghi mã đơn có tiền tố, một bên không, hay ngày tháng ghi hai kiểu, chatbot có thể giúp bạn nghĩ ra cách làm cho hai cột so được với nhau. Cách an toàn là chỉ đưa cho AI cấu trúc, không đưa dữ liệu: mô tả tên cột và vài dòng mẫu đã thay bằng giá trị giả nhưng giữ nguyên định dạng.
Câu lệnh mẫu: "Mình có hai bảng tính cần đối soát. Bảng một có cột mã đơn dạng chữ DH rồi sáu chữ số, bảng hai có cột mã đơn chỉ có sáu chữ số. Cột ngày ở bảng một ghi ngày trước tháng sau, bảng hai ghi tháng trước ngày sau. Hãy hướng dẫn từng bước bằng các hàm có sẵn trong bảng tính để chuẩn hoá hai cột rồi đánh dấu mã có ở bảng một mà không có ở bảng hai. Không dùng macro." Câu trả lời là công thức để bạn tự áp dụng trên dữ liệu thật trong bảng tính của công ty.
Không dán nguyên hai danh sách khách vào chatbot để nhờ so hộ. Ngoài chuyện dữ liệu cá nhân đi ra ngoài, AI có thể so sai mà trình bày rất tự tin, đặc biệt với danh sách dài. Đối soát là việc cần chính xác tuyệt đối, nên kết quả phải đến từ phép so trong bảng tính, nơi bạn kiểm lại được từng dòng, còn AI chỉ đóng vai người chỉ cách.
Báo khách bị ảnh hưởng: ngắn, thật, có việc tiếp theo
Không phải sự cố nào cũng cần báo khách. Đơn hàng bị sót trong bảng theo dõi nội bộ nhưng vẫn được giao đúng hẹn thì khách không biết và không cần biết. Nhưng nếu khách đã bị ảnh hưởng, như không nhận được xác nhận đăng ký, lỡ hẹn vì không có tin nhắc, nhận tin nhắn lặp hay nhận nhầm thông tin, một lời báo ngắn giữ được lòng tin tốt hơn im lặng.
Một lời báo tốt có ba phần: chuyện gì đã xảy ra với họ, nói bằng ngôn ngữ của khách chứ không phải ngôn ngữ kỹ thuật; cửa hàng đã làm gì; và họ cần làm gì tiếp, nếu có. Ví dụ giả định: "Do trục trặc hệ thống, trung tâm chưa gửi được thư xác nhận buổi học thử bạn đăng ký hôm thứ Ba. Lịch học thử của bạn vẫn giữ nguyên vào sáng thứ Bảy. Nếu bạn muốn đổi giờ, chỉ cần trả lời tin nhắn này." Không cần giải thích luồng nào hỏng, bước nào sai.
Có thể nhờ chatbot soạn nháp lời báo, với mô tả sự cố đã bỏ hết tên khách và chi tiết nội bộ. Câu lệnh mẫu: "Soạn tin nhắn ngắn dưới sáu mươi chữ gửi khách bị ảnh hưởng, giọng lịch sự, nhận trách nhiệm, không đổ cho hệ thống một cách né tránh, nói rõ việc khách cần làm tiếp." Đọc lại trước khi gửi, và gửi bằng tay hoặc qua luồng đã kiểm, không qua chính luồng vừa hỏng khi chưa chắc.
Rút kinh nghiệm để lần sau chạy bù nhanh hơn
Mỗi lần chạy bù là một bài học về những gì còn thiếu. Lần đầu thường chậm vì không có mã chung giữa nguồn và đích, không biết cửa sổ sự cố bắt đầu lúc nào, không có cách chạy lại một lượt cũ. Sau mỗi sự cố, chọn một hai thứ để bổ sung: thêm cột mã định danh, thêm bảng nhật ký lượt chạy, thêm luồng giám sát số lượng, viết sẵn mẫu lời báo khách.
Ghi đầy đủ vào sổ sự cố, kèm thời gian từ lúc lỗi bắt đầu tới lúc phát hiện, và từ lúc phát hiện tới lúc xử lý xong phần sót. Khoảng thứ nhất cho biết hệ thống cảnh báo của bạn có tốt không. Khoảng thứ hai cho biết quy trình xử lý của bạn có trơn tru không. Theo dõi hai con số này qua các sự cố là cách đơn giản để thấy vận hành tự động hoá của mình có đang tiến bộ hay không.
Cuối cùng, nếu một luồng cứ phải chạy bù vài lần mỗi quý, hãy coi đó là tín hiệu để xem lại chính luồng: có nên dựng lại cho bền hơn, có nên thay bằng tính năng có sẵn trong ứng dụng, hay có nên tắt hẳn. Bài về khi nào nên tắt một luồng trong danh mục này có cách cân nhắc chi tiết.
Câu hỏi thường gặp
Sửa xong luồng tự động rồi có cần làm gì thêm không?
Cần. Phải xác định khoảng thời gian luồng chạy sai, đối soát nguồn với đích để tìm bản ghi bị sót hoặc ghi sai, chạy bù hoặc sửa dữ liệu, và báo khách nếu họ bị ảnh hưởng. Bản ghi rơi trong lúc lỗi không tự quay lại.
Đối soát dữ liệu là gì và làm thế nào không cần viết mã?
Là so danh sách ở nơi dữ liệu xuất phát với danh sách ở nơi nó đáng lẽ đến trong cùng khoảng thời gian. Xuất cả hai ra bảng tính, đặt cột mã cạnh nhau, dùng hàm tìm kiếm có sẵn để đánh dấu mã có ở nguồn mà thiếu ở đích.
Có nên gửi bù thư xác nhận cho khách sau khi luồng lỗi không?
Tuỳ trường hợp. Thư xác nhận trễ vài ngày có khi gây bối rối hơn không gửi; tin nhắc cho buổi hẹn đã qua thì không gửi. Thường tốt hơn là gửi một lời báo ngắn, nói rõ tình trạng và việc khách cần làm tiếp.
Làm sao chạy bù mà không gửi trùng cho khách?
Kiểm luồng đã sửa xong, chạy bù thử với một hai bản ghi trước, và đảm bảo luồng có khoá chống trùng theo mã định danh. Sau khi chạy bù, đối soát lại để chắc danh sách sót về không và không có dòng trùng mới.
Luồng gửi nhầm thông tin khách cho người khác thì xử lý thế nào?
Coi đó là sự cố lộ dữ liệu cá nhân dù nhỏ. Tạm dừng luồng, báo người phụ trách, ghi lại chi tiết, liên hệ người nhận nhầm nếu phù hợp, và làm theo quy trình của công ty cùng quy định hiện hành về bảo vệ dữ liệu cá nhân.
Vì sao xác định thời điểm bắt đầu lỗi lại hay bị sai?
Vì luồng gãy âm thầm thường không có lượt đỏ nào, và vì công cụ kết nối, bảng tính có thể ghi giờ theo múi giờ khác nhau. Hãy đối chiếu lịch sử phiên bản của bảng, biểu mẫu và quy đổi mọi mốc về giờ Việt Nam.