Checkup post-release automatisé (verdict 🟢🟡🔴)
« Déployé » ≠ « fini »
La release passe au vert, l'image tourne — et beaucoup s'arrêtent là. Mais les vrais problèmes (fuite mémoire, régression de latence, vague de 5xx, restarts en boucle) n'apparaissent que dans la fenêtre qui suit, sous vrai trafic. Le déploiement n'est réellement terminé que quand cette fenêtre est prouvée saine.
D'où un checkup post-release outillé : plutôt qu'un coup d'œil manuel au dashboard (subjectif, oubliable), une checklist de signaux mesurés sur une fenêtre courte (ex. 1h), chacun comparé à un seuil, qui produit un verdict tricolore.
Les signaux à couvrir
Requêtés sur l'observabilité (Prometheus/Grafana), sur [deploy, deploy+1h] :
| Signal | Question | Rouge si… |
|---|---|---|
| Rollout | la nouvelle version sert-elle 100 % ? | rollout bloqué / partiel |
| Restarts | les pods redémarrent-ils ? | restarts > 0 (CrashLoop) |
| Mémoire | fuite ? | courbe qui monte sans plateau / OOM |
| 5xx | erreurs serveur ? | taux 5xx > seuil vs baseline |
| 4xx | contrat cassé côté clients ? | pic de 4xx anormal |
| p99 | latence ? | p99 dégradée vs avant-release |
| Throttling | CPU étranglé ? | throttling > seuil |
| Logs erreur | nouvelles signatures ? | erreurs absentes avant la release |
Le verdict tricolore
L'intérêt : agréger ces signaux en une décision lisible en 2 secondes.
- 🟢 vert : tous les signaux sous seuil → la release est saine, on classe.
- 🟡 jaune : un signal en zone de vigilance (ex. p99 +15 %, quelques 4xx) → surveiller, pas rollback tout de suite.
- 🔴 rouge : au moins un signal critique (restarts, 5xx, OOM) → agir (rollback / hotfix), sans débat.
Le tricolore n'est pas cosmétique : il transforme un dashboard à interpréter en une décision à prendre. C'est ce qui rend le checkup automatisable (un job post-deploy qui poste le verdict dans le canal de livraison) et démocratise la lecture — pas besoin d'être l'expert Grafana pour savoir si la MEP est saine.
Le principe transférable
Un déploiement se clôt par une observation active de sa fenêtre, pas par le succès de la pipeline. Codifie les signaux et leurs seuils une fois, agrège-les en un verdict — tu remplaces « quelqu'un devrait regarder les métriques » (que personne ne fait) par un artefact systématique et partageable.
C'est le pendant post-déploiement de la readiness probe : la probe dit « prêt à servir », le checkup dit « sain une fois servi ». Les deux sont des portes, pas des impressions.
Pourquoi un déploiement n'est-il pas « fini » quand l'image tourne ?