Giám sát hệ thống phải trả lời được câu hỏi

1. Bắt đầu từ câu hỏi, không từ dashboard

Hãy viết ra những điều nhóm thật sự cần biết, theo đúng thứ tự các câu hỏi được đặt ra. Dịch vụ có đang phục vụ được người dùng không? Nếu không thì phần nào, từ lúc nào? Nguyên nhân đến từ bản phát hành vừa rồi, từ lưu lượng, hay từ một dịch vụ phụ thuộc? Tình hình đang xấu thêm không? Hành động nào giúp được ngay?

Mỗi câu hỏi kéo theo một tín hiệu và một cách hiển thị cụ thể. Đó là đề bài tốt hơn nhiều so với “thiết lập giám sát”, và nó cũng cho thấy rõ trong số các biểu đồ hiện có, cái nào chưa từng giúp ai ra quyết định.

• Hành trình người dùng quan trọng có đang hoạt động, đo theo cách người dùng cảm nhận?
• Thành phần hoặc dịch vụ phụ thuộc nào đã suy giảm, và bắt đầu từ thời điểm nào?
• Vấn đề khởi phát cùng một lần triển khai, một thay đổi cấu hình hay một biến động lưu lượng?
• Còn lại bao nhiêu ngân sách lỗi hoặc dư địa công suất?
• Hành động an toàn nhất lúc này là gì: rollback, tăng tài nguyên, tắt một tính năng hay chờ thêm?

Một dashboard ba tháng qua không giúp ai ra quyết định thì không phải lưới an toàn. Nó là tiếng ồn khiến những bảng thật sự hữu ích khó tìm hơn.

2. Đo điều người dùng cảm nhận trước điều máy chủ báo cáo

CPU và bộ nhớ cho biết một máy đang chịu tải thế nào, không cho biết khách hàng có đặt được đơn hay không. Hãy bắt đầu từ đường đi của request: bao nhiêu request thất bại, các request chậm chậm đến mức nào, lượng việc đang đến là bao nhiêu và hệ thống đã đầy đến đâu. Bốn tín hiệu đó trả lời được phần lớn câu hỏi đầu tiên.

Sau đó, biến các hành trình quan trọng thành chỉ số có mục tiêu. “99% lượt gửi đơn hàng thành công dưới hai giây, tính trong 30 ngày” là một câu mà chủ sở hữu nghiệp vụ và kỹ sư đều hiểu như nhau. Nó cũng tạo ra một ngân sách: mức lỗi nào còn chấp nhận được trước khi nhóm tạm dừng làm tính năng để xử lý độ tin cậy.

• Lưu lượng: số request theo từng endpoint và loại client, để bất thường có bối cảnh.
• Lỗi: tỷ lệ thất bại chia theo nguyên nhân, tách lỗi phía client khỏi lỗi phía server.
• Độ trễ: đo ở phân vị thứ 95 và 99, không bao giờ dùng giá trị trung bình.
• Mức bão hoà: độ dài hàng đợi, connection pool, dung lượng đĩa và số worker còn rảnh.
• Sự kiện nghiệp vụ: đơn được tạo, thanh toán được xác nhận, tin nhắn được gửi — chính kết quả mà hệ thống tồn tại vì nó.

3. Log, metric và trace làm ba việc khác nhau

Ba loại này thường bị coi là thay thế được cho nhau, và kết quả là một hệ thống lưu rất nhiều nhưng giải thích rất ít. Metric rẻ để lưu lâu và giỏi ở việc chỉ ra có thứ gì đã thay đổi. Log mang chi tiết của một sự kiện. Trace cho thấy một request đã đi qua những dịch vụ nào và thời gian của nó nằm ở đâu.

Giá trị đến từ khả năng đi qua lại giữa ba loại. Một cảnh báo độ trễ phải dẫn tới trace của các request chậm, và một trace phải dẫn tới log của bước bị lỗi. Điều đó chỉ hoạt động khi request mang theo một mã tương quan từ chặng đầu tiên, và khi mọi tín hiệu đều được gắn cùng tên dịch vụ, môi trường và phiên bản.

• Metric: ít chiều dữ liệu, lưu dài hạn, dùng cho cảnh báo và phân tích xu hướng.
• Log: ghi theo trường có cấu trúc thay vì câu văn, để lọc được chứ không phải đọc từng dòng.
• Trace: lấy mẫu có chủ đích, giữ lại các request chậm và lỗi thay vì lấy mẫu ngẫu nhiên.
• Bối cảnh dùng chung: mã request, tên dịch vụ, môi trường, phiên bản phát hành và khách hàng trên mọi tín hiệu.
• Thời gian lưu trữ đặt theo mức hữu dụng và chi phí, quyết định một lần thay vì để mặc định giữ mãi.

Nếu chẩn đoán một sự cố vẫn phải SSH vào máy chủ thì phần việc quan sát chưa xong — và người cần câu trả lời nhất thường lại không có quyền truy cập đó.

4. Cảnh báo theo triệu chứng, chỉ gọi người khi cần người

Một cảnh báo chỉ có một việc: đưa một người tới vấn đề mà họ có thể xử lý. Mọi thứ phát ra mà không kèm hành động bắt buộc đều dạy cho nhóm thói quen bỏ qua kênh đó, và một kênh bị bỏ qua sẽ thất bại trong im lặng đúng vào lúc quan trọng nhất.

Nguyên tắc thực dụng là gọi người theo triệu chứng mà người dùng nhận thấy, còn nguyên nhân thì đưa vào nơi được xem định kỳ chứ không đổ vào điện thoại. Ổ đĩa gần đầy lúc 3 giờ sáng là một ticket. 5% khách hàng không đặt được đơn là một cuộc gọi. Mỗi cảnh báo gọi người nên dẫn tới một runbook ngắn nêu nguyên nhân thường gặp và những bước kiểm tra đầu tiên.

• Mọi cảnh báo gọi người phải nêu ảnh hưởng tới người dùng, không chỉ chỉ số đã vượt ngưỡng.
• Mọi cảnh báo gọi người phải có chủ sở hữu, runbook và bước tiếp theo rõ ràng.
• Cảnh báo mức nhắc nhở và xu hướng công suất đi vào hàng chờ xem xét, không vào điện thoại trực.
• Cảnh báo dựa trên điều kiện duy trì trong một khoảng thời gian, để một đỉnh đơn lẻ không đánh thức ai.
• Theo dõi tỷ lệ cảnh báo thật sự cần hành động, và xoá những cảnh báo chưa bao giờ cần.

5. Giám sát cần người sở hữu và một nhịp xem lại

Hệ thống giám sát mục dần vì hệ thống thay đổi nhanh hơn phần đo đạc của nó. Một dịch vụ mới lên mà không có metric, một trường bị đổi tên làm hỏng dashboard, một ngưỡng đặt theo lưu lượng năm ngoái phát cảnh báo liên tục. Không có nhịp xem lại, nhóm sẽ phát hiện tất cả những điều đó giữa lúc có sự cố.

Hãy coi việc đo đạc là một phần của tiêu chí hoàn thành cho mọi tính năng có rủi ro, và giữ một buổi xem lại ngắn mỗi tháng: cảnh báo nào đã phát, cái nào hữu ích, cái nào cần đổi. Sau mỗi sự cố thật, hãy hỏi hệ thống giám sát có kể được câu chuyện hay có ai phải phỏng đoán — câu trả lời đó thường là kết quả giá trị nhất của buổi xem lại.

• Dịch vụ mới lên production cùng bộ tín hiệu, dashboard và cảnh báo chuẩn ngay từ ngày đầu.
• Dashboard và cảnh báo được xem lại mỗi tháng và mạnh tay lược bỏ.
• Mỗi lần review sự cố đều hỏi: điều gì đã giúp phát hiện sớm hơn?
• Ngưỡng được đặt lại khi mô hình lưu lượng thay đổi đáng kể.
• Mỗi dịch vụ có một người sở hữu phần giám sát được nêu tên rõ ràng.

Mục tiêu không phải nhìn thấy nhiều hơn. Mục tiêu là người đang trực có thể tự đi từ “có thứ gì đang sai” đến “đây là việc tôi sẽ làm” — và nhóm biết vấn đề trước khi khách hàng phản ánh.