Playbook Réponse Incident

Guide opérationnel : "Quand tout est rouge, que faire ?"

Ce playbook structure la réponse aux incidents en 4 phases, avec des liens directs vers les outils ShellBook.

---

Vue d'Ensemble

graph TD
    A[🚨 ALERTE] --> B{Système<br/>identifié ?}
    B -->|Non| C[Phase 1:<br/>Discovery]
    B -->|Oui| D{Type<br/>d'incident ?}

    C --> D

    D -->|Ressources| E[Phase 2a:<br/>Nettoyage]
    D -->|Application| F[Phase 2b:<br/>Debug App]
    D -->|Performance| G[Phase 3:<br/>Analyse]

    E --> H[Phase 4:<br/>Post-Mortem]
    F --> H
    G --> H

    style A fill:#f44336,stroke:#c92a2a,color:#fff
    style C fill:#2196F3,stroke:#1971c2,color:#fff
    style E fill:#4CAF50,stroke:#2f9e44,color:#fff
    style F fill:#4CAF50,stroke:#2f9e44,color:#fff
    style G fill:#FF9800800800,stroke:#fab005,color:#000
    style H fill:#da77f2,stroke:#9c36b5,color:#fff

---

Phase 1 : Identification (Discovery)

Première Étape Obligatoire

Ne jamais agir sans comprendre. Un diagnostic initial évite d'aggraver la situation.

Objectif

Obtenir une vue complète et rapide de l'état du système avant toute intervention.

Actions

LinuxWindows

# Télécharger et exécuter le script de découverte
curl -sSL https://raw.githubusercontent.com/VBlackJack/ShellBook/main/scripts/bash/server-discovery.sh -o /tmp/discovery.sh
chmod +x /tmp/discovery.sh
sudo /tmp/discovery.sh -o /tmp/audit_$(hostname)_$(date +%Y%m%d).md

Script recommandé : server-discovery.sh

Le rapport généré contient :

• Rôle détecté du serveur (Web, DB, K8s, etc.)
• État des ressources (CPU, RAM, Disque)
• Services actifs et ports ouverts
• Baseline de sécurité

# Exécuter l'audit complet
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\Invoke-ServerAudit.ps1 -OutputPath "C:\Audit\rapport_$(hostname)_$(Get-Date -Format 'yyyyMMdd').md"

Script recommandé : Invoke-ServerAudit.ps1

Le rapport généré contient :

• Rôles Windows détectés (DC, IIS, SQL, Hyper-V)
• État Defender et Firewall
• Ports ouverts avec processus associés
• Membres du groupe Administrators

Arbre de Décision Post-Discovery

graph TD
    A[Rapport Discovery] --> B{Disque > 90% ?}
    B -->|Oui| C[→ Phase 2a: Nettoyage]
    B -->|Non| D{CPU/RAM > 90% ?}

    D -->|Oui| E{Conteneurs ?}
    E -->|Oui| F[→ Phase 2b: Debug Containers]
    E -->|Non| G[→ Phase 3: Analyse Perf]

    D -->|Non| H{Services KO ?}
    H -->|Oui| I[→ Phase 2b: Debug Services]
    H -->|Non| J[→ Phase 3: Analyse Logs]

    style C fill:#4CAF50
    style F fill:#4CAF50
    style G fill:#FF9800800800
    style I fill:#4CAF50
    style J fill:#FF9800800800

---

Phase 2 : Quick Fixes

2a. Nettoyage Système

Attention

Ces scripts libèrent de l'espace. Exécuter en dry-run d'abord si disponible.

Nettoyage Linux

Problème	Script	Commande
Disque plein	cleanup-system.sh	sudo ./cleanup-system.sh
Logs volumineux	logs-extractor.sh	./logs-extractor.sh --since "1 hour ago"
Fichiers temporaires	Commande directe	find /tmp -type f -mtime +7 -delete

# Nettoyage système complet (safe)
sudo ./cleanup-system.sh

# Identifier les fichiers volumineux
du -sh /* 2>/dev/null | sort -rh | head -20

Script recommandé : cleanup-system.sh

Nettoyage Docker / Conteneurs

Problème	Script	Commande
Images orphelines	docker_cleaner_pro.py	python3 docker_cleaner_pro.py --dry-run
Volumes inutilisés	docker_cleaner_pro.py	python3 docker_cleaner_pro.py --include-volumes
Logs conteneurs	Commande directe	truncate -s 0 /var/lib/docker/containers/*/*-json.log

# Dry-run d'abord (voir ce qui sera supprimé)
python3 docker_cleaner_pro.py --dry-run

# Nettoyage effectif avec volumes
python3 docker_cleaner_pro.py --include-volumes --force

Script recommandé : docker_cleaner_pro.py

---

2b. Debug Applications & Services

Pods Kubernetes en CrashLoopBackOff

graph LR
    A[Pod KO] --> B[k8s-pod-inspector.sh]
    B --> C{Exit Code ?}
    C -->|137| D[OOMKilled → Augmenter RAM]
    C -->|1| E[App Error → Voir Logs]
    C -->|143| F[SIGTERM → Graceful Shutdown]

    style A fill:#f44336
    style D fill:#4CAF50
    style E fill:#FF9800800800
    style F fill:#4CAF50

# Inspection détaillée d'un pod
./k8s-pod-inspector.sh -n production my-failing-pod

# Accès rapide aux logs
kubectl logs -n production my-failing-pod --previous --tail=100

Script recommandé : k8s-pod-inspector.sh

Problèmes Réseau Conteneurs

# Debug réseau avec netshoot sidecar
./container-net-debug.sh my-container

# Tests inclus : ping, DNS, curl, ports

Script recommandé : container-net-debug.sh

---

Phase 3 : Analyse Approfondie

Quand utiliser cette phase ?

Les quick fixes n'ont pas résolu le problème, ou vous avez besoin de comprendre la cause racine.

Analyse Base de Données

PostgreSQL - Bloat et Performance

# Vérifier le bloat (fragmentation)
./pg-bloat-check.sh -d production_db -t 30

# Résultat : pourcentage de bloat par table
# Si > 30%, planifier un VACUUM FULL

Script recommandé : pg-bloat-check.sh

MySQL/MariaDB - Audit Sécurité

# Audit de sécurité complet
./mysql-security-audit.sh -u root -H localhost

# Vérifie : utilisateurs sans mot de passe, root@%, etc.

Script recommandé : mysql-security-audit.sh

Redis - Audit des Clés

# Scanner les clés volumineuses (non bloquant)
python3 redis_key_auditor.py --host redis.local --top 50

# Identifie les clés consommant le plus de mémoire

Script recommandé : redis_key_auditor.py

Analyse des Logs

# Extraire les erreurs des dernières 2 heures
./logs-extractor.sh --since "2 hours ago" --level error --output /tmp/errors.log

# Analyse avec patterns connus
grep -E "(OOM|killed|timeout|refused|denied)" /tmp/errors.log

Script recommandé : logs-extractor.sh

Matrice de Diagnostic

Symptôme	Outil	Métrique Clé
Latence DB	pg-bloat-check.sh	Bloat > 30%
Mémoire Redis	redis_key_auditor.py	Top 10 keys size
Pods instables	k8s-pod-inspector.sh	Restart count, exit codes
Réseau conteneur	container-net-debug.sh	DNS resolution, connectivity

---

Phase 4 : Post-Mortem

Documentation Obligatoire

Tout incident résolu doit être documenté pour éviter sa répétition.

Collecte des Preuves

# Extraire tous les logs pertinents
./logs-extractor.sh \
    --since "$(cat /tmp/incident_start_time)" \
    --until "$(date -Iseconds)" \
    --services "nginx,postgresql,docker" \
    --output /tmp/incident_$(date +%Y%m%d)_logs.tar.gz

Script recommandé : logs-extractor.sh

Template Post-Mortem

# Post-Mortem Incident [DATE]

## Résumé
- **Détecté :** HH:MM
- **Résolu :** HH:MM
- **Durée :** X heures
- **Impact :** [Description impact utilisateurs]

## Timeline
| Heure | Événement |
|-------|-----------|
| HH:MM | Alerte reçue |
| HH:MM | Discovery script exécuté |
| HH:MM | Cause identifiée |
| HH:MM | Fix appliqué |
| HH:MM | Service restauré |

## Cause Racine
[Description technique de la cause]

## Actions Correctives
- [ ] Action 1 (responsable, deadline)
- [ ] Action 2 (responsable, deadline)

## Prévention
[Mesures pour éviter que cela se reproduise]

Flowchart Post-Mortem

graph TD
    A[Incident Résolu] --> B[Collecter Logs]
    B --> C[Rédiger Timeline]
    C --> D[Identifier Cause Racine]
    D --> E[Définir Actions Correctives]
    E --> F[Review avec l'équipe]
    F --> G[Publier Post-Mortem]
    G --> H[Suivre Actions]

    style A fill:#4CAF50
    style G fill:#da77f2
    style H fill:#2196F3

---

Quick Reference

Commandes d'Urgence Linux

# État système rapide
uptime && free -h && df -h

# Top processus CPU
ps aux --sort=-%cpu | head -10

# Top processus RAM
ps aux --sort=-%mem | head -10

# Connexions réseau
ss -tunapl | head -20

# Derniers messages kernel
dmesg --human --reltime | tail -30

Commandes d'Urgence Windows

# État système
Get-ComputerInfo | Select-Object CsName, OsUptime, CsProcessors, CsTotalPhysicalMemory

# Top processus CPU
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10

# Top processus RAM
Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10

# Services en échec
Get-Service | Where-Object { $_.Status -eq 'Stopped' -and $_.StartType -eq 'Automatic' }

---

Voir Aussi

• Dashboard Principal
• Tous les Scripts Bash
• Tous les Scripts PowerShell
• Sécurité & Compliance