Joli titre non ? En fait, je souhaite vous faire part de mon expérience sur le débogage .NET en production. "Débogage .NET en production" par opposition au débogage pas à pas dans Visual Studio.

En effet, il n’est pas toujours possible de "dégainer" son Visual Studio dans les environnements comme la recette ou la production. Et même, dans certains cas ce n’est pas adapté car la problématique à déboguer nécessite une certaine charge utilisateurs.

Quels sont les différents environnements ?

Chaque environnement a ses caractéristiques propres ; Pour simplifier, nous pouvons dire que nous avons les types suivants :

• Développement
  • Pas de charge utilisateurs
  • Problèmes unitaires reproductibles
  • Serveurs et réseau différents de la production
  • Débogage invasif ou pas à pas autorisé
• Test/Recette
  • Pas forcement identique à la production
  • Débogage invasif autorisé mais pas utilisable dans tous les cas (exemple : tests de charge)
  • Outils de débogage possiblement non autorisés
• Production
  • Environnement à forte charge / disponibilité
  • Outils de débogage souvent non autorisés

Quelles problématiques pouvons-nous rencontrer ?

Malgré tous les efforts mis en œuvre dans la phase de développement et de tests, il est possible d’observer des comportements anormaux de l’application mise en production. Voici les plus fréquents :

• Apparition de messages d’erreurs aux utilisateurs alors qu’aucune exception n’est loguée (Exceptions non gérées)
• Un état de blocage ou d’attente qui empêche le traitement des requêtes (deadlock ou hang du processus d’exécution W3WP.EXE)
  • Attente sur des ressources externes
  • Locks
  • Deadlocks
• 100% CPU du processus d’exécution W3WP.EXE
  • Boucle infini
  • Serveur surchargé
  • Nombre élevé d’exceptions
  • Utilisation du processeur par le Garbage Collector
• Un arrêt du processus d’exécution inexpliqué (crash de W3WP.EXE)
  • Exceptions non gérées
  • Exceptions internes à la CLR
  • Exceptions de composants COM
  • Recyclages

Comment procéder au débogage ?

Ces problèmes, n’ont pas forcement été identifiés au préalable lors du développement et de la phase de tests et le plus souvent ne sont pas reproductibles sur une autre plateforme que la production. Comment faire pour investiguer et trouver l’origine du problème ?

Le plan d’action le plus souvent utilisé est en 3 étapes :

• Capture d’informations
• Rétablissement de la production
• Analyse ultérieure

>>> Suite : Plan d‘action pour la capture des informations lors d’un problème de production IIS