Quatre périmètres
| Périmètre | Où | Effet |
|---|---|---|
| Destination | page de la destination, ou l'outil de pause de l'assistant | le worker cesse de livrer à cette destination ; son template navigateur est retiré au prochain chargement de la configuration ; les événements continuent d'être collectés et stockés |
| Site | paramètres du site | le collecteur répond site_paused et rejette les événements entrants ; l'indicateur kill_switch du manifeste s'active, de sorte que le SDK se désactive à la page vue suivante |
| Organisation | paramètres de l'organisation | comme pour le site, pour chaque site de l'organisation |
| Plateforme | variable d'environnement de l'opérateur | le collecteur répond 503 avec la raison kill_switch à chaque requête ; réservé à un incident à l'échelle de la plateforme |
Activer l'un d'eux écrit une entrée d'audit avec l'acteur et une action distincte (site.kill_switch_on, org.kill_switch_on), afin que l'historique sépare les arrêts d'urgence des modifications ordinaires.
À quelle vitesse
- Worker : immédiatement pour les nouvelles livraisons ; les lots en cours se terminent ou échouent d'eux-mêmes.
- Collecteur : immédiatement, car le statut du site est lu à chaque requête depuis un cache de courte durée.
- Navigateur : à la page vue suivante. Le SDK recharge le petit manifeste à chaque chargement et s'arrête avant d'initialiser le moindre template fournisseur lorsque l'indicateur est actif ; les pages déjà chargées conservent leur état jusqu'à la prochaine navigation.
Ce que le kill switch ne fait pas : supprimer des événements déjà stockés, rappeler des livraisons déjà réussies ou modifier des données côté fournisseur. Ce sont des actions distinctes, avec leurs propres procédures.
Le playbook
Des données erronées sont envoyées à un fournisseur
Symptômes : des montants dans la mauvaise devise, des commandes de test en production, le mauvais identifiant de pixel. Étapes :
- Mettez la destination en pause (pas le site). La collecte continue, rien n'est perdu pendant que vous enquêtez.
- Ouvrez le moniteur de destination et le débogueur d'événements ; trouvez la première livraison erronée et la version de configuration qui l'a introduite.
- Revenez à la version précédente, ou corrigez le mapping et publiez.
- Réactivez la destination. Les livraisons mises en file d'attente pendant la pause sont envoyées avec la configuration corrigée.
- Dans l'interface du fournisseur, excluez ou supprimez les conversions concernées si la plateforme le permet ; notez l'identifiant de requête dans le rapport d'incident.
Une question juridique ou de consentement doit être tranchée avant le prochain événement
Étapes : activez le kill switch du site ; plus rien de nouveau n'est collecté, le SDK se désactive ; l'entrée d'audit horodate l'arrêt. Enquêtez avec la page de consentement et le débogueur. Reprenez en désactivant le kill switch ; le SDK se réactive à la page vue suivante. Si la question concerne des données déjà collectées, utilisez les outils DSAR (demandes d'exercice des droits) et de conservation, pas le kill switch.
Un fournisseur est en panne
Ne faites rien. Le worker classe les réponses 5xx comme temporaires, réessaie avec un délai progressif et ouvre le circuit breaker de cette destination ; les événements en file d'attente sont livrés lorsque le fournisseur se rétablit, dans la fenêtre d'horodatage de chaque API. Mettre la destination en pause ne ferait que retarder le rétablissement. Surveillez l'état de santé de la destination et le nombre d'événements en dead-letter.
Des identifiants d'accès ont fuité
Étapes : renouvelez les identifiants d'accès dans le coffre-fort (les anciens sont invalidés côté fournisseur par vos soins, puis remplacés dans Track) ; mettre la destination en pause entre-temps évite une rafale d'échecs d'authentification. Le journal d'audit montre qui a lu ou renouvelé les identifiants d'accès ; la valeur elle-même n'a jamais été journalisée.
Compte d'équipe compromis
Étapes : retirez le membre (ses sessions sont révoquées), activez le kill switch de l'organisation si vous ne pouvez pas exclure des modifications publiées, examinez l'historique des versions à la recherche des publications de ce compte, revenez à la version précédente si nécessaire, puis reprenez.
Répétez l'exercice
Le kill switch n'est rapide que si les personnes d'astreinte savent où il se trouve. Placez le lien vers les paramètres du site et ce playbook dans les notes d'astreinte, et entraînez-vous à une pause suivie d'une reprise sur un site de staging une fois par trimestre ; le journal d'audit rend l'exercice vérifiable.