Quand votre déploiement tourne mal : pourquoi l'observabilité est votre outil de récupération
Vous venez de déployer une nouvelle version. En quelques minutes, les utilisateurs commencent à signaler des erreurs. Le canal de support se remplit de captures d'écran. Quelqu'un dit que la page charge indéfiniment. Un autre rapporte un écran blanc.
La première question que tout le monde pose : « Que s'est-il réellement passé ? »
Sans données, l'équipe commence à deviner. Peut-être que c'est la migration de base de données. Peut-être une fuite mémoire. Peut-être juste un pic de trafic. Chaque supposition mène à une action de récupération différente. Si vous devinez mal, vous aggravez la situation.
C'est là que l'observabilité cesse d'être un luxe de monitoring pour devenir votre principal outil de récupération.
Ce que l'observabilité signifie vraiment en situation de crise
L'observabilité, c'est la capacité à comprendre ce qui se passe dans votre système sans avoir à vous connecter un par un sur les serveurs ni à faire des suppositions éclairées. Elle répond à trois questions pratiques lors d'un incident :
- Qu'est-ce qui a cassé ?
- Où cela a-t-il cassé ?
- Comment le réparer ?
Trois types de données vous apportent ces réponses : les logs, les métriques et les traces. Chacun joue un rôle différent lorsque vous essayez de récupérer d'un mauvais déploiement.
Les logs : le premier endroit où regarder
Lorsqu'un utilisateur signale une erreur, les logs sont votre premier indice. Une entrée de log structurée peut vous dire si la connexion à la base de données a été perdue, si une exception non gérée est apparue dans le nouveau code, ou si une API tierce a renvoyé quelque chose d'inattendu.
Sans bons logs, vous ne pouvez pas déterminer si le problème vient de la nouvelle version ou s'il existait avant le déploiement. Vous perdez du temps à courir après des chimères. Avec des logs bien structurés et consultables, vous pouvez filtrer par ID de requête, type d'erreur ou horodatage et cerner le problème en quelques minutes.
La clé, c'est la structure. Une ligne de log comme « Erreur survenue » est inutile. Une ligne comme {"timestamp":"2024-11-20T14:32:01Z","level":"ERROR","service":"payment","trace_id":"abc123","message":"connection refused to database replica-2"} vous indique exactement où chercher.
Voici un exemple pratique pour interroger les logs lors d'un incident :
# Récupérer les 100 dernières lignes de log de tous les pods du service 'my-app'
# et filtrer pour les entrées ERROR
kubectl logs -l app=my-app --tail=100 | grep 'ERROR'
# Pour plus de contexte, utilisez une requête structurée avec jq
kubectl logs -l app=my-app --tail=500 | \
grep 'ERROR' | \
jq '{timestamp, service, trace_id, message}'
Les métriques : le système d'alerte précoce
Les métriques vous donnent la santé numérique de votre système. Après un déploiement, vous voulez savoir :
- L'utilisation CPU a-t-elle grimpé ?
- Le taux d'erreur a-t-il augmenté ?
- Le temps de réponse a-t-il ralenti ?
- Le débit a-t-il chuté ?
Ces chiffres ne servent pas seulement pendant la récupération. Ils vous alertent avant même que les utilisateurs ne se plaignent. Une alerte bien configurée sur le taux d'erreur ou la latence peut notifier l'équipe en quelques secondes après un mauvais déploiement, avant même l'arrivée du premier ticket de support.
Pendant la récupération, les métriques vous indiquent si votre correctif fonctionne. Si vous avez fait un rollback, le taux d'erreur est-il revenu à la ligne de base ? Si vous avez fait un roll forward, la latence s'est-elle stabilisée ? Sans métriques, vous volez à l'aveugle.
Les traces : suivre le chemin de la requête
Quand un utilisateur dit « la page est lente », vous devez savoir où se produit le ralentissement. Est-ce dans votre code applicatif ? Dans la requête en base de données ? Dans un appel API tiers ?
Le tracing suit une requête de l'entrée jusqu'à chaque service qu'elle traverse. Il vous montre le temps passé dans chaque composant. C'est crucial pour décider de votre stratégie de récupération.
Si le tracing montre que la base de données est le goulot d'étranglement, faire un rollback de l'application ne résoudra pas le problème. Vous devez aussi rollbacker la migration de base de données, ou appliquer un correctif d'urgence. Si le tracing montre que le ralentissement vient d'une passerelle de paiement tierce, vous n'avez peut-être pas besoin de rollbacker du tout. Il suffit peut-être d'ajouter un timeout ou un fallback.
Prendre des décisions de récupération avec des données
Une bonne observabilité transforme la panique en processus. Au lieu de deviner, vous suivez un chemin guidé par les données :
- L'alerte se déclenche car le taux d'erreur a dépassé le seuil.
- Vous consultez le tableau de bord des métriques et constatez que le pic a commencé exactement au moment du déploiement.
- Vous examinez les logs et trouvez un motif d'exception spécifique dans le nouveau code.
- Vous vérifiez la trace et confirmez que l'erreur se produit dans le nouveau module de paiement.
- Vous décidez : rollbacker uniquement le module de paiement, ou le désactiver avec un feature flag.
Parfois, les données vous disent de ne pas rollbacker du tout. Si les métriques montrent des erreurs uniquement sur un endpoint, vous pouvez désactiver cette fonctionnalité avec un flag. Si les traces montrent que la base de données va bien mais que le code applicatif a une fuite mémoire, vous pouvez rollbacker uniquement l'application sans toucher à la base de données.
Sans observabilité, vous ne pouvez pas faire ces distinctions. Vous rollbackez tout ou vous ne rollbackez rien. Les deux choix comportent des risques inutiles.
Après la récupération : prouver que le système est sain
L'observabilité ne cesse pas d'être utile une fois le rollback effectué. Vous devez confirmer que le système est réellement redevenu sain. Pas seulement « la page se charge », mais :
- Le taux d'erreur est revenu à la ligne de base.
- La latence est dans la plage normale.
- Les logs ne montrent aucune nouvelle exception.
- Le débit a récupéré.
Ces signaux sont votre preuve que la récupération a réussi. Sans eux, vous espérez que le problème a disparu. Avec eux, vous pouvez clore l'incident en toute confiance.
Le piège : traiter l'observabilité comme un projet futur
De nombreuses équipes considèrent l'observabilité comme quelque chose à mettre en place plus tard. Ils installent un agent de logging, ajoutent quelques métriques, et considèrent que c'est fait. Quand un véritable incident survient, ils réalisent que leurs logs ne sont pas structurés, que leurs métriques ne couvrent pas les bons signaux, et qu'ils n'ont aucune trace du tout.
Un plan de récupération sans observabilité n'est qu'un document. Vous pouvez écrire « rollback si le taux d'erreur augmente », mais si vous ne connaissez pas votre taux d'erreur normal, ou si vous ne pouvez pas le mesurer en temps réel, cette instruction n'a aucun sens.
L'observabilité n'est pas un projet de monitoring. C'est un outil de récupération. Elle donne à votre équipe la capacité de voir, comprendre et agir rapidement quand quelque chose tourne mal. Sans elle, vous marchez dans le noir. Vous savez que quelque chose ne va pas, mais vous ne savez ni où ni comment le réparer.
Checklist pratique pour une observabilité prête pour la récupération
- Chaque service logge du JSON structuré avec horodatage, niveau, nom du service et ID de trace.
- Les métriques clés (taux d'erreur, latence, débit) ont des lignes de base et des alertes définies.
- Le tracing distribué est activé pour tous les chemins de requête critiques.
- Les alertes sont configurées pour se déclencher en quelques secondes après une anomalie de déploiement.
- L'équipe s'est entraînée à utiliser les logs, métriques et traces lors d'un incident simulé.
L'essentiel à retenir
La prochaine fois que vous planifiez un déploiement, posez une question à votre équipe : « Si ce déploiement tourne mal, saurons-nous ce qui s'est passé en moins de cinq minutes ? » Si la réponse est non, corrigez votre observabilité avant de déployer. Les données que vous collectez aujourd'hui sont la seule chose qui vous évitera de deviner demain.