Linux Ops — Sysadmin Tactical prompts

Tu es un SRE senior. Mon serveur Linux est en surcharge. Aide-moi à diagnostiquer en 5 minutes.

Voici les sorties de mes commandes initiales :

```
$ uptime
<COLLE_LA_SORTIE>

$ top -bn1 | head -20
<COLLE_LA_SORTIE>

$ free -h
<COLLE_LA_SORTIE>

$ iostat -x 1 3
<COLLE_LA_SORTIE_OU_PRECISE_SI_IOSTAT_NON_INSTALLÉ>

$ vmstat 1 5
<COLLE_LA_SORTIE>
```

Diagnostique en 4 sections :

1. **Verdict primaire** (1 phrase) : où est le bottleneck principal — CPU / Memory / I/O / Network / Process explosion ?
2. **Evidence** : quelle métrique précise t'a mené à ce verdict (cite la valeur).
3. **Commandes suivantes à lancer** (top 5, dans l'ordre) pour confirmer + localiser le coupable. Donne-moi la commande exacte, pas 'utilise top'.
4. **3 hypothèses sur la cause racine** : la plus probable, l'alternative, et la moins probable mais possible. Pour chaque hypothèse, qu'est-ce qui la confirmerait.

Règle : ne propose JAMAIS de killer un process sans avoir vérifié ce qu'il fait avec `lsof -p PID` ou `ps -ef --forest` pour voir l'arbre des processus.

Tu es un sysadmin sénior. Mon disque Linux est plein. Je dois libérer de l'espace en 10 minutes sans casser le service en prod.

Voici mes sorties :

```
$ df -h
<COLLE_LA_SORTIE>

$ df -i  # inodes
<COLLE_LA_SORTIE>

$ du -sh /* 2>/dev/null | sort -hr | head -20
<COLLE_LA_SORTIE>
```

Diagnostique :

1. **Cause primaire** : disque plein en bytes OU en inodes ? Quel filesystem ?
2. **Top 5 répertoires/fichiers à cibler** (par ordre de gain potentiel) avec la commande exacte pour identifier précisément ce qui consomme :
   - Pour des logs : `find /var/log -type f -size +500M -exec ls -lh {} \;`
   - Pour des bin : `ncdu` ou `du -h --max-depth=2 /opt | sort -hr`
   - Pour les fichiers supprimés mais retenus par un process : `lsof | grep -i deleted | awk '{print $7, $9}' | sort -hr`
3. **Actions de libération sûres** (top 3) : pour chaque action, donne la commande EXACTE + ce que ça libère typiquement + le risque.
4. **Actions à NE PAS faire** sous pression (top 3) — exemples : `rm -rf /var/log/*` sans `truncate -s 0`, `apt clean` sans vérifier les packages installés, supprimer un mountpoint sans le `umount`.
5. **Fix permanent** une fois la crise passée : 1 changement à mettre en place pour éviter la rechute (logrotate config, monitoring threshold, etc.).

Règle : si je vois 'fichiers supprimés mais retenus' (lsof + deleted), redémarrer le process (PID) libère l'espace SANS rm. Souvent c'est la première chose à essayer.

Tu es un sysadmin systemd-natif. Mon service `<NOM_SERVICE>.service` ne démarre pas. Je te donne les sorties :

```
$ systemctl status <NOM_SERVICE>.service
<COLLE_LA_SORTIE>

$ journalctl -u <NOM_SERVICE>.service -n 100 --no-pager
<COLLE_LA_SORTIE>

$ systemctl cat <NOM_SERVICE>.service
<COLLE_LE_FICHIER_UNIT>
```

Aide-moi à diagnostiquer :

1. **Erreur primaire** : repère la ligne ou exit code qui révèle le vrai problème (souvent enterré dans 100 lignes de logs). Cite-la verbatim.
2. **Classification** : config / permissions / dépendance / port / dépendance externe (DB, network) / OOM / autre.
3. **Top 3 hypothèses** sur la cause + commande pour confirmer chacune :
   - permissions : `ls -la /chemin/que/le/service/utilise`
   - port : `ss -tlnp | grep <PORT>` (qui d'autre l'occupe)
   - DB : `psql -h ... -U ... -c 'SELECT 1'` (DB accessible ?)
   - SELinux/AppArmor : `ausearch -m avc -ts recent` ou `dmesg | grep -i denied`
4. **Action de fix** la plus probable, avec la commande exacte.
5. **Comment éviter la rechute** : 1 amélioration du unit file (ex: ajouter `Restart=on-failure` + `RestartSec=10s` + `StartLimitBurst=5`) ou 1 healthcheck à mettre.

Règle : si l'erreur dit 'Address already in use', NE PROPOSE PAS `kill -9 $(lsof -ti:PORT)` aveuglément — d'abord identifie QUI tient le port (peut être un autre service légitime).

Tu es un SRE qui analyse des logs production. Je te donne un échantillon de ~200 lignes du log d'un service. Trouve les patterns récurrents.

Format de mon log : <ex: nginx access log, JSON structured logs, Java stack traces, etc.>

Lignes du log :
```
<COLLE_200_LIGNES_MAX>
```

Analyse :

1. **Top 5 patterns d'erreur** (groupés par type, pas par occurrence individuelle) — pour chacun : pattern type (regex ou description), nombre d'occurrences dans l'échantillon, % du total.
2. **Pour le pattern #1** : analyse approfondie — quelle est la cause probable, est-ce une vraie erreur ou du bruit (timeout normal vs crash), faut-il agir maintenant ou demain matin.
3. **Pattern à ignorer / silence** : repère 1-2 patterns qui sont du bruit (healthcheck failure d'un load balancer, timeout TCP d'un client mobile, etc.) et qu'on devrait filtrer du dashboard.
4. **Pattern à élever en alerte** : repère 1 pattern qui devrait déclencher un PagerDuty (ex: 'OutOfMemoryError', 'connection refused to primary DB').
5. **Une recommandation logging** : un améliorement structurel (ajouter un correlation ID, sortir un champ JSON spécifique, etc.) qui rendrait le diagnostic 10x plus rapide la prochaine fois.

Format : tableau pour 1, paragraphes courts pour 2-5.

Tu es un SRE post-mortem. Mon serveur Linux a redémarré seul à <HEURE>. Je dois savoir POURQUOI avant de le remettre en service.

J'ai collecté :

```
$ last -x | head -20  # reboot history
<COLLE>

$ journalctl --list-boots
<COLLE>

$ journalctl -b -1 -n 100 --no-pager  # logs du boot précédent (= avant le crash)
<COLLE_LES_100_DERNIÈRES_LIGNES_AVANT_LE_REBOOT>

$ dmesg | grep -iE 'oom|panic|hardware|error' | tail -30
<COLLE>

$ uptime
<COLLE>
```

Diagnostique :

1. **Cause primaire identifiée** (ou 'pas concluant — voir #4' si les logs ne suffisent pas) : OOM kill, kernel panic, hardware fault (disk/RAM/PSU), watchdog timeout, mise à jour automatique, ou autre.
2. **Timeline reconstituée** : 5 dernières minutes avant le reboot — qu'est-ce qui s'est passé ?
3. **Le 'smoking gun'** : la ligne précise (cite-la) qui explique le mieux le reboot.
4. **Si pas concluant** : quels logs supplémentaires je devrais récupérer pour aller plus loin (mcelog pour MCE hardware, IPMI System Event Log, SMART status, vendor logs).
5. **Action avant remise en service** : checklist de 5 vérifications (fsck si forced reboot, vérifier l'état RAID / disk SMART, vérifier que les services ont bien fini leur graceful shutdown, etc.).
6. **Recommandation monitoring** : 1 alerte à ajouter qui aurait détecté le pattern AVANT le crash.

Règle : ne remets pas le serveur en prod sans avoir compris la cause. Un reboot sans explication = peut se reproduire dans les heures suivantes.