Site Web en panne lors de la diffusion d'annonces : processus de traitement P1 dans les 2 heures

Lorsque le site Web « tombe soudainement malade » alors qu'il brûle son budget publicitaire, les dégâts ne sont pas seulement l'argent publicitaire brûlé, mais aussi la perte de commandes, la perte de réputation et les troubles internes. Cet article satellite guide le processus de dépannage P1 en 2 heures - pratique, concis, avec des listes de contrôle - afin que votre équipe puisse restaurer sereinement le site Web le plus rapidement possible, tout en réduisant la perte de budget publicitaire.

Il s'agit d'un article complémentaire à l'article principal sur les services de maintenance dans HCM. Si vous avez besoin de la feuille de route complète (SLA, processus, outils), consultez Service de maintenance du site Web Ho Chi Minh – Pillar Page.

Situation typique lorsque "les publicités sont en panne pendant leur diffusion"

• Charge soudaine en raison d'un fort pompage par TVC/Influenceur/Performance → CPU/RAM/DB "brûlant en rouge", les lignes attendent pour une connexion complète, délai d'attente Web.

• Mise à jour dépêchée (plugin/thème/core) avant de lancer la campagne → conflit, erreur PHP/JS, page blanche.

• Infrastructure faible : cache/CDN non optimisé, base de données pas d'index/mise en cache, pas de mise à l'échelle automatique.

• Attaque DDoS/couche 7 juste à côté le « point de chute » – suspicion de la part des concurrents/botnets.

• Problèmes de paiement/panier : délai d'attente de la passerelle, échec du webhook → les utilisateurs ne peuvent pas payer, perte de revenus.

Objectif P1 en 2 heures

1. Récupération d'accès (page d'accueil/atterrissage/paiement minimum) à un niveau "suffisant" niveau.

2. Réduisez la consommation budgétaire : ajustez le canal publicitaire pour un atterrissage temporaire, réduisez le budget ou effectuez une pause contrôlée.

3. Isolez la cause et évitez toute récidive pendant la période de l'incident.

4. Court rapport post-mortem dans les 24 heures pour apprendre le test.

120 minutes Processus (minute par minute)

T-00 → T-15 : EXAMEN ET NOTIFICATION RAPIDES

• Activer une page de maintenance conviviale (503 + nouvelle tentative après) ou atterrissage de basculement statique (HTML + formulaire/CTA), rebond limité.

• Notification interne (Marketing/CS/Ventes/Fondateur) dans une phrase : "P1 – temps d'arrêt du site, ETA 120' - mises à jour toutes les 15'."

• Vérification rapide :

  • TTFB/uptime (StatusCake/UptimeRobot).

  • Connexions CPU/RAM/IO/DB (tableau de bord Cloud/Hébergement) BREATHING »

    • Charge élevée suspectée : activer/renforcer CDN/WAF, page de cache, réduire la durée de vie ; désactiver temporairement les requêtes lourdes (recherche, filtre).

    • Conflit de code suspecté : restaurer la dernière version (Git/Backup), désactiver le suspect plugin.

    • Couche DDoS 7 suspectée : activez le Mode d'attaque (Cloudflare), bloquez les IP/ASN anormaux, la limite de débit importante des points de terminaison (/search, /cart, /checkout).

    • Congestion de la base de données : vider le cache de requêtes lentes, augmenter max_connections temporairement, redémarrez le service si nécessaire.

    T-30 → T-60 : MINIMISER LA RÉCUPÉRATION ET RÉDUIRE LES COÛTS PUBLICITÉS

    • Rouvrir l'itinéraire pour la page de vente/d'arrivée/de paiement en premier. La partie blog/introduction peut être laissée pour ; plus tard.

    • Marketing :

      • Si le site n'est pas stable : transférez le budget vers un atterrissage statique (AMP/HTML statique, CDN) ou un formulaire de prospect de secours (Google Form/Typeform).

      • Réduisez de 30 à 70 % du budget pour les équipes qui ont un feu vif ; Désactivez temporairement les emplacements de mauvaise qualité.

      • Mettre à jour le service client : "Le système est en cours de maintenance urgente, veuillez commander via la hotline/la boîte de réception".

    • Contrôle qualité rapide : ordinateur/mobile, connexion/inscription/panier/paiement (bac à sable), formulaire pour prospects, pixel/GA4/UTM.

    T-60 → T-90 : STABILISÉ ET HARDIFIÉ

    • Protection supplémentaire :

      • Cache le HTML pleine page (sauf panier/paiement).

      • Différer/async JS, désactiver les scripts inutiles.

      • Limitations sévères des fonctionnalités : recherche en direct, comparaison, suggestions associées.

    • Infrastructure :

      • Augmenter temporairement le CPU/RAM du vCPU, activer la mise à l'échelle automatique si disponible.

      • Déplacez le média vers CDN s'il n'est pas encore disponible.

    • DB :

      • Optimisez l'index de pliage pour les tables fréquemment interrogées (commandes, publications, produits).

      • Activez le cache d'objets (Redis/Memcached).

    T-90 → T-120 : ESSAYEZ ADS À CHARGE LÉGÈRE ET REDISCRIMINATION ADS

    • Test de charge légère (scénario de parcours utilisateur principal 5 à 10 requêtes/s).

    • Réaffectation des annonces : petits groupes, augmentant progressivement en fonction du seuil de charge.

    • Journalisation des incidents : chronologie – cause préliminaire – modifications appliquées – retard dans être effectué plus tard.

    Ensemble de rôles et canaux de communication (5 personnes suffisent)

    • Responsable des incidents (DevOps/Tech Lead) : prise de décision technique, mises à jour en 15 minutes.

    • Ingénieur Web : restauration, correctif, activation/activation des fonctionnalités, assurance qualité technique techniques.

    • Performance/Marketing : ajuster les annonces/atterrissages, les messages du service client.

    • CS/CRM : Recevoir des leads/commandes manuellement, rassurer les clients, synthétiser les commentaires.

    • Partie prenante (PM/Fondateur) : approuver les messages publics et prioriser les sources force.

    Canal : 1 groupe de discussion général (Slack/Telegram), 1 tableau de tâches (Trello/Jira) → éviter le chaos de l'information.

    Listes de contrôle de combat rapides

    A. Technique (restauration en 2 heures)

    • Activer l'atterrissage 503 ou statique (avec CTA).

    • CDN/WAF : sous-attaque, limite de débit, combat de robots.

    • Code/plug-in de restauration, désactiver les éléments récemment mis à jour.

    • Rouvrir les pages semi-importantes ; désactivez les fonctions lourdes.

    • Redis/Memcached + cache de pages plein ; Réduisez le TTL DNS/CDN.

    • DB : augmentez la connexion temporaire, optimisez les requêtes lentes, redémarrez si verrouillé.

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

    B. Marketing/CS (réduire la consommation budgétaire)

    • Ajuster le budget de la campagne, désactiver temporairement le groupe à risque.

    • Redirection vers un formulaire d'atterrissage/de sauvegarde statique.

    • Bref avis sur la fanpage/CS : maintenance urgente en cours.

    • Collecte manuelle de leads (hotline/boîte de réception) – entrez à nouveau dans CRM plus tard.

    C. Après stabilisation (24 h)

    • Post-mortem : cause première (RCA) + actions préventives.

    • Plan d'optimisation de l'infrastructure (cache/CDN/WAF/autoscale).

    • Restaurer le calendrier des exercices et les mises à jour de sécurité.

    Pour comprendre le paysage global de la maintenance par mois (calendrier, cadence, rapport), reportez-vous à Processus de maintenance mensuel du site Web et perspective stratégique dans articles sur la maintenance et le service après-vente.

    6 causes profondes courantes et comment "boucher le trou"

    1. Conflits de code/plug-in juste avant la campagne
       Prévention : staging → QA → déploiement avec liste de contrôle ; geler le code 48 heures avant l'heure Surveillance : cache hit/miss, TTFB.
       Correction : activer le cache de page complète, déplacer les médias vers CDN, réduire les scripts.

    2. Congestion de la base de données - requêtes lentes
       Prévention : ajouter un index, un plan de requête, une pagination, une mise en cache.
       Surveiller : journal des requêtes lent, max. connexions.
       Correction : optimise rapidement les requêtes lourdes, augmente les ressources, divise les répliques le cas échéant.

    3. DDoS/Couche 7 au bon moment
       Prévention : WAF, gestion des robots, seuil par IP/ASN.
       Surveillance : pics inhabituels par pays/ASN.
       Correction : Sous attaque, défi, blocage plage.

    autoscale
    Prévention : charge benchmark, autoscale, séparation stockage BD/fichiers.
    Remède : mise à niveau temporaire de la configuration, après la campagne de planification de l'architecture.

    Exemple de message de communication (court – rassurant – avec alternative)

    "Désolé pour le désagrément ! L'augmentation soudaine du trafic a provoqué une surcharge temporaire du système. L'équipe technique se rétablit dans les 120 minutes. Vous pouvez commander rapidement via le lien de sauvegarde ou envoyer un SMS à la boîte de réception/Hotline 09xx… pour une assistance immédiate ! 

    Après l'incident : 7 choses à faire pour ne plus avoir P1

    1. avant la campagne. 48 à 72 h.

    2. Staging requis + liste de contrôle d'assurance qualité, avec restauration en 1 clic.

    3. CDN + cache pleine page + cache d'objets fonctionne réellement (mesure des succès/échecs).

    4. Gestion WAF/Bot prédéfinie pour les heures de pointe.

    5. Planifier la mise à l'échelle automatique (au moins une mise à l'échelle temporaire).

    6. DR/Sauvegarde : instantané avant la campagne ; Restaurez l'exercice périodiquement.

    7. Runbook « P1-Ads » : qui fait quoi, quel canal, quel message – publiez-le immédiatement dans la salle de crise.

    Quand externaliser une équipe de maintenance ?

    • Vous n'avez pas de garde 24h/24 et 7j/7, ou n'en avez pas. DevOps.

    sérieusement, veuillez consulter la Page du service de maintenance Web pour choisir le package approprié. Si vous avez besoin d'une perspective stratégique à long terme en matière de HCM (SLA, rôles, processus), lisez les piliers sur la maintenance du site Web à Ho Chi Minh.

    Le site Web est en panne lors de la diffusion d'annonces. Le risque peut être contrôlé si l'équipe dispose d'un runbook P1 clair, donne la priorité à une récupération minimale en 120 minutes, brûle les budgets correctement et corrige les vulnérabilités architecturales après l'incident. N'attendez pas le prochain téléchargement pour élaborer un plan.

    Besoin d'un plan de 90 jours pour être "à toute épreuve" pendant la saison de campagne ?

    • Recevez un audit technique de 60 minutes gratuit et une proposition de SLA spécifique.

    • Référez-vous à la feuille de route de maintenance actuelle dans HCM dans article approfondi et processus de maintenance mensuel.

    • Ou contactez directement via Services de maintenance Web pour obtenir des conseils sur les forfaits appropriés.