Ce qu'il faut vérifier après un déploiement dépend de ce que vous venez de déployer

Vous venez de pousser une nouvelle version en production. Le pipeline est vert. Le déploiement s'est terminé sans erreur. Et maintenant ?

La plupart des équipes fixent un tableau de bord en espérant que rien ne casse. Mais les signaux qui comptent dépendent entièrement de ce que vous avez déployé. Vérifier les mêmes métriques pour une application, une base de données et un changement d'infrastructure vous rendra aveugle aux vrais problèmes. Chaque type de déploiement a ses propres modes de défaillance, et vous devez surveiller les bons signaux pour chacun.

Applications : surveillez la façon dont les requêtes sont traitées

Lorsque vous déployez une nouvelle version d'une application, le plus important est de savoir si elle traite correctement les requêtes utilisateur. Deux métriques vous donnent cette réponse plus rapidement que toute autre chose : le taux d'erreur et la latence.

Le taux d'erreur vous indique combien de requêtes échouent. Si le taux d'erreur grimpe juste après un déploiement, quelque chose ne va pas. Cela peut être un bug dans le nouveau code, une incohérence de configuration ou une incompatibilité avec l'environnement de production. Quelle qu'en soit la cause, les utilisateurs rencontrent des échecs, et vous devez le savoir immédiatement.

La latence vous indique le temps que met l'application à répondre aux requêtes. Une augmentation soudaine de la latence signifie que la nouvelle version est plus lente. Elle consomme peut-être plus de ressources, rencontre un goulot d'étranglement ou effectue des appels inefficaces vers des services en aval. Les utilisateurs peuvent ne pas voir d'erreurs, mais ils ressentiront la lenteur, et c'est tout aussi dommageable.

Le débit est un autre signal utile, en particulier pour les applications qui servent de nombreux utilisateurs. Le débit mesure le nombre de requêtes que l'application peut traiter par unité de temps. Si le débit chute alors que le nombre d'utilisateurs reste le même, la nouvelle version est moins efficace. Quelque chose dans le code ralentit les choses, même si le taux d'erreur et la latence semblent normaux.

Ces trois signaux sont les premières choses à vérifier après un déploiement d'application. Ils reflètent ce que les utilisateurs vivent réellement. Ne vous fiez pas au fait que le processus est toujours en cours d'exécution ou que le conteneur est opérationnel. Cela vous indique que l'application est vivante, mais pas si elle fonctionne correctement.

Le diagramme suivant résume les métriques à vérifier en premier selon ce que vous avez déployé :

Bases de données : vérifiez la réplication, les requêtes et les connexions

Les bases de données ne servent pas directement les requêtes comme le font les applications. Elles fournissent des données aux applications. Les signaux à surveiller sont donc différents.

L'état de la réplication est critique. La plupart des bases de données en production utilisent des réplicas pour lire les données. Si la réplication prend du retard ou se casse après un déploiement, les applications pourraient lire des données obsolètes ou incohérentes. C'est particulièrement dangereux après des changements de schéma ou des migrations de données. Quelques secondes de retard de réplication peuvent être acceptables, mais des minutes de retard signifient que quelque chose ne va pas.

La performance des requêtes est la prochaine chose à surveiller. Après un déploiement qui modifie le schéma, ajoute des index ou change la façon dont l'application écrit les données, certaines requêtes peuvent soudainement devenir lentes. Surveillez les requêtes qui prennent plus de temps que d'habitude ou celles qui commencent à expirer. Une seule requête lente peut ralentir toute l'application.

Le nombre de connexions compte également. Les bases de données ont un nombre limité de connexions. Si un déploiement fait que les connexions s'accumulent ou restent bloquées, la base de données peut manquer de connexions disponibles. Les nouvelles requêtes échoueront et l'application semblera cassée même si la base de données elle-même est saine.

La taille du journal de transactions est un signal moins évident mais important. Les bases de données écrivent des journaux pour chaque modification. Si un déploiement change la façon dont l'application écrit les données, le journal peut croître plus rapidement que d'habitude. Sans nettoyage approprié, le journal peut remplir le disque et arrêter la base de données. Les équipes de base de données ont généralement un seuil de sécurité pour la taille du journal. S'il dépasse ce seuil, une action est nécessaire.

Infrastructure : commencez par l'état des nœuds

Les déploiements d'infrastructure incluent des modifications de serveurs, de conteneurs, de réseaux ou de ressources cloud. Le premier signal à vérifier est l'état du nœud. Le serveur ou le conteneur est-il toujours en vie ? L'utilisation du CPU et de la mémoire est-elle dans les plages normales ? Le disque se remplit-il ?

Une infrastructure saine est un prérequis pour que les applications et les bases de données fonctionnent correctement. Si un nœud redémarre constamment ou manque de ressources, tout ce qui s'exécute dessus en souffrira. L'état du nœud est la base de référence. Si cela est cassé, rien d'autre n'a d'importance.

Les signaux réseau sont également importants, en particulier après des modifications des règles de pare-feu, des équilibreurs de charge ou des maillages de services. Surveillez l'augmentation de la latence entre les nœuds, la perte de paquets ou les connexions interrompues. Ces problèmes n'apparaissent souvent pas directement dans les métriques d'application, mais ils provoquent des défaillances mystérieuses difficiles à déboguer.

Les signaux sont connectés, mais commencez par un seul

Les signaux d'application, de base de données et d'infrastructure n'existent pas isolément. Une application lente peut être causée par une base de données lente. Une base de données lente peut être causée par un nœud d'infrastructure à court de mémoire. Pour obtenir une vue d'ensemble, vous devez lire les signaux des trois couches ensemble.

Mais lorsque vous devez prendre une décision rapide après un déploiement, chaque équipe a généralement un signal principal à surveiller. Les équipes d'application surveillent le taux d'erreur et la latence. Les équipes de base de données surveillent la réplication et la performance des requêtes. Les équipes d'infrastructure surveillent l'état des nœuds. Commencez par là. Si quelque chose semble anormal, creusez dans les autres couches pour trouver la cause racine.

Liste de contrôle pratique pour la vérification post-déploiement

• Pour les déploiements d'application : vérifiez le taux d'erreur, la latence et le débit dans les cinq premières minutes.
• Pour les déploiements de base de données : vérifiez le retard de réplication, les requêtes lentes, le nombre de connexions et la taille du journal de transactions.
• Pour les déploiements d'infrastructure : vérifiez l'état des nœuds, l'utilisation du CPU et de la mémoire, l'espace disque et la latence réseau.
• Si un signal semble anormal, vérifiez les signaux associés dans les autres couches pour trouver la cause réelle.

À retenir

N'utilisez pas le même tableau de bord pour chaque déploiement. Les signaux qui comptent dépendent de ce que vous venez de modifier. Les applications ont besoin de métriques au niveau des requêtes. Les bases de données ont besoin de métriques au niveau des données. L'infrastructure a besoin de métriques de ressources et de réseau. Sachez quels signaux surveiller pour chaque type de déploiement, et vous détecterez les problèmes avant vos utilisateurs.