Blog /

Poser un diag'

Aussi saugrenu que cela puisse paraitre poser un diagnostic sur un comportement applicatif anormal est relativement similaire entre l'IT et le médical.

En y réfléchissant 2 minutes:

• Vous avez des symptômes ;
• Vous avez des points de référence à rapprocher de vos métriques ;
• Vous avez vos logs qui vous permettent d'avoir un historique récent du « patient ».

À vous en fonction de vos connaissances et de votre expérience de trouver l'origine du problème.

On oubliera pas qu'à cela viendra s'ajouter le contexte et la gravité de la situation qui pourront entrainer des réactions assez variables des interlocuteurs que vous aurez la chance (ou pas!) d'avoir en face en fonction de leur capacité à gérer le stress de la situation et/ou la pression imposée par leur hiérarchie.

Combien de fois avez-vous entendu cette phrase après un incident : « Une fois qu'on a trouvé le problème, ça nous a pris 5 minutes à corriger. » ?

C'est précisément là que se cache le coût réel de l'incident.

Lors de votre dernier incident P1, combien de temps vos équipes ont-elles passé à diagnostiquer l'origine de la panne avant d'intervenir ? Si vous êtes comme la plupart des organisations, la réponse est probablement : bien plus longtemps que la résolution elle-même.

La racine du problème

Dans notre pratique quotidienne d'accompagnement d'infrastructures en production, nous constatons systématiquement que le temps de diagnostic dépasse largement le temps de correction. Ce constat n'est pas anodin : il révèle une faiblesse structurelle dans la manière dont nous concevons et observons de manière générale, nos systèmes.

Un incident en production se déroule généralement en trois phases :

1. Détection : Nos outils d'observabilité nous alertent (ou pire, c'est un utilisateur qui nous prévient)
2. Diagnostic : On recherche l'origine de la cause
3. Résolution : On corrige le problème
4. Post-mortem : On résume l'incident, on en tire les conclusions nécessaires et surtout on propose des pistes d'amélioration afin d'éviter qu'il ne se reproduise.

Le paradoxe ? On investit massivement dans la phase 3 (architectures résilientes, haute disponibilité, redondance...), mais on sous-estime dramatiquement la phase 2 alors que c'est celle qui au final est la plus simple à optimiser puiqu'elle ne nécessite que:

• D'avoir des métriques et des logs fiables (et accessibles !);
• Disposer d'une équipe assez expérimentée pour en tirer le meilleur parti.

Cas d'étude : quand l'erreur de conception devient un cauchemar

Prenons un exemple concret tiré de notre expérience que vous pouvez retrouver en détails dans son interprétation ici.

Lors de cette incident, nous n'avons aucune variation notable au niveau de l'application, pas de mise à jour récente, pas de campagne de communication active, pas de pic de traffic particulier bref la routine et pourtant nous avons une application assez conséquente qui s'effondre en quelques minutes de manière similaire sur ses 10 noeuds applicatifs.

Imaginez la scène : votre plateforme ralentit. Les utilisateurs se plaignent. Le monitoring vous alerte. Mais voilà, rien pour aiguiller un semblant de début d'analyse.

• Est-ce un problème applicatif ? Une requête SQL mal optimisée ?
• Est-ce l'infrastructure ? Un nœud qui sature ?
• Est-ce externe ? Un service tiers qui répond lentement ?
• Est-ce le fournisseur de cloud qui rencontre un soucis ?
• Est-ce temporaire ? Un pic de charge inhabituel ?

Sans une observabilité fine et des outils de diagnostic appropriés, vos équipes vont passer des heures à éliminer les hypothèses une par une. C'est exactement ce que nous appelons le coût caché du diagnostic.

L'impact business : au-delà de la disponibilité technique

Pour les équipes techniques

Le coût du diagnostic se manifeste de plusieurs façons :

• Charge cognitive : Chaque incident mobilise plusieurs ingénieurs, interrompt leur travail en cours et même s'ils sont expérimentés génère toujours un peu de stress
• Astreintes : Des équipes réveillées la nuit pour diagnostiquer, parfois pendant des heures avant de pouvoir intervenir
• Burn-out : La répétition d'incidents longs à diagnostiquer érode la motivation et l'efficacité des équipes

Pour l'organisation

D'un point de vue business, l'impact est tout aussi significatif :

• Coût de l'indisponibilité : Chaque minute compte. Si votre diagnostic prend 2 heures au lieu de 20 minutes, vous multipliez par 6 le coût de l'incident ;
• Perte de confiance : Des incidents fréquents et longs affectent la confiance des utilisateurs et des parties prenantes ;
• Opportunité manquée : Le temps passé en diagnostic est du temps non consacré à créer de la valeur.

Selon nos observations, une infrastructure avec un bon système de diagnostic peut réduire de 70 à 80% le temps de résolution des incidents. Autrement dit, un incident qui aurait duré 2 heures est résolu en 30 minutes.

Les signaux d'alerte : êtes-vous concernés ?

Quelques questions pour évaluer votre maturité en matière de diagnostic :

1. Lors de votre dernier incident, avez-vous pu identifier immédiatement quel service était en cause ?
2. Disposez-vous de traces distribuées permettant de suivre une requête de bout en bout ?
3. Vos métriques sont-elles corrélées à vos logs et vos événements applicatifs ?
4. Pouvez-vous reproduire facilement un incident en environnement de test ?
5. Vos équipes connaissent-elles les outils et méthodologies permettant d'être efficaces lors du diagnostic ? Mieux ! Disposez-vous d'un PRA à jour et testé ?

Si vous avez répondu « non » à plusieurs de ces questions, vous êtes probablement en train de payer le prix fort en temps de diagnostic.

Les fondations d'un diagnostic efficace

1. L'observabilité avant tout

En premier lieu l'observabilité n'est pas du monitoring. Le monitoring vous dit qu'il y a un problème. L'observabilité vous permet de comprendre pourquoi.

Les trois piliers essentiels :

• Logs structurés : Permettent de rechercher et filtrer efficacement ;
• Métriques : Donnent une vue quantitative de l'état du système et permettent surtout de rapprocher un état « normal » d'un état « dégradé » ;
• Traces : Montrent le parcours d'une requête à travers votre architecture ;

2. La corrélation des données

L'efficacité vient ensuite de la capacité à corréler ces différentes sources. Quand une alerte se déclenche, pouvez-vous immédiatement :

• Voir les logs associés ?
• Identifier les traces des requêtes impactées ?
• Comparer avec les métriques historiques ?

3. La méthodologie

Avoir les outils ne suffit pas. Vos équipes doivent également maîtriser une méthodologie de diagnostic structurée :

1. Qualifier l'incident (périmètre, gravité, impact)
2. Établir une chronologie
3. Formuler des hypothèses
4. Les tester systématiquement
5. Documenter les résultats

Cette approche méthodique, couplée aux bons outils, transforme un diagnostic chaotique de 3 heures en une investigation structurée de 20 minutes.

Dernière qualité et sans doute la plus importante dont doit faire preuve une bonne équipe d'Ops, ne pas hésiter à se rapprocher des équipes applicatives et / ou des équipes métier pour contextualiser l'incident !

Comme bien souvent, la technique n'est qu'un outil, l'humain est souvent essentiel à la compréhension globale d'un incident.

Du diagnostic à la résilience

Chez Rix, notre approche repose sur un principe simple : un système bien observé est un système rapide à réparer.

Cela implique :

• D'anticiper les scénarios de défaillance : Identifier les points de vulnérabilité ;
• D'instrumenter finement : Ne pas se contenter du monitoring « par défaut » ;
• De former les équipes : Investir dans la montée en compétences sur les outils de diagnostic, avoir de beaux graphs c'est bien, savoir bien les interpréter c'est mieux ! ;
• Automatiser : Créer des runbooks et des playbooks pour les scénarios récurrents qui vont vous permettre d'être à la fois plus véloce mais également d'éviter l'erreur humaine liée au stress de l'incident.

Notre retour d'expérience, notamment avec Bedrock où nous avons affiné les alertes pour distinguer les variations jour/nuit, montre qu'un investissement dans le diagnostic se rentabilise dès le premier incident majeur évité ou raccourci.

Conclusion : le diagnostic comme investissement stratégique

Le temps de diagnostic n'est pas une fatalité. C'est un indicateur de maturité de votre infrastructure et de vos pratiques DevOps.

Trois actions à mettre en place dès maintenant :

1. Mesurez : Commencez à tracer le temps de diagnostic et comparez le au temps de résolution sur vos incidents
2. Investissez : Dans l'observabilité, la formation et les outils, si vous n'investissez pas dans ces trois domaines de manière coordonnées, l'effort est vain.
3. Itérez : Chaque incident est une opportunité d'améliorer votre capacité de diagnostic

Car au final, on ne mesure l'efficacité d'un bon système de diagnostic qu'en cas de crise. Mais quand cette crise arrive, la différence entre 20 minutes et 3 heures de diagnostic peut faire toute la différence pour votre activité, vos équipes et votre réputation.

La question n'est pas de savoir si vous aurez un incident, mais quand. Et ce jour-là, combien de temps vos équipes passeront-elles à chercher avant de pouvoir agir ?

Vous souhaitez améliorer votre capacité de diagnostic et réduire le temps de résolution de vos incidents ? Parlons-en.