Diagnostiquer les pannes de gateway API en production (Course #gateway-ops-clinic)
For ingénieurs plateforme, SRE, responsables des opérations API, architectes d'intégration.
À la fin, vous saurez
À l'issue de cette formation, vous saurez diagnostiquer une panne de gateway API sur n'importe quelle plateforme — registre des plafonds, mesure du rayon d'impact du limiteur et suite de tests de parité — afin que le prochain incident soit borné par des preuves et non par une documentation éditeur que vous n'avez pas encore lue.
Cas fil rouge
Thornbury Freight achemine ses API douane, suivi et réservation pour 9 pays à travers deux parcs de gateways hérités d'une acquisition : l'un managé, l'autre auto-hébergé sur Kubernetes. Le pic atteint 3 200 req/s à la clôture douanière de 06:00 CET, et les deux derniers incidents étaient des défaillances de limiteur ayant laissé un partenaire émettre 8× son débit contractuel sans qu'un seul 429 ne soit renvoyé. La direction veut une norme d'exploitation unique sur les deux parcs : p99 sous 400 ms, aucune limite plateforme non recensée à la mise en service, et chaque incident clos sur des preuves reproductibles.
Programme chaque ligne est quelque chose que vous faites
6 modules · 18 sujets · dans l'ordre du cours
-
Module 1
Les limiteurs cèdent en position ouverte
Objectif. Mesurer ce qu'un limiteur de débit distribué applique réellement quand son magasin de compteurs est indisponible, et produire le rayon d'impact pour votre parc.
- Calculer le multiplicateur de défaillance : une limite de 100 req/min dégénère en 100×N quand N nœuds retombent en comptage local
- Comparer les comptages local, cluster et adossé à Redis sur un même cluster de 3 nœuds et relever la précision obtenue lors d'une partition de 60 secondes
- Rédiger le contrat client d'une gateway qui ne déleste pas — budget de réessai, gigue, et table de décision 429 contre 503
-
Module 2
Trouver le plafond avant la production
Objectif. Recenser les limites publiées qu'une conception touche et construire le registre des plafonds qui fait de chacune un choix délibéré.
- Cataloguer les plafonds franchis par votre conception — charge utile, template de mapping, taille de trame, timeout d'intégration — et marquer chacun ferme ou relevable par quota
- Arbitrer un plafond contre un autre : porter un timeout d'intégration de 29 s vers 300 s peut se payer en quota de throttle au niveau du compte
- Réviser le registre à chaque évolution de conception, avec pour cible zéro limite plateforme non recensée à la mise en service
-
Module 3
Les preuves que la gateway retient
Objectif. Établir ce que la plateforme n'enregistre pas et réunir les preuves manquantes avant l'incident qui en aura besoin.
- Démontrer le trou : des événements de log tronqués à 1024 octets écartent silencieusement les corps de requête et de réponse de la piste d'audit
- Distinguer indicateur de charge et compteur de trafic — une métrique de capacité qui bouge à trafic nul n'est pas un nombre de requêtes
- Mettre en place les preuves qu'il faut posséder soi-même : identifiant de corrélation, trace amont et stockage échantillonné des charges utiles avec une rétention cible de 30 jours
-
Module 4
Chaque saut réécrit la requête
Objectif. Comparer la requête émise par le client à celle reçue par le backend, et cataloguer chaque transformation imposée par la gateway.
- Exécuter un diff de 12 cas d'en-têtes et de paramètres à travers la gateway et relever chaque suppression, remappage et changement de sensibilité à la casse
- Localiser la rupture d'identité : un en-tête Authorization supprimé sous un mode d'authentification parvient au backend sous un autre
- Écrire les tests de négociation de contenu qui détectent une gateway n'honorant que le premier type de média Accept
-
Module 5
La configuration ne voyage pas
Objectif. Rejouer un même jeu de policies sur deux implémentations et documenter précisément où s'arrête la portabilité.
- Exécuter le même jeu de policies sur deux gateways et relever lesquelles des 6 familles de pannes divergent
- Lire une revendication de conformité avec précision : elle couvre une combinaison Route-et-Profil plus les seules fonctionnalités étendues que l'implémentation revendique
- Verrouiller la dérive en CI en réconciliant configuration déclarée et configuration active à chaque merge, avec échec du build en cas d'écart
-
Module 6
Préparer la sortie avant l'entrée
Objectif. Concevoir le chemin de migration et de retour arrière d'un parc de gateways avant le déplacement de la première route.
- Classer chaque annotation et policy en traduite, spécifique à l'implémentation, ou sans équivalent sur la cible
- Prouver la parité avant tout déplacement de trafic, avec pour cible 100 % des routes couvertes par un contrôle de parité automatisé
- Répéter le retour arrière plutôt que le documenter, dans une fenêtre de reprise de 15 minutes
Références & documentation officielle chaque affirmation ci-dessus a une source
Module 1
- RFC 6585 — Additional HTTP Status CodesSpécification
- Plugin Rate Limiting AdvancedDoc MuleSoft
Module 2
Module 3
- Notes importantes Amazon API GatewayDoc MuleSoft
- Capacity of an Azure API Management instanceDoc MuleSoft
Module 4
- RFC 9110 — HTTP SemanticsSpécification
Module 5
- Gateway API implementationsDoc MuleSoft
Module 6
- Announcing Ingress2Gateway 1.0Doc MuleSoft