Liste de contrôle des opérations de production Linux avec exemples pratiques

Introduction

Les opérations de production Linux peuvent transformer un simple changement en panne lorsque l'opérateur omet l'observation, la vérification de version ou la planification de la reprise. Une liste de contrôle accompagnée d'exemples pratiques aide les équipes à passer d'un problème observé à un résultat vérifié sans deviner.

Cet article s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui gèrent des systèmes Linux en production. Il relie les opérations Linux, la liste de contrôle Linux, les bonnes pratiques Linux et la maintenance Linux à des commandes concrètes, des sorties attendues, des signaux d'échec et des décisions de reprise.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire de version et d'environnement

Avant de toucher à un système de production, vous avez besoin d'un inventaire précis : ce qui est installé, quelle version, comment c'est déployé et ce qui en dépend. Une inspection en lecture seule constitue la première étape. Écrivez la sortie dans un fichier journal avec un horodatage afin de pouvoir comparer les états avant et après.

Exemple : Vérification du système d'exploitation et du noyau

Exécutez ces commandes pour capturer la version de l'OS et du noyau :

cat /etc/os-release
uname -r

Sortie attendue pour un système Ubuntu 22.04 LTS typique :

PRETTY_NAME="Ubuntu 22.04.3 LTS"
VERSION_ID="22.04"
5.15.0-91-generic

Si la version du noyau est plus ancienne que celle recommandée pour votre charge de travail, planifiez une fenêtre de maintenance pour la mettre à jour. Enregistrez l'état actuel dans un fichier :

{
  echo "--- Inventaire $(date -u +%Y-%m-%dT%H:%M:%SZ) ---"
  cat /etc/os-release
  uname -r
} >> /var/log/inventory.log

Utilisez >> pour ajouter, jamais pour écraser le journal. Si la version attendue est absente, vérifiez l'historique du gestionnaire de paquets :

grep " install " /var/log/dpkg.log

Cela montre les installations récentes et peut révéler des changements involontaires.

Vérification des services en cours d'exécution

Utilisez systemctl pour lister les services actifs et leurs états :

systemctl list-units --type=service --state=running

Recherchez les services qui devraient être en cours d'exécution mais ne le sont pas, ou les services qui s'exécutent de manière inattendue. Par exemple, si nginx.service est absent de la liste, vérifiez si nginx est installé et activé :

systemctl status nginx

Sortie attendue pour un service en cours d'exécution :

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-05-20 10:15:42 UTC; 1h 20min ago

Si le service est inactif, démarrez-le avec sudo systemctl start nginx, mais vérifiez d'abord la configuration avec sudo nginx -t. C'est une vérification de syntaxe en lecture seule :

sudo nginx -t

Succès attendu :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si la vérification de syntaxe échoue, corrigez la configuration avant de démarrer le service pour éviter un état cassé.

Chemin de configuration sûr

Modifier la configuration est risqué. Suivez un chemin sûr : sauvegardez la configuration actuelle, effectuez un changement limité, testez-le et ayez un plan de retour en arrière. Utilisez toujours un contrôle de version ou au moins des sauvegardes horodatées.

Exemple : Modification d'un fichier d'unité systemd

Supposons que vous deviez augmenter la limite de fichiers ouverts pour un service comme PostgreSQL. D'abord, localisez le fichier d'unité :

systemctl cat postgresql.service

Cela affiche le contenu actuel du fichier d'unité. Copiez-le en sauvegarde :

sudo cp /etc/systemd/system/postgresql.service /etc/systemd/system/postgresql.service.bak.$(date +%Y%m%d)

Maintenant, éditez le fichier avec sudo systemctl edit postgresql.service --full ou utilisez un éditeur de texte. L'approche sûre consiste à créer un fichier de remplacement plutôt que de modifier l'original :

sudo systemctl edit postgresql.service

Cela ouvre un fichier de remplacement vide. Ajoutez :

[Service]
LimitNOFILE=65536

Enregistrez et quittez. Rechargez ensuite systemd et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart postgresql.service

Vérifiez que le changement a pris effet :

systemctl show postgresql.service -p LimitNOFILE

Sortie attendue :

LimitNOFILE=65536

Si le service ne démarre pas, vérifiez l'état et les journaux :

systemctl status postgresql.service
journalctl -u postgresql.service -n 50

Si le problème vient du changement récent, revenez en arrière en supprimant le fichier de remplacement :

sudo rm /etc/systemd/system/postgresql.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart postgresql.service

Testez toujours les changements de configuration sur un environnement de préproduction d'abord si possible.

Exemple : Modification d'un paramètre du noyau avec sysctl

Pour définir un paramètre du noyau de manière persistante, utilisez /etc/sysctl.d/. Par exemple, augmentez le nombre maximal de connexions :

echo 'net.core.somaxconn = 1024' | sudo tee /etc/sysctl.d/99-custom.conf

Appliquez le changement :

sudo sysctl -p /etc/sysctl.d/99-custom.conf

Vérifiez :

sysctl net.core.somaxconn

Sortie attendue :

net.core.somaxconn = 1024

Pour revenir en arrière, supprimez le fichier et rechargez les paramètres par défaut :

sudo rm /etc/sysctl.d/99-custom.conf
sudo sysctl --system

Vérification et diagnostics

Après tout changement, vérifiez que le système se comporte comme prévu. Cette section couvre les commandes pour vérifier les processus, les sockets réseau, l'utilisation du disque et les journaux.

Vérification des processus

Utilisez ps pour inspecter un processus spécifique. Par exemple, vérifiez le processus maître de nginx :

ps -C nginx -o pid,user,cmd

Sortie attendue :

  PID USER     CMD
 1234 root     nginx: master process /usr/sbin/nginx
 1235 www-data nginx: worker process

Si le processus maître est absent, nginx n'est pas en cours d'exécution. Vous pouvez également utiliser pgrep :

pgrep -a nginx

Vérification des ports en écoute

Utilisez ss pour lister les ports TCP en écoute :

ss -tlnp

La sortie attendue inclut des lignes comme :

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

Cela confirme que nginx écoute sur le port 80. Si le port attendu est absent, vérifiez la configuration du service et les journaux.

Diagnostic de l'utilisation du disque

Vérifiez l'utilisation du système de fichiers avec df -h :

df -h

Exemple de sortie :

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   30G   18G  63% /

Si un système de fichiers est plein à plus de 90 %, enquêtez avec du :

sudo du -sh /var/log/*

Cela montre quel répertoire consomme le plus d'espace. Nettoyez les anciens journaux avec précaution, en vous assurant de ne pas supprimer de fichiers actifs.

Analyse des journaux

Utilisez journalctl pour afficher les journaux récents d'un service :

journalctl -u sshd.service -n 20 --no-pager

Recherchez les messages d'erreur tels que Authentication failure ou Failed password. Cela peut indiquer une attaque par force brute. Vous pouvez également filtrer par heure :

journalctl --since "2024-05-20 10:00:00" --until "2024-05-20 11:00:00"

Modes de défaillance et reprise

Même les opérateurs prudents rencontrent des échecs. Cette section décrit les modes de défaillance courants et les étapes de reprise.

Boucle de redémarrage d'un service

Si un service plante sans cesse après le démarrage, utilisez systemctl status pour voir le code de sortie et le nombre de redémarrages :

systemctl status myapp.service

Cherchez des lignes comme :

Active: activating (auto-restart) (Result: exit-code)

Consultez les journaux pour trouver la cause première :

journalctl -u myapp.service -n 100

Les problèmes courants incluent des fichiers de configuration manquants, des erreurs de permission ou des échecs de dépendances. Par exemple, si l'application ne peut pas se connecter à une base de données, vous pourriez voir :

Error: connection refused to 127.0.0.1:5432

Corrigez le problème sous-jacent (par exemple, démarrez le service de base de données) et redémarrez l'application. Si vous ne pouvez pas le corriger immédiatement, vous pouvez temporairement arrêter la boucle de redémarrage avec :

sudo systemctl stop myapp.service

Puis enquêtez sans générer de journaux excessifs.

Reprise après un disque plein

Lorsque le système de fichiers racine est plein, le système peut se comporter de manière erratique. D'abord, identifiez les gros fichiers :

sudo find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null

Les coupables courants sont les anciens journaux, les fichiers core dump ou les caches de paquets. Pour les journaux, vous pouvez tronquer (et non supprimer) un fichier pour libérer de l'espace immédiatement :

sudo truncate -s 0 /var/log/syslog

Pour les caches de paquets, nettoyez avec :

sudo apt-get clean

Après avoir libéré de l'espace, vérifiez avec df -h.

Système qui ne répond pas

Si le système devient insensible, essayez de reprendre le contrôle via SSH ou la console. Si SSH ne répond pas, utilisez une interface de gestion à distance (par exemple, IPMI, console cloud). Vérifiez la charge moyenne et la mémoire :

uptime
free -h

Si la charge est élevée, utilisez top ou htop pour trouver le processus qui consomme du CPU :

top -bn1 | head -20

Identifiez le processus et décidez de le tuer :

sudo kill -15 <PID>

Attendez quelques secondes ; s'il ne se termine pas, utilisez kill -9 :

sudo kill -9 <PID>

Essayez toujours une terminaison gracieuse d'abord pour éviter la corruption des données.

Liste de contrôle des opérations

Utilisez cette liste de contrôle avant et après tout changement sur un système Linux de production.

Liste de contrôle avant changement

• [ ] Confirmez l'état actuel avec des commandes en lecture seule (par ex., systemctl status, df -h, ps aux).
• [ ] Enregistrez la sortie dans un fichier journal avec un horodatage.
• [ ] Sauvegardez tout fichier de configuration que vous prévoyez de modifier.
• [ ] Vérifiez la version attendue du logiciel et des dépendances.
• [ ] Identifiez le rayon d'impact : quels services ou utilisateurs sont affectés ?
• [ ] Planifiez la procédure de retour en arrière.
• [ ] Planifiez le changement pendant une fenêtre de maintenance si possible.
• [ ] Informez les parties prenantes.

Liste de contrôle après changement

• [ ] Vérifiez que le changement a pris effet avec la commande appropriée.
• [ ] Vérifiez la santé du service (par ex., systemctl status, point de terminaison de santé de l'application).
• [ ] Examinez les journaux pour toute nouvelle erreur.
• [ ] Surveillez les métriques clés pendant un certain temps (CPU, mémoire, disque, réseau).
• [ ] Documentez le changement dans votre journal des modifications.
• [ ] Supprimez les sauvegardes temporaires seulement après avoir confirmé la stabilité.

Conclusion

Une liste de contrôle des opérations de production Linux n'est utile que si chaque recommandation est limitée à une version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation.

Comme prochaine étape, choisissez une vérification à faible risque pour votre environnement de production Linux. Enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et passez en revue les dépendances telles que systemd, Bash et Docker le cas échéant.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de reprise avant qu'un incident ne force la décision.