INFOCHIEF ACADEMY · IT ADMINISTRATOR KNOWLEDGE SERIES

Hệ thống đang chậm hay sắp gặp sự cố? Chọn chỉ số giám sát hạ tầng nào?

Chọn chỉ số từ trải nghiệm dịch vụ, rồi nối với tải, lỗi và giới hạn tài nguyên. Đường cơ sở, cảnh báo có hành động và dữ liệu điều tra giúp đội IT nhận biết sự suy giảm mà bảng trạng thái thiết bị có thể bỏ sót.

Biên soạn: Infochief Academy · Chuyên đề: Quản trị vận hành IT

← Trở về thư viện bài viết

Minh họa biên tập: nhóm vận hành phân tích biểu đồ độ trễ, tải và tín hiệu hệ thống.

Người dùng báo hệ thống chậm, trong khi bảng giám sát vẫn xanh: CPU thấp, bộ nhớ còn trống và máy chủ không mất kết nối. Hai thông tin ấy không nhất thiết mâu thuẫn. Hạ tầng có thể chưa vượt ngưỡng được đặt, nhưng một giao dịch quan trọng đang chờ ở cơ sở dữ liệu, dịch vụ định danh hoặc đường tích hợp.

Chọn chỉ số giám sát vì thế không bắt đầu từ việc thiết bị cung cấp bao nhiêu biểu đồ. Nó bắt đầu từ câu hỏi doanh nghiệp muốn nhận biết điều gì và cần hành động sớm đến mức nào. Chỉ số có ích phải giúp phân biệt trải nghiệm đang suy giảm, năng lực đang bị ép và một cơ chế có khả năng gây sự cố.

Đo dịch vụ từ nơi người dùng thực sự trải nghiệm

Trước hết cần xác định những hành trình quan trọng: đăng nhập, tra cứu, ghi nhận đơn hàng hoặc hoàn thành thanh toán. Với mỗi hành trình, chọn điểm đo và điều kiện thành công. Một phản hồi HTTP thành công không luôn có nghĩa nghiệp vụ thành công; ứng dụng có thể trả trang lỗi bên trong một phản hồi kỹ thuật hợp lệ.

Đo từ bên ngoài dịch vụ giúp phát hiện vấn đề mà chỉ số máy chủ bỏ sót. Có thể dùng giao dịch tổng hợp với dữ liệu thử phù hợp, hoặc số liệu từ yêu cầu thực. Hai cách bổ sung cho nhau: kiểm tra tổng hợp tạo nhịp đo ổn định, còn dữ liệu thực phản ánh trải nghiệm trong các điều kiện sử dụng đa dạng.

Cần ghi rõ phạm vi đo. Một kiểm tra từ mạng nội bộ không đại diện cho người dùng ở chi nhánh; một giao dịch đơn giản không đại diện cho báo cáo cuối tháng. Khi đọc biểu đồ, đội phải biết chỉ số phản ánh nhóm người dùng và loại công việc nào trước khi kết luận toàn hệ thống ổn.

Kiến thức quản trị vận hành IT có thể được vận dụng để nối kiểm tra hạ tầng với kiểm tra dịch vụ. Mục tiêu là nhìn được cả thành phần và chuỗi sử dụng, thay vì chọn một phía rồi kỳ vọng nó giải thích mọi vấn đề.

Kết hợp độ trễ, tải, lỗi và mức bão hòa

Một cách tổ chức phổ biến trong thực hành SRE là xem đồng thời độ trễ, lưu lượng, lỗi và mức bão hòa. Độ trễ cho biết công việc mất bao lâu; lưu lượng cho biết hệ thống đang nhận bao nhiêu công việc; lỗi phản ánh kết quả không đạt; bão hòa phản ánh tài nguyên hoặc hàng đợi đang bị ép đến đâu.

Các nhóm này cần được cụ thể hóa theo dịch vụ. Với ứng dụng giao dịch, tải có thể là yêu cầu mỗi giây hoặc giao dịch hoàn thành. Với xử lý theo lô, khối lượng tồn đọng và thời gian hoàn tất có thể quan trọng hơn. Chọn đơn vị đúng giúp đội tránh đọc “ít yêu cầu” như trạng thái tốt khi hệ thống đã không còn nhận được yêu cầu.

Độ trễ trung bình dễ che nhóm người dùng bị chậm nhiều. Các phân vị như p95 có thể cho thấy phần đuôi phân bố: trong tập đo phù hợp, khoảng 95% giá trị nằm không cao hơn mức đó. Nhưng cần đủ mẫu, tách đúng loại giao dịch và hiểu cách công cụ tổng hợp; không nên lấy trung bình các phân vị rồi xem đó là phân vị chung.

Nhóm tín hiệu	Ví dụ theo dịch vụ	Câu hỏi hành động
Độ trễ	Thời gian hoàn thành giao dịch theo nhóm người dùng	Chậm ở toàn bộ luồng hay một bước phụ thuộc?
Tải và kết quả	Yêu cầu đến, giao dịch hoàn tất, tỷ lệ lỗi	Nhu cầu tăng hay hệ thống đang từ chối công việc?
Bão hòa	Hàng đợi, phiên kết nối, thời gian chờ I/O	Tài nguyên nào đang giới hạn năng lực?
Xu hướng rủi ro	Dung lượng tăng, chứng thư gần hạn, tác vụ trễ	Còn bao lâu để can thiệp trước khi có tác động?

Không cần mọi tín hiệu đều tạo cảnh báo tức thời. Một số phục vụ điều tra, một số phục vụ lập kế hoạch và một số cần đánh thức người trực. Phân loại mục đích từ đầu giúp tránh biến toàn bộ hệ thống đo thành nguồn thông báo liên tục.

Dùng đường cơ sở để đọc những bất thường

Một mức sử dụng có thể bình thường với hệ thống này nhưng đáng lo ở hệ thống khác. Cần đối chiếu với khung giờ, ngày làm việc, mùa cao điểm và các thay đổi triển khai. Đường cơ sở nên phản ánh các chu kỳ sử dụng có ý nghĩa, không chỉ một tuần thuận tiện để lấy dữ liệu.

Ngưỡng cảnh báo cũng cần xét thời gian can thiệp. Nếu mở rộng lưu trữ mất nhiều ngày, cảnh báo dựa trên tốc độ tăng và thời gian dự kiến cạn có thể hữu ích hơn chỉ một mức phần trăm. Nếu hàng đợi tăng nhanh trong vài phút, cần nhận biết trước khi giao dịch vượt thời gian chấp nhận.

Tránh áp ngưỡng CPU hoặc bộ nhớ cố định cho mọi hệ thống. CPU thấp có thể đi cùng chờ khóa hoặc I/O; bộ nhớ được dùng nhiều có thể là cache hợp lệ. Chỉ số tài nguyên cần được đọc cùng thời gian chờ, kết quả dịch vụ và kiến trúc, không dùng riêng để quyết định khởi động lại hoặc mua thêm thiết bị.

Khi thay đổi phần mềm, công cụ đo hoặc cách lấy mẫu, phải đánh dấu trên biểu đồ. Một bước nhảy có thể do dữ liệu đổi cách tính chứ không phải hiệu suất xấu đi. Nếu không quản lý ngữ cảnh, đội sẽ điều tra một hiện tượng do chính hệ thống đo tạo ra.

Liên hệ với quản lý dịch vụ IT, những đường cơ sở này cần được nối với yêu cầu dịch vụ và lịch thay đổi. Đội kỹ thuật có thể phát hiện xu hướng; chủ dịch vụ giúp xác định xu hướng đó đã tác động đến cam kết nào và cần ưu tiên ra sao.

Cảnh báo phải có người nhận và bước tiếp theo

Một cảnh báo hiệu quả cần mô tả điều gì đang xảy ra, dịch vụ nào bị ảnh hưởng, bằng chứng ở đâu và người nhận nên làm gì trước. Chỉ ghi “CPU cao” thường khiến kỹ sư phải tự tìm lại bối cảnh. Cảnh báo gắn đúng thành phần, dịch vụ và hướng dẫn sẽ giảm thời gian chuyển từ thông báo sang điều tra.

Cần phân biệt tín hiệu cần phản ứng ngay với xu hướng có thể xử lý trong giờ làm việc. Đánh thức người trực cho những việc không có hành động tức thời tạo mệt mỏi và làm các cảnh báo quan trọng bị bỏ qua. Ngược lại, chỉ đưa một lỗi đang chặn nghiệp vụ vào báo cáo ngày có thể làm đội nhận biết quá muộn.

Để giảm nhiễu, có thể xem xét thời gian duy trì điều kiện, việc gom sự kiện cùng nguyên nhân và lịch bảo trì đã được phê duyệt. Nhưng cơ chế giảm thông báo phải có giới hạn: không được vô tình che một dịch vụ quan trọng trong suốt cửa sổ bảo trì chỉ vì một thành phần đang được thao tác.

Vai trò giám sát đội IT phù hợp với việc rà đường nhận cảnh báo, ca trực và thời gian xử lý. Cần kiểm tra cả trường hợp người nhận chính không phản hồi và trường hợp công cụ gửi thông báo bị lỗi; cảnh báo được tạo chưa chắc đã được người có trách nhiệm nhìn thấy.

Tình huống giả định: CPU thấp nhưng giao dịch vẫn chậm

Giả sử một ứng dụng nội bộ có thời gian tạo đơn hàng tăng rõ ở giờ cao điểm. CPU máy chủ ứng dụng không cao, nên đội ban đầu nghĩ vấn đề nằm ở máy người dùng. Đây là tình huống minh họa; không thể dùng riêng biểu hiện này để kết luận nguyên nhân cho một hệ thống thật.

Khi tách độ trễ theo bước, đội thấy thời gian chờ cơ sở dữ liệu tăng. Số phiên kết nối đang dùng gần mức giới hạn, trong khi một tác vụ báo cáo chạy trùng giờ. Log và dữ liệu truy vết cung cấp bằng chứng để xem xét giả thuyết cạnh tranh tài nguyên, thay vì tiếp tục chỉ nhìn CPU.

Nhóm ứng dụng và cơ sở dữ liệu cần kiểm tra truy vấn, khóa, quản lý kết nối và lịch tác vụ. Mua thêm CPU có thể không giải quyết cơ chế đang giới hạn. Sau khi chọn thay đổi phù hợp, phải đo lại dưới tải tương đương và kiểm tra cả giao dịch tạo đơn lẫn tác vụ báo cáo.

Bộ chỉ số được điều chỉnh để quan sát độ trễ giao dịch, thời gian chờ kết nối và tải báo cáo. Cảnh báo được thiết kế theo tác động và thời gian phản ứng, không phải đưa mọi giá trị đo lên mức khẩn cấp. Đội cũng ghi điều kiện phải mở lại điều tra nếu biểu hiện quay về dưới một kiểu tải khác.

Bài học ở đây là chỉ số giúp đặt và kiểm chứng giả thuyết. Chúng không tự kể toàn bộ nguyên nhân. Metrics cho thấy điều gì thay đổi; log và traces có thể giúp giải thích đường thực hiện, nhưng phải được thu thập với quyền truy cập và mức dữ liệu phù hợp.

Rà bộ chỉ số theo quyết định mà nó hỗ trợ

Sau mỗi sự cố đáng kể, hãy hỏi bộ giám sát đã phát hiện trước người dùng chưa, cảnh báo có đến đúng người không và dữ liệu có đủ để điều tra không. Câu trả lời giúp bổ sung những khoảng trống cụ thể, thay vì chỉ thêm nhiều biểu đồ sau mỗi lần gián đoạn.

Theo dõi số cảnh báo có hành động, cảnh báo bị bỏ qua, lỗi đường gửi và dịch vụ quan trọng chưa có kiểm tra từ góc nhìn người dùng. Những dữ liệu này cần được đọc cùng khối lượng hoạt động. Mục tiêu không phải giảm mọi thông báo xuống tối thiểu mà là giữ thông báo có ích và dữ liệu điều tra đủ chất lượng.

Khi báo cáo với lãnh đạo, trình bày tác động, xu hướng và lựa chọn. “Hàng đợi tăng, có nguy cơ không hoàn thành trước giờ chốt” dễ dẫn đến quyết định hơn một trang chỉ có tỷ lệ CPU. Năng lực IT Manager giúp kết nối những tín hiệu này với nguồn lực, lịch nghiệp vụ và phương án xử lý.

Một bước khởi đầu thực tế là chọn một hành trình quan trọng, đo kết quả cùng bốn nhóm tín hiệu và rà mỗi cảnh báo liên quan. Sau đó kiểm tra bằng một tình huống có kiểm soát: hệ thống có nhận biết, chuyển đúng người và giữ đủ bằng chứng không? Kết quả thử sẽ chỉ ra việc cần làm tiếp theo.

Giám sát đáng tin không phải bảng luôn xanh. Đó là khả năng nhận biết đúng biểu hiện, hiểu giới hạn của dữ liệu và chuyển tín hiệu thành hành động kịp thời. Khi bộ chỉ số được chọn theo cách ấy, đội có thể nhìn thấy cả sự suy giảm hiện tại lẫn rủi ro đang hình thành.