Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là PM của một sàn thương mại điện tử. Đợt sale 12/12, sếp hỏi: "Hệ thống mình chịu được bao nhiêu người vào cùng lúc? Trang load có nhanh không? Lỡ sập thì sao?". Nếu bạn chỉ trả lời chung chung kiểu "chắc ổn", bạn đã đánh mất uy tín kỹ thuật trước cả engineer lẫn lãnh đạo.
Ba khái niệm Latency (độ trễ), Throughput (thông lượng) và Availability (độ sẵn sàng) chính là ba trục đo lường cốt lõi để nói chuyện về hiệu năng hệ thống. Chúng là ngôn ngữ chung giữa PM và engineer khi bàn về SLA, khi viết yêu cầu phi chức năng (non-functional requirements), khi đặt mục tiêu cho sprint, và khi đàm phán với khách hàng doanh nghiệp.
Một Technical PM giỏi không cần tự tay tối ưu hệ thống, nhưng phải hiểu đủ sâu để: đặt mục tiêu hợp lý, đọc được dashboard giám sát, biết khi nào con số "p99 = 2 giây" là thảm họa và khi nào nó chấp nhận được, và biết đánh đổi giữa ba trục này khi nguồn lực có hạn. Bài học này sẽ trang bị cho bạn đúng vốn từ và tư duy đó.
Khái niệm cốt lõi
Latency — Độ trễ
Latency là thời gian từ lúc gửi một request đến lúc nhận được phản hồi. Nếu bạn bấm nút "Thanh toán" và hệ thống mất 800 mili-giây để trả về kết quả, thì latency của request đó là 800ms.
Điều quan trọng nhất bạn cần nhớ: đừng bao giờ đo latency bằng giá trị trung bình (average). Trung bình che giấu sự thật. Giả sử 99 request mất 100ms nhưng 1 request mất 10 giây, trung bình vẫn chỉ khoảng 200ms — nghe có vẻ ổn, nhưng thực tế có người dùng phải chờ 10 giây và rất có thể họ đã bỏ đi.
Vì vậy người ta dùng percentile (phân vị):
- p50 (median): 50% request nhanh hơn con số này. Đây là trải nghiệm của người dùng "điển hình".
- p95: 95% request nhanh hơn con số này. 5% còn lại chậm hơn.
- p99: 99% request nhanh hơn con số này. Đây là phần "đuôi" (tail latency) — trải nghiệm của 1% người dùng xui xẻo nhất.
Tại sao tail latency lại quan trọng đến vậy? Vì một trang web thường gọi nhiều API song song. Nếu trang sản phẩm cần gọi 10 service và mỗi service có p99 = 1s, thì xác suất ít nhất một service rơi vào "đuôi chậm" tăng lên đáng kể — kết quả là người dùng cảm nhận chậm thường xuyên hơn nhiều so với con số 1% gợi ý.
Throughput — Thông lượng
Throughput là số lượng request hệ thống xử lý được trong một đơn vị thời gian. Đơn vị phổ biến:
- RPS (Requests Per Second) — số request mỗi giây, dùng cho web/API nói chung.
- QPS (Queries Per Second) — số truy vấn mỗi giây, thường dùng cho database hoặc search.
- TPS (Transactions Per Second) — số giao dịch mỗi giây, dùng cho hệ thống thanh toán, ngân hàng.
Lưu ý quan trọng: latency và throughput không tỉ lệ thuận đơn giản với nhau. Khi tải tăng dần, hệ thống vẫn giữ latency thấp cho đến một điểm gọi là "knee" (điểm gãy). Vượt qua điểm đó, hàng đợi (queue) bắt đầu dồn ứ, latency tăng vọt theo cấp số nhân dù throughput gần như không tăng thêm. Đây là lý do "thêm tải" không bao giờ miễn phí.
Availability — Độ sẵn sàng
Availability là tỉ lệ phần trăm thời gian hệ thống hoạt động bình thường trong một khoảng thời gian. Người ta thường nói về "số 9":
| Availability | Downtime/năm | Downtime/tháng |
|---|---|---|
| 99% ("hai số 9") | ~3.65 ngày | ~7.2 giờ |
| 99.9% ("ba số 9") | ~8.76 giờ | ~43 phút |
| 99.95% | ~4.38 giờ | ~22 phút |
| 99.99% ("bốn số 9") | ~52.6 phút | ~4.3 phút |
| 99.999% ("năm số 9") | ~5.26 phút | ~26 giây |
Hai khái niệm bổ trợ: SLA, SLO, SLI
- SLI (Service Level Indicator): chỉ số đo thực tế, ví dụ "p99 latency", "% request thành công".
- SLO (Service Level Objective): mục tiêu nội bộ bạn đặt ra, ví dụ "p99 < 500ms trong 99.9% thời gian".
- SLA (Service Level Agreement): cam kết hợp đồng với khách hàng, thường kèm điều khoản đền bù nếu vi phạm. SLA luôn "lỏng" hơn SLO một chút để có biên an toàn.
Tình huống thực tế
Tình huống 1 — Tiki và cú "đơ giỏ hàng" ngày sale
Bối cảnh: Một sàn TMĐT lớn tại Việt Nam (gọi là sàn X) tổ chức Flash Sale 0h ngày 11/11. Bình thường hệ thống chịu khoảng 2.000 RPS, p99 ở mức 600ms — hoàn toàn ổn. Nhưng vào đúng 0h, lượng truy cập tăng vọt lên 18.000 RPS chỉ trong vài giây.
Diễn giải: Service giỏ hàng (cart) vượt qua điểm "knee". Hàng đợi đến database dồn ứ, p99 latency từ 600ms nhảy lên 9 giây. Người dùng bấm "Thêm vào giỏ" và quay vòng vòng, nhiều người bấm đi bấm lại — tạo thêm tải, đẩy hệ thống lún sâu hơn (hiệu ứng retry storm). Throughput thực tế xử lý được tụt xuống còn 1.200 RPS dù lượng request đổ vào gấp 15 lần. Availability của tính năng giỏ hàng rơi xuống dưới 90% trong 4 phút vàng đầu tiên — đúng lúc doanh thu cao nhất.
Bài học rút ra: Throughput đỉnh (peak) khác xa throughput trung bình. PM phải hỏi engineer "tải đỉnh dự kiến là bao nhiêu, gấp mấy lần ngày thường?" chứ không phải tải trung bình. Và phải có cơ chế chống retry storm (như exponential backoff, hàng đợi ảo xếp hàng — virtual waiting room) cho các sự kiện sale.
Tình huống 2 — Ví điện tử và cái giá của "số 9"
Bối cảnh: Một ví điện tử tại Đông Nam Á (gọi là ví Y) ký hợp đồng với một chuỗi siêu thị lớn để xử lý thanh toán tại quầy. Khách hàng doanh nghiệp yêu cầu SLA 99.99% cho API thanh toán, kèm điều khoản phạt: mỗi 0.01% downtime vượt mức bị trừ 2% phí dịch vụ tháng đó.
Diễn giải: Team kỹ thuật của ví Y đang chạy ở 99.9% (ba số 9 — khoảng 43 phút downtime/tháng). Để lên 99.99% (chỉ ~4.3 phút/tháng), họ phải: triển khai multi-region active-active (hai trung tâm dữ liệu cùng chạy), tự động failover database dưới 30 giây, đội on-call 24/7, và loại bỏ mọi "single point of failure". Chi phí hạ tầng tăng khoảng 2.5 lần. PM phải tính: doanh thu từ hợp đồng này có bù được chi phí thêm bốn-số-chín không, và rủi ro phạt là bao nhiêu.
Bài học rút ra: Mỗi con "9" thêm vào có giá rất đắt. PM không nên gật đầu với SLA cao chỉ vì khách hàng muốn — phải mô hình hóa chi phí và rủi ro. Đôi khi giải pháp là đàm phán SLA 99.95% với điều khoản phạt nhẹ hơn, vừa khả thi kỹ thuật vừa giữ được khách.
Tình huống 3 — Grab và bài toán latency vùng xa
Bối cảnh: Một siêu ứng dụng gọi xe (gọi là app Z) nhận phản ánh rằng tài xế và khách ở các tỉnh xa thường xuyên thấy bản đồ và ghép chuyến chậm hơn hẳn so với ở TP.HCM, dù cùng một phiên bản app.
Diễn giải: Server đặt chính tại Singapore. Với người dùng ở TP.HCM, p50 latency mạng khoảng 40ms — chấp nhận được. Nhưng với người dùng ở tỉnh có hạ tầng mạng yếu, chỉ riêng độ trễ mạng (network latency) đã 150–250ms, cộng thêm thời gian xử lý phía server, p95 chạm 1.5 giây. Đây không phải lỗi code mà là latency vật lý do khoảng cách và chất lượng đường truyền. Giải pháp họ áp dụng: đặt CDN và edge server gần người dùng hơn, cache dữ liệu bản đồ tĩnh tại biên, và tối ưu kích thước payload để giảm số byte truyền đi.
Bài học rút ra: Latency không chỉ là chuyện "code chậm". Nó gồm cả độ trễ mạng, khoảng cách địa lý, và chất lượng hạ tầng người dùng cuối. PM cần phân tích latency theo từng phân khúc người dùng (segment), không chỉ nhìn con số tổng.
Hướng dẫn từng bước
Khi bạn cần thiết lập và làm việc với các chỉ số hiệu năng cho một sản phẩm, hãy đi theo trình tự sau:
- Xác định "happy path" quan trọng nhất. Chọn 2–3 luồng nghiệp vụ cốt lõi (ví dụ: tìm kiếm sản phẩm, thêm giỏ hàng, thanh toán). Đừng cố đo mọi thứ — tập trung vào luồng ảnh hưởng doanh thu và trải nghiệm.
- Đặt SLO cho từng luồng theo cả ba trục. Ví dụ với luồng thanh toán: "p99 latency < 800ms, throughput chịu được 5.000 TPS đỉnh, availability 99.95%". Số liệu phải cụ thể và đo được.
- Lấy baseline từ dữ liệu thật. Trước khi đặt mục tiêu, hãy xem dashboard hiện tại (qua Grafana, Datadog, New Relic...). Biết mình đang đứng ở đâu thì mới đặt mục tiêu hợp lý. Đừng đặt p99 = 100ms nếu hiện tại đang là 2 giây.
- Hỏi về tải đỉnh, không chỉ tải trung bình. Yêu cầu engineer ước tính tỉ lệ peak/average, và các sự kiện đặc biệt (sale, lễ, viral). Lên kế hoạch capacity cho đỉnh, không cho trung bình.
- Phân tích latency theo segment. Tách theo vùng địa lý, loại thiết bị, mạng. Một con số tổng có thể che giấu việc một nhóm người dùng đang chịu trải nghiệm tệ.
- Thiết lập alert dựa trên SLO. Cảnh báo nên kích hoạt khi "ngân sách lỗi" (error budget) sắp cạn, chứ không phải mỗi khi có một spike nhỏ. Tránh "alert fatigue" — team bị làm phiền quá nhiều sẽ ngó lơ cả cảnh báo thật.
- Đặt error budget và dùng nó để ra quyết định. Nếu SLO availability là 99.9%, bạn có "ngân sách" 43 phút downtime/tháng. Còn ngân sách thì cho phép team deploy nhanh, thử nghiệm. Hết ngân sách thì đóng băng tính năng mới, tập trung ổn định hệ thống.
Lỗi thường gặp & mẹo
Lỗi 1: Dùng average latency. Như đã nói, trung bình che giấu phần đuôi. Luôn yêu cầu p95/p99. Mẹo: khi engineer báo cáo "latency trung bình 150ms", hãy hỏi lại "p99 là bao nhiêu?".
Lỗi 2: Nhầm latency với throughput. "Hệ thống nhanh" (latency thấp) và "hệ thống khỏe" (throughput cao) là hai chuyện khác nhau. Một API có thể trả lời cực nhanh khi vắng tải nhưng sụp đổ khi đông. Đừng kết luận về năng lực từ một lần test đơn lẻ.
Lỗi 3: Cam kết SLA quá cao. Mỗi con 9 đắt theo cấp số nhân. Đừng hứa năm-số-chín cho một tính năng nội bộ ít người dùng.
Lỗi 4: Quên tính downtime do bảo trì và deploy. Availability tính cả những lần bạn chủ động dừng hệ thống. Mẹo: dùng kỹ thuật deploy không gián đoạn (rolling/blue-green) để không "đốt" ngân sách availability mỗi lần ra bản mới.
Lỗi 5: Bỏ qua latency mạng của người dùng cuối. Server nhanh không có nghĩa người dùng thấy nhanh. Đặc biệt ở Việt Nam với người dùng tỉnh xa và mạng di động.
Mẹo vàng: Khi đánh đổi giữa ba trục, hãy nhớ định lý CAP và thực tế vận hành — bạn hiếm khi tối ưu được cả ba cùng lúc với nguồn lực cố định. Hãy hỏi: "Với sản phẩm này, người dùng đau nhất khi nào — khi chậm, khi nghẽn, hay khi sập?" Câu trả lời quyết định bạn ưu tiên trục nào.
Bài tập thực hành
- Bài tập đọc số: Một API có p50 = 90ms, p95 = 350ms, p99 = 1.8s, xử lý 2 triệu request/ngày. Hãy tính: mỗi ngày có bao nhiêu request chậm hơn 1.8 giây? Theo bạn, đây có phải vấn đề đáng ưu tiên không, và tại sao?
- Bài tập availability: Khách hàng yêu cầu SLA 99.95%. Hãy tra bảng và cho biết mỗi tháng bạn được phép "chết" tối đa bao nhiêu phút. Nếu team thường mất 10 phút mỗi lần deploy và deploy 3 lần/tuần, hệ thống có đáp ứng nổi SLA này không?
- Bài tập viết SLO: Chọn một sản phẩm bạn đang dùng (ví dụ app ngân hàng, app đặt đồ ăn). Viết SLO cho luồng quan trọng nhất theo cả ba trục latency, throughput, availability. Giải thích vì sao bạn chọn các con số đó.
- Bài tập tình huống: Đội của bạn còn 43 phút error budget trong tháng, nhưng vừa dùng hết 38 phút do một sự cố. Sếp muốn deploy một tính năng lớn ngay tuần này. Bạn sẽ quyết định thế nào và giải thích với sếp ra sao?
Tóm tắt
- Latency đo tốc độ phản hồi của từng request. Luôn dùng percentile (p50, p95, p99), không bao giờ dùng trung bình. Phần "đuôi" p99 quyết định trải nghiệm tệ nhất và thường là vấn đề lớn ở quy mô cao.
- Throughput (RPS/QPS/TPS) đo năng lực xử lý của hệ thống. Quan tâm tải đỉnh, không chỉ trung bình. Vượt điểm "knee", latency tăng vọt còn throughput đứng yên.
- Availability đo tỉ lệ thời gian hệ thống sống. Thuộc bảng "số 9": mỗi con 9 thêm vào đắt theo cấp số nhân về chi phí lẫn vận hành.
- Dùng bộ SLI / SLO / SLA để biến các chỉ số thành mục tiêu và cam kết. Cam kết SLA luôn để biên an toàn so với SLO nội bộ.
- Dùng error budget để cân bằng giữa tốc độ phát triển tính năng và sự ổn định.
- Vai trò PM: đặt mục tiêu hợp lý dựa trên dữ liệu thật, hỏi đúng câu hỏi (tải đỉnh, p99, segment), và biết đánh đổi giữa ba trục theo nỗi đau thực sự của người dùng.