Methode resolution » Historique » Révision 2
Révision 1 (florian, 13/06/2019 10:26) → Révision 2/4 (florian, 13/06/2019 10:26)
# 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. »`