Bài 37 — Performance Engineering — Load, Stress, Soak Test

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

Hãy hình dung bạn là Technical BA cho một ví điện tử. Đêm trước ngày khuyến mãi lớn, sếp hỏi: "Hệ thống chịu được bao nhiêu giao dịch một giây?". Nếu bạn chỉ trả lời "chắc là ổn thôi anh", thì sáng hôm sau khi hệ thống sập lúc 0h, người bị gọi điện đầu tiên thường là... bạn. Câu hỏi của sếp thực ra không phải câu hỏi kỹ thuật thuần túy — nó là một câu hỏi về yêu cầu phi chức năng (NFR) mà BA phải biến thành con số đo được, rồi phối hợp với đội kỹ thuật để kiểm chứng.

Đó chính là vai trò của Performance Engineering. Ở bài này, chúng ta không học cách viết script JMeter dòng nào đặt ở đâu — đó là việc của QA performance. Cái BA cần là: hiểu rõ các loại performance test khác nhau giải quyết câu hỏi gì, biết cách định nghĩa tiêu chí pass/fail bằng con số, biết đọc kết quả test để ra quyết định go/no-go, và biết viết yêu cầu test sao cho đội kỹ thuật làm đúng cái doanh nghiệp cần.

Rất nhiều dự án thất bại không phải vì code sai, mà vì không ai định nghĩa "nhanh" và "chịu tải" nghĩa là gì cho đến khi production cháy. Bài này giúp bạn trở thành người ngăn chặn điều đó từ giai đoạn phân tích yêu cầu.

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

Performance test trả lời những câu hỏi khác nhau

Sai lầm phổ biến nhất là gộp tất cả vào một khái niệm mơ hồ gọi là "test tải". Thực ra mỗi loại test trả lời một câu hỏi kinh doanh hoàn toàn khác nhau. Bạn cần phân biệt rõ để chọn đúng loại cho đúng tình huống.

Ba loại quan trọng nhất mà BA gặp thường xuyên là Load, Stress và Soak — đúng như tên bài.

Load test — kiểm chứng "bình thường thì ổn"

Load test mô phỏng lượng người dùng và giao dịch mà bạn dự kiến trong điều kiện vận hành thực tế. Mục tiêu là xác nhận: ở mức tải này, hệ thống đáp ứng các chỉ tiêu về thời gian phản hồi và tỷ lệ lỗi. Đây là loại test bạn dùng để trả lời "hệ thống có sẵn sàng go-live không".

Câu hỏi BA phải chuẩn bị trước khi load test: tải bình thường là bao nhiêu? Tải cao điểm (peak) là bao nhiêu? Con số này không tự nhiên mà có — nó đến từ phân tích nghiệp vụ: số người dùng hoạt động hàng ngày, hành vi sử dụng theo giờ, mùa cao điểm.

Stress test — tìm điểm gãy

Stress test cố tình đẩy hệ thống vượt giới hạn để tìm ra hai thứ: breaking point (ngưỡng sập) và failure mode (cách nó sập). Một hệ thống tốt khi quá tải sẽ "degrade gracefully" — chậm lại nhưng vẫn trả lỗi tử tế, không sập toàn bộ. Một hệ thống tệ thì đổ domino: một service chết kéo theo cả cụm.

Với BA, stress test cho bạn con số để đàm phán: "Hệ thống bắt đầu lỗi ở 1.200 RPS, mà cao điểm dự kiến là 800 RPS — vậy ta còn dư 50% headroom, chấp nhận được". Hoặc ngược lại: "Sập ở 850 RPS mà cao điểm là 800 — quá rủi ro, cần scale thêm".

Soak test — săn rò rỉ thầm lặng

Soak test (còn gọi endurance test) chạy hệ thống ở mức tải bình thường nhưng kéo dài rất lâu — 8, 12, có khi 24-72 giờ. Mục tiêu là phát hiện những vấn đề chỉ lộ ra theo thời gian: memory leak (rò rỉ bộ nhớ), connection pool cạn dần, log đầy ổ đĩa, file tạm không được dọn, biến đếm bị tràn.

Đây là loại test hay bị bỏ qua nhất vì tốn thời gian, nhưng lại là loại bắt được những lỗi đắt giá nhất — vì chúng chỉ xuất hiện trên production sau vài ngày chạy, đúng lúc bạn không ngờ tới.

Các chỉ số (metrics) BA bắt buộc phải hiểu

Bạn không cần đo, nhưng phải đọc được và đưa vào spec:

• Throughput (RPS/TPS): số request/giao dịch xử lý được mỗi giây. Đây là thước đo "khả năng tải".
• Latency / Response time: thời gian phản hồi. Lưu ý quan trọng: đừng bao giờ chỉ nhìn trung bình (average). Trung bình che giấu sự thật. Hãy dùng percentile: p95 (95% request nhanh hơn giá trị này), p99. Nếu p99 = 4 giây nghĩa là cứ 100 người dùng có 1 người chờ 4 giây — với hệ thống lớn đó là hàng nghìn người mỗi giờ.
• Error rate: tỷ lệ lỗi. Thường đặt ngưỡng < 0.1% hoặc < 1% tùy hệ thống.
• Concurrency / Virtual Users (VU): số người dùng đồng thời.
• Resource utilization: CPU, RAM, disk I/O, network của máy chủ. Soak test đặc biệt nhìn vào đường RAM có dốc lên đều không.

Tình huống thực tế

Tình huống 1 — Sàn TMĐT và sự kiện 12.12

Một sàn thương mại điện tử tại Việt Nam (giả định gọi là ShopViet) chuẩn bị cho sự kiện sale 12.12. BA của dự án phân tích dữ liệu năm trước: ngày thường khoảng 5.000 đơn/giờ, nhưng khung giờ flash sale 0h–1h ngày 12.12 lên tới 80.000 đơn/giờ — gấp 16 lần.

BA biến con số này thành spec test rõ ràng: Load test ở 22 đơn/giây (tải thường), Stress test đẩy dần lên xem gãy ở đâu, và đặc biệt là Spike test mô phỏng cú nhảy từ 5.000 lên 80.000 đơn/giờ trong vòng 2 phút — đúng hành vi khi đồng hồ điểm 0h.

Kết quả load test bình thường thì đẹp. Nhưng spike test phơi bày vấn đề: khi tải nhảy vọt, dịch vụ tính tồn kho (inventory) không kịp scale, p99 latency vọt lên 12 giây, một số đơn bị oversell (bán quá số lượng tồn). Đội kỹ thuật phải thêm hàng đợi (queue) đệm trước inventory và pre-warm thêm server trước giờ G.

Bài học: Load test không đủ. Với sự kiện có cú tăng đột ngột, BA phải yêu cầu thêm spike test, và con số tải phải đến từ phân tích dữ liệu lịch sử chứ không phải ước đoán.

Tình huống 2 — Ví điện tử và memory leak âm thầm

Một ví điện tử (giả định MoMoPay-like) triển khai phiên bản mới của dịch vụ xử lý giao dịch. Đội QA chạy load test 2 giờ, mọi chỉ số xanh, p95 dưới 300ms, error rate gần 0. Họ go-live.

Bốn ngày sau, vào lúc 2h sáng, dịch vụ bắt đầu chậm dần rồi tự restart liên tục. Nguyên nhân: một memory leak nhỏ — mỗi giao dịch giữ lại vài KB bộ nhớ không được giải phóng. Trong 2 giờ test không đủ tích lũy để lộ, nhưng sau 4 ngày với hàng triệu giao dịch, RAM cạn kiệt.

Sau sự cố, BA đưa vào "definition of done" cho mọi release của dịch vụ tài chính: bắt buộc có soak test tối thiểu 12 giờ ở mức tải production trước khi go-live, với tiêu chí "đường RAM phải đi ngang (flat), không dốc lên".

Bài học: Test ngắn cho cảm giác an toàn giả. Những lỗi đắt giá nhất trong hệ thống tài chính thường là lỗi tích lũy theo thời gian — chỉ soak test bắt được.

Tình huống 3 — Ngân hàng số và bài học "degrade gracefully"

Một ngân hàng số ở Đông Nam Á chạy stress test cho hệ thống chuyển khoản trước khi mở campaign mở tài khoản miễn phí. Stress test cho thấy breaking point ở 1.500 TPS. Nhưng điều quan trọng hơn con số: khi vượt ngưỡng, hệ thống không trả lỗi tử tế. Thay vào đó, các request bị treo, connection pool tới database cạn, và cả các giao dịch đang xử lý dở cũng bị kẹt — một số khách hàng bị trừ tiền nhưng không nhận được tiền.

BA cùng kiến trúc sư định nghĩa lại yêu cầu phi chức năng: hệ thống phải có cơ chế circuit breaker và trả về thông báo "Hệ thống đang bận, vui lòng thử lại" khi vượt 80% ngưỡng tải, thay vì để treo. Họ chạy lại stress test với tiêu chí mới: ở mức quá tải, error rate có thể cao nhưng tuyệt đối không được có giao dịch "treo nửa chừng".

Bài học: Stress test không chỉ tìm con số breaking point. Quan trọng hơn là quan sát cách hệ thống sập, và biến quan sát đó thành yêu cầu thiết kế cho khả năng phục hồi.

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

Đây là quy trình một Technical BA tham gia vào hoạt động performance engineering, từ phân tích đến đọc kết quả.

Bước 1 — Thu thập số liệu tải từ nghiệp vụ. Trước khi nói chuyện về test, hãy trả lời: Bao nhiêu người dùng đồng thời ở giờ thường? Giờ cao điểm? Có sự kiện đột biến nào (sale, lương về, đầu tháng)? Lấy số từ dữ liệu lịch sử (Google Analytics, log production, báo cáo nghiệp vụ), không đoán mò. Nếu là hệ thống mới, ước lượng từ business plan: ví dụ "100.000 user, 10% active hàng ngày, mỗi user 5 giao dịch".

Bước 2 — Định nghĩa tiêu chí pass/fail bằng con số (SLA/SLO). Viết rõ ràng và đo được. Ví dụ: "p95 latency ≤ 500ms, p99 ≤ 1s, error rate < 0.1%, throughput ≥ 800 RPS". Tránh câu chữ mơ hồ như "hệ thống phải nhanh".

Bước 3 — Chọn loại test phù hợp. Map từng câu hỏi kinh doanh sang loại test: "Go-live có ổn không?" → Load. "Chịu được tới đâu?" → Stress. "Chạy lâu có sao không?" → Soak. "Sự kiện sale thì sao?" → Spike.

Bước 4 — Xác định kịch bản (scenario) và tỷ trọng. Hệ thống thực không chỉ làm một việc. BA mô tả các luồng chính và tỷ lệ: ví dụ 60% xem sản phẩm, 25% thêm giỏ hàng, 15% thanh toán. Test phải phản ánh đúng mix này, không phải chỉ bắn một endpoint.

Bước 5 — Chuẩn bị test data và môi trường. Lưu ý: môi trường test nên giống production về cấu hình (hoặc theo tỷ lệ biết trước). Database phải có lượng dữ liệu tương đương production — test trên DB rỗng cho kết quả vô nghĩa vì không có index nào bị áp lực.

Bước 6 — Phối hợp với QA performance chạy test. BA không viết script nhưng review kịch bản, xác nhận đúng nghiệp vụ, và theo dõi cùng.

Bước 7 — Đọc kết quả và ra quyết định. Nhìn percentile chứ không nhìn trung bình. Đối chiếu với tiêu chí ở Bước 2. So sánh breaking point với peak dự kiến để tính headroom. Với soak test, kiểm tra đường tài nguyên có đi ngang không.

Bước 8 — Viết khuyến nghị go/no-go. Tổng hợp thành báo cáo cho stakeholder bằng ngôn ngữ kinh doanh: "Hệ thống đáp ứng tải cao điểm dự kiến với 40% dư địa. Khuyến nghị go-live, nhưng cần soak test 12h trước khi mở campaign vì chưa kiểm chứng độ bền dài hạn."

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

Chỉ nhìn average latency. Đây là lỗi kinh điển. Trung bình 200ms nghe rất đẹp, nhưng nếu p99 là 5 giây thì hàng nghìn khách hàng đang khổ sở. Luôn yêu cầu báo cáo theo percentile (p50, p95, p99).

Test trên môi trường không giống production. Test trên server yếu hơn, DB rỗng, hoặc thiếu cache layer → kết quả không có giá trị. Hãy làm rõ tỷ lệ giữa môi trường test và production để biết cách quy đổi.

Bỏ qua soak test vì "tốn thời gian". Như tình huống 2 cho thấy, đây thường là test bắt được lỗi đắt nhất. Với hệ thống tài chính, ngân hàng, đừng bao giờ bỏ.

Quên think time. Người dùng thật không bắn request liên tục — họ đọc, suy nghĩ, gõ. Nếu script không có "think time" giữa các bước, bạn tạo ra tải không thực tế (quá nặng hoặc sai phân bố).

Không định nghĩa tải dựa trên dữ liệu. Con số tải bịa ra ("chắc 1000 user") làm toàn bộ bài test mất ý nghĩa. Luôn truy ngược về dữ liệu nghiệp vụ.

Lẫn lộn stress test và load test. Load test xác nhận "bình thường thì ổn"; stress test tìm "gãy ở đâu". Đừng dùng kết quả load test để khẳng định giới hạn của hệ thống.

Mẹo — luôn theo dõi cả phía server, không chỉ phía client. Số liệu từ tool test (response time) chỉ là một nửa câu chuyện. Phải nhìn CPU, RAM, DB connection của server mới hiểu vì sao chậm. (Việc quan sát sâu hơn về logs, metrics, traces sẽ được nói kỹ ở bài Observability.)

Mẹo — đặt baseline. Lưu lại kết quả của lần test đầu làm mốc. Mỗi release sau so với baseline để phát hiện hồi quy hiệu năng (performance regression) sớm.

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

Bài 1 — Định nghĩa tiêu chí. Bạn là BA cho một app đặt món ăn. Giờ cao điểm là 11h–13h và 18h–20h. Hãy viết một bộ tiêu chí pass/fail (SLO) cho load test gồm: throughput mục tiêu, p95/p99 latency, error rate. Tự đưa ra giả định về số đơn/giờ và giải thích con số đến từ đâu.

Bài 2 — Chọn loại test. Với mỗi tình huống sau, hãy chọn loại test (Load/Stress/Soak/Spike) và giải thích trong một câu: (a) Sắp có chương trình "săn voucher 0h"; (b) Cần biết hệ thống chịu được tối đa bao nhiêu để lập kế hoạch hạ tầng; (c) Hệ thống chạy ổn nhưng cuối tuần hay tự chậm dần; (d) Xác nhận hệ thống sẵn sàng go-live cho tải hàng ngày.

Bài 3 — Đọc kết quả. Một soak test 12 giờ cho thấy: error rate ổn định 0.05%, p95 latency tăng từ 220ms (giờ đầu) lên 480ms (giờ thứ 12), và RAM tăng tuyến tính từ 40% lên 78%. Hệ thống pass hay fail? Bạn khuyến nghị gì với đội kỹ thuật?

Bài 4 — Truy ngược con số. Cho business plan: 200.000 người dùng đăng ký, ước tính 8% hoạt động mỗi ngày, mỗi người trung bình 6 thao tác, tập trung 70% vào khung 4 giờ cao điểm. Hãy tính throughput mục tiêu (RPS) cho khung cao điểm và trình bày cách tính.

Tóm tắt

• Performance engineering là cách BA biến yêu cầu phi chức năng mơ hồ ("phải nhanh", "phải chịu tải") thành con số đo được và kiểm chứng được.
• Load test xác nhận hệ thống ổn ở tải dự kiến; Stress test tìm ngưỡng sập và cách sập; Soak test săn lỗi tích lũy theo thời gian như memory leak. Thêm Spike test cho các sự kiện đột biến.
• Luôn đọc latency theo percentile (p95, p99), không bao giờ chỉ nhìn trung bình.
• Con số tải phải đến từ dữ liệu nghiệp vụ thật, và tiêu chí pass/fail phải viết rõ ràng, đo được trước khi test.
• Vai trò BA: thu thập số liệu tải, định nghĩa SLO, chọn đúng loại test, mô tả kịch bản đúng nghiệp vụ, đọc kết quả và đưa khuyến nghị go/no-go bằng ngôn ngữ kinh doanh.
• Đừng bao giờ bỏ soak test với hệ thống tài chính, và luôn quan sát cả phía server để hiểu nguyên nhân, không chỉ con số phía client.