Công bố chỉ số cùng đơn vị và mẫu số rõ ràng

Một tỷ lệ phần trăm về chất lượng yêu cầu chưa đủ nghĩa nếu thiếu tập yêu cầu được đếm và quy tắc xác định yêu cầu nào đạt. Lỗi trả về nhanh có thể làm biểu đồ chỉ đo độ trễ trông tốt hơn, trong khi khách hàng không nhận được kết quả hữu ích. Loại lỗi đó khỏi mẫu số cũng có thể khiến các yêu cầu thành công còn lại trông khả quan, nhưng phép đo khi ấy trả lời một câu hỏi hẹp hơn.

Bài viết dành cho kỹ sư dữ liệu công bố chỉ số vận hành từ bản ghi yêu cầu. Bạn cần biết SQL cơ bản. Ví dụ dùng một tập dữ liệu giả lập nhỏ, được chạy bằng SQLite. Mục tiêu là công bố tỷ lệ có thể tái hiện, giải thích đơn vị và phân biệt kết quả không đạt với kết quả chưa đủ thông tin để phân loại. Ví dụ không triển khai bộ xuất telemetry hay cảnh báo vận hành thực tế.

Xác định tập yêu cầu trước khi tính tỷ lệ

Tập mục tiêu gồm các yêu cầu công khai đến ranh giới dịch vụ trong ngày 02/10/2026 theo UTC. Yêu cầu kiểm tra sức khỏe bị loại theo chính sách nêu rõ. Mỗi yêu cầu là một quan sát, kể cả yêu cầu thất bại; mỗi lần thử lại cũng sẽ là một yêu cầu riêng. Một quan sát đạt phải vừa thành công vừa hoàn tất trong tối đa 500 mili giây, tính cả trường hợp đúng 500.

SRE Workbook của Google mô tả SLI dưới dạng số sự kiện tốt chia cho tổng số sự kiện, đồng thời phân biệt kết quả dịch vụ mong muốn với cách triển khai phép đo. Ở đây, 500 mili giây là ngưỡng giả định để chấp nhận một kết quả. Đó không phải khuyến nghị về độ trễ. Ngưỡng này cũng chưa phải SLO: SLO còn phải quy định riêng tỷ lệ mong muốn và cửa sổ đánh giá.

Dữ liệu mẫu giả định mã yêu cầu không trùng, thời điểm dùng định dạng UTC chuẩn, loại yêu cầu và kết quả cuối cùng đã được kiểm tra hợp lệ, còn thời lượng là số nguyên không âm tính bằng mili giây hoặc NULL. Ví dụ cũng giả định đã thu thập đầy đủ tập yêu cầu đến. Đây là điều kiện đầu vào do hệ thống phía trước bảo đảm, không phải cam kết từ khai báo cột SQLite. Nếu mục tiêu trải nghiệm người dùng bao gồm cả yêu cầu chưa đến được ranh giới đo này, cần một phép đo khác để quan sát chúng.

Giữ rõ yêu cầu đạt, không đạt và chưa phân loại được

Chạy các khối SQL theo thứ tự trong một cơ sở dữ liệu mới. Cả tám yêu cầu ban đầu đều có kết quả cuối cùng. Yêu cầu kiểm tra sức khỏe ở dòng cuối vẫn nằm trong bảng thô nhưng bị loại khỏi tập đủ điều kiện.

CREATE TABLE requests (
  request_id TEXT PRIMARY KEY,
  arrived_at TEXT,
  kind TEXT,
  outcome TEXT,
  latency_ms INTEGER
);
INSERT INTO requests VALUES
 ('r1','2026-10-02T00:00:00Z','public','success',120),
 ('r2','2026-10-02T08:00:00Z','public','success',450),
 ('r3','2026-10-02T09:00:00Z','public','success',500),
 ('r4','2026-10-02T10:00:00Z','public','success',700),
 ('r5','2026-10-02T11:00:00Z','public','error',30),
 ('r6','2026-10-02T12:00:00Z','public','error',100),
 ('r7','2026-10-02T13:00:00Z','public','timeout',1000),
 ('r8','2026-10-02T14:00:00Z','health','success',2);

CREATE VIEW eligible AS
SELECT * FROM requests
WHERE kind = 'public'
  AND arrived_at >= '2026-10-02T00:00:00Z'
  AND arrived_at <  '2026-10-03T00:00:00Z';

CREATE VIEW classified AS
SELECT *, CASE
  WHEN outcome IN ('error','timeout') THEN 'bad'
  WHEN latency_ms IS NULL THEN 'unknown'
  WHEN latency_ms <= 500 THEN 'good'
  ELSE 'bad'
END AS quality
FROM eligible;

CREATE VIEW quality_counts AS
SELECT COUNT(*) AS eligible_count,
       COALESCE(SUM(quality = 'good'),0) AS good_count,
       COALESCE(SUM(quality = 'bad'),0) AS bad_count,
       COALESCE(SUM(quality = 'unknown'),0) AS unknown_count
FROM classified;

Thứ tự điều kiện có ý nghĩa. Một lỗi đã không đáp ứng yêu cầu kết hợp thành công và đủ nhanh, ngay cả khi thiếu thời lượng. Yêu cầu thành công nhưng mất thời lượng vẫn chưa thể phân loại. Tài liệu CASE của SQLite quy định nhánh WHEN đúng đầu tiên sẽ chọn kết quả. Chuỗi kết quả ngoài tập cho phép có thể bị phân loại sai trong truy vấn này, nên kiểm tra tập giá trị kết quả trước khi chạy là một phần của hợp đồng.

Mở ảnh kích thước đầy đủ ↗

Công bố các số đếm cùng tỷ lệ. Truy vấn không đưa ra một giá trị điểm khi còn trường hợp chưa phân loại được, và để tỷ lệ không xác định khi tập yêu cầu rỗng. Cận dưới và cận trên mô tả các cách phân loại có thể xảy ra đối với những yêu cầu đã quan sát nhưng còn thiếu thông tin.

SELECT eligible_count, good_count, bad_count, unknown_count,
       CASE WHEN eligible_count > 0 AND unknown_count = 0
            THEN 1.0 * good_count / eligible_count END AS good_fraction,
       CASE WHEN eligible_count > 0
            THEN 1.0 * good_count / eligible_count END AS lower_fraction,
       CASE WHEN eligible_count > 0
            THEN 1.0 * (good_count + unknown_count) / eligible_count
       END AS upper_fraction
FROM quality_counts;

Các số đếm ban đầu là 7 yêu cầu đủ điều kiện, 3 đạt, 4 không đạt và 0 chưa phân loại. Cả ba tỷ lệ bằng 3/7, xấp xỉ 0,428571. SQL dùng phép chia dấu phẩy động; các số đếm nguyên nhỏ vẫn giữ được tỷ lệ toán học chính xác để bên sử dụng khác tính lại. Hiển thị giá trị thành 42,86% là lựa chọn trình bày, không tạo ra phép đo khác.

Kết quả này cũng khác thông lượng. Nhân đôi các yêu cầu ban đầu với mã mới làm cả hai số đếm tăng gấp đôi nhưng vẫn giữ tỷ lệ 3/7; điều đó không có nghĩa tải giữ nguyên. Giữ số lượng yêu cầu bên cạnh chất lượng khi quyết định có cần chú ý đến năng lực xử lý hay không.

So sánh các mẫu số khác nhau một cách minh bạch

Hai cách tính dễ được chọn thay thế đều cho giá trị lớn hơn trên đúng tập dữ liệu ban đầu:

SELECT
  SUM(outcome = 'success' AND latency_ms <= 500) AS good_count,
  COUNT(*) AS all_requests,
  SUM(outcome = 'success') AS successful_requests,
  SUM(latency_ms <= 500) AS fast_requests
FROM eligible;

Kết quả lần lượt là 3, 7, 4 và 5. Chia số yêu cầu đạt cho số yêu cầu thành công được 3/4, tức 75%: tỷ lệ yêu cầu đủ nhanh trong nhóm thành công. Chia số yêu cầu nhanh cho toàn bộ yêu cầu được 5/7: tỷ lệ hoàn tất nhanh, bao gồm cả hai lỗi trả về nhanh. Mỗi cách có thể hữu ích cho một chỉ số chẩn đoán được đặt tên riêng. Cả hai đều khác tỷ lệ chất lượng yêu cầu kết hợp đã thống nhất.

Giữ định nghĩa tử số trong tên biểu đồ. “Yêu cầu thành công và đủ nhanh trên toàn bộ yêu cầu công khai đến” thể hiện rõ cả hai điều kiện. “Hiệu năng” che mất chúng. Nếu bên sử dụng cần tập yêu cầu khác, hãy công bố một định nghĩa riêng thay vì âm thầm đổi mẫu số của chỉ số hiện có.

Thiếu thời lượng tạo ra kết quả có cận

Bây giờ thêm một yêu cầu thành công nhưng mất dữ liệu thời lượng. Đã biết yêu cầu này đến, nên loại nó sẽ làm mẫu số bị thu hẹp có chọn lọc.

INSERT INTO requests VALUES
 ('r9','2026-10-02T15:00:00Z','public','success',NULL);
SELECT eligible_count, good_count, bad_count, unknown_count,
       CASE WHEN eligible_count > 0 AND unknown_count = 0
            THEN 1.0 * good_count / eligible_count END AS good_fraction,
       CASE WHEN eligible_count > 0
            THEN 1.0 * good_count / eligible_count END AS lower_fraction,
       CASE WHEN eligible_count > 0
            THEN 1.0 * (good_count + unknown_count) / eligible_count
       END AS upper_fraction
FROM quality_counts;

Các số đếm trở thành 8, 3, 4 và 1. Giá trị điểm là NULL; hai cận là 3/8 và 4/8. Nếu thời lượng bị mất không quá 500 mili giây, yêu cầu đạt; nếu dài hơn, yêu cầu không đạt. Đây là hai cận có thể đạt được khi phân loại phần chưa biết, không phải khoảng tin cậy và không bảo vệ khỏi yêu cầu đến bị thất lạc hoặc đơn vị bị ghi sai. Chính sách có thể chủ động tính trường hợp chưa biết là thất bại, nhưng khi đó kết quả là điểm chính sách thận trọng và cần được đặt tên rõ.

Mở ảnh kích thước đầy đủ ↗

Thiếu thời lượng của một yêu cầu lỗi vẫn là khuyết tật telemetry, dù đã biết kết quả kết hợp này không đạt. Theo dõi riêng mức đầy đủ của phép đo; chỉ đếm yêu cầu chưa phân loại chất lượng không thể đếm hết mọi phép đo còn thiếu.

Công bố đơn vị và giới hạn hiểu biết của dữ liệu

Lưu tỷ lệ này dưới dạng giá trị không có thứ nguyên từ không đến một. Hướng dẫn đặt tên của Prometheus khuyến nghị dùng tỷ lệ thay cho phần trăm từ 0 đến 100 và dùng giây cho chỉ số thời lượng. Trường mili giây được ghi rõ trong dữ liệu mẫu có thể dùng nội bộ, nhưng khi xuất thời lượng theo giây, phải chia giá trị cho 1.000 và đồng thời đổi ngưỡng thành 0,5 giây. Đổi tên trường không thực hiện phép chuyển đơn vị.

Tuân theo quy ước của hệ thống nhận. Prometheus khuyến nghị hậu tố đơn vị; quy ước chỉ số của OpenTelemetry thường bỏ đơn vị khỏi tên khi metadata đã chứa đơn vị và khuyến nghị dùng giây cho thời lượng. Đây là khác biệt về cách đặt tên, không phải khác biệt về đại lượng vật lý.

Kết quả công bố cần giữ phiên bản định nghĩa, cửa sổ yêu cầu đến theo UTC, ngưỡng 500 mili giây có tính biên, các số đếm đủ điều kiện/đạt/không đạt/chưa phân loại và mã ảnh chụp dữ liệu đầu vào. Độ phủ của nguồn cũng cần bằng chứng độc lập: truy vấn trên các dòng đã chuyển đến không chứng minh bộ thu thập không làm mất dòng nào. Chờ kết quả cuối cùng có thể làm thay đổi thời điểm chốt báo cáo; không nên âm thầm chuyển yêu cầu sang ngày hoàn tất. Bằng chứng đến muộn cần một lần sửa báo cáo được ghi nhận hoặc một ảnh chụp dữ liệu có mã riêng.

Thử các trường hợp biên

Tạo lại dữ liệu ban đầu trước mỗi bài thử độc lập. Đổi r3 từ 500 thành 501 mili giây: số yêu cầu đạt giảm từ ba xuống hai. Đặt thời lượng r5 thành NULL: yêu cầu vẫn không đạt, còn số phép đo thiếu thời lượng tăng lên. Chuyển r1 đến đúng đầu ngày kế tiếp: yêu cầu rời khỏi tập được tính. Xóa mọi yêu cầu công khai: tất cả số đếm bằng không và mọi tỷ lệ là NULL, dù vẫn còn yêu cầu kiểm tra sức khỏe.

Cuối cùng, làm lại ví dụ thêm yêu cầu thứ chín rồi khôi phục thời lượng của nó lần lượt thành 500 và 501 trên cùng cơ sở dữ liệu đã thêm dòng đó. Tỷ lệ lần lượt đạt 4/8 và 3/8. Hai trường hợp giải thích ý nghĩa của khoảng kết quả. Không trường hợp nào xác lập mục tiêu độ tin cậy cho hệ thống thực tế hoặc chứng minh nguồn yêu cầu đến là đầy đủ.