Automation chạy xong: người dùng có kiểm tra được không?
Từ câu chuyện xây Notifly đến cách làm rõ trạng thái, lần chạy, từng trường hợp và hành động khi lỗi.
Viết bởi Phan Lâm Duy Khôi
Một automation cần giúp người dùng trả lời bốn câu hỏi: luồng đang thế nào, lần chạy vừa rồi có kết quả gì, một trường hợp cụ thể đã đi qua đâu, và khi lỗi thì có thể làm gì tiếp theo. Trạng thái “hoàn tất” chỉ trả lời được một phần.
Câu hỏi xuất hiện khi mình xây Notifly
Trong bài LinkedIn gốc, mình kể về lúc tạo một automation, cho contact đi vào luồng và nhận thông báo hoàn tất. Nhưng mình vẫn muốn biết contact nào vừa chạy, đã đi qua bước nào, email có được gửi hay chưa và lỗi nằm ở đâu nếu có.
Mình quay lại tổ chức phần kết quả và nhật ký theo bốn lớp. Bài này phát triển cách nhìn đó thành những câu hỏi bạn có thể dùng khi làm sản phẩm. Các tình huống và tiêu chí bên dưới là gợi ý thiết kế; chúng không mô tả toàn bộ cơ chế hiện tại của Notifly, cũng không phải kết quả cải thiện đã được đo.
Tách trạng thái của luồng khỏi trạng thái của lần chạy
Một luồng có thể đang bật nhưng một lần chạy bên trong lại thất bại. Ngược lại, một luồng đã tạm dừng vẫn có thể có những công việc đang xử lý. Dùng chung một nhãn cho cả hai khiến người dùng khó biết mình đang nhìn vào điều gì.
Trước khi chọn màu và tên trạng thái, hãy chốt đối tượng được mô tả, điều kiện chuyển trạng thái và ý nghĩa của việc tạm dừng. Tạm dừng có ngăn trường hợp mới vào luồng không? Công việc đã nhận sẽ chạy tiếp hay dừng? Đây là quy tắc sản phẩm cần thống nhất với kỹ thuật và vận hành.
- Cấp luồng: được bật, tạm dừng hay cần người dùng xử lý cấu hình?
- Cấp lần chạy: đang chờ, đang xử lý, kết thúc hay còn kết quả chưa xác định?
- Cấp từng bước: thành công, thất bại, bị bỏ qua hay chưa đến lượt?
Một lần chạy cần nói rõ đã xử lý đến đâu
Ví dụ minh họa: một lần chạy xử lý 10 contact, trong đó 7 hoàn tất, 2 thất bại và 1 đang chờ. Đây là số liệu giả định để bàn về giao diện, không phải dữ liệu vận hành của Notifly. Gắn nhãn “hoàn tất” cho cả nhóm sẽ che mất phần cần xử lý tiếp.
Một kết quả hữu ích nên nêu thời điểm bắt đầu, thời điểm cập nhật gần nhất, phạm vi xử lý và cách đếm từng nhóm. Các nhóm chỉ nên cộng lại thành tổng khi chúng dùng cùng một đối tượng và không chồng nhau. Nếu dữ liệu chưa đầy đủ, nói rõ phần chưa xác định thay vì hiển thị số 0.
Với người vận hành, bước tiếp theo thường là mở đúng nhóm thất bại hoặc đang chờ. Vì vậy, số tổng quan cần dẫn được đến danh sách trường hợp liên quan, thay vì chỉ là những ô số để nhìn.
Truy vết được một contact, không chỉ nhìn số tổng
Hãy thử tìm một contact cụ thể: họ vào luồng từ nguồn nào, thời điểm nào, đã đi qua bước nào và dừng ở đâu? Nếu mỗi màn hình đặt tên một kiểu hoặc không nối được các lần thử với cùng một công việc, người dùng sẽ phải tự ghép câu chuyện.
Gợi ý cho cuộc trao đổi với kỹ thuật: có mã lần chạy, mã bước và mã trường hợp để nối sự kiện với nhau; kèm thời điểm và kết quả từng bước. Đây là mô hình thông tin đề xuất, không phải yêu cầu phải dùng một công cụ cụ thể. OpenTelemetry cũng mô tả log với thời gian, mức độ và định danh trace/span để liên kết ngữ cảnh kỹ thuật.
Người dùng không nhất thiết cần thấy mã kỹ thuật ở mọi nơi. Họ cần một diễn giải dễ hiểu và một mã tham chiếu có thể gửi cho hỗ trợ khi cần.
Kết quả chưa xác định khác với thất bại
Giả sử yêu cầu gửi email bị hết thời gian chờ. Nhà cung cấp có thể đã nhận yêu cầu nhưng phản hồi chưa về. Vì vậy, “chưa biết kết quả” cần được phân biệt với “thất bại”.
AWS giải thích cách nhận diện yêu cầu lặp để tránh tạo thêm tác động. Khi bàn thiết kế, cần chốt cách tra cứu kết quả cũ và điều kiện thử lại. Khóa Button trên giao diện chưa đủ để bảo đảm an toàn.
Đặt nhãn theo đúng bằng chứng hệ thống đang có; đừng suy kết quả giao nhận từ trạng thái của một bước nội bộ.
Cho biết phải làm gì khi có lỗi
Thay vì một thông báo chung, hãy cho người dùng biết bước bị ảnh hưởng, phần kết quả đã xác nhận và hành động được phép tiếp theo. Có lỗi cần sửa dữ liệu trước; có lỗi cần chờ hoặc nhờ hỗ trợ. Không phải lỗi nào cũng nên có cùng Button chạy lại.
Ví dụ nội dung thông báo được đề xuất: “Chưa xác nhận được kết quả bước gửi email. Kiểm tra trạng thái nhà cung cấp trước khi thử lại.” Câu này không kết luận thất bại khi hệ thống chưa biết kết quả.
- Lần thử mới chỉ xử lý phần nào: cả nhóm, một contact hay một bước?
- Phần đã hoàn tất có được giữ nguyên không?
- Ai được phép chạy lại, và quyền đó được kiểm tra ở đâu?
- Nếu bấm hai lần hoặc tải lại trang, hệ thống xử lý thế nào?
Nhật ký cần đủ để kiểm tra, không cần chứa mọi dữ liệu
Ghi thêm dữ liệu không tự động làm nhật ký hữu ích hơn. Với mỗi trường, hãy hỏi nó giúp tìm lỗi hay ra quyết định gì, ai cần được đọc và có thể dùng mã tham chiếu thay cho nội dung gốc không.
OWASP khuyến nghị loại bỏ hoặc bảo vệ dữ liệu như token truy cập, mật khẩu và dữ liệu cá nhân nhạy cảm; đồng thời hạn chế quyền xem nhật ký. Khi đưa email hay thông tin khách hàng lên màn hình, cần xác định quyền xem và cách che dữ liệu phù hợp. Màn hình hỗ trợ người vận hành và log kỹ thuật có thể cần các mức chi tiết khác nhau.
Chốt bản đầu bằng tiêu chí kiểm tra được
Bản đầu không cần một trang tổng hợp mọi loại log. Bạn có thể bắt đầu từ tổng quan lần chạy, danh sách trường hợp và chi tiết bước đang cần xử lý. Phạm vi thực tế còn phụ thuộc người dùng, rủi ro và khả năng hệ thống.
Dưới đây là các tiêu chí đề xuất để Product, Dev và QA cùng bàn; chưa phải cam kết hay mô tả tính năng đã có của Notifly.
- Khi một contact thất bại, người dùng tìm được contact đó và bước bị lỗi từ phần tổng quan.
- Khi còn công việc đang chờ, màn hình không nói toàn bộ đã thành công.
- Khi chưa có xác nhận từ dịch vụ ngoài, trạng thái giữ rõ sự chưa chắc chắn và không mở hành động có thể tạo tác động lặp khi chưa có cơ chế bảo vệ.
- Khi được phép thử lại, phạm vi, quyền và ảnh hưởng lên phần đã hoàn tất đều được giải thích trước.
- Khi không có quyền xem, dữ liệu chi tiết và hành động xử lý đều bị chặn, không chỉ ẩn bằng giao diện.
Đo xem người dùng có tự kiểm tra và xử lý được không
Sau khi đưa vào dùng, mình sẽ muốn quan sát thời gian người vận hành cần để tìm đúng lỗi, tỷ lệ tình huống họ xác định được bước tiếp theo và số lần cần nhờ hỗ trợ. Với tác vụ gửi ra ngoài, cần theo dõi cả những lần thực hiện trùng ngoài dự kiến. Đây là các tín hiệu đề xuất, chưa phải kết quả đã đạt được.
Một bài kiểm tra nhỏ: đưa cho người dùng một lần chạy có kết quả lẫn lộn, yêu cầu tìm một trường hợp và giải thích họ sẽ làm gì tiếp. Nếu họ phải đoán ý nghĩa trạng thái hoặc nhờ kỹ thuật đọc hộ, giao diện vẫn còn điều cần làm rõ.
Bạn có thể áp dụng cách kiểm tra này cho import dữ liệu, đồng bộ, xuất báo cáo hoặc xử lý đơn hàng. Bắt đầu từ một tác vụ và xem người dùng có trả lời được bốn câu hỏi ở đầu bài hay chưa.