Project

General

Profile

Actions

Methode de resolution de problèmes

Source : https://members.loria.fr/LNussbaum/files/asrall-s-problemes.pdf

Questions à se poser : caractérisation

Caractérisation du problème :

  • Quels sont les symptômes ? Qu’est-ce qui marche ou pas ?
  • Quel est le comportement attendu ?
  • Y a-t-il plusieurs symptômes en même temps, peut-être liés ?
  • Quelles sont les conséquences du problème ? (gravité ?)

Fréquence du problème :

  • Est-ce la première fois que ce problème apparaît ?
  • Est-il possible qu’il se soit déjà produit sans qu’il soit détecté ?
  • Depuis quand le problème est-il présent ?
  • Y a-t-il un moyen de rechercher des occurences précédentes ?

Questions à se poser : environnement

  • Environnement logiciel : versions / branches du logiciel affecté ? Des logiciels utilisés par ce logiciel affecté ? (bibliothèques, noyau, distribution, . . . )
  • Matériel spécifique ?
  • Perturbations (logicielles, matérielles ou réseau) ?
  • Y a-t-il quelque chose de particulier dans l’environnement ?

Questions à se poser : reproductibilité

  • Le problème est-il reproductible ?
  • Peut-on simplifier la procédure permettant de reproduire le problème (test case) ?
  • Se reproduit-il systématiquement, ou de manière aléatoire ?
  • Attention aux Heisenbugs : bug qui ne se manifeste pas lorsque des outils de détection sont utilisés pour le rechercher.

Méthodes pour l’investigation

  • Si le problème est présent en permanence : localiser le problème
  • Si le problème est reproductible : réduire le test case

Dans les deux cas :

Objectif : faciliter l’analyse et réduire le nombre de suspects

Méthode (en général) : recherche par dichotomie

  • Sur la pile logicielle (noyau, bibliothèques, . . . )
  • Sur la pile réseau (Ethernet, IP, TCP/UDP, . . . )
  • Sur l’historique des modifications d’un logiciel (git bisect)

Deux moyens d’avancer :

  • Remplacer tour-à-tour les différents élements

    Exemple : changer de noyau

  • Tester les différentes couches séparément

    Exemple : problème avec connexions TCP, est-ce que ping marche ?

Si vous ne pouvez pas reproduire le problème :

  • Analyse pendant que le problème se produit
  • Analyse post-mortem : Beaucoup plus difficile !

Bonnes pratiques

Utilisez au maximum les informations acquises

  • En cas de message d’erreur peu clair : regardez le code source pour savoir pourquoi ce message est affiché

Choisissez bien vos hypothèses et vos pistes d’investigations

  • Quelles sont leurs probabilités ? (Les bugs graves dans les parties critiques du noyau sont rares)
  • Quelles sont leurs coûts ? en temps d’investigation, en conséquences sur les utilisateurs, . . .
  • Quelles informations pourront être acquises :
  • en cas de succès ?
  • en cas d’échec ?

Comment pourrez-vous vérifier votre hypothèse une fois l’expérience mise en place ?

Documentez les investigations

  • Liste des occurences du problème, extraits de logs, . . .
  • Avec date, heure et nom de la machine (si besoin)*
  • Hypothèses rejetées (et justification)
  • Permet à quelqu’un d’autre d’apporter de l’aide
  • Permet de tester des hypothèses

Appelez à l’aide

À lire : How To Ask Questions The Smart Way : http://www.catb.org/esr/faqs/smart-questions.html

Points les plus importants :

  • Choisissez votre cible avec soin vous serez ignoré si vous visez trop haut pour un problème simple
  • Soyez sûr de votre analyse avant de hurler au bug
  • Décrivez les symptômes le plus précisément possible (Une info que vous jugez inutile peut être utile pour quelqu’un d’autre)
  • Ne mélangez pas symptômes (= faits) et hypothèses

Documentations

Différents niveaux de qualité/confiance :

  • Code source, changelogs
  • Rapports de bugs (qualité différente selon les projets)
  • Listes de diffusion (mailing lists), souvent en anglais
  • Documentations officielles (man, site web, /usr/share/doc/)
  • Documentations non officielles (how-to)
  • Forums (car peu de développeurs y participent)

Soyez critiques vis-à-vis des documentations !

  • Fraîcheur ? (attention aux traductions !)
  • Qui en est l’auteur ? Peut-on lui faire confiance ?
  • Est-ce vraiment le même problème que le mien ?
  • Est-ce la même version du logiciel que la mienne ?

Outils classiques

Logs :

  • Générés par la plupart des services dans /var/log/
  • Niveau de log paramétrable pour chaque service ou via syslog

Logiciel :

  • -verbose, -debug
  • Parfois mode debug activable à la compilation

Réseau :

  • ethtool : Ethernet / carte réseau
  • ifconfig, route, netstat, ip, . . .
  • nmap : scanner de ports
  • tcpdump : analyseur de trafic
  • wireshark : analyseur de trafic plus évolué (graphique) Utilisation de wireshark à distance (Network pipes) :
wireshark -k -i <(ssh host tshark -w - not tcp port 22)

Il faut se connecter en root à host Lucas Nussbaum Diagnostique

Système :

  • gdb et autres débogueurs (valgrind)
  • ltrace : trace les appels de bibliothèques
  • strace : trace les appels systèmes
  • Systemtap : instrumentation du noyau

Outils de diagnostic spécifiques à des matériels ou technologies :

  • /proc/mdstat pour le RAID logiciel
  • tune2fs pour les systèmes de fichier ext[2-4]
  • . . .

Après avoir identifié le problème

  • Est-ce le problème racine, ou une conséquence d’un autre problème ?
  • Comment aurait-il pû être évité ?
  • Comment auriez-vous pû le trouver plus vite ? Êtes-vous passé à côté d’indices ?
  • Y a-t-il un bug à signaler ? Comment signaler efficacement un bug http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html

« Le premier objectif d’un rapport de bug est de permettre au programmeur de voir le bug
de ses propres yeux. Si vous ne pouvez le faire planter devant lui, donnez lui des
instructions détaillées afin qu’il puisse le faire planter par lui-même.
Si le premier objectif ne peut être atteint, et donc si le programmeur ne peut voir l’erreur se
produire, le second objectif d’un rapport de bug est de décrire ce qui s’est mal passé.
Décrivez tout, en détails. Dites ce que vous avez vu, mais dites aussi ce que vous vous
attendiez à voir. Recopiez les messages d’erreur, surtout s’ils contiennent des nombres.
Bien entendu, si vous pensez en être capable, diagnostiquez l’erreur par vous-même, mais
si vous le faites, vous devriez tout de même lui communiquer les symptômes. »

Updated by florian 10 months ago · 4 revisions