Bài 22 — RED Method và USE Method — Operations Management for Tech

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa nhận trách nhiệm vận hành hệ thống thanh toán của một sàn thương mại điện tử lớn ở Việt Nam. Dashboard hiện lên trước mặt bạn có 300 biểu đồ: CPU của từng máy chủ, dung lượng RAM, số kết nối database, nhiệt độ ổ đĩa... Rồi một buổi tối thứ Sáu, khách hàng bắt đầu than phiền "không thanh toán được". Bạn nhìn vào 300 biểu đồ đó và... không biết bắt đầu từ đâu. Mọi thứ đều "xanh", nhưng khách hàng vẫn khổ sở.

Vấn đề ở đây không phải là thiếu dữ liệu — mà là thiếu một khung tư duy để chọn ra đúng vài chỉ số quan trọng nhất. Đây chính là lý do RED Method và USE Method ra đời. Hai phương pháp này trả lời cùng một câu hỏi cốt lõi: "Với mỗi thành phần trong hệ thống, tôi nên đo đúng những gì để biết nó khỏe hay bệnh?" Thay vì đo mọi thứ có thể đo, bạn đo những thứ thực sự cho biết trải nghiệm người dùng và sức khỏe tài nguyên.

Ở Bài 21, bạn đã học về 4 Golden Signals của Google — một khung tư duy tổng quát cho monitoring. Bài 22 này sẽ đi sâu vào hai phương pháp cụ thể và bổ trợ cho nhau: RED tập trung vào dịch vụ/API (góc nhìn của người dùng), còn USE tập trung vào tài nguyên (góc nhìn của hệ thống bên trong). Nắm vững cả hai, bạn sẽ có bộ công cụ để thiết kế dashboard và alert một cách có kỷ luật, thay vì đoán mò.

Khái niệm cốt lõi

RED Method — dành cho service và API

RED được Tom Wilkie (đồng sáng lập Grafana Labs, tác giả Cortex/Loki) đề xuất, lấy cảm hứng trực tiếp từ 4 Golden Signals nhưng đơn giản hóa để dễ áp dụng cho mỗi request-driven service — tức là bất kỳ dịch vụ nào nhận request và trả về response (API, microservice, endpoint HTTP...).

RED là viết tắt của ba chỉ số:

Rate (Tỷ lệ) — số lượng request mà dịch vụ xử lý mỗi giây (requests/second, viết tắt RPS hoặc QPS). Đây là "khối lượng công việc" đang đổ vào dịch vụ. Ví dụ: API /checkout đang nhận 450 request/giây.
Errors (Lỗi) — số lượng request bị lỗi mỗi giây, hoặc tỷ lệ lỗi (%). Thường tính theo mã HTTP 5xx, hoặc theo định nghĩa lỗi nghiệp vụ của bạn. Ví dụ: 9 request/giây trả về lỗi 500, tức tỷ lệ lỗi 2%.
Duration (Thời lượng) — thời gian dịch vụ xử lý mỗi request, thường biểu diễn bằng phân phối (distribution) chứ không phải giá trị trung bình. Bạn quan tâm đến các phân vị (percentile): p50, p95, p99. Ví dụ: p95 latency = 800ms nghĩa là 95% request được xử lý dưới 800ms.

Điểm mấu chốt cần khắc sâu: Duration phải đo bằng percentile, không bao giờ chỉ dùng trung bình (average). Vì sao? Giả sử 99 request nhanh 50ms và 1 request chậm 5000ms, trung bình chỉ là ~100ms — trông rất đẹp. Nhưng cái request 5000ms đó chính là một khách hàng đang chờ mòn mỏi. Percentile p99 sẽ phơi bày nó, còn average thì che giấu nó.

Vì sao RED mạnh? Vì ba chỉ số này phản ánh trực tiếp trải nghiệm người dùng: người dùng quan tâm dịch vụ có chạy không (Errors), có nhanh không (Duration), và mức tải như thế nào (Rate) giúp bạn hiểu bối cảnh. RED áp dụng đồng nhất cho mọi service — dù đó là service Go, Node.js hay Java, bạn luôn đo cùng ba thứ. Điều này khiến dashboard trở nên nhất quán và dễ đọc trên toàn hệ thống.

USE Method — dành cho tài nguyên

USE được Brendan Gregg (chuyên gia performance nổi tiếng, từng ở Netflix và Sun Microsystems) đề xuất. Nếu RED nhìn từ ngoài vào (góc người dùng), thì USE nhìn từ trong ra (góc tài nguyên hệ thống). USE dùng để chẩn đoán tại sao một tài nguyên bị nghẽn.

USE là viết tắt của ba chỉ số, áp dụng cho mỗi tài nguyên (CPU, memory, disk, network interface, connection pool...):

Utilization (Mức sử dụng) — phần trăm thời gian tài nguyên bận làm việc. Ví dụ: CPU utilization 85%, disk busy 70%.
Saturation (Mức bão hòa) — mức độ công việc bị xếp hàng chờ vì tài nguyên không xử lý kịp. Đây là chỉ số dễ bị bỏ quên nhất nhưng cực kỳ quan trọng. Ví dụ: độ dài hàng đợi run-queue của CPU, số byte trong swap, số connection đang chờ trong pool.
Errors (Lỗi) — số sự kiện lỗi của tài nguyên đó. Ví dụ: gói tin bị drop trên network interface, lỗi ECC của memory, lỗi I/O của ổ đĩa.

Điểm tinh tế: Utilization cao chưa chắc là vấn đề, nhưng Saturation cao gần như luôn là vấn đề. Một CPU chạy 100% utilization nhưng saturation = 0 (không có việc chờ) là đang làm việc hiệu quả tối đa — tốt. Nhưng CPU 100% utilization với run-queue dài 20 tiến trình đang chờ nghĩa là hệ thống đã quá tải, mọi thứ đang chậm lại. Đó là lý do bạn không thể chỉ nhìn Utilization; Saturation mới là cảnh báo sớm cho tình trạng nghẽn.

RED và USE bổ trợ nhau như thế nào

Đừng coi RED và USE là hai lựa chọn loại trừ. Chúng là hai lớp của cùng một câu chuyện:

RED cho bạn biết có vấn đề gì với dịch vụ hay không (triệu chứng, symptom) — ví dụ Duration p99 tăng vọt.
USE giúp bạn tìm nguyên nhân gốc ở tầng tài nguyên (chẩn đoán) — ví dụ connection pool của database đã saturation.

Một quy tắc thực dụng: Alert dựa trên RED (symptom-based), điều tra dựa trên USE (cause-based). Bạn báo động khi người dùng bị ảnh hưởng (RED xấu), rồi dùng USE để đào xuống xem tài nguyên nào đang nghẽn. Cách phân vai này giúp bạn tránh được biển alert nhiễu — chủ đề mà Bài 18 đã bàn.

Tình huống thực tế

Ví dụ 1 — Sàn TMĐT "ChợViệt" và cú nghẽn connection pool đêm sale

ChợViệt (tên giả định, mô phỏng một sàn TMĐT Việt Nam) chạy chương trình sale 12.12. Đêm đó, đội SRE thiết lập dashboard RED cho service order-api. Vào lúc 20:00, họ thấy:

Rate: tăng từ 200 RPS lên 1.100 RPS (mức tải tăng gấp 5,5 lần — bình thường trong ngày sale).
Errors: nhảy từ 0,3% lên 6% — báo động đỏ.
Duration: p99 tăng từ 400ms lên 4.200ms.

RED đã làm đúng nhiệm vụ: cho biết người dùng đang khổ. Nhưng RED không nói tại sao. Đội chuyển sang USE, soi từng tài nguyên mà order-api phụ thuộc. CPU của các pod chỉ ở mức 45% utilization — không phải thủ phạm. Nhưng khi nhìn connection pool tới PostgreSQL, họ thấy: Utilization 100%, và Saturation — số request đang xếp hàng chờ lấy connection — lên tới 180 request chờ liên tục. Đây chính là điểm nghẽn.

Nguyên nhân gốc: pool được cấu hình tối đa 20 connection, đủ cho tải thường ngày nhưng không đủ cho đêm sale. Các request phải xếp hàng chờ connection, timeout, rồi trả lỗi. Đội tăng pool size lên 60 và bật thêm read replica cho các truy vấn đọc. Trong 8 phút, Errors về 0,4%, p99 về 600ms.

Bài học: Nếu chỉ nhìn CPU (Utilization của một tài nguyên phổ biến nhất), họ đã bỏ sót hoàn toàn. Chính chỉ số Saturation của connection pool — thứ ít ai nghĩ tới — mới là chìa khóa. RED phát hiện triệu chứng, USE tìm ra nguyên nhân.

Ví dụ 2 — Fintech "MoMoo" và cái bẫy của giá trị trung bình

Một ví SĐT giả định tên MoMoo có API /transfer. Đội vận hành theo dõi Duration bằng average latency và luôn thấy con số đẹp: trung bình 120ms. Họ tự tin hệ thống nhanh. Nhưng bộ phận chăm sóc khách hàng liên tục nhận phàn nàn: "chuyển tiền bị treo cả 5-6 giây".

Khi một kỹ sư SRE mới về, anh đổi cách đo Duration sang phân phối percentile. Kết quả gây sốc:

p50 = 90ms (một nửa giao dịch rất nhanh)
p95 = 850ms
p99 = 6.400ms

Hóa ra 1% giao dịch — nhưng với hàng triệu giao dịch/ngày thì đó là hàng chục nghìn khách hàng — bị chậm tới hơn 6 giây. Average 120ms đã che giấu hoàn toàn "cái đuôi dài" (long tail) này. Đào sâu bằng USE, họ phát hiện các giao dịch chậm đều rơi vào những pod có disk I/O saturation cao do log đồng bộ (synchronous logging) ghi xuống ổ đĩa chậm.

Bài học: Trong RED, cách bạn biểu diễn Duration quyết định bạn có nhìn thấy sự thật hay không. Luôn dùng percentile (p95, p99), đặc biệt p99, để bắt long tail latency. Average là kẻ nói dối dễ thương nhất trong monitoring.

Ví dụ 3 — Startup logistics và USE cho hàng đợi message

Một startup logistics ở TP.HCM dùng RabbitMQ để điều phối đơn giao hàng giữa các service. Một ngày, đơn giao bị chậm cập nhật trạng thái. RED trên dispatch-api trông ổn: Rate bình thường, Errors thấp, Duration ổn. Vậy vấn đề ở đâu?

Đội áp dụng tư duy USE cho hàng đợi message (coi queue như một tài nguyên):

Utilization: consumer đang xử lý gần hết công suất.
Saturation: số message tồn đọng trong queue (queue depth) tăng đều từ vài trăm lên 45.000 message và chưa dừng.
Errors: một số message bị đẩy vào dead-letter queue.

Saturation tăng không ngừng là dấu hiệu kinh điển: tốc độ nạp message (producer) đang nhanh hơn tốc độ xử lý (consumer). Nguyên nhân: một service upstream vừa deploy tạo ra gấp đôi số event, trong khi số consumer không đổi. Đội scale consumer từ 4 lên 12 instance, queue depth rút về dưới 500 trong 15 phút.

Bài học: USE không chỉ áp dụng cho CPU/memory/disk cổ điển. Bất cứ thứ gì có "công suất hữu hạn và có thể xếp hàng chờ" — connection pool, thread pool, message queue — đều là một "tài nguyên" và đều đo được bằng Utilization/Saturation/Errors. Đây là sức mạnh tổng quát của USE.

Hướng dẫn từng bước

Dưới đây là quy trình áp dụng cả hai phương pháp cho một service của bạn.

Bước 1 — Liệt kê tài nguyên (cho USE). Vẽ ra sơ đồ mọi tài nguyên mà service phụ thuộc: CPU, memory, disk I/O, network, connection pool database, thread pool, message queue, cache. Đây là "danh sách kiểm tra" để không bỏ sót điểm nghẽn.

Bước 2 — Định nghĩa RED cho service. Với mỗi service/endpoint, xác định rõ:

Rate: đếm request bằng gì (counter tổng request).
Errors: định nghĩa "lỗi" là gì — chỉ 5xx, hay bao gồm cả 4xx do lỗi nghiệp vụ, hay timeout? Viết ra rõ ràng.
Duration: đo bằng histogram để tính được percentile (không dùng gauge trung bình).

Bước 3 — Instrument code. Dùng thư viện như Prometheus client để tạo metric. Với RED, ba metric cơ bản: một counter http_requests_total (có label status, route), và một histogram http_request_duration_seconds. Rate và Errors được tính từ counter, Duration từ histogram.

Bước 4 — Xây dashboard theo lớp. Tạo một hàng RED cho mỗi service quan trọng (3 biểu đồ: Rate, Errors %, Duration p50/p95/p99). Bên dưới, tạo khu vực USE cho các tài nguyên nền. Sắp xếp để khi RED đỏ, mắt bạn dễ dàng nhìn xuống USE để chẩn đoán.

Bước 5 — Đặt alert dựa trên RED. Báo động khi Error rate vượt ngưỡng (ví dụ >2% trong 5 phút) hoặc Duration p99 vượt SLO. Đừng đặt alert trên từng chỉ số USE riêng lẻ (như "CPU >80%") — vì CPU cao chưa chắc ảnh hưởng người dùng. Dùng USE để điều tra, không phải để báo động chính.

Bước 6 — Diễn tập điều tra. Khi có sự cố, đi theo dòng chảy: RED cho biết service nào đau → theo dependency → dùng USE tìm tài nguyên bão hòa → xử lý. Luyện tập lối tư duy này cho đến khi thành phản xạ.

Lỗi thường gặp & mẹo

Lỗi 1 — Dùng average cho Duration. Như đã thấy ở ví dụ MoMoo, average che giấu long tail. Mẹo: luôn hiển thị ít nhất p95 và p99. Trong Prometheus, dùng histogram_quantile() trên metric histogram.

Lỗi 2 — Bỏ quên Saturation. Đa số đội chỉ đo Utilization vì nó dễ (CPU %, RAM %). Nhưng Saturation mới là cảnh báo sớm. Mẹo: với mỗi tài nguyên, tự hỏi "công việc xếp hàng chờ ở đây được đo bằng gì?" — run-queue, queue depth, số connection chờ, thời gian chờ trong pool.

Lỗi 3 — Định nghĩa Errors mập mờ. Nếu bạn không thống nhất "lỗi là gì", Error rate sẽ vô nghĩa. Một timeout phía client có tính là lỗi của service không? Mẹo: viết định nghĩa lỗi thành tài liệu, thống nhất trong đội, gắn label rõ ràng.

Lỗi 4 — Nhầm vai RED và USE. Đặt alert trên "CPU >90%" rồi bị đánh thức lúc 3 giờ sáng dù người dùng chẳng hề hấn gì. Mẹo: nhớ khẩu quyết — alert on RED (symptom), investigate with USE (cause).

Lỗi 5 — Đo Rate/Errors bằng đơn vị không nhất quán. Có nơi đếm mỗi phút, có nơi mỗi giây. Mẹo: chuẩn hóa tất cả về per-second để so sánh và cộng gộp dễ dàng.

Mẹo tổng quát: RED cho service, USE cho tài nguyên — đọc thầm câu này mỗi khi thiết kế một dashboard mới, bạn sẽ không bao giờ lạc lối giữa 300 biểu đồ nữa.

Bài tập thực hành

Vẽ RED cho một service của bạn. Chọn một API bất kỳ trong hệ thống (hoặc một dự án cá nhân). Viết ra chính xác: bạn sẽ đo Rate bằng metric nào, định nghĩa Errors ra sao, và Duration lấy percentile nào. Vẽ tay 3 biểu đồ RED cho service đó.

Lập bảng USE. Liệt kê 5 tài nguyên mà service ở bài 1 phụ thuộc (ví dụ: CPU, memory, DB connection pool, disk, network). Với mỗi tài nguyên, điền vào bảng 3 cột: Utilization đo bằng gì, Saturation đo bằng gì, Errors đo bằng gì. Đặc biệt cố gắng điền cho được cột Saturation — đây là phần khó nhất.

Tình huống chẩn đoán. Cho biết: một service có Rate ổn định, nhưng Errors tăng lên 8% và Duration p99 tăng gấp 10 lần, trong khi CPU và RAM đều dưới 50%. Hãy liệt kê 3 tài nguyên bạn sẽ kiểm tra Saturation đầu tiên và giải thích lý do.

Phản biện average. Cho một tập 10 giá trị latency: 40, 45, 50, 48, 42, 47, 44, 46, 43, 3800 (ms). Tính average và ước lượng p90. Viết một đoạn ngắn giải thích vì sao con số average gây hiểu lầm ở đây.

Tóm tắt

RED và USE là hai khung tư duy bổ trợ giúp bạn chọn đúng chỉ số thay vì đo mọi thứ một cách vô định hướng.

RED (Tom Wilkie) dành cho service/API, đo ba thứ: Rate (request/giây), Errors (lỗi/giây hoặc %), Duration (phân phối latency, luôn dùng percentile p95/p99 chứ không dùng average). RED phản ánh trực tiếp trải nghiệm người dùng.
USE (Brendan Gregg) dành cho tài nguyên, đo ba thứ: Utilization (mức bận), Saturation (mức xếp hàng chờ — chỉ số cảnh báo sớm quan trọng nhất), Errors (lỗi của tài nguyên). USE dùng để chẩn đoán nguyên nhân gốc.
Nguyên tắc vàng: Alert dựa trên RED (triệu chứng), điều tra dựa trên USE (nguyên nhân).
Hai cạm bẫy lớn nhất cần tránh: dùng average cho latency, và bỏ quên Saturation.

Nắm chắc hai phương pháp này, bạn sẽ thiết kế được dashboard và alert có kỷ luật, chẩn đoán sự cố nhanh gọn, và không bao giờ lạc lối giữa rừng biểu đồ nữa.