Website Down Khi Chạy Ads: Quy Trình Xử Lý P1 Trong 2 Giờ

September 8, 2025
4004
Thiết Kế Website
Thiết Kế Website Chuẩn SEO
Thiết Kế Website Cho Doanh Nghiệp Nhỏ
Dịch Vụ Thiết Kế Website
Digital Marketing
SEO Website
Landing Page
Web Design
Website Down Khi Chạy Ads: Quy Trình Xử Lý P1 Trong 2 Giờ

Khi đang đốt ngân sách quảng cáo mà website “đột ngột lăn ra ốm”, thiệt hại không chỉ là tiền Ads cháy sạch, mà còn mất đơn, rớt uy tín và rối loạn nội bộ. Bài vệ tinh này hướng dẫn quy trình xử lý sự cố P1 trong 2 giờ – thực chiến, gọn, có checklists – để đội bạn bình tĩnh khôi phục website nhanh nhất, đồng thời giảm thất thoát ngân sách quảng cáo.

Đây là bài bổ trợ cho bài trọng tâm về dịch vụ bảo trì tại HCM. Nếu bạn cần lộ trình đầy đủ (SLA, quy trình, công cụ), xem Dịch vụ bảo trì website Hồ Chí Minh – Pillar Page.

Tình huống điển hình khi “đang chạy Ads bị down”

  • Tải đột biến do TVC/Influencer/Performance bơm mạnh → CPU/RAM/DB “đỏ lửa”, hàng đợi kết nối đầy, web time-out.

  • Cập nhật vội (plugin/theme/core) trước khi chạy chiến dịch → xung đột, lỗi PHP/JS, blank page.

  • Hạ tầng yếu: cache/CDN chưa tối ưu, DB không có index/caching, không có autoscale.

  • Bị tấn công DDoS/Layer 7 đúng lúc “điểm rơi” – nghi ngờ từ đối thủ/botnet.

  • Sự cố thanh toán/giỏ hàng: gateway timeout, webhook fail → người dùng không thanh toán được, doanh thu thất thoát.

Mục tiêu P1 trong 2 giờ

  1. Khôi phục truy cập (tối thiểu trang chủ/landing/checkout) ở mức “đủ dùng”.

  2. Giảm cháy ngân sách: điều chỉnh kênh Ads về landing tạm, giảm ngân sách, hoặc tạm dừng có kiểm soát.

  3. Cô lập nguyên nhân & chặn tái diễn trong khung giờ sự cố.

  4. Báo cáo post-mortem ngắn trong 24h để rút kinh nghiệm.

Quy trình 120 phút (minute-by-minute)

T-00 → T-15: ĐÁNH GIÁ NHANH & THÔNG BÁO

  • Bật trang bảo trì thân thiện (503 + retry-after) hoặc failover landing tĩnh (HTML + form/CTA), hạn chế bounce.

  • Thông báo nội bộ (Marketing/CS/Sales/Founder) bằng một câu: “P1 – site gián đoạn, ETA 120’ – cập nhật mỗi 15’.”

  • Kiểm tra nhanh:

    • TTFB/uptime (StatusCake/UptimeRobot).

    • CPU/RAM/IO/DB connections (Cloud/Hosting dashboard).

    • Log gần nhất (nghi vấn plugin/theme/DDoS/DB lock).

T-15 → T-30: CÔ LẬP NGUYÊN NHÂN & “BẬT THỞ”

  • Nghi ngờ tải cao: bật/siết CDN/WAF, cache page, giảm TTL; tạm tắt các truy vấn nặng (search, filter).

  • Nghi ngờ code xung đột: rollback phiên bản gần nhất (Git/Backup), tắt plugin nghi vấn.

  • Nghi ngờ DDoS Layer 7: bật Under Attack Mode (Cloudflare), chặn IP/ASN bất thường, rate-limit endpoint nặng (/search, /cart, /checkout).

  • DB nghẽn: flush slow query cache, tăng max_connections tạm, khởi động lại dịch vụ nếu cần.

T-30 → T-60: KHÔI PHỤC TỐI THIỂU & GIẢM CHI PHÍ ADS

  • Mở lại đường cho trang bán/landing/checkout trước; phần blog/giới thiệu có thể để sau.

  • Marketing:

    • Nếu site chưa ổn định: chuyển ngân sách về landing tĩnh (AMP/HTML tĩnh, CDN) hoặc form lead dự phòng (Google Form/Typeform).

    • Giảm 30–70% ngân sách các nhóm đang cháy mạnh; tạm tắt placement kém chất lượng.

    • Cập nhật CSKH: “hệ thống đang bảo trì khẩn, vui lòng đặt qua hotline/inbox”.

  • QA nhanh: desktop/mobile, login/đăng ký/giỏ hàng/checkout (sandbox), form lead, pixel/GA4/UTM.

T-60 → T-90: ỔN ĐỊNH & CỨNG HÓA

  • Bổ sung bảo vệ:

    • Cache HTML toàn trang (trừ giỏ hàng/checkout).

    • Defer/async JS, tắt script không cần thiết.

    • Giới hạn tính năng nặng: tìm kiếm sống, so sánh, gợi ý liên quan.

  • Hạ tầng:

    • Tăng tạm CPU/RAM vCPU, bật autoscale nếu có.

    • Di chuyển media sang CDN nếu chưa.

  • DB:

    • Tối ưu index gấp cho bảng thường truy vấn (orders, posts, products).

    • Bật object cache (Redis/Memcached).

T-90 → T-120: THỬ TẢI NHẸ & TÁI PHÂN BỔ ADS

  • Kiểm tra tải nhẹ (kịch bản user journey chính 5–10 req/s).

  • Phân bổ lại quảng cáo: từng nhóm nhỏ, tăng dần theo ngưỡng chịu tải.

  • Ghi log sự cố: mốc thời gian – nguyên nhân sơ bộ – thay đổi đã áp dụng – tồn đọng cần làm sau.

Bộ vai trò & kênh liên lạc (5 người là đủ)

  • Incident Lead (DevOps/Tech Lead): ra quyết định kỹ thuật, cập nhật 15’.

  • Web Engineer: rollback, hotfix, tắt/bật tính năng, QA kỹ thuật.

  • Performance/Marketing: điều chỉnh Ads/landing, thông điệp CSKH.

  • CS/CRM: nhận Lead/đơn thủ công, trấn an khách, tổng hợp phản hồi.

  • Stakeholder (PM/Founder): duyệt thông điệp public & ưu tiên nguồn lực.

Kênh: 1 nhóm chat chung (Slack/Telegram), 1 bảng việc (Trello/Jira) → tránh loạn thông tin.

Checklists tác chiến nhanh

A. Kỹ thuật (khôi phục trong 2h)

  • Bật 503 hoặc landing tĩnh (có CTA).

  • CDN/WAF: Under Attack, rate-limit, bot fight.

  • Rollback code/plug-in, vô hiệu thứ vừa cập nhật.

  • Mở lại các trang bán quan trọng; tắt chức năng nặng.

  • Redis/Memcached + page cache full; giảm TTL DNS/CDN.

  • DB: tăng kết nối tạm, tối ưu truy vấn chậm, restart nếu lock.

  • QA checkout/form/pixel/GA4/UTM.

B. Marketing/CS (giảm cháy ngân sách)

  • Điều chỉnh ngân sách chiến dịch, tạm tắt nhóm rủi ro.

  • Chuyển hướng về landing tĩnh/form dự phòng.

  • Thông báo ngắn gọn trên fanpage/CS: đang bảo trì khẩn.

  • Thu lead thủ công (hotline/inbox) – nhập lại CRM sau.

C. Sau khi ổn định (24h)

  • Post-mortem: nguyên nhân gốc (RCA) + hành động phòng ngừa.

  • Kế hoạch tối ưu hạ tầng (cache/CDN/WAF/autoscale).

  • Lịch kiểm thử khôi phục (restore drill) & cập nhật an toàn.

Để hiểu toàn cảnh công tác bảo trì theo tháng (lịch, nhịp, báo cáo), tham khảo Quy trình bảo trì website hàng tháng và góc nhìn chiến lược trong bài viết về bảo trì & hậu mãi.

6 nguyên nhân gốc thường gặp & cách “bịt lỗ”

  1. Xung đột code/plug-in ngay trước chiến dịch
    Phòng ngừa: staging → QA → deploy có checklist; freeze code 48h trước giờ G.
    Theo dõi: error log, Sentry.
    Khắc phục: rollback bản ổn định, tắt nhanh plug-in nghi vấn.

  2. Tải không chịu nổi vì không có cache/CDN
    Phòng ngừa: page cache full (người chưa đăng nhập), object cache, CDN gần người dùng.
    Theo dõi: hit/miss cache, TTFB.
    Khắc phục: bật cache toàn trang, dời media lên CDN, giảm script.

  3. DB nghẽn – truy vấn chậm
    Phòng ngừa: thêm index, query plan, phân trang, caching.
    Theo dõi: slow query log, max connections.
    Khắc phục: tối ưu gấp truy vấn nặng, tăng tài nguyên, chia replica nếu có.

  4. DDoS/Layer 7 đúng thời điểm
    Phòng ngừa: WAF, bot management, threshold per IP/ASN.
    Theo dõi: spikes bất thường theo quốc gia/ASN.
    Khắc phục: Under Attack, challenge, block range.

  5. Gateway/Thanh toán lỗi
    Phòng ngừa: health check định kỳ, retry/backoff, fallback manual.
    Theo dõi: error rate theo provider.
    Khắc phục: chuyển tạm sang cổng phụ, thông báo khách đặt cọc COD/inbox.

  6. Hạ tầng quá nhỏ – không autoscale
    Phòng ngừa: benchmark tải, autoscale, tách DB/file storage.
    Khắc phục: nâng cấu hình tạm thời, sau chiến dịch lên plan kiến trúc.

Mẫu thông điệp truyền thông (ngắn – trấn an – có lối thay thế)

“Xin lỗi vì sự bất tiện! Lượng truy cập tăng đột biến khiến hệ thống tạm quá tải. Đội kỹ thuật đang khôi phục trong 120 phút. Anh/chị có thể đặt hàng nhanh tại link dự phòng hoặc nhắn inbox/Hotline 09xx… để được hỗ trợ ngay. Cảm ơn anh/chị đã thông cảm!”

Sau sự cố: 7 việc cần làm để lần sau không còn P1

  1. Freeze code trước chiến dịch 48–72h.

  2. Staging bắt buộc + checklist QA, có rollback 1-click.

  3. CDN + full page cache + object cache hoạt động thực sự (đo hit/miss).

  4. WAF/Bot management preset cho giờ cao điểm.

  5. Kế hoạch autoscale (ít nhất scale-up tạm thời).

  6. DR/Backup: snapshot trước chiến dịch; restore drill định kỳ.

  7. Runbook “P1-Ads”: ai làm gì, kênh nào, thông điệp nào – dán ngay phòng war-room.

Khi nào nên thuê ngoài đội bảo trì?

  • Bạn không có on-call 24/7, hoặc không có DevOps.

  • Hệ thống nhiều plugin tuỳ biến, khó rollback.

  • Chính sách bảo mật/backup không rõ ràng.

  • Đã từng gặp P1 lúc chạy Ads và thiệt hại lớn.

Khi sẵn sàng đặt SLA và checklist nghiêm túc, hãy xem trang dịch vụ Web Maintenance để chọn gói phù hợp. Nếu bạn cần góc nhìn chiến lược dài hạn ở HCM (SLA, roles, quy trình), đọc bài trụ cột về bảo trì website tại Hồ Chí Minh.

Website down khi chạy Ads là rủi ro có thể kiểm soát nếu đội ngũ có runbook P1 rõ ràng, ưu tiên khôi phục tối thiểu trong 120 phút, giảm cháy ngân sách đúng cách và bít các lỗ hổng kiến trúc sau sự cố. Đừng đợi lần down tiếp theo rồi mới lập kế hoạch.

Cần một plan 90 ngày để “chống đạn” mùa chiến dịch?

Zalo
Facebook
Zalo
Facebook