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

Bạn vừa chạy xong một bài load test kéo dài 45 phút. Terminal đầy log, InfluxDB đầy metric, Grafana lấp lánh mấy chục biểu đồ. Bạn tự hào lắm. Nhưng rồi sếp hỏi một câu đơn giản: "Vậy hệ thống có chịu được đợt sale 12.12 không?" — và bạn không trả lời được trong 30 giây.

Đó chính là khoảnh khắc nhiều bạn làm performance testing "vỡ mộng". Chạy test là phần dễ. Phần khó — và cũng là phần quyết định giá trị công việc của bạn — là biến đống số liệu thô thành một câu trả lời rõ ràng, có căn cứ, mà người ra quyết định hiểu ngay và tin được.

Một report tốt không phải là dán ảnh Grafana vào Word. Report tốt là một lập luận: Tôi test cái gì, trong điều kiện nào, kết quả ra sao, so với mục tiêu thì đạt hay không, điểm nghẽn ở đâu, và tôi khuyến nghị làm gì tiếp theo. Cả engineer lẫn giám đốc đọc xong đều phải rút ra được đúng một kết luận giống nhau.

Bài này dạy bạn cách đọc kết quả test cho đúng (tránh những cái bẫy diễn giải số liệu) và viết findings cho ra tấm ra món — theo một format chuẩn mà các team QA/Performance chuyên nghiệp ở Việt Nam và quốc tế đang dùng. Đây là kỹ năng "mềm" nhưng lại là thứ phân biệt một người chạy tool với một Performance Engineer thực thụ.

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

Report là một lập luận, không phải một bãi số liệu

Nguyên tắc số một: mỗi con số bạn đưa ra phải phục vụ một kết luận. Nếu một biểu đồ không giúp người đọc quyết định điều gì, hãy bỏ nó ra khỏi phần chính (đẩy xuống phụ lục). Report bị loãng vì quá nhiều số là lỗi phổ biến nhất của người mới.

Cấu trúc phân tầng theo người đọc

Report performance chuẩn có ba tầng, phục vụ ba loại người đọc khác nhau:

• Executive Summary (1 trang) — cho management, PO, sếp. Họ chỉ cần biết: Pass hay Fail? Hệ thống chịu được bao nhiêu user? Rủi ro gì? Có được go-live không? Viết bằng ngôn ngữ nghiệp vụ, tối thiểu thuật ngữ kỹ thuật.

• Test Details & Results (vài trang) — cho tech lead, dev senior. Mô tả cấu hình test, môi trường, kịch bản, và bảng metric đầy đủ: latency (p50/p90/p95/p99), throughput (RPS), error rate, tài nguyên server (CPU/RAM).

• Analysis & Recommendations — cho dev sẽ đi fix. Phân tích điểm nghẽn cụ thể, bằng chứng (log, biểu đồ correlation), và hành động khuyến nghị kèm mức ưu tiên.

Những metric phải đọc đúng (không đọc sai)

Đây là phần "reading" — bạn phải hiểu con số nói gì:

• Trung bình (average) là kẻ nói dối. Nếu 95% request trả về trong 200ms nhưng 5% mất 8 giây, average có thể vẫn "đẹp" (~600ms) nhưng trải nghiệm thực tế đã tệ. Luôn nhìn percentile: p95, p99. Câu thần chú: "Average hides the pain, percentiles reveal it."

• Throughput phải đi kèm error rate. RPS cao mà 20% request lỗi thì throughput đó là giả. Server "xử lý nhanh" vì nó đang trả về lỗi 500 nhanh, chứ không phải phục vụ khách thành công.

• Latency phải đi kèm số user concurrent. "p95 = 300ms" vô nghĩa nếu không biết lúc đó có bao nhiêu VU (virtual user). 300ms ở 100 user và 300ms ở 5.000 user là hai câu chuyện khác nhau hoàn toàn.

• Correlation là chìa khóa của analysis. Điểm quý nhất trong report là khi bạn đặt cạnh nhau: đường latency tăng vọt tại phút thứ 12 — và đúng lúc đó CPU database chạm 100%. Đó không còn là số liệu, đó là bằng chứng nhân quả.

Pass/Fail phải dựa trên tiêu chí đã định trước

Một report chuyên nghiệp không tự bịa ra "đạt" hay "không đạt". Nó so kết quả với SLA/SLO đã thống nhất trước khi test. Ví dụ: "p95 < 500ms và error rate < 1% ở tải 2.000 concurrent user". Nếu chưa có tiêu chí, bạn không có cơ sở để nói pass/fail — và report của bạn trở thành ý kiến cá nhân thay vì kết luận kỹ thuật.

Tình huống thực tế

Ví dụ 1 — Report "đẹp" nhưng suýt gây thảm họa (sàn TMĐT tại TP.HCM)

Một sàn thương mại điện tử tại TP.HCM chuẩn bị cho đợt sale 11.11. Bạn QA junior chạy load test API /checkout và gửi report: "Average response time 480ms, throughput 1.200 RPS. Hệ thống ổn định, sẵn sàng go-live." Sếp gật đầu.

May thay, một anh Performance Engineer đọc lại. Anh yêu cầu xem percentile thay vì average. Kết quả: p50 = 210ms, p95 = 3.400ms, p99 = 11.000ms. Nghĩa là cứ 100 khách thì 1 người phải chờ 11 giây ở bước thanh toán — và error rate thực tế là 6,8%, bị "giấu" vì report chỉ nhìn average.

Anh vẽ lại một biểu đồ correlation: p99 latency bắt đầu leo dốc từ phút thứ 8, trùng khớp với lúc connection pool của database đạt giới hạn 100 connection. Report được viết lại với executive summary: "FAIL — không đủ sức chịu tải mục tiêu. Rủi ro mất ~7% đơn ở giờ cao điểm. Nguyên nhân: DB connection pool. Khuyến nghị: tăng pool lên 300 + thêm read replica trước khi go-live."

Bài học: average che giấu nỗi đau. Một report dựa trên average có thể trông "xanh" trong khi hệ thống đang chuẩn bị sập. Luôn báo cáo percentile và luôn kèm error rate.

Ví dụ 2 — Findings mơ hồ khiến dev không fix được (fintech ở Hà Nội)

Một công ty fintech ở Hà Nội test API xác thực OTP. QA gửi finding: "API bị chậm khi tải cao, đề nghị dev tối ưu." Dev đọc xong… không biết bắt đầu từ đâu. "Chậm" là bao nhiêu? "Tải cao" là bao nhiêu user? "Tối ưu" cái gì? Finding bị đá qua đá lại ba ngày mà không ai đụng vào code.

Tuần sau, QA lead viết lại theo format chuẩn: "Tại 1.500 VU, endpoint POST /otp/verify có p95 tăng từ 180ms lên 4.200ms sau phút thứ 5. Log cho thấy 2.100 lỗi timeout khi gọi Redis. CPU của Redis node chạm 98% liên tục. Giả thuyết: OTP đang lưu không TTL nên Redis phình bộ nhớ và chậm dần. Bằng chứng: đính kèm biểu đồ Redis memory + trích log. Khuyến nghị (P1): đặt TTL 5 phút cho key OTP; test lại sau khi sửa."

Dev fix trong đúng một buổi chiều.

Bài học: một finding tốt phải có đủ bốn thành phần — con số cụ thể (định lượng), điều kiện (bao nhiêu tải), bằng chứng (log/biểu đồ), và hành động khuyến nghị kèm mức ưu tiên. "Chậm, đề nghị tối ưu" không phải finding, đó là lời than.

Ví dụ 3 — So sánh baseline để chứng minh tiến bộ (startup logistics Đông Nam Á)

Một startup logistics phủ khắp Đông Nam Á tối ưu API tra cứu đơn hàng. Sau khi thêm cache, họ cần chứng minh với nhà đầu tư rằng khoản đầu tư hạ tầng có hiệu quả. QA không chỉ gửi kết quả mới, mà gửi một bảng so sánh baseline vs sau tối ưu:

Nhìn bảng này, không cần giải thích dài dòng, cả nhà đầu tư lẫn kỹ sư đều thấy rõ giá trị.

Bài học: con số chỉ có ý nghĩa khi có điểm tham chiếu. Luôn report kèm baseline (kết quả lần trước hoặc mục tiêu SLA) để biến số liệu trơ trọi thành một câu chuyện có hướng đi.

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

Đây là quy trình đọc kết quả và viết report bạn có thể áp dụng ngay sau mỗi lần test.

Bước 1 — Thu thập và xác thực dữ liệu. Trước khi diễn giải, kiểm tra dữ liệu có sạch không: test có chạy đủ thời gian không? Có bị lỗi phía load generator (client-side error) làm sai lệch số không? Ramp-up có đúng không? Đừng bao giờ report từ một lần test bị hỏng giữa chừng.

Bước 2 — Đọc các metric cốt lõi theo đúng thứ tự. Nhìn error rate trước (nếu lỗi cao thì mọi latency đều đáng ngờ), rồi percentile latency (p95, p99), rồi throughput, cuối cùng là tài nguyên server. Ghi lại số ở các mốc tải quan trọng, không chỉ số cuối.

Bước 3 — Đối chiếu với tiêu chí Pass/Fail. Lấy kết quả so với SLA/SLO đã định. Kết luận rõ ràng cho từng tiêu chí: đạt hay không đạt. Đây là "phán quyết" của report.

Bước 4 — Tìm điểm nghẽn bằng correlation. Đặt biểu đồ latency cạnh biểu đồ CPU/RAM/DB. Tìm thời điểm mọi thứ "gãy" cùng lúc. Đó là ứng cử viên nguyên nhân gốc. Ghi lại giả thuyết kèm bằng chứng.

Bước 5 — Viết Executive Summary (viết CUỐI, đặt ĐẦU). Một trang, ngôn ngữ nghiệp vụ. Dưới đây là template chuẩn:

Load Test Report — Order API — 2026-06-27
Executive Summary
Mục tiêu: Kiểm chứng /checkout chịu 2.000 concurrent user, p95 < 500ms, error < 1%.
Kết quả: FAIL. Đạt tối đa ~1.100 user ổn định trước khi p95 vượt ngưỡng.
Rủi ro: Ở tải mục tiêu, ~7% đơn có nguy cơ thất bại/timeout.
Nguyên nhân chính: DB connection pool giới hạn ở 100.
Khuyến nghị: Tăng pool + read replica; re-test. Chưa nên go-live.
Mức độ tin cậy: Cao (test 3 lần, kết quả nhất quán).

Bước 6 — Điền phần Test Details. Ghi rõ để người khác lặp lại được: công cụ (JMeter/k6), số VU, ramp-up, thời lượng, môi trường (staging/prod-like), spec server, phiên bản build. Kèm bảng metric đầy đủ.

Bước 7 — Viết Findings & Recommendations. Mỗi finding một khối: mô tả hiện tượng (định lượng) → bằng chứng → giả thuyết nguyên nhân → khuyến nghị + mức ưu tiên (P0/P1/P2). Sắp xếp theo mức độ nghiêm trọng.

Bước 8 — Rà soát trước khi gửi. Tự hỏi: người không dự buổi test đọc xong có hiểu và ra quyết định được không? Có con số nào không có ngữ cảnh không? Có claim nào không có bằng chứng không?

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

Lỗi: Chỉ report average. Như đã thấy ở ví dụ 1, average che giấu đuôi phân phối. Luôn dùng p95/p99. Với hệ thống quan trọng, thậm chí xem p99.9.

Lỗi: Đưa throughput mà quên error rate. RPS cao khi hệ thống đang trả lỗi hàng loạt là "throughput ma". Luôn ghép cặp throughput + error rate + số VU.

Lỗi: Kết luận Pass/Fail không dựa trên tiêu chí. Nếu chưa có SLA, đừng phán "hệ thống ổn". Hãy nói "chưa có tiêu chí để đánh giá pass/fail; đề xuất SLA là X".

Lỗi: Screenshot Grafana không chú thích. Ảnh biểu đồ dán vào mà không có mũi tên, không có ghi chú "đây là lúc CPU chạm trần" thì người đọc không hiểu bạn muốn chỉ ra điều gì. Luôn annotate.

Lỗi: Đổ lỗi cho hệ thống khi nghẽn nằm ở load generator. Nếu máy chạy k6/JMeter hết CPU/băng thông, số liệu bạn thu được là về máy test của bạn, không phải về hệ thống. Luôn kiểm tra sức khỏe load generator trước.

Mẹo — Dùng ngôn ngữ tác động, không chỉ ngôn ngữ kỹ thuật. Thay vì "p99 = 8s", với management hãy viết "cứ 100 khách có 1 người chờ 8 giây — nhiều người sẽ bỏ giỏ hàng". Dịch số thành hệ quả kinh doanh.

Mẹo — Luôn đính kèm mức độ tin cậy. Test một lần và test ba lần cho kết quả giống nhau có độ tin cậy rất khác. Ghi rõ để người đọc biết nên tin đến đâu.

Mẹo — Report cả điều tốt. Nếu 4/5 endpoint đạt SLA, hãy nói rõ. Report chỉ toàn màu đỏ khiến người đọc mất phương hướng; nêu cả cái đạt giúp họ khoanh vùng vấn đề.

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

• Đọc lại một kết quả thô. Lấy một file kết quả JMeter (.jtl) hoặc summary k6 bạn từng chạy. Tính/tra p50, p95, p99, error rate và RPS. So sánh p95 với average — chênh lệch bao nhiêu? Viết một câu kết luận về "nỗi đau bị average che giấu".

• Viết Executive Summary 1 trang. Dùng template ở Bước 5, viết summary cho một lần test bất kỳ. Đưa cho một người không rành kỹ thuật đọc và hỏi họ: "Bạn hiểu hệ thống pass hay fail không, và tại sao?" Nếu họ ngập ngừng, viết lại.

• Viết một finding hoàn chỉnh. Chọn một điểm nghẽn, viết finding đủ 4 phần: hiện tượng định lượng → bằng chứng → giả thuyết nguyên nhân → khuyến nghị kèm P0/P1/P2. So với chuẩn "chậm, đề nghị tối ưu" ở ví dụ 2, finding của bạn cụ thể hơn ở đâu?

• Tạo bảng so sánh baseline. Nếu bạn có hai lần test (trước/sau một thay đổi), dựng bảng so sánh như ví dụ 3 với cột "% thay đổi". Nếu chỉ có một lần test, dựng bảng "Kết quả vs SLA mục tiêu".

Tóm tắt

• Report performance là một lập luận có bằng chứng, không phải một bãi số liệu hay bộ sưu tập screenshot.
• Cấu trúc ba tầng theo người đọc: Executive Summary (pass/fail, rủi ro, khuyến nghị) → Test Details (đủ để lặp lại) → Findings & Recommendations (nguyên nhân + hành động + ưu tiên).
• Đọc metric cho đúng: ưu tiên percentile hơn average, luôn ghép throughput với error rate và số VU, và dùng correlation để tìm nguyên nhân gốc.
• Pass/Fail phải dựa trên SLA/SLO định trước, không phải cảm tính.
• Một finding tốt có đủ bốn phần: con số cụ thể, điều kiện tải, bằng chứng, khuyến nghị kèm mức ưu tiên.
• Cuối cùng, hãy dịch số thành hệ quả kinh doanh và luôn ghi rõ mức độ tin cậy — đó là thứ biến một người chạy tool thành một Performance Engineer mà cả team lẫn ban lãnh đạo tin tưởng.