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 thay vì từ dashboard

Hãy viết ra những điều đội ngũ thật sự cần biết, theo đúng thứ tự chúng được đặt ra trong thực tế. 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ừ thời điểm 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 có đang xấu thêm không? Và lúc này hành động nào sẽ giúp được?

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 rõ ràng hơn nhiều so với “thiết lập giám sát”, đồng thời cũng chỉ ra ngay trong số biểu đồ đang có, cái nào chưa từng giúp ai đưa ra quyết định.

• Các hành trình người dùng quan trọng có đang hoạt động, đo theo đúng cách người dùng cảm nhận?
• Thành phần hay dịch vụ phụ thuộc nào đã suy giảm và suy giảm từ khi nào?
• Vấn đề xuất hiện cùng lúc với một lần triển khai, một thay đổi cấu hình hay một đợt tăng lưu lượng?
• Còn bao nhiêu ngân sách lỗi và còn bao nhiêu dư địa công suất?
• Lúc này hành động an toàn nhất 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 liền không giúp ai ra quyết định thì không còn là lưới an toàn. Nó trở thành tiếng ồn, khiến những bảng thật sự hữu ích khó tìm hơn.

2. Đo cảm nhận của người dùng trước, chỉ số máy chủ sau

CPU và bộ nhớ cho biết một máy đang chịu tải ra sao, nhưng 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, những request chậm thì chậm đến mức nào, lượng việc đang đổ vào là bao nhiêu và hệ thống đã đầy tới đâu. Bốn tín hiệu đó trả lời được gần hết câu hỏi đầu tiên.

Sau đó, hãy chuyể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 phát biểu mà cả người phụ trách nghiệp vụ lẫn kỹ sư đều hiểu giống nhau. Nó cũng tạo ra một ngân sách rõ ràng: lỗi đến mức nào thì đội phải tạm dừng làm tính năng để quay lại lo độ tin cậy.

• Lưu lượng: số request theo từng endpoint và từng loại client, để một bất thường luôn có bối cảnh đi kèm.
• 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ị 95 và 99, không 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 là những kết quả mà hệ thống sinh ra để phục vụ.

3. Log, metric và trace đảm nhiệm ba vai trò khác nhau

Ba loại dữ liệu này thường bị xem 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 có chi phí lưu trữ thấp, phù hợp để giữ lâu và giỏi trong việc chỉ ra có điều gì vừa 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ó tiêu vào đâu.

Giá trị nằm ở khả năng đi qua lại giữa ba loại dữ liệu. Một cảnh báo độ trễ phải dẫn được tới trace của những request chậm, và trace phải dẫn được tới log của bước bị lỗi. Điều đó chỉ khả thi khi request mang theo một mã tương quan ngay từ chặng đầu, 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 để cảnh báo và quan sát xu hướng.
• Log: ghi theo trường có cấu trúc thay vì viết thành câu, để lọc được thay vì phải đọc từng dòng.
• Trace: lấy mẫu có chủ đích, giữ lại những 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, hiện diện trên mọi tín hiệu.
• Thời gian lưu: quyết định một lần dựa trên mức hữu dụng và chi phí, thay vì để mặc định giữ mãi.

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

4. Cảnh báo theo triệu chứng và chỉ gọi người khi thật sự cần

Một cảnh báo chỉ có duy nhất một nhiệm vụ: đưa một người đến đúng vấn đề mà họ có thể xử lý. Mọi thông báo phát ra mà không đòi hỏi hành động nào đều đang tập cho cả đội thói quen bỏ qua kênh đó, và một kênh bị bỏ qua sẽ im lặng thất bại đú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 xét định kỳ thay vì đổ thẳ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. Và mọi cảnh báo gọi người đều phải dẫn tới một runbook ngắn gọn, gồm nguyên nhân thường gặp và những bước kiểm tra đầu tiên.

• Cảnh báo gọi người phải mô tả được ảnh hưởng tới người dùng, không chỉ báo một chỉ số đã vượt ngưỡng.
• Cảnh báo gọi người phải có chủ sở hữu, có runbook và có 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 người trực.
• Cảnh báo dựa trên điều kiện phải 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, rồi loại bỏ những cảnh báo chưa bao giờ cần đến.

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

Hệ thống giám sát xuống cấp dần theo thời gian, bởi 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 nào. 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 nay báo động liên tục. Nếu không có nhịp xem lại, đội ngũ sẽ phát hiện tất cả những điều đó ngay giữa lúc sự cố đang diễn ra.

Hãy xem phần đo đạc là một mục trong tiêu chí hoàn thành của mọi tính năng có rủi ro, đồng thời duy trì một buổi xem lại ngắn mỗi tháng: tháng này cảnh báo nào đã phát, cái nào hữu ích, cái nào cần điều chỉnh. Sau mỗi sự cố thật, hãy hỏi thêm một câu: hệ thống giám sát có kể được câu chuyện hay vẫn phải có người ngồi phỏng đoán? Câu trả lời đó thường là giá trị lớn nhất thu được từ buổi review.

• Dịch vụ mới lên production có sẵn 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 dạn lược bỏ.
• Mọi buổi review sự cố đều đặt câu hỏi: điều gì có thể giúp phát hiện sớm hơn?
• Ngưỡng được thiết lập 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, gọi được tên cụ thể.

Đích đến không phải là nhìn thấy nhiều hơn, mà là người đang trực tự đi được từ “có điều gì đó đang sai” đến “đây là việc tôi sẽ làm”, và đội ngũ nắm được tình hình trước khi khách hàng gọi tới.