Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là người vận hành hệ thống cho một sàn thương mại điện tử. Ngày thường mọi thứ chạy êm ru, CPU chỉ dùng 30%, hóa đơn cloud vừa phải. Rồi đến 0 giờ ngày 11/11 — sự kiện sale lớn nhất năm — lượng truy cập tăng gấp 20 lần trong vòng 15 phút. Hệ thống nghẽn, trang chủ trả về lỗi 503, khách hàng không thể thanh toán. Mỗi phút downtime là hàng trăm triệu đồng doanh thu bốc hơi, và tệ hơn là niềm tin của khách hàng.
Kịch bản ngược lại cũng đau không kém: sếp tài chính gọi bạn lên hỏi vì sao hóa đơn AWS tháng này lên tới 800 triệu đồng, trong khi phần lớn máy chủ chạy dưới 10% công suất suốt cả tháng. Bạn đã trả tiền cho một đống tài nguyên "để phòng hờ" mà chẳng bao giờ dùng đến.
Hai câu chuyện này là hai mặt của cùng một đồng xu, và đó chính là trọng tâm của bài học hôm nay: Capacity Planning (hoạch định năng lực) và Cost Optimization (tối ưu chi phí). Nói đơn giản, đây là nghệ thuật trả lời hai câu hỏi tưởng chừng mâu thuẫn nhau: "Làm sao để hệ thống luôn đủ sức chịu tải?" và "Làm sao để không đốt tiền vô ích?". Người vận hành giỏi không phải người mua thật nhiều máy chủ để cho an toàn, mà là người biết cân bằng giữa độ tin cậy và chi phí một cách có kỷ luật, dựa trên dữ liệu chứ không phải cảm tính.
Đây là kỹ năng làm cho bạn từ một "người trực máy" trở thành một người có tiếng nói trong quyết định kinh doanh. Vì cuối cùng, hạ tầng công nghệ luôn là một dòng chi phí lớn, và biết cách quản nó chính là biết cách tạo ra giá trị.
Khái niệm cốt lõi
Capacity Planning là gì?
Capacity Planning là quá trình đảm bảo hệ thống của bạn có đủ tài nguyên (nhưng không dư thừa quá mức) để đáp ứng nhu cầu hiện tại và tương lai, ở một mức độ tin cậy chấp nhận được. Bốn loại tài nguyên bạn thường phải quan tâm:
- CPU — sức tính toán, đo bằng phần trăm sử dụng hoặc số core.
- Memory (RAM) — bộ nhớ, thường là điểm nghẽn âm thầm nhất, dễ gây crash khi cạn.
- Storage — dung lượng lưu trữ (đĩa, database, object storage).
- Bandwidth / Network — băng thông mạng và số kết nối đồng thời.
Bốn bước cơ bản: Measure → Forecast → Plan → Validate
Quy trình hoạch định năng lực chuẩn gồm bốn bước, và đây là khung xương của cả bài học:
- Measure (Đo lường) — Bạn không thể quản lý thứ mình không đo. Thu thập dữ liệu sử dụng thực tế: CPU, memory, storage, bandwidth qua thời gian, đặc biệt là các đỉnh (peak).
- Forecast (Dự báo) — Dựa trên dữ liệu lịch sử, dự đoán nhu cầu tương lai theo các mô hình tăng trưởng khác nhau.
- Plan (Lập kế hoạch) — Quyết định cần thêm bao nhiêu tài nguyên, khi nào, và chuẩn bị bao nhiêu "phần đệm" an toàn (headroom).
- Validate (Kiểm chứng) — Kiểm tra giả định của bạn bằng load test hoặc theo dõi thực tế, rồi lặp lại chu kỳ.
Các mô hình dự báo tăng trưởng
Dự báo là phần dễ sai nhất, vì tương lai không phải lúc nào cũng nối tiếp quá khứ theo một đường thẳng. Ba mô hình phổ biến:
- Tuyến tính (Linear) — Nhu cầu tăng đều đặn theo thời gian, ví dụ mỗi tháng thêm 5% người dùng. Phù hợp với sản phẩm trưởng thành, tăng trưởng ổn định.
- Hàm mũ (Exponential) — Nhu cầu tăng theo cấp số nhân, kiểu "viral". Một startup gọi vốn thành công và bùng nổ người dùng thường rơi vào đây. Nguy hiểm vì nếu dùng mô hình tuyến tính để dự báo, bạn sẽ luôn thiếu tài nguyên.
- Theo mùa vụ (Seasonal) — Nhu cầu lặp lại theo chu kỳ. Với thị trường Việt Nam, đây là mô hình cực kỳ quan trọng: các đợt sale 11/11, 12/12, Black Friday, cao điểm mua sắm Tết Nguyên đán, hay giờ vàng livestream buổi tối.
Headroom — vùng đệm an toàn
Headroom là khoảng tài nguyên dự phòng bạn cố tình để trống. Nếu hệ thống chạy ở 95% CPU vào giờ bình thường, bạn không còn chỗ để hấp thụ đột biến, và không kịp phản ứng khi có sự cố. Một quy tắc thực dụng phổ biến: giữ mức sử dụng ở đỉnh không vượt quá 60–70% để còn dư địa. Headroom là cái giá bạn trả cho sự an tâm — nhưng để quá nhiều thì lãng phí, quá ít thì rủi ro. Đây chính là nghệ thuật cân bằng.
Cost Optimization — mặt còn lại của đồng xu
Tối ưu chi phí không có nghĩa là mua rẻ nhất. Nó là đảm bảo mỗi đồng chi cho hạ tầng đều tạo ra giá trị. Các đòn bẩy chính:
- Right-sizing — chọn đúng kích cỡ máy chủ, không dùng máy 32GB RAM cho ứng dụng chỉ cần 4GB.
- Auto-scaling — tự động co giãn số lượng máy theo tải, để không trả tiền cho công suất nhàn rỗi lúc thấp điểm.
- Reserved Instances / Savings Plans — cam kết dùng dài hạn (1–3 năm) để đổi lấy giảm giá sâu (30–60%) cho phần tải nền ổn định.
- Spot Instances — mua tài nguyên "dư thừa" của nhà cung cấp với giá rẻ tới 70–90%, đổi lại có thể bị thu hồi bất cứ lúc nào. Hợp cho các tác vụ chịu được gián đoạn.
- Dọn dẹp tài nguyên mồ côi — đĩa không gắn với máy nào, IP tĩnh không dùng, snapshot cũ, môi trường test bị quên tắt.
Tình huống thực tế
Ví dụ 1: Sàn TMĐT Việt và cú sốc 11/11
Một sàn thương mại điện tử tại TP.HCM (gọi là "ShopNhanh") vận hành trên AWS. Ngày thường lưu lượng khoảng 2.000 RPS, cụm máy chủ chạy 20 instance ở mức CPU trung bình 40%. Nhóm vận hành đo được rằng năm ngoái, đỉnh sale 11/11 lưu lượng lên tới 38.000 RPS — gấp 19 lần.
Nếu dùng mô hình tuyến tính, họ chỉ dự báo tăng khoảng 30% so với năm trước và chuẩn bị thiếu trầm trọng. Thay vào đó, họ phân tích theo mùa vụ: lấy tỉ lệ đỉnh/nền năm ngoái (19x), nhân với mức tăng trưởng nền năm nay (khoảng 1,5x), ra đỉnh dự kiến ~57.000 RPS. Họ chuẩn bị auto-scaling group có thể bung lên 300 instance, kèm 30% headroom, và pre-warm (làm nóng trước) hệ thống 2 tiếng trước giờ G thay vì để auto-scaling phản ứng chậm.
Bài học: Với hệ thống có tính mùa vụ mạnh như ở Việt Nam, phải dự báo theo tỉ lệ đỉnh/nền lịch sử, không dùng đường thẳng. Và auto-scaling không phải phép màu — nó cần thời gian khởi động máy mới, nên với sự kiện biết trước, hãy chuẩn bị công suất từ trước.
Ví dụ 2: Startup fintech đốt tiền cloud vô thức
Một startup fintech ở Hà Nội tăng trưởng nóng sau vòng gọi vốn. Trong 6 tháng, hóa đơn AWS phình từ 150 triệu lên 780 triệu đồng/tháng. Nhóm kỹ thuật quá bận build tính năng nên không ai nhìn lại hạ tầng. Khi kiểm toán chi phí, họ phát hiện: 40% chi phí đến từ các máy database được cấp cỡ lớn (chọn "cho chắc") nhưng dùng dưới 15% CPU; hàng chục môi trường test dev tạo ra để demo rồi quên tắt; và 200GB snapshot backup trùng lặp không ai xóa.
Họ thực hiện chiến dịch tối ưu: right-sizing các database (tiết kiệm ~35%), mua Savings Plan 1 năm cho phần tải nền (tiết kiệm thêm ~30% trên phần đó), tự động tắt môi trường non-production ngoài giờ làm việc, và dọn snapshot cũ. Kết quả: hóa đơn giảm về 430 triệu đồng/tháng mà không ảnh hưởng hiệu năng.
Bài học: Chi phí cloud tăng âm thầm khi không ai giám sát. Phần lớn lãng phí đến từ việc cấp phát dư ("để cho chắc") và tài nguyên mồ côi, chứ không phải từ tải thật. Right-sizing và cam kết dài hạn cho tải nền là hai đòn bẩy mạnh nhất.
Ví dụ 3: Netflix và bài học pre-provisioning
Netflix nổi tiếng với việc dùng auto-scaling trên AWS, nhưng họ học được một bài học đắt: auto-scaling phản ứng theo thời gian thực không đủ nhanh cho các đỉnh dựng đứng. Họ chuyển sang predictive scaling — dùng dữ liệu lịch sử để biết trước rằng lúc 20h tối lượng xem tăng vọt, và chủ động thêm công suất trước thời điểm đó, thay vì đợi CPU chạm ngưỡng rồi mới phản ứng.
Bài học: Với các mẫu tải lặp lại và dự đoán được (giờ vàng, cuối tuần, sự kiện), dự báo chủ động (predictive) thắng phản ứng bị động (reactive). Đo lường tốt cho phép bạn "nhìn trước" thay vì "chạy theo".
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay cho hệ thống của mình:
Bước 1 — Thiết lập đo lường. Đảm bảo bạn có công cụ giám sát (CloudWatch, Prometheus, Datadog...) thu thập CPU, memory, storage, bandwidth, RPS liên tục. Lưu dữ liệu ít nhất 3–6 tháng để nhìn thấy xu hướng và mùa vụ. Quan trọng: theo dõi giá trị đỉnh (p95, p99), không chỉ trung bình — vì hệ thống sập ở đỉnh chứ không sập ở mức trung bình.
Bước 2 — Xác định chỉ số nút cổ chai. Với mỗi service, tìm ra tài nguyên nào sẽ cạn trước. Ứng dụng của bạn nghẽn ở CPU, RAM, kết nối database, hay băng thông? Đây là chỉ số bạn cần lập kế hoạch quanh nó.
Bước 3 — Chọn mô hình dự báo. Vẽ dữ liệu lịch sử lên biểu đồ. Nó tăng tuyến tính, theo hàm mũ, hay có đỉnh mùa vụ? Chọn mô hình phù hợp và tính nhu cầu dự kiến cho 3, 6, 12 tháng tới.
Bước 4 — Tính công suất cần thiết kèm headroom. Công thức thực dụng:
> Số instance cần = (Nhu cầu đỉnh dự báo ÷ Sức tải mỗi instance) ÷ Ngưỡng sử dụng mục tiêu
Ví dụ: dự báo đỉnh 60.000 RPS, mỗi instance chịu 1.000 RPS, ngưỡng mục tiêu 70% → cần 60.000 ÷ 1.000 ÷ 0,7 ≈ 86 instance.
Bước 5 — Thiết kế co giãn. Cấu hình auto-scaling với ngưỡng hợp lý (ví dụ scale-out khi CPU > 60%), đặt số min/max an toàn, và cân nhắc predictive scaling cho các mẫu tải biết trước.
Bước 6 — Tối ưu chi phí song song. Phân tách tải thành phần nền ổn định (dùng Reserved/Savings Plan) và phần đột biến (dùng on-demand hoặc spot). Right-size các máy đang chạy. Đặt lịch tắt môi trường non-production.
Bước 7 — Kiểm chứng và lặp lại. Chạy load test để xác nhận giả định về sức tải. Đặt cảnh báo (alert) khi mức sử dụng vượt ngưỡng headroom. Xem lại kế hoạch định kỳ mỗi quý.
Lỗi thường gặp & mẹo
Lỗi 1 — Lập kế hoạch dựa trên giá trị trung bình. Trung bình che giấu các đỉnh. Một hệ thống trung bình 40% CPU có thể vẫn chạm 100% vào giờ cao điểm. Luôn lập kế hoạch quanh p95/p99.
Lỗi 2 — Tin tưởng mù quáng vào auto-scaling. Auto-scaling cần thời gian (khởi động máy, warm-up cache, cân bằng tải). Với đỉnh dựng đứng, nó phản ứng không kịp. Với sự kiện biết trước, hãy pre-provision.
Lỗi 3 — Chỉ nhìn hạ tầng, quên giới hạn phần mềm. Bạn thêm 100 máy web nhưng database chỉ chịu được 500 kết nối — nghẽn vẫn xảy ra. Capacity planning phải nhìn toàn chuỗi, tìm nút thắt thật sự.
Lỗi 4 — "Để cho chắc" mà không đo lại. Thói quen cấp phát dư vì sợ thiếu là nguồn lãng phí lớn nhất. Hãy đo, rồi right-size dựa trên dữ liệu.
Lỗi 5 — Không ai sở hữu chi phí. Khi hóa đơn cloud là "của chung", không ai chịu trách nhiệm. Gắn tag chi phí theo team/dự án và cho từng đội thấy con số của mình.
Mẹo hay:
- Gắn tag cho mọi tài nguyên (team, môi trường, dự án) để truy vết chi phí.
- Đặt budget alert để được cảnh báo khi chi phí vượt ngưỡng, đừng đợi đến cuối tháng mới ngã ngửa.
- Dùng spot instance cho batch job, xử lý dữ liệu, CI/CD — những việc chịu được gián đoạn.
- Tách rõ tải nền (cam kết dài hạn, giá rẻ) và tải đột biến (linh hoạt, on-demand).
Bài tập thực hành
- Đo lường thực tế: Chọn một service bạn đang quản (hoặc giả định). Thu thập số liệu CPU, memory, RPS trong 30 ngày. Xác định giá trị p95 ở đỉnh và giá trị trung bình — so sánh chênh lệch giữa chúng.
- Dự báo: Giả sử service của bạn hiện phục vụ 5.000 RPS ở đỉnh, tăng trưởng nền 8%/tháng, và có đợt sale Tết làm lưu lượng nhân 6 lần. Hãy tính đỉnh RPS dự kiến trong đợt Tết 4 tháng tới.
- Tính công suất: Với đỉnh dự báo ở bài 2, nếu mỗi instance chịu 800 RPS và ngưỡng sử dụng mục tiêu là 65%, bạn cần bao nhiêu instance? Đừng quên headroom.
- Tối ưu chi phí: Liệt kê hệ thống của bạn thành hai nhóm — tải nền ổn định và tải đột biến. Nhóm nào nên dùng Reserved/Savings Plan, nhóm nào nên dùng on-demand hoặc spot? Ước tính phần trăm tiết kiệm.
- Săn lãng phí: Rà soát và liệt kê 3 loại tài nguyên mồ côi có thể tồn tại trong hệ thống của bạn (đĩa không gắn máy, môi trường test quên tắt, snapshot cũ...). Ước tính chi phí chúng đang ngốn.
Tóm tắt
- Capacity Planning đảm bảo hệ thống đủ tài nguyên để chịu tải mà không dư thừa lãng phí, qua bốn bước: Measure → Forecast → Plan → Validate.
- Đo lường phải dựa trên giá trị đỉnh (p95/p99), không phải trung bình, vì hệ thống sập ở đỉnh.
- Chọn đúng mô hình dự báo: tuyến tính, hàm mũ, hay mùa vụ. Với thị trường Việt Nam, các đỉnh mùa vụ (11/11, Tết, giờ vàng livestream) là yếu tố sống còn.
- Luôn giữ headroom (thường 30–40%) làm vùng đệm an toàn, và pre-provision cho sự kiện biết trước thay vì phụ thuộc hoàn toàn auto-scaling.
- Cost Optimization là mặt còn lại của đồng xu: right-sizing, tách tải nền (Reserved/Savings Plan) khỏi tải đột biến (on-demand/spot), và dọn dẹp tài nguyên mồ côi.
- Lãng phí lớn nhất đến từ việc "cấp phát cho chắc" và tài nguyên bị lãng quên — hãy đo lường, gắn tag, và đặt budget alert.