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ử. Marketing vừa chốt một chiến dịch flash sale lúc 0 giờ ngày 12/12, ngân sách quảng cáo 2 tỷ đồng, kỳ vọng kéo về gấp 8 lần lượng truy cập so với ngày thường. Câu hỏi đầu tiên mà CEO hỏi bạn không phải "banner màu gì" mà là: "Hệ thống có chịu nổi không?". Nếu bạn không trả lời được câu hỏi đó bằng dữ liệu, bạn không phải Technical PM — bạn đang đánh bạc với doanh thu và uy tín của công ty.
Load testing (kiểm thử tải) và capacity planning (lập kế hoạch năng lực) chính là cách bạn biến câu hỏi "có chịu nổi không" từ phỏng đoán thành một con số có cơ sở. Đây là kỹ năng phân biệt giữa một PM "nói chuyện được với engineer" và một PM thật sự dẫn dắt được quyết định kỹ thuật trước những thời điểm sống còn: ra mắt sản phẩm, mùa sale, gọi vốn cần demo trước nhà đầu tư, hay onboard một khách hàng enterprise lớn.
Điều quan trọng cần hiểu ngay: load testing không phải việc "của riêng đội QA". PM là người duy nhất biết expected traffic (lưu lượng kỳ vọng) sẽ là bao nhiêu, vì bạn nắm dự báo kinh doanh, lịch chiến dịch, và mục tiêu tăng trưởng. Nếu bạn đưa sai con số đầu vào, mọi bài test bên dưới đều vô nghĩa. Bài này giúp bạn hiểu đủ sâu để chủ trì cuộc trò chuyện đó, đặt đúng câu hỏi, và đọc đúng kết quả.
Khái niệm cốt lõi
Phân biệt các loại kiểm thử tải
Nhiều người gộp chung tất cả vào hai chữ "load test", nhưng thực ra có vài loại khác nhau, mỗi loại trả lời một câu hỏi khác nhau:
Load test (kiểm thử tải thường): Mô phỏng đúng lượng traffic kỳ vọng — thường là daily peak (đỉnh trong ngày). Mục tiêu là xác nhận hệ thống xử lý ổn định ở mức tải thực tế, đáp ứng đúng các chỉ tiêu về thời gian phản hồi và tỷ lệ lỗi. Đây là bài test "liệu mình có sống sót qua một ngày bình thường không".
Stress test (kiểm thử ép tải): Cố tình đẩy tải vượt qua năng lực dự kiến, tăng dần cho đến khi hệ thống gãy. Mục tiêu là tìm breaking point (điểm gãy) — con số mà tại đó hệ thống bắt đầu sụp. Stress test trả lời câu hỏi: "Mình chịu được tối đa bao nhiêu, và khi gãy thì gãy như thế nào?". Một hệ thống tốt khi quá tải sẽ chậm lại có kiểm soát (graceful degradation), chứ không sụp đổ toàn bộ (cascading failure).
Spike test (kiểm thử tăng đột ngột): Tăng tải lên rất nhanh trong thời gian ngắn rồi rút về. Đây chính là kịch bản flash sale: 0 giờ mở bán, traffic nhảy vọt trong 30 giây. Khác với stress test (tăng từ từ), spike test kiểm tra khả năng hệ thống phản ứng tức thời — auto-scaling kịp không, cache có sập không.
Soak test (kiểm thử ngâm tải / endurance test): Giữ tải ở mức vừa phải nhưng kéo dài nhiều giờ, thậm chí nhiều ngày. Mục tiêu là phát hiện các vấn đề tích lũy như memory leak (rò rỉ bộ nhớ), kết nối database không được giải phóng, đĩa đầy dần vì log. Nhiều hệ thống qua được load test 30 phút nhưng chết sau 8 tiếng chạy thật.
Ba chỉ số bạn phải đọc được
Khi nhìn báo cáo load test, đừng để bị ngợp. Tập trung vào ba nhóm con số (gắn liền với bài trước về latency, throughput, availability):
- Throughput: số request hệ thống xử lý mỗi giây, thường gọi là RPS (requests per second) hoặc QPS (queries per second).
- Latency / response time: thời gian phản hồi. Tuyệt đối không chỉ nhìn trung bình (average) — hãy nhìn percentile: p95, p99. p99 = 800ms nghĩa là 99% request nhanh hơn 800ms, còn 1% chậm hơn. 1% nghe nhỏ nhưng với 1 triệu request/ngày là 10.000 khách hàng có trải nghiệm tệ.
- Error rate: tỷ lệ request lỗi. Khi tải tăng, error rate thường bật lên đột ngột tại breaking point — đó là dấu hiệu rõ nhất bạn đã chạm giới hạn.
Capacity planning là gì
Capacity planning là quá trình trả lời: "Với lượng người dùng dự báo, mình cần bao nhiêu tài nguyên (server, database, băng thông) để phục vụ ổn định, và chi phí bao nhiêu?". Nó là cây cầu nối giữa dự báo kinh doanh (PM nắm) và hạ tầng kỹ thuật (engineer nắm).
Công thức tư duy cốt lõi mà mọi Technical PM nên thuộc:
> Capacity cần thiết = Peak traffic dự báo × Hệ số an toàn (headroom)
Headroom (vùng dự phòng) thường là 1.5–2 lần, vì bạn cần dư địa cho sai số dự báo, cho lúc một phần hạ tầng hỏng, và cho tăng trưởng giữa hai lần nâng cấp. Một hệ thống chạy thường xuyên ở 90% công suất là một hệ thống chỉ cách thảm họa đúng một cú spike.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT Việt Nam và đêm 12/12
Một sàn TMĐT cỡ vừa tại Việt Nam (giả định tên "ChợViệt") có daily peak khoảng 3.000 RPS vào giờ tối. Chiến dịch 12/12 dự báo gấp 8 lần, tức ~24.000 RPS, và quan trọng hơn — phần lớn dồn vào 2 phút đầu khi mở bán.
PM cùng đội kỹ thuật chạy spike test mô phỏng cú nhảy từ 3.000 lên 24.000 RPS trong 30 giây. Kết quả: tới khoảng 11.000 RPS, p99 latency của API "thêm vào giỏ hàng" nhảy từ 200ms lên 6 giây, error rate vọt lên 12%. Đào sâu thì thấy nghẽn ở một query kiểm tra tồn kho khóa cả dòng dữ liệu (lock contention) ở database.
Đội xử lý bằng cách đưa số liệu tồn kho lên cache Redis và xử lý trừ kho theo hàng đợi bất đồng bộ. Test lại đạt 26.000 RPS với p99 dưới 900ms. Bài học: breaking point thực tế (11.000) thấp hơn nhiều so với phỏng đoán dựa trên peak thường (3.000 × headroom). Nếu không spike test, ChợViệt đã sập đúng 2 phút quan trọng nhất năm — và 2 tỷ tiền quảng cáo đổ vào một trang lỗi.
Tình huống 2 — Startup fintech và buổi demo gọi vốn
Một startup ví điện tử ở Đông Nam Á chuẩn bị demo trước quỹ đầu tư, cam kết "phục vụ được 1 triệu người dùng". PM yêu cầu load test ở mức kỳ vọng và mọi thứ xanh đẹp trong 30 phút. Nhưng khi đội thêm soak test chạy 10 tiếng ở mức tải trung bình, RAM của service xác thực tăng đều và sập sau giờ thứ 7 — một memory leak ở thư viện tạo JWT.
Nếu chỉ load test ngắn, lỗi này không bao giờ lộ ra; nó sẽ phát nổ vào tuần thứ hai sau khi nhận vốn, đúng lúc nhiều mắt đang nhìn vào. Bài học: "qua được peak" không đồng nghĩa với "chạy bền". Với hệ thống tài chính cần uptime cao, soak test là bắt buộc, không phải tùy chọn.
Tình huống 3 — App đặt đồ ăn và cú headroom sai
Một app giao đồ ăn dự báo giờ ăn trưa peak 5.000 RPS, đội hạ tầng cấu hình auto-scaling tối đa đúng 5.000 RPS để "tiết kiệm chi phí cloud". Một ngày trời mưa lớn ở TP.HCM, ai cũng ngại ra ngoài, traffic thực tế chạm 7.200 RPS. Hệ thống không có headroom, auto-scaling đụng trần, đơn hàng rớt, khách bỏ app.
Sau sự cố, PM đặt lại chính sách: cấu hình trần auto-scaling ở mức 1.8 lần peak dự báo, và thêm cảnh báo khi tải vượt 70% trần. Chi phí cloud tăng nhẹ ở phần dự phòng, nhưng đổi lại không mất doanh thu vào đúng những ngày nhu cầu cao bất thường. Bài học: capacity planning không phải tối ưu chi phí về 0, mà là cân bằng giữa chi phí và rủi ro mất doanh thu. Những ngày "bất thường" chính là những ngày kiếm được nhiều tiền nhất.
Hướng dẫn từng bước
Đây là quy trình một Technical PM nên chủ trì cùng đội kỹ thuật:
Bước 1 — Xác định mục tiêu và SLO. Trước khi test, chốt tiêu chí "đạt": ví dụ p99 < 1 giây, error rate < 0.5%, ở mức traffic X. Không có ngưỡng "đạt", bạn không biết test thành công hay thất bại.
Bước 2 — Dự báo traffic đầu vào. Đây là phần PM đóng góp giá trị nhất. Lấy số từ dữ liệu lịch sử (peak ngày thường, peak mùa sale gần nhất), nhân với kỳ vọng tăng trưởng từ kế hoạch kinh doanh. Ghi rõ cả số trung bình lẫn số đỉnh, và mô tả hình dạng traffic (tăng từ từ hay nhảy vọt).
Bước 3 — Thiết kế kịch bản thực tế. Đừng chỉ bắn một API. Mô phỏng hành vi người dùng thật: tỷ lệ duyệt sản phẩm, thêm giỏ, thanh toán đúng như thực tế. Một bài test 90% chỉ đọc dữ liệu sẽ cho kết quả sai lệch nếu thực tế có nhiều thao tác ghi.
Bước 4 — Chọn loại test phù hợp với rủi ro. Sắp ra mắt thường ngày thì load test. Có flash sale thì thêm spike test. Hệ thống cần chạy bền 24/7 thì thêm soak test. Muốn biết giới hạn thật thì stress test.
Bước 5 — Chạy trên môi trường giống production. Test trên một server nhỏ rồi suy ra production là sai lầm kinh điển. Dùng môi trường staging có cấu hình tương đương, dữ liệu có khối lượng tương đương (1 triệu bản ghi hành xử rất khác 1.000 bản ghi).
Bước 6 — Đọc kết quả và tìm nút thắt cổ chai (bottleneck). Nhìn xem chỉ số nào gãy trước: CPU, RAM, database connection, hay băng thông. Bottleneck thường nằm ở một điểm duy nhất — thường là database.
Bước 7 — Tính capacity và chốt headroom. Từ breaking point, lùi lại nhân hệ số an toàn để ra cấu hình production. Quyết định ngưỡng auto-scaling và ngưỡng cảnh báo.
Bước 8 — Lặp lại định kỳ. Code thay đổi, traffic tăng. Một bài test sáu tháng trước không còn giá trị. Đưa load test vào lịch định kỳ và trước mỗi sự kiện lớn.
Lỗi thường gặp & mẹo
- Chỉ nhìn latency trung bình. Average che giấu thảm họa. Một PM giỏi luôn hỏi "p99 là bao nhiêu?".
- Test trên môi trường tí hon rồi ngoại suy. Kết quả ở quy mô nhỏ không tuyến tính với quy mô lớn — nghẽn xuất hiện đột ngột, không theo đường thẳng.
- Quên test thành phần phụ thuộc bên thứ ba. Cổng thanh toán, SMS OTP, API đối tác có thể có rate limit riêng. Hệ thống của bạn nhanh không cứu được nếu đối tác chặn bạn ở 1.000 RPS.
- Dùng dữ liệu test quá sạch. Cache "ấm" sẵn cho kết quả đẹp giả tạo. Hãy test cả kịch bản cache lạnh (cold cache) như khi vừa deploy xong.
- Coi load test là việc một lần. Hãy biến nó thành thói quen định kỳ.
- Mẹo headroom: giữ production chạy dưới 60–70% công suất ở peak thường. Phần dư là bảo hiểm cho ngày bất thường.
- Mẹo giao tiếp: khi báo cáo cho lãnh đạo, dịch con số kỹ thuật sang ngôn ngữ kinh doanh: "Hệ thống chịu được 26.000 RPS, tức gấp 1.8 lần dự báo 12/12, dư địa an toàn cho cả tình huống traffic vượt kỳ vọng 80%".
Bài tập thực hành
- Dự báo và đặt SLO: Chọn một sản phẩm bạn đang làm (hoặc một app bạn dùng hàng ngày). Ước lượng daily peak RPS dựa trên số người dùng và hành vi. Viết ra một SLO cụ thể: ngưỡng p99, error rate, ở mức traffic nào.
- Thiết kế kịch bản: Liệt kê 5 hành động chính của người dùng và ước lượng tỷ lệ phần trăm mỗi hành động trong tổng traffic. Đây chính là "mô hình tải" để đưa cho engineer.
- Chọn loại test: Cho ba tình huống — (a) ra mắt tính năng mới ngày thường, (b) flash sale Black Friday, (c) hệ thống ngân hàng chạy 24/7 — hãy chọn loại test phù hợp và giải thích trong một câu mỗi loại.
- Tính capacity: Daily peak dự báo 4.000 RPS, sự kiện sắp tới dự báo gấp 5 lần. Với headroom 1.7, bạn cần hệ thống chịu được tối thiểu bao nhiêu RPS? Auto-scaling nên đặt trần ở đâu?
Tóm tắt
Load testing trả lời câu hỏi "hệ thống chịu được bao nhiêu", còn capacity planning trả lời "mình cần chuẩn bị bao nhiêu tài nguyên". Là Technical PM, bạn không cần viết script test, nhưng bạn là người cung cấp đầu vào quan trọng nhất — dự báo traffic — và là người đọc kết quả để ra quyết định kinh doanh.
Hãy nhớ bốn loại test: load (xác nhận chịu được peak thường), stress (tìm breaking point), spike (kiểm tra cú nhảy đột ngột như flash sale), và soak (phát hiện lỗi tích lũy theo thời gian). Luôn đọc latency theo percentile p95/p99 chứ không phải trung bình. Luôn để headroom 1.5–2 lần. Và luôn nhớ: những ngày traffic bất thường cũng chính là những ngày quan trọng nhất với doanh thu — đừng để hệ thống gãy đúng lúc bạn cần nó nhất.