La base est revenue depuis deux heures, mais plus personne ne peut se connecter : appli mobile, agences et partenaire bloqués

Toutes les connexions de MasterLinux passent par le service d'authentification ml-auth (auth.masterlinux.lab) :

• sur site, à Bouskoura : la passerelle API nginx ml-gw-01 (adresse virtuelle active, keepalived) et son secours ml-gw-02 ; elle relaie vers AWS par Direct Connect ;
• dans AWS (eu-west-3) : le Deployment ml-auth sur EKS (namespace auth, autoscaling de 6 à 40 pods) et sa base RDS PostgreSQL Multi-AZ ml-auth-db ;
• les clients : l'appli mobile des élèves, les terminaux des 14 agences (réglages de reprise distribués par AWS AppConfig) et le batch de synchronisation des partenaires, un job Cloud Run du projet GCP masterlinux-batch.

À 06:09, une maintenance AWS a provoqué une bascule Multi-AZ de ml-auth-db : 3 minutes sans base. Depuis 06:12, RDS est disponible. Mais l'authentification ne s'est jamais rétablie : la passerelle renvoie des 502 et 504, l'autoscaling est monté à 40 pods qui redémarrent sans cesse, le trafic entrant est dix fois plus haut que d'habitude. À 08:00, l'équipe de nuit a déjà « redémarré tous les pods » et « ajouté des nœuds », sans effet. Le directeur des opérations propose de « refaire une bascule de la base, au cas où » ; l'équipe applicative veut « monter à 80 pods ».

Vous êtes l'ingénieur de fiabilité (SRE) d'astreinte, sur ml-bastion (kubectl sur le cluster eks-masterlinux-prod, AWS CLI v2, gcloud, psql en lecture), avec un accès SSH à ml-gw-01 et ml-gw-02. Le runbook de délestage de la passerelle s'appelle RB-AUTH-07.