Hạ tầng cloud chịu tải Black Friday và 12.12: checklist kỹ thuật

Black Friday năm nay rơi vào thứ Sáu 27/11/2026, còn 12.12 là thứ Bảy. Với hệ thống bán hàng chạy trên cloud, hai tuần trước đó là thời điểm làm bốn việc quan trọng nhất: kiểm tra hạn mức tài nguyên của tài khoản, đặt lịch tăng công suất tối thiểu trước giờ mở sale, chạy kiểm thử tải trên môi trường giống production, và đóng băng thay đổi trong những ngày cao điểm. Autoscaling phản ứng theo tải là cần nhưng chưa đủ, vì máy mới khởi động luôn chậm hơn đợt khách đổ vào lúc 0 giờ.

Lịch cao điểm cuối năm 2026

Sự kiện	Ngày	Thứ
Black Friday	27/11/2026	Thứ Sáu
Cyber Monday	30/11/2026	Thứ Hai
Ngày đôi 12.12	12/12/2026	Thứ Bảy

Nhiều chương trình mở từ 0 giờ, nên đỉnh tải thường dồn vào vài phút đầu. Kế hoạch hạ tầng nên lấy đúng những phút này làm chuẩn, không lấy trung bình cả ngày.

Bước 1: kiểm tra hạn mức tài nguyên

Mỗi nhà cung cấp cloud đặt giới hạn mặc định cho số lượng tài nguyên trên một tài khoản hoặc một region. Trên AWS, Service Quotas cho phép xem hạn mức, mức sử dụng và gửi yêu cầu tăng. Tài liệu nói rõ yêu cầu tăng cần thời gian xem xét, có thể được duyệt, từ chối hoặc chỉ duyệt một phần. Vì vậy đừng để đến ngày 26/11 mới phát hiện nhóm autoscaling không thể thêm máy vì chạm giới hạn.

Danh sách nên rà: số vCPU theo loại máy, số địa chỉ IP công khai, kết nối cơ sở dữ liệu, giới hạn đồng thời của hàm serverless, giới hạn tốc độ của API gateway. Ghi lại mức dùng ở đỉnh năm ngoái và nhân với hệ số tăng trưởng bạn dự kiến.

Bước 2: scale chủ động thay vì chờ phản ứng

Predictive scaling cho tải có chu kỳ

Theo tài liệu predictive scaling của Amazon EC2 Auto Scaling, cơ chế này phân tích dữ liệu lịch sử để nhận ra mẫu tải theo ngày hoặc tuần, rồi tăng công suất trước khi tải đến. Nó phù hợp với ứng dụng khởi động lâu và lưu lượng lặp lại như giờ hành chính. Nhưng một đợt sale chỉ diễn ra mỗi năm một lần thì dữ liệu lịch sử không phản ánh được.

Ghi đè dự báo bằng lịch cố định

AWS hướng dẫn cách xử lý chính tình huống này: tạo hai scheduled action, một cái nâng công suất tối thiểu khi sự kiện bắt đầu và một cái trả về mức cũ khi kết thúc. Vì predictive scaling tối ưu theo công suất, một mức tối thiểu cao hơn dự báo sẽ được tôn trọng. Trong thời gian đó nhóm vẫn có thể scale thêm nếu dự báo hoặc chính sách động yêu cầu. Chi tiết nằm trong trang ghi đè dự báo bằng scheduled action.

Chú ý múi giờ: nếu không chọn, scheduled action dùng UTC. 0 giờ ngày 27/11 tại Việt Nam tương ứng 17:00 UTC ngày 26/11. Nên đặt hành động tăng công suất sớm hơn giờ mở sale ít nhất bằng thời gian khởi động máy và làm nóng ứng dụng.

Bước 3: kiểm thử tải đúng cách

1. Dùng kịch bản người dùng thật: xem sản phẩm, thêm giỏ, áp mã giảm giá, thanh toán. Không chỉ bắn request vào trang chủ.
2. Tăng tải theo bậc và theo cú sốc: vừa thử tăng dần, vừa thử nhảy vọt trong một phút để mô phỏng giờ mở sale.
3. Quan sát điểm nghẽn đầu tiên: thường là cơ sở dữ liệu, kết nối tới cổng thanh toán hoặc dịch vụ bên thứ ba, không phải máy chủ web.
4. Báo trước cho đối tác: cổng thanh toán, dịch vụ gửi SMS OTP, đơn vị vận chuyển có giới hạn riêng.
5. Chạy lại sau mỗi lần sửa: gỡ một điểm nghẽn thường làm lộ điểm nghẽn tiếp theo.

Nếu hệ thống tách thành nhiều dịch vụ, mỗi dịch vụ có ngưỡng chịu tải khác nhau; bài so sánh microservices với monolithic giải thích vì sao một dịch vụ nhỏ như tồn kho có thể kéo sập cả luồng thanh toán.

Bước 4: giảm tải cho lõi hệ thống

• Đưa ảnh, CSS, JavaScript và trang danh mục ít thay đổi lên CDN.
• Cache kết quả tìm kiếm và trang sản phẩm phổ biến, đặt thời gian hết hạn ngắn cho giá và tồn kho.
• Dùng hàng đợi cho tác vụ không cần đồng bộ: gửi email xác nhận, xuất hóa đơn, đồng bộ sang hệ thống kế toán.
• Chuẩn bị trang chờ có xếp hàng cho trường hợp vượt ngưỡng, tốt hơn để trang lỗi 500.
• Đặt rate limit theo người dùng để chặn bot săn mã giảm giá chiếm tài nguyên.

Bước 5: đóng băng thay đổi và chuẩn bị sự cố

Thống nhất một khoảng code freeze, ví dụ từ ba ngày trước Black Friday đến hết Cyber Monday, chỉ cho phép bản vá khẩn có người duyệt. Pipeline triển khai vẫn nên sẵn sàng để rollback nhanh; nếu đội đang dùng quy trình như trong bài CI/CD với GitHub Actions, hãy thử chạy lại một lần rollback thật trước ngày cao điểm.

Song song, kiểm tra bản sao lưu cơ sở dữ liệu có khôi phục được không, ghi rõ ai trực, ai có quyền quyết định tắt tính năng phụ để cứu luồng chính. Phần kế hoạch khôi phục chi tiết có trong bài sao lưu và phục hồi dữ liệu trên cloud.

Bảng chỉ số cần nhìn trong giờ cao điểm

Người trực không nên phải mở mười màn hình khác nhau. Gom về một dashboard với những chỉ số trả lời được câu hỏi "khách có mua được hàng không":

• Tỷ lệ đặt hàng thành công mỗi phút, so với cùng giờ ngày thường.
• Tỷ lệ lỗi và độ trễ ở bước thanh toán, tách riêng theo từng cổng thanh toán.
• Số kết nối cơ sở dữ liệu đang dùng so với giới hạn.
• Độ dài hàng đợi xử lý đơn và thời gian chờ trung bình.
• Số máy đang chạy so với hạn mức tài khoản.

Đặt cảnh báo theo xu hướng bất thường, không chỉ theo ngưỡng cố định, để người trực có vài phút phản ứng trước khi khách hàng nhận ra.

Sau cao điểm: thu nhỏ và rút kinh nghiệm

Đừng quên scheduled action thứ hai để trả công suất về mức cũ; quên bước này là cách nhanh nhất để hóa đơn tháng 12 tăng vọt. Trong tuần sau sự kiện, tổng hợp số liệu đỉnh tải, điểm nghẽn và sự cố. Dữ liệu này chính là đầu vào tốt nhất cho 12.12 và cho mùa mua sắm Tết Đinh Mùi 2027 ngay sau đó.

Câu hỏi thường gặp

Autoscaling có tự xử lý được đợt sale lúc 0 giờ không?

Autoscaling động phản ứng sau khi tải tăng, trong khi máy mới cần thời gian khởi động. Với đợt tăng đột ngột đã biết trước giờ, nên kết hợp scheduled action nâng công suất tối thiểu trước giờ mở sale.

Nên tăng hạn mức tài nguyên trước bao lâu?

Càng sớm càng tốt. AWS cho biết yêu cầu tăng hạn mức cần thời gian xem xét và có thể chỉ được duyệt một phần, nên hãy gửi trước sự kiện ít nhất vài ngày làm việc.

Kiểm thử tải trên production có an toàn không?

Rủi ro cao vì có thể ảnh hưởng khách thật và dữ liệu thật. Nên dùng môi trường staging cấu hình giống production; nếu buộc phải thử trên production, chọn giờ thấp điểm và báo trước cho các bên liên quan.