1. 11:05 24/08/2026
Một ứng dụng có thể vẫn hoạt động theo nghĩa máy chủ trả về mã 200, nhưng người dùng lại phải chờ quá lâu, không nhận được email hoặc thấy đơn hàng ở trạng thái không rõ ràng. Đây là lý do observability, hay khả năng quan sát hệ thống, quan trọng hơn việc chỉ kiểm tra ứng dụng còn chạy hay không.
Observability giúp đội ngũ trả lời ba câu hỏi: chuyện gì đang xảy ra, vấn đề bắt đầu từ đâu và ảnh hưởng đến ai. Thay vì đoán qua vài dòng log rời rạc, nhóm phát triển có thể kết nối dữ liệu từ giao diện, API, hàng đợi và cơ sở dữ liệu để tìm nguyên nhân nhanh hơn.
Ba loại dữ liệu nên có
- Logs: Ghi lại sự kiện có ý nghĩa dưới dạng có cấu trúc, chẳng hạn thời gian, mức độ nghiêm trọng, tên dịch vụ, mã yêu cầu và kết quả xử lý. Log dạng JSON thường dễ tìm kiếm hơn văn bản tự do. Không nên chỉ ghi nội dung như lỗi xảy ra, mà nên bổ sung thao tác nào thất bại và có thể xử lý lại hay không.
- Metrics: Theo dõi các chỉ số tổng hợp như tỷ lệ lỗi, thời gian phản hồi, số yêu cầu trong hàng đợi, mức sử dụng CPU và số kết nối cơ sở dữ liệu. Nên quan sát cả độ trễ trung vị lẫn các phân vị cao như p95 để nhận ra nhóm người dùng đang chờ lâu.
- Traces: Theo dõi một yêu cầu xuyên qua nhiều thành phần. Một thao tác thanh toán có thể đi từ trình duyệt đến API, dịch vụ đơn hàng, cổng thanh toán và hệ thống gửi email. Trace giúp xác định bước nào chiếm nhiều thời gian nhất.
Cách triển khai thực tế
Ngay tại cổng API, hãy tạo một request ID nếu yêu cầu chưa có mã định danh. Mã này cần được truyền qua các dịch vụ nội bộ và xuất hiện trong log của từng bước. Khi người dùng báo lỗi, đội hỗ trợ có thể xin mã yêu cầu thay vì yêu cầu họ gửi toàn bộ ảnh chụp màn hình.
Ví dụ, người dùng bấm đặt hàng và nhận thông báo thất bại. Dashboard cho thấy tỷ lệ lỗi API không tăng đáng kể, nhưng trace của request lại chỉ ra dịch vụ thanh toán mất nhiều thời gian rồi hết hạn. Log của dịch vụ đơn hàng cho biết giao dịch chưa được xác nhận, còn hàng đợi email vẫn bình thường. Từ đó, nhóm có thể tập trung kiểm tra kết nối với cổng thanh toán thay vì sửa nhầm phần giao diện.
Cảnh báo cũng cần được thiết kế cẩn thận. Một cảnh báo tốt nên gắn với triệu chứng ảnh hưởng đến người dùng, có ngưỡng hợp lý trong một khoảng thời gian và liên kết đến hướng dẫn xử lý. Nếu gửi cảnh báo cho mọi ngoại lệ nhỏ, đội ngũ sẽ dần bỏ qua cả những cảnh báo quan trọng. Mỗi cảnh báo nên trả lời được: ai nhận, cần kiểm tra đâu và bước giảm thiểu đầu tiên là gì.
Đừng quên quyền riêng tư
Log không được chứa mật khẩu, token truy cập, dữ liệu thẻ hoặc thông tin cá nhân đầy đủ nếu không cần thiết. Hãy che bớt dữ liệu nhạy cảm, giới hạn quyền truy cập, đặt thời gian lưu trữ phù hợp và ghi lại hoạt động truy cập hệ thống quan sát. Việc thêm observability không nên tạo ra một kho dữ liệu rủi ro mới.
Lộ trình bắt đầu gọn nhẹ
- Chọn một luồng quan trọng như đăng nhập hoặc thanh toán.
- Chuẩn hóa log và bổ sung request ID.
- Đo tỷ lệ lỗi, độ trễ và tình trạng tài nguyên chính.
- Thêm trace cho các lời gọi giữa dịch vụ.
- Viết runbook cho vài cảnh báo có tác động lớn.
- Kiểm tra dữ liệu quan sát trong môi trường thử nghiệm trước khi đưa lên sản xuất.
Observability không phải là thu thập càng nhiều dữ liệu càng tốt. Mục tiêu là tạo ra thông tin đủ rõ, đúng ngữ cảnh và có thể hành động, để đội ngũ phát hiện sự cố sớm, giảm thời gian chẩn đoán và cải thiện sản phẩm dựa trên bằng chứng thay vì phỏng đoán.