Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Technical BA của một sàn thương mại điện tử. Marketing vừa chốt một chiến dịch "Ngày đôi" 12/12 với kỳ vọng lượng khách tăng gấp 8 lần ngày thường. Câu hỏi mà sếp đặt ra cho bạn không phải "tính năng đã sẵn sàng chưa", mà là: "Hệ thống có chịu nổi không? Cần thêm bao nhiêu server? Tốn bao nhiêu tiền? Và nếu không kịp thì điều gì sẽ gãy trước?".
Đó chính là Capacity Planning — lập kế hoạch năng lực hệ thống. Nó trả lời câu hỏi: liệu hệ thống có đủ tài nguyên (CPU, RAM, băng thông, dung lượng lưu trữ, số kết nối database…) để phục vụ tải dự kiến trong N tháng hoặc N năm tới hay không, với chi phí tối ưu nhất.
Nhiều người nghĩ đây là việc của DevOps hay SRE. Đúng một phần, nhưng người nắm rõ nghiệp vụ tạo ra tải lại là BA. Bạn là người biết campaign nào sắp chạy, phân khúc khách hàng nào đang tăng trưởng, hợp đồng B2B nào vừa ký kéo theo bao nhiêu giao dịch mỗi ngày. Không có những input nghiệp vụ đó, mọi con số kỹ thuật chỉ là phỏng đoán. Một Technical BA giỏi là cây cầu nối giữa "kế hoạch kinh doanh" và "năng lực hạ tầng" — và Capacity Planning chính là nơi cây cầu đó được kiểm chứng bằng tiền thật.
Bài này tập trung vào tư duy và phương pháp ước lượng năng lực, dự báo tải (forecasting), và cách BA viết ra một bản kế hoạch capacity thuyết phục được cả team kỹ thuật lẫn ban lãnh đạo.
Khái niệm cốt lõi
Capacity Planning là gì và khác gì với Performance Test
Hai khái niệm này hay bị nhầm. Performance Test (đã có bài riêng) trả lời câu hỏi "với cấu hình hiện tại, hệ thống chịu được bao nhiêu?". Còn Capacity Planning dùng kết quả đó cộng với dự báo tăng trưởng để trả lời "trong tương lai tôi cần chuẩn bị bao nhiêu tài nguyên?".
Nói cách khác: performance test cho bạn biết "trần" hiện tại; capacity planning cho bạn biết bao giờ bạn sẽ chạm trần đó và phải nâng trần lúc nào.
Bốn nhóm input bắt buộc
Một bản capacity plan tốt luôn bắt đầu từ dữ liệu, không phải cảm tính. Có bốn nhóm input:
1. Current usage (mức sử dụng hiện tại): Đây là baseline. Các chỉ số phổ biến:
- RPS / TPS (Requests / Transactions per second) — số request hoặc giao dịch mỗi giây.
- Concurrent users — số người dùng đồng thời.
- Data volume — dung lượng dữ liệu sinh ra mỗi ngày (GB/day) và tổng tích lũy.
- Resource utilization — phần trăm CPU, RAM, IOPS, băng thông đang dùng.
3. Peak factor (hệ số đỉnh tải): Tải không bao giờ trải đều. Một ngân hàng có đỉnh vào lúc trả lương cuối tháng; một app gọi xe có đỉnh giờ tan tầm; một sàn TMĐT có đỉnh ngày sale. Tỷ số Peak / Average thường từ 3 đến 10 lần, có khi hơn.
4. SLO / SLA mục tiêu: Bạn muốn giữ độ trễ p95 dưới bao nhiêu ms? Uptime 99.9% hay 99.99%? Mục tiêu càng cao thì càng cần dư địa (headroom) tài nguyên lớn, càng tốn tiền.
Headroom — vùng đệm an toàn
Đây là khái niệm quan trọng mà BA hay quên. Bạn không bao giờ lập kế hoạch để hệ thống chạy ở 100% công suất, vì khi đó chỉ cần một biến động nhỏ là sập. Quy tắc thực dụng: lập kế hoạch để tải đỉnh dự kiến không vượt quá 60–70% công suất tối đa. Phần 30–40% còn lại là headroom để hấp thụ đột biến, hỏng hóc một node, hay sai số dự báo.
Little's Law — công thức nền tảng
Một công thức kinh điển bạn nên thuộc lòng:
> L = λ × W
Trong đó L là số request đang xử lý đồng thời (concurrency), λ là tốc độ đến (arrival rate, RPS), W là thời gian xử lý trung bình mỗi request (latency). Ví dụ: nếu hệ thống nhận 200 RPS và mỗi request mất trung bình 0,5 giây, thì luôn có khoảng 100 request "trong người" cùng lúc. Con số này quyết định bạn cần bao nhiêu thread, bao nhiêu connection pool, bao nhiêu instance.
Forecasting — nghệ thuật dự báo tải
Dự báo có ba cách tiếp cận chính:
- Trend-based: ngoại suy theo xu hướng lịch sử (ví dụ mỗi tháng tăng 8%).
- Event-based: dựa trên sự kiện đã biết (sắp có campaign, sắp onboard khách lớn).
- Seasonal: dựa trên tính mùa vụ (Tết, Black Friday, ngày đôi, lương cuối tháng).
Tình huống thực tế
Tình huống 1 — Sàn TMĐT chuẩn bị ngày đôi 12/12
Một sàn TMĐT tại Việt Nam (gọi là ShopViet) có baseline ngày thường: 1.500 RPS trung bình, đỉnh 4.500 RPS vào 21h. Hệ thống checkout chạy trên 12 instance, mỗi instance test ra chịu được tối đa 500 RPS trước khi p95 latency vượt 800ms.
BA ngồi với Marketing và lấy được con số: campaign 12/12 kỳ vọng traffic gấp 8 lần đỉnh ngày thường, tập trung vào khung "flash sale" lúc 0h và 12h trưa. Phép tính:
- Đỉnh dự kiến: 4.500 × 8 = 36.000 RPS.
- Công suất hiện tại: 12 × 500 = 6.000 RPS — chỉ đáp ứng 1/6.
- Áp dụng quy tắc headroom 65%: cần công suất tối đa khoảng 36.000 / 0,65 ≈ 55.000 RPS.
- Số instance cần: 55.000 / 500 = 110 instance.
Bài học: Đừng nhân một hệ số tăng trưởng duy nhất cho toàn hệ thống. Mỗi service có pattern tải khác nhau. Việc của BA là bóc tách flow nghiệp vụ để biết phần nào thực sự bị tải — đó là chỗ tiết kiệm được nhiều tiền nhất.
Tình huống 2 — Ví điện tử và bài toán dung lượng dữ liệu 3 năm
Một ví điện tử Đông Nam Á (gọi là PayGo) cần lập capacity plan lưu trữ cho 3 năm. Hiện tại: 4 triệu người dùng active, mỗi người trung bình 6 giao dịch/tháng, mỗi bản ghi giao dịch (kèm log, audit trail) khoảng 4 KB.
BA tính dung lượng phát sinh:
- Hiện tại: 4tr × 6 × 4 KB = 96 GB/tháng, tức ~1,15 TB/năm.
- Giả định tăng trưởng người dùng 5%/tháng (kế hoạch kinh doanh) và tần suất giao dịch tăng dần lên 9 lần/tháng năm thứ 3.
- Cộng dồn theo mô hình lãi kép, sau 3 năm tổng dữ liệu giao dịch ước khoảng 18–22 TB, chưa kể index và bản sao replica nhân đôi/nhân ba con số.
Bài học: Capacity không chỉ là CPU và RPS. Dung lượng dữ liệu là khoản phình to âm thầm và compliance thường ép bạn giữ dữ liệu rất lâu. BA hiểu nghiệp vụ truy vấn (ai đọc gì, đọc dữ liệu cũ tới mức nào) sẽ tìm ra cách phân tầng lưu trữ tiết kiệm khổng lồ.
Tình huống 3 — Ngân hàng onboard khách doanh nghiệp lớn
Một ngân hàng số tại Việt Nam vừa ký hợp đồng làm cổng thanh toán cho một chuỗi siêu thị lớn. Hợp đồng SLA cam kết p99 latency dưới 300ms và uptime 99,95%. Khách hàng này sẽ đẩy thêm khoảng 2 triệu giao dịch/ngày, dồn 40% vào khung 17h–20h.
BA dùng Little's Law để ước lượng concurrency cần thiết: đỉnh giờ cao điểm khoảng (2tr × 0,4) / (3 giờ × 3600 giây) ≈ 74 TPS trung bình trong khung đỉnh, nhưng burst thực tế gấp 3 → ~220 TPS. Với latency xử lý 150ms, concurrency = 220 × 0,15 ≈ 33 giao dịch đồng thời. Từ đó họ tính ra connection pool tới core banking, số thread, và số instance cần thêm.
Điểm gãy được phát hiện không nằm ở application server mà ở database connection limit của hệ thống core banking cũ — chỉ cho phép tối đa 200 connection, và các hệ thống khác đã dùng 160. BA báo cáo đây là bottleneck nghiêm trọng và kiến nghị thương lượng lại timeline onboard, đồng thời mở dự án nâng cấp core trước.
Bài học: Capacity planning hay phát lộ ra điểm nghẽn ở nơi bạn không ngờ — thường là một hệ thống legacy phía sau. Việc đưa khách lớn vào không chỉ là "thêm server", mà là kiểm tra toàn bộ chuỗi phụ thuộc. BA là người nhìn được toàn cảnh end-to-end đó.
Hướng dẫn từng bước
Đây là quy trình 7 bước để bạn tự lập một bản capacity plan:
Bước 1 — Thu thập baseline. Lấy số liệu thực 4–8 tuần gần nhất: RPS/TPS trung bình và đỉnh, concurrent users, data volume/ngày, % CPU/RAM/IOPS. Lấy từ APM/monitoring, đừng đoán.
Bước 2 — Xác định peak factor. Vẽ biểu đồ tải theo giờ/ngày/tuần để thấy tỷ số Peak/Average. Ghi rõ các đỉnh mùa vụ (Tết, cuối tháng, ngày sale).
Bước 3 — Lấy growth assumptions từ business. Ngồi với sales, marketing, product để lấy: kế hoạch tăng user, campaign sắp tới, khách B2B sắp onboard. Quy mọi giả định thành con số % tăng trưởng theo tháng.
Bước 4 — Dựng ba kịch bản dự báo. Conservative / Expected / Aggressive. Ngoại suy baseline theo growth + peak factor cho từng mốc thời gian (3, 6, 12, 24 tháng).
Bước 5 — Tính tài nguyên cần và áp headroom. Chia tải dự kiến cho công suất một đơn vị, rồi chia tiếp cho mức headroom 65–70%. Làm cho từng service riêng, đừng gộp.
Bước 6 — Định giá và tối ưu chi phí. Quy số instance/storage ra tiền theo bảng giá cloud. Cân nhắc auto-scaling, reserved instance, data tiering, caching để giảm số tài nguyên thường trực.
Bước 7 — Viết kế hoạch và trigger điểm hành động. Nêu rõ: khi nào cần scale (ví dụ "khi CPU đỉnh chạm 70% trong 3 ngày liên tiếp thì kích hoạt nâng cấp"). Đây gọi là capacity trigger — biến kế hoạch tĩnh thành quy trình vận hành sống.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng tải trung bình thay vì tải đỉnh. Hệ thống sập ở đỉnh, không phải ở trung bình. Một hệ thống average 1.000 RPS nhưng đỉnh 8.000 RPS phải được lập kế hoạch cho 8.000, không phải 1.000.
Lỗi 2 — Nhân một hệ số tăng trưởng cho toàn hệ thống. Như tình huống ShopViet, mỗi service có pattern riêng. Gộp chung dẫn đến vừa thừa chỗ này vừa thiếu chỗ kia.
Lỗi 3 — Quên headroom. Lập kế hoạch sát 100% công suất là tự sát. Luôn chừa 30–40%.
Lỗi 4 — Bỏ qua dependency phía sau. Application server scale dễ, nhưng database, third-party API, legacy core thường có giới hạn cứng. Hãy kiểm tra cả chuỗi.
Lỗi 5 — Lập kế hoạch một lần rồi quên. Capacity plan phải được rà soát định kỳ (quý/6 tháng) đối chiếu dự báo với thực tế để hiệu chỉnh.
Mẹo: Luôn trình bày capacity dưới dạng đơn vị tiền và rủi ro, không phải đơn vị kỹ thuật khô khan. Ban lãnh đạo không hiểu "cần thêm 40 instance", nhưng hiểu rất rõ "nếu không đầu tư 300 triệu, campaign 12/12 có 70% khả năng sập trong 2 tiếng vàng, mất doanh thu ước tính 5 tỷ".
Mẹo: Phân biệt scale up (nâng cấu hình một máy) và scale out (thêm máy). Scale out linh hoạt và rẻ hơn cho tải biến động lớn theo mùa vụ; scale up phù hợp các thành phần khó chia nhỏ như database.
Mẹo: Đừng chỉ tính "đủ", hãy tính cả thời điểm chạm trần (runway). Câu trả lời giá trị nhất bạn đưa cho team không phải "cần bao nhiêu" mà là "còn bao nhiêu tháng nữa trước khi sập nếu không làm gì".
Bài tập thực hành
Bài 1 — Tính tài nguyên cơ bản. Một app giao đồ ăn có baseline đỉnh 3.000 RPS, mỗi instance chịu 400 RPS. Kế hoạch năm tới tăng trưởng user khiến đỉnh tăng 2,5 lần. Áp headroom 65%. Hỏi: cần bao nhiêu instance ở mốc cuối năm? (Gợi ý: tính đỉnh mới → chia headroom → chia công suất/instance.)
Bài 2 — Dự báo dung lượng. Một hệ thống log sinh 50 GB/ngày, tăng đều 6%/tháng. Tính tổng dung lượng tích lũy sau 12 tháng. Sau đó đề xuất một chiến lược tiering nếu chỉ 10% log được truy vấn sau 30 ngày.
Bài 3 — Tình huống tổng hợp. Bạn là Technical BA cho một ví điện tử. Hợp đồng mới đẩy thêm 1,5 triệu giao dịch/ngày, 35% dồn vào khung 18h–21h, SLA yêu cầu p99 < 250ms, latency xử lý hiện tại 120ms. Hãy: (a) ước lượng TPS đỉnh (giả định burst gấp 3 so với trung bình khung đỉnh), (b) dùng Little's Law tính concurrency, (c) liệt kê 3 dependency bạn sẽ đi kiểm tra điểm nghẽn, (d) viết một capacity trigger cụ thể.
Bài 4 — Thuyết phục lãnh đạo. Viết một đoạn 5–6 câu trình bày kết quả Bài 3 cho ban giám đốc, diễn đạt bằng ngôn ngữ tiền bạc và rủi ro thay vì thuật ngữ kỹ thuật.
Tóm tắt
Capacity Planning là việc đảm bảo hệ thống đủ tài nguyên phục vụ tải tương lai với chi phí tối ưu. Nó khác performance test ở chỗ kết hợp năng lực hiện tại với dự báo tăng trưởng.
Những điều cần nhớ:
- Bốn nhóm input: current usage, growth assumptions, peak factor, và SLO mục tiêu.
- Luôn lập kế hoạch theo tải đỉnh, không phải trung bình, và luôn chừa headroom 30–40%.
- Little's Law (L = λ × W) giúp ước lượng concurrency từ RPS và latency.
- Bóc tách từng service thay vì nhân một hệ số chung; mỗi service có pattern tải riêng.
- Capacity planning thường phát lộ điểm nghẽn ở dependency phía sau (database, legacy, third-party) — hãy kiểm tra cả chuỗi end-to-end.
- Trình bày kết quả bằng tiền và rủi ro, kèm capacity trigger rõ ràng để biến kế hoạch thành quy trình vận hành sống.