Méthode de Diagnostic Structurée
L'Approche Systématique
En informatique, et particulièrement dans le cloud, le dépannage ne doit pas être du "trial and error" aléatoire. Une méthode structurée vous fera gagner du temps et vous rendra plus efficace.
┌─────────────────────────────────────────────────────────────┐
│ MÉTHODE DE DIAGNOSTIC EN 5 ÉTAPES │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. SYMPTÔME │
│ └── Qu'est-ce qui ne fonctionne pas exactement ? │
│ Soyez précis ! "Ça marche pas" n'est pas un │
│ symptôme valide. │
│ │
│ 2. HYPOTHÈSES │
│ └── Quelles sont les causes possibles ? │
│ Listez-les par probabilité. │
│ │
│ 3. TESTS │
│ └── Comment vérifier chaque hypothèse ? │
│ Un test à la fois, méthodiquement. │
│ │
│ 4. CORRECTIF │
│ └── Quelle action résout le problème ? │
│ Appliquer et valider. │
│ │
│ 5. DOCUMENTATION │
│ └── Noter la solution pour référence future. │
│ Mettre à jour le runbook. │
│ │
└─────────────────────────────────────────────────────────────┘
Étape 1 : Définir le Symptôme
Mauvais vs Bon Symptôme
❌ MAUVAIS SYMPTÔMES (trop vagues) :
• "Le serveur ne marche pas"
• "C'est cassé"
• "J'ai une erreur"
• "Ça fonctionnait avant"
✅ BONS SYMPTÔMES (précis) :
• "SSH timeout après 30 secondes vers IP 52.1.2.3"
• "Erreur 502 Bad Gateway sur http://example.com"
• "Instance i-xxx passe à terminated après 10 secondes"
• "Page web retourne erreur 500 depuis 14h30"
Questions à Se Poser
┌─────────────────────────────────────────────────────────────┐
│ QUESTIONS DE CLARIFICATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUOI ? │
│ • Quel est le message d'erreur exact ? │
│ • Quelle fonctionnalité est affectée ? │
│ • Quel service/instance est concerné ? │
│ │
│ QUAND ? │
│ • Quand le problème a-t-il commencé ? │
│ • Le problème est-il constant ou intermittent ? │
│ • Y a-t-il des patterns (heures, jours) ? │
│ │
│ OÙ ? │
│ • Quelle région/AZ ? │
│ • Quelle instance/ressource ? │
│ • Depuis où le problème est-il observé ? │
│ │
│ QUI ? │
│ • Tous les utilisateurs ou certains seulement ? │
│ • Depuis certains réseaux/IPs ? │
│ │
│ CHANGEMENT ? │
│ • Qu'est-ce qui a changé récemment ? │
│ • Déploiement ? Configuration ? AWS ? │
│ │
└─────────────────────────────────────────────────────────────┘
Étape 2 : Formuler des Hypothèses
Catégories de Problèmes EC2
┌─────────────────────────────────────────────────────────────┐
│ CATÉGORIES DE PROBLÈMES │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🌐 RÉSEAU │
│ ├── Security Group mal configuré │
│ ├── NACL bloquant │
│ ├── Route Table incorrecte │
│ ├── Internet Gateway manquant │
│ └── Pas d'IP publique │
│ │
│ 🔐 SÉCURITÉ / AUTH │
│ ├── Mauvaise clé SSH │
│ ├── Mauvais utilisateur │
│ ├── Permissions du fichier .pem │
│ └── IAM (pour les appels API) │
│ │
│ 💻 INSTANCE │
│ ├── Instance non running │
│ ├── Status check failed │
│ ├── Service non démarré (Apache, SSH) │
│ └── Disque plein │
│ │
│ 📦 APPLICATION │
│ ├── Application crashée │
│ ├── Configuration incorrecte │
│ ├── Dépendance manquante │
│ └── Port incorrect │
│ │
│ ☁️ AWS │
│ ├── Panne régionale │
│ ├── Service dégradé │
│ └── Maintenance │
│ │
└─────────────────────────────────────────────────────────────┘
Prioriser les Hypothèses
Règle d'or : Du plus simple au plus complexe
Du plus probable au moins probable
Exemple pour "SSH timeout" :
HAUTE PROBABILITÉ (vérifier d'abord)
1. Security Group - port 22 fermé
2. Pas d'IP publique
3. Instance pas running
MOYENNE PROBABILITÉ
4. NACL bloquant
5. Route table sans route vers IGW
6. Firewall sur l'instance
BASSE PROBABILITÉ
7. Panne AWS régionale
8. Bug du client SSH
Étape 3 : Tester les Hypothèses
Tests pour Problèmes Réseau
# 1. Vérifier l'état de l'instance
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].State.Name'
# 2. Vérifier l'IP publique
aws ec2 describe-instances --instance-ids i-xxx \
--query 'Reservations[].Instances[].PublicIpAddress'
# 3. Vérifier les Security Groups
aws ec2 describe-security-groups --group-ids sg-xxx
# 4. Tester la connectivité réseau (depuis votre machine)
ping IP_PUBLIQUE # ICMP (si autorisé)
telnet IP_PUBLIQUE 22 # Test port SSH
nc -zv IP_PUBLIQUE 22 # Alternative à telnet
# 5. Vérifier la route table du subnet
aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-xxx"
Tests pour Problèmes d'Instance
# 1. Vérifier les status checks
aws ec2 describe-instance-status --instance-ids i-xxx
# 2. Récupérer les logs système (si configuré)
aws ec2 get-console-output --instance-id i-xxx
# 3. Vérifier les métriques CloudWatch
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-xxx \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T01:00:00Z \
--period 300 \
--statistics Average
Depuis l'Instance (si accessible)
# Vérifier les services
systemctl status sshd
systemctl status httpd
# Vérifier les ports ouverts
netstat -tlnp
ss -tlnp
# Vérifier l'espace disque
df -h
# Vérifier la mémoire
free -m
# Vérifier les logs
tail -100 /var/log/messages
tail -100 /var/log/secure
journalctl -xe
Étape 4 : Appliquer le Correctif
Règles pour les Correctifs
┌─────────────────────────────────────────────────────────────┐
│ RÈGLES POUR APPLIQUER UN CORRECTIF │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. UN CHANGEMENT À LA FOIS │
│ └── Ne changez pas 5 choses en même temps ! │
│ └── Sinon vous ne saurez pas ce qui a résolu │
│ │
│ 2. DOCUMENTER AVANT DE CHANGER │
│ └── Noter l'état actuel │
│ └── Pouvoir revenir en arrière │
│ │
│ 3. TESTER APRÈS CHAQUE CHANGEMENT │
│ └── Vérifier si le problème est résolu │
│ └── Vérifier qu'on n'a pas créé de nouveaux problèmes │
│ │
│ 4. VALIDER COMPLÈTEMENT │
│ └── Le test rapide OK ne suffit pas │
│ └── Tester tous les cas d'usage affectés │
│ │
└─────────────────────────────────────────────────────────────┘
Exemple de Correctif Documenté
PROBLÈME : SSH timeout vers instance i-0123456789
DIAGNOSTIC :
- Instance : running ✓
- IP publique : 52.1.2.3 ✓
- Security Group : sg-abc123
→ Port 22 : MANQUANT ❌
CORRECTIF APPLIQUÉ :
aws ec2 authorize-security-group-ingress \
--group-id sg-abc123 \
--protocol tcp \
--port 22 \
--cidr 0.0.0.0/0
VALIDATION :
ssh -i ma-cle.pem ec2-user@52.1.2.3
→ Connexion réussie ✓
DATE : 2024-12-18 14:30
TECHNICIEN : Haythem
Étape 5 : Documenter
Template de Documentation
# Incident : [Titre court]
## Date et Durée
- Début : YYYY-MM-DD HH:MM
- Résolution : YYYY-MM-DD HH:MM
- Durée totale : X heures
## Symptôme
[Description précise du problème observé]
## Impact
- Utilisateurs affectés : X
- Services impactés : [liste]
- Niveau de sévérité : Critique/Majeur/Mineur
## Cause Racine
[Explication de la cause fondamentale]
## Chronologie
- HH:MM - Détection du problème
- HH:MM - Début du diagnostic
- HH:MM - Cause identifiée
- HH:MM - Correctif appliqué
- HH:MM - Validation et clôture
## Solution Appliquée
[Description du correctif]
## Actions Préventives
- [ ] Action 1 pour éviter que ça se reproduise
- [ ] Action 2
- [ ] Mise à jour du runbook
## Leçons Apprises
[Ce qu'on a appris de cet incident]
Exercice Pratique
Scénario
Contexte :
Vous avez lancé une instance EC2 il y a 5 minutes.
L'instance est en état "running".
Vous essayez de vous connecter en SSH.
Résultat :
$ ssh -i ma-cle.pem ec2-user@52.1.2.3
ssh: connect to host 52.1.2.3 port 22: Connection timed out
Appliquez la méthode de diagnostic !
Réponse Guidée
ÉTAPE 1 : SYMPTÔME
"SSH timeout après 30 secondes vers 52.1.2.3 port 22
depuis mon poste (IP: 203.0.113.50)"
ÉTAPE 2 : HYPOTHÈSES (par probabilité)
1. Security Group - port 22 non ouvert ou IP non autorisée
2. Pas de route vers Internet Gateway
3. NACL bloquant le port 22
4. Instance pas encore complètement démarrée
ÉTAPE 3 : TESTS
Test 1 : Security Group
→ aws ec2 describe-security-groups --group-ids sg-xxx
→ Résultat : Port 22 ouvert vers 10.0.0.0/8 seulement
→ Mon IP 203.0.113.50 n'est pas autorisée !
ÉTAPE 4 : CORRECTIF
aws ec2 authorize-security-group-ingress \
--group-id sg-xxx \
--protocol tcp \
--port 22 \
--cidr 203.0.113.50/32
VALIDATION :
ssh -i ma-cle.pem ec2-user@52.1.2.3
→ Connexion réussie !
ÉTAPE 5 : DOCUMENTATION
[Remplir le template ci-dessus]
Résumé
| Étape | Action | Durée Typique |
|---|---|---|
| 1. Symptôme | Définir précisément | 2-5 min |
| 2. Hypothèses | Lister par probabilité | 5-10 min |
| 3. Tests | Vérifier méthodiquement | Variable |
| 4. Correctif | Un changement à la fois | Variable |
| 5. Documentation | Toujours documenter | 10-15 min |
Quiz de Validation
- Pourquoi faut-il tester une hypothèse à la fois ?
- Quelle est la différence entre un symptôme vague et précis ?
- Par quoi commencer : les causes probables ou improbables ?
- Pourquoi documenter même les petits incidents ?
- Que faire si le premier correctif ne fonctionne pas ?
Prochaine section : Lab : Scénarios de Panne