Một trong những sự cố khó phát hiện nhất là website vẫn mở bình thường nhưng không còn tạo lead hoặc đơn hàng. Trang chủ trả HTTP 200, banner vẫn hiển thị, người quản trị nhìn qua không thấy lỗi; trong khi form không gửi email, checkout thất bại hoặc dữ liệu không vào CRM.
Đây là lý do doanh nghiệp cần phân biệt availability monitoring với business transaction monitoring.
Vì sao website online vẫn có thể mất lead?
Một hành trình chuyển đổi thường đi qua nhiều thành phần; chỉ cần một mắt xích lỗi, người dùng có thể thấy thông báo thành công nhưng doanh nghiệp không nhận được dữ liệu.
landing page → JavaScript → form → API → email/SMTP hoặc CRM → automation → người tiếp nhận.
Những lỗi phổ biến gồm:
- form render nhưng submit trả lỗi;
- CAPTCHA hoặc anti-spam chặn nhầm;
- SMTP hết quota hoặc xác thực thất bại;
- webhook không gọi được CRM;
- API trả 200 nhưng payload không được xử lý;
- checkout lỗi ở bước thanh toán;
- tracking mất event nên đội marketing tưởng không có chuyển đổi;
- lead vào CRM nhưng routing sai owner;
- cache/CDN giữ JavaScript cũ sau cập nhật.
Bài các lỗi website thường gặp có thể dùng để mở rộng runbook theo từng dạng lỗi kỹ thuật.
Monitoring form nên kiểm tra đến đâu?
Mức cơ bản chỉ xác nhận endpoint trả phản hồi. Mức tốt hơn kiểm tra toàn bộ chuỗi:
- tải trang;
- xác nhận form có thể tương tác;
- điền dữ liệu test;
- submit;
- kiểm tra phản hồi frontend;
- xác nhận request phía server;
- xác nhận lead xuất hiện ở điểm tiếp nhận;
- xóa hoặc gắn nhãn dữ liệu test theo quy trình.
Không phải website nào cũng nên gửi form test liên tục trên production. Nếu form kích hoạt SMS, email marketing, hóa đơn hoặc automation tốn phí, cần tạo test route, tài khoản sandbox hoặc cơ chế loại trừ dữ liệu tổng hợp.
Checkout monitoring cần tránh tạo đơn hàng thật ngoài ý muốn
Với ecommerce, hành trình quan trọng có thể gồm tìm sản phẩm → thêm giỏ → checkout → chọn phương thức thanh toán. Nếu payment provider có sandbox, nên dùng môi trường test. Nếu không, có thể thiết kế kiểm tra đến điểm trước giao dịch tài chính hoặc sử dụng synthetic order đã được nghiệp vụ cho phép.
Mục tiêu không phải tạo traffic giả mà là xác minh chức năng quan trọng vẫn hoạt động.
Đừng quên SMTP, CRM và các dependency sau form
Một form thành công trên giao diện không chứng minh lead đã đến người bán hàng. Cần quan sát ít nhất một tín hiệu ở downstream:
- delivery log của email;
- webhook status;
- API response;
- record mới trong CRM;
- hàng đợi xử lý;
- alert khi backlog tăng;
- chênh lệch bất thường giữa submit và lead received.
OWASP Logging Cheat Sheet xem application logging không chỉ hữu ích cho bảo mật mà còn cho business process monitoring như transaction và sales-process abandonment. Vì vậy log có cấu trúc tốt là một phần của khả năng phát hiện mất lead.
Nên đặt alert dựa trên lỗi hay dựa trên sự im lặng?
Cả hai.
Alert lỗi trực tiếp có thể dựa trên HTTP 5xx, exception, failed webhook hoặc payment error. Nhưng có những sự cố không sinh lỗi rõ ràng. Khi đó cần absence alert: ví dụ một website vốn có conversion ổn định nhưng đột ngột không có form submit trong khoảng thời gian bất thường.
Không nên áp một ngưỡng cố định cho mọi doanh nghiệp. Cần dựa trên baseline theo giờ/ngày, mùa vụ và lượng traffic.
Phân loại mức độ ảnh hưởng
Một cách đơn giản:
- P1: toàn bộ checkout hoặc form chính không hoạt động.
- P2: một kênh lead hoặc một phương thức thanh toán lỗi.
- P3: tracking/notification lỗi nhưng dữ liệu gốc vẫn được lưu.
- P4: cảnh báo xu hướng hoặc lỗi không chặn chuyển đổi.
Severity phải gắn với tác động kinh doanh, không chỉ mức độ “kỹ thuật trông có vẻ nghiêm trọng”.
Runbook khi phát hiện mất lead
Khi alert xuất hiện, nên:
- xác minh bằng luồng test được phép;
- xác định thời điểm bắt đầu;
- kiểm tra thay đổi gần nhất;
- đối chiếu frontend, server log, API và hệ thống tiếp nhận;
- cô lập lỗi theo dependency;
- dùng workaround nếu có;
- phục hồi chức năng;
- kiểm tra dữ liệu có bị thất lạc hay cần reprocess;
- ghi nguyên nhân và hành động phòng tái diễn.
Nếu sự cố xuất hiện ngay sau cập nhật, hãy liên hệ với quy trình bảo trì website có backup, kiểm thử và rollback thay vì sửa trực tiếp nhiều thay đổi trên production cùng lúc.
Checklist tối thiểu cho website tạo lead
- Form chính được kiểm tra định kỳ.
- Có test data hoặc sandbox rõ ràng.
- SMTP/webhook/API có log.
- CRM có đối chiếu số lead nhận được.
- Checkout có synthetic flow phù hợp.
- Alert có owner.
- Có kênh dự phòng khi form lỗi.
- Có quy trình reprocess lead nếu dữ liệu bị kẹt.
- Tracking được QA nhưng không dùng tracking làm nguồn duy nhất xác nhận đơn/lead.
Một dịch vụ chăm sóc website có thể xử lý nhiều hạng mục nội dung và kỹ thuật, nhưng với website phụ thuộc trực tiếp vào form/checkout, nên bổ sung monitoring theo chính hành trình tạo doanh thu. Khi đó câu hỏi không còn là “website có online không?” mà là “người dùng có hoàn thành được việc mà website được xây để phục vụ không?”
Đọc thêm trong cụm Managed Website: Website Monitoring; Uptime website; Dịch vụ quản trị và vận hành website.
Khi lỗi nằm ở email chứ không phải form
Nếu submission đã tới application nhưng notification không tới mailbox, chuyển sang Email Deliverability cho website để kiểm tra SMTP/provider, bounce, reject và inbox placement. Nếu lỗi liên quan sender authentication hoặc DNS TXT, xem SPF, DKIM, DMARC. Toàn bộ lớp domain, DNS, certificate và email được tổ chức trong Domain, DNS & Email Infrastructure Operations.
Từ mất lead sang Integration Reliability
Khi form đã submit nhưng dữ liệu đi qua API, webhook, queue hoặc CRM không đầy đủ, vấn đề thuộc lớp Website Integration Reliability. Để tìm record thiếu, trùng hoặc lệch trạng thái giữa website với CRM/ERP/payment, dùng Data Reconciliation thay vì chỉ nhìn frontend hoặc HTTP status.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
