Sprint 6 Report — Multi-environnements¶

Période : 2026-07-07 à 2026-08-17 Release : aucune — main reste une archive (#57), la promotion se fait par overlay Équipe : 1 ingénieur DevOps (Youssef Kadi) Repo : gitlab.com/yk-devops/fastapi-eks-project

Executive Summary¶

À l'entrée du Sprint 6, la plateforme était complète mais mono-environnement : une seule instance de l'API, une seule base, un seul jeu de secrets, et aucune façon de valider un changement ailleurs qu'en production. Ce sprint a livré la séparation dev / staging / prod sur un cluster unique, par isolation de namespace et overlays Kustomize (ADR 029), avec deux ApplicationSet ArgoCD et une promotion d'image par merge request délibérée.

Le socle est en place et prouvé en conditions réelles : trois bases de données, trois rôles IRSA aux permissions cloisonnées, un DNS à plat, une isolation inter-environnements vérifiée à trois niveaux (réseau, quota, identité cloud) et une rétention d'images par environnement. Le Gateway reste partagé, un seul NLB pour les trois environnements, fastapi devenant un namespace de plateforme pendant que les charges vivent dans fastapi-<env>.

Mais la signature du sprint est ailleurs. Le multi-environnements a servi de révélateur. En mettant trois environnements sous le même cluster, il a rendu visibles des défauts qui existaient déjà et que l'instance unique masquait : deux environnements exposés publiquement en clair et branchés sur la base de production, aucune redirection HTTP vers HTTPS, un plafond d'autoscaling réel de 3 replicas là où le tableau de bord en annonçait 5, des 503 servis sous charge par deux causes distinctes, et la rétention du registre qui a supprimé l'image servie par la production. Deux incidents de sécurité et sept incidents techniques ont été capitalisés.

Conséquence directe sur le pilotage : 77 % du scope est né en cours de sprint (33 issues sur 43), contre 55 % au Sprint 5. Le sprint a duré six semaines pour un timebox de deux, et se clôt à 36 issues sur 43, les 7 restantes partant en Sprint 7.

Bilan des actions de la rétrospective Sprint 5¶

On rend compte des 3 actions que la rétro du Sprint 5 s'était engagée à mener. Une rétro dont personne ne vérifie les actions est un rituel vide.

Action Sprint 5	Verdict	Détail
`resource_group` sur les jobs infra start/stop	⚠️ Fait sur le papier, sans effet prouvé	Livré et mergé le 2026-07-25 (#132). Mais le critère de vérification annoncé, deux pipelines infra qui se sérialisent, n'a jamais été exercé en live. Pire, le diagnostic du 2026-08-16 a montré que le schedule de teardown du soir échoue à zéro job depuis au moins le 06/08 et ne détruit donc rien. Le garde-fou existe, la protection non. Repart en #174.
Cadrer le multi-environnements par un ADR stratégie AVANT tout code	✅ Fait	ADR 029 livré (#133), 23 Ko, qui a effectivement tenu le sprint : isolation par namespace, promotion overlay-driven, rôle de `main`, une seule instance RDS multi-bases. Aucune de ces quatre décisions n'a été rouverte ensuite.
Alerter sur les pannes silencieuses (PrometheusRule `metrics.k8s.io` Unavailable)	❌ Non fait	#141 n'a pas été ouverte une seule fois du sprint. Deuxième report consécutif. Elle repart en Sprint 7, et le sprint qui vient de s'écouler a donné trois nouveaux exemples de panne silencieuse (métriques perdues, plafond d'autoscaling, image expirée du registre).

Stories livrées¶

36 issues fermées sur 43, portées par 73 merge requests mergées (!242 → !316).

Socle multi-environnements¶

Issue	Livré
#133	ADR 029, stratégie multi-environnements
#134	Overlays Kustomize dev/staging/prod + 2 ApplicationSet
#136	ResourceQuota, LimitRange, RBAC et Pod Security Admission par environnement
#137	Une base de données par environnement, trois jeux de droits cloisonnés
#138	Sous-domaines DNS et secrets AWS Secrets Manager par environnement, IRSA scopé
#139	Write-back GitOps reciblé sur `dev` seul, promotion par merge request
#144	Script `promote.sh` et page pédagogique sur la promotion multi-env
#151	Correction de `promote.sh`, qui reformatait les overlays à chaque promotion

Sécurité¶

Issue	Livré
#146	SEC-006 : dev et staging étaient exposés publiquement en clair et branchés sur la base de production
#147	SEC-007 : aucune redirection HTTP vers HTTPS, identifiants transmis en clair, production comprise
#135	NetworkPolicy inter-environnements, `default-deny` puis autorisation intra-env. Isolation prouvée à trois niveaux
#156	L'URL de l'API n'est plus figée dans l'image du frontend : les trois environnements tapaient la production

Capacité et comportement sous charge¶

Issue	Livré
#158	Le plafond réel de l'autoscaling était 3 replicas, pas les 5 affichés
#164	Le HPA sur la mémoire interdisait tout scale-down, effet cliquet
#149	Le quota de production saturait pendant un rollout à pleine charge
#162	Sous charge, la liveness probe redémarrait les pods de production
#169	INC-066 : la readiness expire sous throttling CPU, Envoy sert des 503
#172	INC-067 : le keep-alive d'uvicorn plus court que le pool d'Envoy, un 503 sur 5 700
#148	`cilium-envoy`, plan de données L7, tournait en `BestEffort` et serait évincé le premier

Chaîne de livraison et registre¶

Issue	Livré
#150	INC-062 et INC-065 : la rétention ECR expirait l'image servie par la production
#157	Le périmètre des pipelines : un merge documentaire reconstruisait l'image. 17 jobs et ~8 min → 5 jobs et 2 min 24
#161	Backend déplacé sous `backend/`, le contexte de build ne contient plus que de l'applicatif (ADR 030)
#176	Sources `pip-compile` restées à la racine après #161
#173	Le chart metrics-server n'était pas épinglé, sa version changeait à chaque montage
#168	Aucun contrôle `terraform fmt` en CI, un bloc mal aligné vivait dans le dépôt
#132	`resource_group` sur les jobs infra start/stop

Observabilité¶

Issue	Livré
#152	INC-063 : plus aucune métrique de l'API collectée depuis le passage au multi-env
#153	Le dashboard RED agrégeait les trois environnements sans les distinguer

Documentation et process¶

Issue	Livré
#166	Radiateur d'information : page d'état du projet générée depuis l'API
#170	Rien ne rappelait le mot-clé `Closes #N` à l'ouverture d'une MR, corrigé par un template
#171	Gabarit, sommaire et identité visuelle pour les pages `comprendre/`
#167	La section 2 du runbook validait l'autoscaling par le mauvais chemin
#175	Le `CLAUDE.md` du dépôt affirmait que le schedule du soir lançait `registry-scan`
#177	Page expliquant la refonte du périmètre de pipeline
#142, #143	Nettoyage des sauvegardes résiduelles, `CLAUDE.md` public à la racine

Stories non livrées, reportées en Sprint 7¶

Issue	Pourquoi
#140	Tests E2E API et frontend. Issue du cadrage initial. Porte le gate de production dur, donc structurante
#141	Blackbox Exporter et alerte `APIService Unavailable`. Issue du cadrage initial, deuxième report
#163	Karpenter. N'était plus bloqué depuis la levée du cliquet HPA le 12/08, mais n'a pas trouvé de place
#165	Dimensionnement du runner : 2 vCPU pour un `config.toml` qui en promet 4
#174	Cadrage du garde-fou de teardown, non tranché : détruire ou seulement prévenir ?
#178	Couverture de sécurité imaginaire : `dependency_scanning` n'apparaît dans aucun pipeline
#179	Découpage du `.gitlab-ci.yml`, 819 lignes et 12 ancres YAML utilisées 35 fois

Aucune de ces 7 issues n'est en priority::high. Deux d'entre elles, #140 et #141, viennent pourtant du cadrage initial : ce sont les seules des 10 issues de départ à ne pas avoir été livrées.

Vélocité¶

Baseline Sprint 5 = 20 éléments livrés. Sprint 6 = 36 éléments, portés par 73 merge requests (!242 → !316).

Type	Nb
`type::infra`	10
`type::docs`	9
`type::bug`	5
`type::ci-cd`	5
`type::security`	4
`type::fix`	2
`type::feature`	1
Total	36

Scope ajouté en cours de sprint : 33 issues sur 43, soit 77 %. Le cadrage du 2026-07-07 comptait 10 issues (#132 à #141). Tout le reste est né pendant le sprint, en trois vagues nettes : le cutover multi-env de fin juillet (11 issues), la campagne de charge du 11 au 12 août (9 issues), et la journée du 16 août consacrée au coût et au périmètre des pipelines (8 issues).

Lecture honnête de ce chiffre. Au Sprint 5, les 55 % d'ajout étaient revendiqués comme une force : des findings de validation live tracés et livrés le jour même. À 77 % sur six semaines, l'interprétation change. Le cadrage initial de 10 issues sous-estimait le sujet d'un facteur quatre, et un sprint qui absorbe quatre fois son scope n'est plus un sprint time-boxé, c'est une file d'attente. C'est le principal enseignement de pilotage de ce sprint.

Incidents majeurs et résolutions¶

Le sprint a capitalisé 9 incidents : 2 de sécurité (SEC-006, SEC-007) et 7 techniques (INC-062 à INC-068). Détail complet dans sprint6.md.

Les deux incidents de sécurité¶

SEC-006 et SEC-007 partagent la même nature : la protection était écrite quelque part, mais rien ne l'appliquait. Dev et staging exposés publiquement en clair et branchés sur la base de production, alors qu'une consigne écrite disait le contraire. Aucune redirection HTTP vers HTTPS, donc des identifiants transmis en clair sur la production elle-même.

Leçon commune, et sans doute la plus importante du sprint : une règle écrite dans une documentation n'est pas un contrôle. Seul un test négatif, tenter l'action interdite et vérifier qu'elle échoue, distingue les deux.

Les incidents techniques¶

Incident	Sujet	Leçon retenue
INC-062, INC-065	La rétention ECR a supprimé l'image servie par staging puis par la production	Élargir la fenêtre de 5 à 30 puis 100 ne fait que retarder l'échéance. Il faut marquer ce qui est en service. Le premier correctif portait lui-même le défaut symétrique
INC-063	Plus aucune métrique de l'API après le passage au multi-env	Un `namespaceSelector` figé sur un namespace devenu vide. Une supervision muette ne se signale pas elle-même
INC-064	`trivy-image-scan` rouge sur deux CVE d'outillage jamais installé	Un scanner rapporte ce qu'il sait lire, pas ce qui est installé
INC-066	Sous charge, la readiness expire et Envoy sert des 503	Le throttling CPU retire la capacité exactement au pire moment
INC-067	Un 503 sur 5 700 servi aux clients, keep-alive uvicorn plus court que le pool Envoy	Deux délais qui ne se parlent pas finissent par se croiser. Corriger la première panne en a révélé une seconde, qu'elle masquait
INC-068	Une CVE système bloque tous les builds	Épingler par digest fige aussi les failles : un rebuild ne récupère aucun correctif amont

Décisions d'architecture (ADR)¶

ADR	Décision
029	Stratégie multi-environnements : isolation par namespace et overlays Kustomize sur un cluster unique, promotion par merge request, `main` conservé en archive, une seule instance RDS portant trois bases
030	Layout du dépôt et contexte de build : backend déplacé sous `backend/`, le contexte de build ne contient plus que de l'applicatif

L'ADR 029 est le document structurant du sprint. Ses quatre décisions ont tenu six semaines sans être rouvertes, ce qui valide l'action de la rétro Sprint 5 : cadrer par un ADR avant de coder.

Rétrospective¶

Ce qui a bien fonctionné¶

L'ADR avant le code. Quatre décisions posées en début de sprint, aucune rouverte ensuite. Le contraste avec les sprints précédents est net.
Les campagnes de charge comme méthode. Les 503 n'ont pas été trouvés par lecture de code mais par tir de charge mesuré, puis séparés en deux causes distinctes grâce aux response_flags d'Envoy. Chiffres à l'appui : 87 578 requêtes à 729 req/s, zéro 503 après correctif.
Le coût de la CI traité comme un sujet d'ingénierie. #157 divise par plus de trois le coût d'un merge documentaire, avec un job pipeline-scope qui garantit qu'aucun pipeline ne part à vide.
Chaque finding tracé le jour même. 33 issues nées en cours de sprint, toutes avec leur milestone. Le scope a bougé, la traçabilité non.
L'outillage d'observabilité enfin utilisé pour diagnostiquer. Les logs d'accès Envoy introuvables par kubectl logs ont été retrouvés en une requête LogQL dans Loki, déployé depuis le Sprint 4.

Ce qui a bloqué ou coûté du temps¶

Le timebox n'a pas été tenu, et de loin. Six semaines pour deux annoncées. Aucun point d'arrêt intermédiaire n'a été posé pour constater la dérive pendant qu'elle se produisait.
Le cadrage a sous-estimé le sujet d'un facteur quatre. 10 issues prévues, 43 réelles. Le multi-environnements n'était pas une story, c'était un chantier.
Trois défauts découverts après plusieurs jours ou semaines d'existence : les métriques perdues, le plafond d'autoscaling à 3, les environnements exposés en clair. Aucun ne s'est signalé de lui-même, ce qui renvoie exactement à l'action #141 reportée deux fois.
Les correctifs qui portaient leur propre défaut. La rétention ECR a demandé deux passes, la seconde ayant introduit un défaut symétrique de la première.
Les indicateurs verts qui ne prouvaient rien. Quatre formes distinctes ont été identifiées et documentées pendant le sprint, dont un pipeline vide qui sort failed sans erreur et des jobs de sécurité qui ne tournent jamais sur une merge request.

3 actions concrètes pour Sprint 7¶

Clore le Sprint 7 à sa date, avec un point d'étape à mi-parcours. Vérifiable : une revue de mi-sprint datée, et une clôture qui sort le reliquat au lieu de prolonger la fenêtre. C'est la réponse directe aux six semaines pour deux.
Solder les gardes-fous qui n'en sont pas : #174, le teardown du soir qui ne détruit rien, et #178, dependency_scanning absent de tous les pipelines. Vérifiable par test négatif dans les deux cas : provoquer la situation que le garde-fou est censé attraper, et constater qu'il attrape. Un vert ne suffit pas.
Livrer #141, l'alerte sur les pannes silencieuses. Troisième inscription. Vérifiable : couper volontairement le composant surveillé et recevoir l'alerte. Le sprint qui s'achève a fourni trois exemples de plus, la dette n'est plus théorique.

Validation end-to-end¶

Dernière validation complète en conditions réelles : 2026-08-16, avant le teardown du cluster.

Isolation inter-environnements prouvée à trois niveaux (#135) : réseau par NetworkPolicy, ressources par quota, identité cloud par rôle IRSA scopé
Trois bases de données avec droits cloisonnés, un seul Gateway et donc un seul NLB pour les trois environnements
Charge validée : 87 578 requêtes en 120 s à 729,2 req/s, zéro 503, confirmé par l'absence de response_flags: UC dans Loki sur la route fastapi
Rétention ECR par environnement validée après deux passes, marquage inuse- de ce qui est en service
Coût d'un merge documentaire : 5 jobs et 2 min 24, contre 17 jobs et environ 8 min avant #157

Restant à vérifier au prochain montage from-scratch (#148, #173) : cilium-envoy et cilium-operator en Burstable, Hubble en BestEffort, et metrics-server épinglé en 3.13.1 visible dans helm list -n kube-system. Ces trois points sont livrés dans le dépôt mais n'ont pas encore été observés sur un cluster monté de zéro.

Documentation publique : doc.devopsyouss.com

Sprint 6 clôturé le 2026-08-17. Aucune release vers main : la promotion se fait par overlay, main reste une archive (#57). Les 7 issues restantes sont reportées en Sprint 7.