Trên trang này ↓
Một báo giá chuyển từ “chờ duyệt” sang “đã gửi”, nhưng người quản lý không biết ai đã đổi trạng thái. Địa chỉ giao hàng bị sửa sau khi đơn được xác nhận, đội hỗ trợ chỉ thấy giá trị hiện tại. Khi sản phẩm B2B có nhiều vai trò cùng thao tác trên một hồ sơ, lịch sử hoạt động phải giúp đội tái dựng thay đổi thay vì chỉ báo rằng “đã có cập nhật”.
Bắt đầu từ câu hỏi đội vận hành cần trả lời
Danh sách sự kiện nên xuất phát từ tình huống phải kiểm tra. Với quy trình báo giá, sales cần biết ai tạo bản nháp, quản lý đã duyệt phiên bản nào và nội dung nào thay đổi trước khi gửi. Với hồ sơ khách hàng, đội hỗ trợ có thể cần xem số điện thoại hoặc người phụ trách đã đổi lúc nào.
Không phải mọi cú nhấp đều có giá trị nghiệp vụ. Việc mở một tab, đóng hộp thoại hoặc gõ rồi xóa trong ô nhập thường không giúp giải quyết tranh chấp hay xử lý lỗi. Ngược lại, thay đổi trạng thái, người phụ trách, quyền truy cập, giá trị tiền, điều kiện thanh toán hoặc địa chỉ giao hàng thường cần được cân nhắc.
| Tiêu chí | Nhật ký hoạt động cho người dùng | Log kỹ thuật cho đội phát triển |
|---|---|---|
| Câu hỏi chính | Ai đã thay đổi dữ liệu nghiệp vụ nào, vào lúc nào? | Dịch vụ nào đã chạy, lỗi gì xảy ra, request đi qua đâu? |
| Người đọc | Vận hành, hỗ trợ, quản lý và người có quyền kiểm tra. | Developer, SRE hoặc đội xử lý sự cố kỹ thuật. |
| Cách trình bày | Ngôn ngữ nghiệp vụ, gắn với hồ sơ và hành động cụ thể. | Mã lỗi, stack trace, request ID và thông tin chẩn đoán. |
| Phạm vi dữ liệu | Chọn lọc, có quyền xem và thời hạn lưu theo mục đích. | Chi tiết kỹ thuật cần cho theo dõi hệ thống và điều tra lỗi. |
Hai loại dữ liệu có thể liên kết bằng mã sự kiện hoặc request ID, nhưng không nên dùng log kỹ thuật làm giao diện lịch sử cho khách hàng. Nó vừa khó đọc, vừa có nguy cơ lộ thông tin nội bộ.
Mỗi sự kiện cần đủ cấu trúc để tái dựng thay đổi
Người thực hiện
Lưu định danh ổn định và loại tác nhân: người dùng, tích hợp hoặc tác vụ hệ thống. Tên hiển thị có thể đổi, vì vậy không nên chỉ lưu một chuỗi tên.
Hành động và đối tượng
Dùng động từ nghiệp vụ như “duyệt báo giá” hoặc “đổi người phụ trách”, kèm loại và mã hồ sơ liên quan.
Thời điểm và ngữ cảnh
Ghi thời gian thống nhất, nguồn thao tác và mã liên kết khi cần đối chiếu với quy trình nền hoặc tích hợp.
Giá trị trước và sau
Lưu phần thay đổi cần thiết, không sao chép toàn bộ hồ sơ vào mỗi sự kiện. Trường nhạy cảm có thể chỉ ghi rằng giá trị đã đổi.
Ví dụ, “Lan cập nhật đơn hàng” còn quá mơ hồ. Bản ghi hữu ích hơn là: người dùng nội bộ đổi trạng thái đơn từ “chờ xác nhận” sang “đã xác nhận” qua trang chi tiết đơn, tại một thời điểm cụ thể. Nếu thay đổi do đồng bộ từ CRM, tác nhân phải thể hiện là tích hợp và có mã để truy ngược lần chạy.
Quy trình thiết kế nhật ký hoạt động
Bước 1: Liệt kê tình huống cần đối chiếu
Thu thập câu hỏi thật từ hỗ trợ, vận hành, sales và quản lý. Ghi rõ hồ sơ nào, thay đổi nào và ai cần xem câu trả lời.
Bước 2: Lập danh mục sự kiện
Đặt tên sự kiện theo hành động nghiệp vụ, xác định lúc nào phát sinh và dữ liệu tối thiểu đi kèm. Tránh tên chung như “record_updated”.
Bước 3: Chốt quy tắc lưu thay đổi
Với từng trường, quyết định lưu giá trị trước và sau, chỉ lưu dấu hiệu đã đổi, hay không đưa vào lịch sử.
Bước 4: Thiết kế quyền xem và thời hạn
Xác định vai trò nào được xem nhóm sự kiện nào, phạm vi hồ sơ và thời điểm dữ liệu hết nhu cầu sử dụng.
Bước 5: Viết test case từ câu hỏi ban đầu
Tạo thay đổi bằng giao diện, API, tác vụ nền và tích hợp. Kiểm tra thứ tự, người thực hiện, giá trị hiển thị, quyền xem và liên kết về hồ sơ.
Không sao chép dữ liệu nhạy cảm vào mọi sự kiện
Giá trị trước và sau giúp xử lý nhiều tình huống, nhưng cũng làm tăng số nơi chứa dữ liệu. Mật khẩu, token, thông tin xác thực và dữ liệu thanh toán không được đưa vào lịch sử. Với số điện thoại, địa chỉ hoặc giá trị hợp đồng, đội cần quyết định rõ ai được xem, có cần che một phần hay chỉ cần ghi “đã thay đổi”.
Quy tắc này nên nối với thiết kế phân quyền cho sản phẩm nội bộ và xóa dữ liệu an toàn. Quyền sửa một hồ sơ không tự động đồng nghĩa với quyền xem toàn bộ lịch sử của hồ sơ đó.
Giao diện phải giúp truy ngược nhanh, không chỉ liệt kê
Dòng thời gian nên dùng câu dễ hiểu, đặt thay đổi quan trọng lên trước và liên kết về đối tượng liên quan. Người dùng cần lọc theo loại sự kiện, người thực hiện hoặc khoảng thời gian khi lịch sử dài. Giá trị trước và sau nên mở khi cần thay vì chiếm toàn bộ màn hình.
| Nhu cầu | Cách hiển thị phù hợp | Điều cần tránh |
|---|---|---|
| Xem nhanh hồ sơ | Dòng thời gian ngắn, ưu tiên thay đổi trạng thái và người phụ trách. | Hiển thị mọi sự kiện nền ngang nhau. |
| Đối chiếu một thay đổi | Mở chi tiết giá trị trước và sau, tác nhân và nguồn thao tác. | Chỉ ghi “đã cập nhật” mà không có trường thay đổi. |
| Xử lý sự cố | Có mã liên kết đến dữ liệu kỹ thuật cho người được phép. | Đưa stack trace hoặc payload nội bộ ra giao diện chung. |
Checklist nghiệm thu nhật ký hoạt động
Dữ liệu sự kiện
- Mỗi sự kiện có tác nhân, hành động, đối tượng và thời điểm nhất quán.
- Thay đổi quan trọng hiển thị đúng giá trị trước và sau theo đặc tả.
- Sự kiện từ giao diện, API, tích hợp và tác vụ nền phân biệt được nguồn.
- Thao tác thất bại không bị ghi như một thay đổi đã hoàn tất.
Quyền và khả năng sử dụng
- Người dùng chỉ thấy sự kiện thuộc hồ sơ và trường dữ liệu họ được phép xem.
- Dữ liệu bí mật không xuất hiện trong chi tiết hoặc nội dung tìm kiếm.
- Bộ lọc, thứ tự thời gian và liên kết về hồ sơ hoạt động trên mobile.
- Quy tắc lưu trữ và xử lý dữ liệu hết hạn được kiểm thử.
Phạm vi đầu tiên nên gọn và kiểm tra được
Phiên bản đầu không cần ghi mọi thao tác. Hãy bắt đầu với các thay đổi ảnh hưởng đến cam kết với khách hàng, quyền truy cập, tiền, trạng thái xử lý và người chịu trách nhiệm. Một danh mục sự kiện nhỏ nhưng có cấu trúc rõ sẽ hữu ích hơn một kho dữ liệu lớn mà đội không thể đọc hoặc quản lý.
Auranium có thể cùng đội sản phẩm xác định danh mục sự kiện, dữ liệu cần lưu, quyền xem và bộ test case trước khi đưa chức năng này vào kế hoạch Product Development.
