Checklist Hạ tầng Cloud Mùa Sale 11.11, 12.12 cho IT Manager

Chuẩn bị hạ tầng cho mùa sale cuối năm nên bắt đầu 6–8 tuần trước ngày sale và gồm 5 nhóm việc: dự báo năng lực, củng cố kiến trúc và auto-scale, kiểm thử tải, bảo mật – sao lưu, và vận hành ngày G. Checklist dưới đây chia việc theo từng mốc thời gian để IT Manager giao việc và theo dõi tiến độ.

Nếu bạn đọc bài này khi 11.11 chỉ còn vài tuần, hãy bắt đầu từ mục “7 việc ưu tiên khi còn dưới 4 tuần” — đó là phần cho hiệu quả lớn nhất trong thời gian ngắn nhất.

Tóm tắt nhanh

Mốc an toàn: bắt đầu trước 6–8 tuần, đóng băng thay đổi (code freeze) trước 5–7 ngày.

Kiểm thử tải ở mức 1,5 lần traffic đỉnh dự báo, không phải mức trung bình.

Sao lưu và thử khôi phục trước sale; đây là việc hay bị bỏ qua nhất.

Ngày G cần người trực, bảng giám sát và kịch bản xử lý sự cố được viết sẵn.

Lịch mùa sale cuối năm 2026 và mốc bắt đầu chuẩn bị

Mùa sale cuối năm 2026 có 4 đỉnh traffic lớn, nối tiếp nhau trong khoảng 3 tháng. Bảng dưới tính sẵn mốc bắt đầu chuẩn bị theo quy tắc 6 tuần.

Sự kiện	Ngày	Thứ	Nên bắt đầu chuẩn bị từ
11.11	11/11/2026	Thứ Tư	30/09/2026
Black Friday	27/11/2026	Thứ Sáu	16/10/2026
12.12	12/12/2026	Thứ Bảy	31/10/2026
Mua sắm Tết Nguyên đán 2027	Cao điểm tháng 1/2027	—	Cuối tháng 11/2026

Vì các đỉnh nối tiếp nhau, hạ tầng chuẩn bị cho 11.11 nên được giữ và tinh chỉnh dần cho 12.12 và Tết, thay vì làm lại từ đầu mỗi lần.

7 việc ưu tiên khi còn dưới 4 tuần đến 11.11

Khi thời gian ngắn, hãy làm những việc giảm rủi ro sập hệ thống nhiều nhất trước. Bảy việc dưới đây xếp theo thứ tự hiệu quả trên thời gian bỏ ra.

Đưa ảnh, video sản phẩm ra CDN (Sun CDN + Sun S3). Mất 2–5 ngày, giảm mạnh tải lên máy chủ gốc.
Sao lưu toàn bộ và thử khôi phục một lần bằng Acronis Data Protection. Biết chắc mình khôi phục được trong bao lâu.
Thêm ít nhất 1 máy chủ ứng dụng và đặt sau Load Balancer (Sun Load Balancer) để không còn điểm chết đơn lẻ.
Thêm read replica cho database (Sun Database) và chuyển truy vấn trang sản phẩm, tìm kiếm sang bản sao.
Bật giám sát và cảnh báo (Sun Monitor) cho CPU, RAM, kết nối database, tỷ lệ lỗi 5xx.
Chạy một bài kiểm thử tải ở mức 1,5 lần đỉnh năm ngoái; sửa điểm nghẽn đầu tiên lộ ra.
Viết kịch bản xử lý sự cố một trang và phân công người trực cho đêm 10/11 rạng sáng 11/11.

Các thay đổi kiến trúc lớn như chuyển sang microservices nên để sau mùa sale; tuần cuối không phải lúc tái cấu trúc.

Checklist chuẩn bị hạ tầng theo từng mốc thời gian

Checklist chia thành 7 mốc từ 8 tuần trước sale đến tuần sau sale. Mỗi mục là một việc có thể giao cho một người và kiểm tra được là đã xong hay chưa.

[ẢNH 1 — Timeline 7 mốc chuẩn bị hạ tầng mùa sale]

T-8 đến T-6 tuần: Đánh giá và dự báo năng lực

☐ Thu số liệu traffic, đơn hàng/phút, CPU, kết nối database của đợt sale gần nhất.
☐ Lấy kế hoạch marketing: giờ mở deal, ngân sách quảng cáo, KOL livestream, kênh bán.
☐ Tính mục tiêu năng lực = đỉnh năm trước × tăng trưởng dự kiến × 1,3–1,5.
☐ Vẽ sơ đồ luồng đơn hàng: website, app, các sàn, cổng thanh toán, vận chuyển, ERP.
☐ Liệt kê điểm chết đơn lẻ: thành phần nào hỏng thì cả hệ thống dừng.

T-6 đến T-4 tuần: Củng cố kiến trúc và auto-scale

☐ Đưa toàn bộ ảnh, video, CSS, JS ra Sun S3 + Sun CDN; đặt thời gian cache phù hợp.
☐ Chuyển session, giỏ hàng ra bộ nhớ đệm dùng chung để ứng dụng stateless.
☐ Chạy tối thiểu 2 máy chủ ứng dụng sau Sun Load Balancer, health check kiểm tra cả database.
☐ Cấu hình auto-scale cho dịch vụ không trạng thái trên Sun Container (Spinner); đặt số máy tối thiểu, tối đa.
☐ Thêm read replica, bật connection pooling cho Sun Database.
☐ Đưa luồng đồng bộ đơn và tồn kho đa sàn qua Sun Kafka Highway để san phẳng đỉnh.
☐ Kiểm tra hạn mức tài nguyên (quota) của tài khoản cloud; đề nghị nâng trước nếu cần.

T-4 đến T-2 tuần: Kiểm thử tải và tối ưu

☐ Viết kịch bản test theo hành vi thật: xem sản phẩm, tìm kiếm, thêm giỏ, thanh toán.
☐ Chạy test tăng dần đến 1,5 lần mục tiêu năng lực; ghi lại điểm nghẽn đầu tiên.
☐ Sửa điểm nghẽn, chạy lại; lặp đến khi đạt tiêu chí ở bảng “Chỉ số đạt” bên dưới.
☐ Thử tắt ngẫu nhiên 1 máy chủ giữa bài test để xác nhận hệ thống tự hồi phục.
☐ Tối ưu truy vấn chậm nhất (slow query log) và thêm index còn thiếu.

T-2 đến T-1 tuần: Bảo mật, sao lưu, đóng băng thay đổi

☐ Sao lưu đầy đủ bằng Acronis, lưu bản sao ở vị trí tách biệt, thử khôi phục và đo thời gian.
☐ Rà soát tường lửa, đóng cổng không dùng, giới hạn truy cập quản trị qua VPN hoặc VPC.
☐ Bật giới hạn tần suất (rate limit) chống bot săn deal và tấn công đăng nhập.
☐ Kiểm tra chứng chỉ SSL còn hạn qua hết mùa sale.
☐ Đóng băng thay đổi code và cấu hình từ T-5 ngày; chỉ sửa lỗi khẩn cấp có duyệt.
☐ Viết kịch bản xử lý sự cố và phân công người trực (xem bảng bên dưới).

T-24 giờ: Làm nóng hệ thống

☐ Scale theo lịch: tăng sẵn số máy chủ lên 60–70% mức tối đa trước giờ mở sale 30–60 phút.
☐ Làm nóng cache: gọi trước trang sản phẩm deal để CDN và bộ nhớ đệm có sẵn dữ liệu.
☐ Kiểm tra lần cuối bảng giám sát, kênh cảnh báo, số điện thoại hỗ trợ của nhà cung cấp cloud.

Ngày G: Giám sát và phản ứng

☐ Đội trực có mặt từ 1 giờ trước giờ mở sale, cùng một kênh liên lạc (war room).
☐ Theo dõi bảng chỉ số mỗi 5 phút trong 2 giờ đầu.
☐ Mọi thay đổi trong ngày G đều được ghi lại: ai làm, lúc nào, vì sao.

T+1 đến T+7 ngày: Thu hẹp và rút kinh nghiệm

☐ Đưa tài nguyên về mức nền để dừng chi phí giờ cao điểm.
☐ Lưu số liệu đỉnh làm dữ liệu dự báo cho đợt sau.
☐ Họp rút kinh nghiệm: sự cố gì, phát hiện sau bao lâu, xử lý mất bao lâu.

Cách stress test server trước mùa sale

Stress test là giả lập lượng người dùng lớn truy cập cùng lúc để tìm giới hạn của hệ thống trước khi khách hàng thật tìm ra nó. Công cụ phổ biến và miễn phí gồm k6, Apache JMeter và Locust.

Chỉ số đạt	Ngưỡng tham khảo
Thời gian phản hồi p95 trang sản phẩm	Dưới 800 ms
Thời gian phản hồi p95 API thanh toán	Dưới 1.500 ms
Tỷ lệ lỗi (HTTP 5xx)	Dưới 1%
CPU trung bình máy chủ ứng dụng ở mức tải mục tiêu	Dưới 70%
Kết nối database đang dùng	Dưới 80% giới hạn

Lưu ý: chạy stress test từ máy chủ đặt ngoài hệ thống cần kiểm thử, thông báo trước cho nhà cung cấp cloud, và không test trực tiếp vào API của sàn TMĐT — hãy giả lập (mock) phần này.

Chỉ số cần giám sát trong ngày G

Trong ngày sale, chỉ cần theo dõi chặt 6 chỉ số dưới đây; chúng báo hiệu sự cố sớm hơn khiếu nại của khách hàng. Cấu hình cảnh báo trên Sun Monitor theo ngưỡng gợi ý.

[ẢNH 2 — Bảng giám sát ngày G]

Chỉ số	Ngưỡng cảnh báo	Ngưỡng khẩn cấp
CPU trung bình nhóm máy ứng dụng	70%	85%
Tỷ lệ lỗi 5xx	1%	3%
Thời gian phản hồi p95	1 giây	3 giây
Kết nối database đang dùng	70% giới hạn	90% giới hạn
Độ trễ hàng đợi đơn hàng (consumer lag)	2 phút	10 phút
Tỷ lệ cache hit của CDN	Dưới 85%	Dưới 70%

Kịch bản xử lý 4 sự cố thường gặp mùa sale

Sự cố	Dấu hiệu	Hành động đầu tiên
Máy chủ ứng dụng quá tải	CPU trên 85%, p95 tăng vọt	Tăng số máy tối đa của auto-scale, kiểm tra máy mới đã nhận traffic
Database nghẽn	Kết nối gần giới hạn, truy vấn chậm	Chuyển thêm truy vấn đọc sang replica, tạm tắt tính năng nặng (gợi ý sản phẩm, lọc nâng cao)
Đơn hàng đồng bộ chậm	Consumer lag tăng, tồn kho lệch giữa các sàn	Thêm worker xử lý hàng đợi, tạm giảm tồn kho hiển thị trên sàn để tránh bán vượt
Bot săn deal, tấn công	Request tăng bất thường từ ít địa chỉ IP	Siết rate limit, chặn dải IP, bật xác minh trên trang thanh toán

Để hiểu sâu cơ chế mở rộng tự động và cách đặt ngưỡng, đọc Auto-scale hạ tầng cloud trong mùa sale 11.11, 12.12. Seller Shopee có thể xem thêm hạ tầng cloud cho seller Shopee; toàn cảnh có trong hướng dẫn giải pháp cloud thương mại điện tử.

Câu hỏi thường gặp khi chuẩn bị hạ tầng mùa sale

Bao lâu trước mùa sale cần chuẩn bị hạ tầng?

Nên bắt đầu 6–8 tuần trước ngày sale. Tuần 8–4 dành cho dự báo và củng cố kiến trúc, tuần 4–2 cho kiểm thử tải, 2 tuần cuối cho sao lưu, bảo mật và đóng băng thay đổi.

Stress test server như thế nào?

Dùng công cụ như k6, JMeter hoặc Locust giả lập người dùng xem sản phẩm, thêm giỏ và thanh toán, tăng dần đến 1,5 lần traffic đỉnh dự báo. Đạt khi p95 dưới 800 ms cho trang sản phẩm và tỷ lệ lỗi dưới 1%.

Cloud nào auto-scale tốt cho mùa sale?

Cloud phù hợp cần có Load Balancer, container hoặc máy chủ tự mở rộng, CDN có node gần người mua và giám sát có cảnh báo. Sunteco cung cấp đủ các thành phần này với máy chủ tại Việt Nam, giá VNĐ và không tính phí data transfer.

Code freeze trước mùa sale là gì?

Code freeze là giai đoạn ngừng triển khai thay đổi code và cấu hình, thường 5–7 ngày trước sale, chỉ cho phép sửa lỗi khẩn cấp đã được duyệt. Mục tiêu là tránh lỗi mới phát sinh đúng lúc traffic cao nhất.

Ngày sale cần bao nhiêu người trực hệ thống?

Tối thiểu 3 vai trò: một người theo dõi hạ tầng, một người phụ trách ứng dụng và database, một người điều phối liên lạc với marketing và chăm sóc khách hàng. Hệ thống lớn nên có thêm người trực từ nhà cung cấp cloud.