Google Cloud ouvre la fault injection en preview pour prouver la survie à une panne de zone
Google Cloud lance Fault Injection Testing en preview : des templates d’expérience automatisent le failover Cloud SQL et la dégradation de trafic via le load balancer L7, avec dry-run et réversion automatique. Les équipes GCP sans pratique de chaos engineering ont désormais un point d’entrée natif, au périmètre encore étroit.
27 août 2026. Deux scénarios. Dry-run avant injection. Google Cloud annonce Fault Injection Testing (FIT) en preview : un service managé qui déclenche volontairement des pannes pour vérifier qu’une application y survit, avec un dry-run automatisé et une réversion à l’expiration d’un minuteur. Pour les équipes GCP qui n’ont jamais mis en place de chaos engineering, c’est le premier chemin natif ; pour celles qui en ont déjà une pratique, le périmètre reste volontairement étroit.
Pourquoi Google pousse la résilience dans le produit
Le raisonnement de Google Cloud tient en une phrase : dans le cloud, on n’a plus d’accès direct à l’infrastructure pour provoquer une panne « proprement ». En datacenter auto-hébergé, un opérateur débranche un câble ou coupe un commutateur ; dans le cloud, les couches basses sont abstraites. Sans outil natif pour prouver qu’une application survit à une panne, la stratégie de fiabilité garde un trou que trois risques viennent combler : la confiance et la réputation dégradées après des incidents répétés, les pénalités réglementaires pour les secteurs qui doivent prouver leur reprise d’activité, et les migrations bloquées quand une équipe ne peut pas vérifier qu’une application critique tient une panne de zone.
FIT répond en automatisant la partie pénible : concevoir, déclencher, surveiller et réverter une panne volontaire. Le service s’appuie sur des templates d’expérience, des « plans » qui définissent la panne à injecter et les ressources ciblées. En preview, deux scénarios sont disponibles.
Les deux pannes que FIT sait injecter
Le premier scénario est le failover Cloud SQL : FIT déclenche la bascule d’une instance Cloud SQL haute disponibilité de sa zone primaire vers sa zone de secours. C’est l’exercice que toute équipe de production redoute de faire à la main — couper la zone principale d’une base et observer si l’application rebascule sans perte.
Le second est la dégradation de trafic applicatif : FIT ajoute sélectivement de la latence et des codes d’erreur HTTP à travers un load balancer de couche 7. Là où le failover teste la reprise, la dégradation teste la résistance : comment l’application, ses timeouts et ses retries se comportent quand une partie du trafic devient lent ou échoue.
Le séquençage est ce qui distingue FIT d’un simple script de panne. Avant toute injection, le service exécute un dry-run automatisé : une simulation en lecture seule qui vérifie les permissions et produit la liste à jour de toutes les ressources qui seront affectées. Ce n’est qu’après validation de ce périmètre que l’injection démarre, manuellement. La panne court sur la durée définie dans le template, puis les défauts sont révertés à l’expiration du minuteur. Si l’expérience dérape, une capacité stop and revert interrompt immédiatement l’exercice et restaure l’état nominal.
Un périmètre encore étroit
Le positionnement de FIT est honnête sur ses limites. Google Cloud recommande explicitement de l’utiliser en non-production pendant la preview, le temps d’apprendre comment le service s’articule avec les pratiques existantes. Deux partenaires, KeyBank et Servier, valident déjà des déploiements avec FIT en approximant des scénarios exigeants comme les pannes zonales.
Le périmètre technique est lui aussi restreint : deux types de panne, orientés réseau et base de données, pas de panne CPU, mémoire ou disque à l’intérieur des pods. Une pratique de chaos engineering complète — comme celle qu’offrent Chaos Mesh, LitmusChaos ou les offres commerciales — couvre un spectre bien plus large et fonctionne multi-cloud. FIT n’entre pas en concurrence avec ces outils sur ce terrain ; il en occupe la première marche, celle que la plupart des équipes n’ont jamais franchie.
L’accès suit les canaux habituels : la console Google Cloud, le CLI gcloud et les API REST. L’activation passe par l’API Fault Testing, et l’exécution d’expériences requiert le rôle roles/faulttesting.operator. Le chemin de prise en main recommandé est balisé : demander l’accès preview, activer l’API, assigner le rôle, puis exécuter un premier dry-run sur une ressource en non-production.
Pour mesurer le chemin parcouru, il suffit de comparer l’état actuel à l’état cible. Aujourd’hui, un failover Cloud SQL se déclenche à la main, sans filet ni réversion automatique :
# Failover manuel d’une instance Cloud SQL HA (ce que FIT automatise, encadre et réverte)
gcloud sql instances failover INSTANCE_NAME --project=PROJECT_IDFIT enveloppe exactement cette commande dans un template, un dry-run et une réversion minuteur — la différence entre un exercice reproductible et un geste d’urgence.
FIT face à AWS FIS et au chaos auto-hébergé
FIT n’arrive pas sur un terrain vide. AWS propose depuis plusieurs années Fault Injection Service (FIS), qui couvre un spectre plus large — pannes d’instance, de réseau, de disque — et s’intègre aux experiments codés en CloudFormation. Google Cloud choisit au contraire de démarrer étroit : deux scénarios, mais natif et pilotable en console, sans stack d’infra-as-code à écrire.
La comparaison se joue sur trois axes. Sur le périmètre de panne, FIS et les outils auto-hébergés comme Chaos Mesh injectent des défauts applicatifs et multi-cloud que FIT n’approche pas encore. Sur la friction, FIT gagne : un dry-run automatisé qui liste les ressources affectées avant l’injection, et une réversion minuteur par défaut, suppriment les deux excuses classiques pour ne pas tester. Sur la preuve réglementaire, enfin, pouvoir produire un rapport d’expérience reproductible depuis un service managé pèse lourd dans un audit de continuité.
Le choix n’est donc pas binaire. Une équipe GCP qui démarre a intérêt à adopter FIT pour la partie native, et à réserver Chaos Mesh aux défauts que FIT ne couvre pas — panne de pod, saturation CPU, latence inter-service. Les deux outils se complètent plus qu’ils ne se concurrencent.
Intégrer FIT dans un game day
Un game day est l’exercice collectif où une équipe provoque une panne volontaire et observe sa propre réaction. FIT en devient l’échafaudage naturel : le template fige le scénario, le dry-run le rend sûr, et le minuteur garantit que l’incident artificiel se termine.
Le déroulé recommandé tient en quatre temps. Avant : exécuter le dry-run pour valider le périmètre et prévenir les équipes concernées. Pendant : déclencher l’injection manuellement, puis observer les dashboards, les alertes et le comportement des retries. Si ça dérape : utiliser stop and revert pour restaurer l’état nominal, sans attendre la fin du minuteur. Après : consigner les écarts entre le comportement attendu et le comportement observé, et transformer chaque écart en ticket.
C’est là que la valeur de FIT se matérialise : un game day qui demande aujourd’hui une journée de préparation se réduit à un template et une exécution encadrée. La preview impose encore la non-production, mais la mécanique — template, dry-run, réversion — est exactement celle que la production attendra.
Verdict
Si vous êtes sur GCP et n’avez aucune pratique de chaos engineering, commencez par FIT en non-production dès que l’accès preview est ouvert : le dry-run automatisé supprime la peur de casser, et les deux scénarios couvrent les pannes que vous devez prouver pour un audit de continuité. Le coût d’entrée est un template et un rôle, pas une refonte.
Si vous avez déjà une pratique de chaos multi-cloud ou des pannes applicatives à injecter, gardez Chaos Mesh ou l’équivalent, et considérez FIT comme un complément pour la partie GCP native — failover et dégradation L7 — que vos outils ne pilotent pas aussi proprement. Le périmètre de la preview est trop étroit pour remplacer une plateforme de chaos ; il est exactement à la bonne taille pour la démarrer.