Projet

Général

Profil

Methode resolution » Historique » Version 2

florian, 13/06/2019 10:26

1 2 florian
# Methode de resolution de problèmes 
2 1 florian
3
> Source : https://members.loria.fr/LNussbaum/files/asrall-s-problemes.pdf
4
5
## Questions à se poser : caractérisation
6
7
**Caractérisation du problème :**
8
9
* Quels sont les symptômes ? Qu’est-ce qui marche ou pas ?
10
* Quel est le comportement attendu ?
11
* Y a-t-il plusieurs symptômes en même temps, peut-être liés ?
12
* Quelles sont les conséquences du problème ? (gravité ?)
13
14
**Fréquence du problème :**
15
16
* Est-ce la première fois que ce problème apparaît ?
17
* Est-il possible qu’il se soit déjà produit sans qu’il soit détecté ?
18
* Depuis quand le problème est-il présent ?
19
* Y a-t-il un moyen de rechercher des occurences précédentes ?
20
21
## Questions à se poser : environnement
22
23
* Environnement logiciel : versions / branches du logiciel affecté ? Des logiciels utilisés par ce logiciel affecté ? (bibliothèques, noyau, distribution, . . . )
24
* Matériel spécifique ?
25
* Perturbations (logicielles, matérielles ou réseau) ?
26
* Y a-t-il quelque chose de particulier dans l’environnement ?
27
28
## Questions à se poser : reproductibilité
29
30
* Le problème est-il reproductible ?
31
* Peut-on simplifier la procédure permettant de reproduire le problème (test case) ?
32
* Se reproduit-il systématiquement, ou de manière aléatoire ?
33
* Attention aux Heisenbugs : bug qui ne se manifeste pas lorsque des outils de détection sont utilisés pour le rechercher.
34
35
# Méthodes pour l’investigation
36
37
* Si le problème est présent en permanence : localiser le problème
38
* Si le problème est reproductible : réduire le test case
39
40
**Dans les deux cas :**
41
42
> Objectif : faciliter l’analyse et réduire le nombre de suspects
43
44
**Méthode (en général) : recherche par dichotomie**
45
46
* Sur la pile logicielle (noyau, bibliothèques, . . . )
47
* Sur la pile réseau (Ethernet, IP, TCP/UDP, . . . )
48
* Sur l’historique des modifications d’un logiciel (git bisect)
49
50
Deux moyens d’avancer :
51
52
* Remplacer tour-à-tour les différents élements
53
> Exemple : changer de noyau
54
55
* Tester les différentes couches séparément   
56
> Exemple : problème avec connexions TCP, est-ce que ping marche ?
57
58
**Si vous ne pouvez pas reproduire le problème :**
59
60
* Analyse pendant que le problème se produit
61
* Analyse post-mortem : Beaucoup plus difficile !
62
63
## Bonnes pratiques
64
65
**Utilisez au maximum les informations acquises**
66
67
* En cas de message d’erreur peu clair : regardez le code source pour savoir pourquoi ce message est affiché
68
69
**Choisissez bien vos hypothèses et vos pistes d’investigations**
70
71
* Quelles sont leurs probabilités ? (Les bugs graves dans les parties critiques du noyau sont rares)
72
* Quelles sont leurs coûts ? en temps d’investigation, en conséquences sur les utilisateurs, . . .
73
* Quelles informations pourront être acquises :
74
* en cas de succès ?
75
* en cas d’échec ?
76
77
Comment pourrez-vous vérifier votre hypothèse une fois l’expérience mise en place ?
78
79
**Documentez les investigations**
80
81
* Liste des occurences du problème, extraits de logs, . . .
82
* Avec date, heure et nom de la machine (si besoin)*
83
* Hypothèses rejetées (et justification)
84
* Permet à quelqu’un d’autre d’apporter de l’aide
85
* Permet de tester des hypothèses
86
87
**Appelez à l’aide**
88
89
À lire : How To Ask Questions The Smart Way : http://www.catb.org/esr/faqs/smart-questions.html
90
91
Points les plus importants :
92
93
* Choisissez votre cible avec soin vous serez ignoré si vous visez trop haut pour un problème simple
94
* Soyez sûr de votre analyse avant de hurler au bug
95
* 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)
96
* Ne mélangez pas symptômes (= faits) et hypothèses
97
98
99
# Documentations
100
101
**Différents niveaux de qualité/confiance :**
102
103
* Code source, changelogs
104
* Rapports de bugs (qualité différente selon les projets)
105
* Listes de diffusion (mailing lists), souvent en anglais
106
* Documentations officielles (man, site web, /usr/share/doc/)
107
* Documentations non officielles (how-to)
108
* Forums (car peu de développeurs y participent)
109
110
111
**Soyez critiques vis-à-vis des documentations !**
112
113
* Fraîcheur ? (attention aux traductions !)
114
* Qui en est l’auteur ? Peut-on lui faire confiance ?
115
* Est-ce vraiment le même problème que le mien ?
116
* Est-ce la même version du logiciel que la mienne ?
117
118
119
# Outils classiques
120
121
**Logs :**
122
123
* Générés par la plupart des services dans /var/log/
124
* Niveau de log paramétrable pour chaque service ou via
125
syslog
126
127
**Logiciel :**
128
129
* -verbose, -debug
130
* Parfois mode debug activable à la compilation
131
132
**Réseau :**
133
134
* ethtool : Ethernet / carte réseau
135
* ifconfig, route, netstat, ip, . . .
136
* nmap : scanner de ports
137
* tcpdump : analyseur de trafic
138
* wireshark : analyseur de trafic plus évolué (graphique) Utilisation de wireshark à distance (Network pipes) :
139
140
~~~
141
wireshark -k -i <(ssh host tshark -w - not tcp port 22)
142
~~~
143
144
> Il faut se connecter en root à host Lucas Nussbaum Diagnostique
145
146
**Système :**
147
148
* gdb et autres débogueurs (valgrind)
149
* ltrace : trace les appels de bibliothèques
150
* strace : trace les appels systèmes
151
* Systemtap : instrumentation du noyau
152
153
**Outils de diagnostic spécifiques à des matériels ou technologies :**
154
155
* /proc/mdstat pour le RAID logiciel
156
* tune2fs pour les systèmes de fichier ext[2-4]
157
* . . .
158
159
160
# Après avoir identifié le problème
161
162
* Est-ce le problème racine, ou une conséquence d’un autre problème ?
163
* Comment aurait-il pû être évité ?
164
* Comment auriez-vous pû le trouver plus vite ? Êtes-vous passé à côté d’indices ?
165
* Y a-t-il un bug à signaler ? Comment signaler efficacement un bug http://www.chiark.greenend.org.uk/~sgtatham/bugs-fr.html
166
167
> `« Le premier objectif d’un rapport de bug est de permettre au programmeur de voir le bug
168
de ses propres yeux. Si vous ne pouvez le faire planter devant lui, donnez lui des
169
instructions détaillées afin qu’il puisse le faire planter par lui-même.
170
Si le premier objectif ne peut être atteint, et donc si le programmeur ne peut voir l’erreur se
171
produire, le second objectif d’un rapport de bug est de décrire ce qui s’est mal passé.
172
Décrivez tout, en détails. Dites ce que vous avez vu, mais dites aussi ce que vous vous
173
attendiez à voir. Recopiez les messages d’erreur, surtout s’ils contiennent des nombres.
174
Bien entendu, si vous pensez en être capable, diagnostiquez l’erreur par vous-même, mais
175
si vous le faites, vous devriez tout de même lui communiquer les symptômes. »`