10 réglages serveur à vérifier en fin d’année
(Pour éviter tout incident)
« Est‑ce qu’il faut vraiment vérifier quelque chose à la fin de l’année ? » La réponse est oui.
La fin d’année ne rend pas le serveur spécial, mais les personnes le deviennent.
- Le personnel de maintenance est réduit pendant les vacances
- Les schémas de trafic se perturbent
- L’attention se relâche
Ainsi, la période de fin d’année est souvent le moment où le risque d’incident est le plus élevé. Ce guide n’est pas une liste de tâches compulsive, mais un plan réaliste pour que rien ne se passe pendant les vacances.
1. Utilisation du disque et vitesse d’accumulation des logs
Les logs ne diminuent pas à la fin de l’année.
Vérifiez particulièrement :
- L’utilisation de
/var/log - La configuration de rotation des logs d’application
- La taille des logs des conteneurs Docker (logs JSON qui augmentent indéfiniment)
Un disque plein arrête le serveur sans préavis. Ce qui est gérable en semaine peut devenir un incident pendant les vacances.
2. Pas seulement « il y a un backup », mais « on peut le restaurer »
Il suffit d’un seul point : est‑ce que la restauration fonctionne réellement ?
Avant la fin d’année, faites au moins une fois :
- Vérifier l’existence du backup le plus récent
- Valider rapidement que le fichier compressé n’est pas corrompu
- Restaurer dans un environnement de test
Ne laissez pas la découverte du 1ᵉʳ jour de l’année que le backup était cassé.
3. Date d’expiration des certificats SSL/TLS
Les incidents liés aux certificats sont fréquents à la fin de l’année et au début de l’année.
- Le renouvellement automatique de Let’s Encrypt fonctionne réellement ?
- Le
cronou lesystemd timern’est pas désactivé ? - Aucun message d’erreur dans les logs de renouvellement récents
« Le renouvellement automatique est suffisant » est le déclencheur d’incident le plus courant.
4. Règles de pare‑feu et réglages « temporaires »
Au fil de l’année, ces éléments s’accumulent :
- Ports ouverts à des fins de test
- IP temporairement autorisées
- Ports de services obsolètes
Ces réglages temporaires deviennent des failles de sécurité si personne ne se souvient de leur raison. La fin d’année est le moment idéal pour les nettoyer.
5. Méthode d’accès SSH et gestion des clés
Les intrusions pendant les vacances sont souvent détectées tard.
- Désactivation de la connexion par mot‑de‑passe ?
- Suppression des clés SSH inutilisées
- Suppression des clés d’employés quittés ou de prestataires externes
- Le compte administrateur possède uniquement les privilèges nécessaires
L’optimisme « personne ne s’intéresse à notre serveur » est rarement vrai.
6. Échec silencieux des cron/scheduleurs
Les cron, systemd timer ou autres planificateurs échouent souvent sans alerte.
- Pas d’erreurs dans les logs récents ?
- Aucun job échoué depuis longtemps ?
- Aucun job inutile qui tourne encore ?
Un planificateur défectueux persiste en 2025 si on ne le corrige pas.
7. Utilisation des ressources : pas la moyenne, mais le pic
Le trafic de fin d’année est plus volatile :
- Pic de trafic sur une courte période
- Accès anormaux de bots/crawlers
- Schémas de vacances par pays
Surveillez donc les pics :
- Utilisation CPU et mémoire
- Nombre de connexions à la base de données, longueur de la file d’attente
- Nombre d’utilisateurs simultanés, sessions
« Tout est normal » n’est pas rassurant en fin d’année.
8. État des services dépendants
Même si votre serveur est sain, un service dépendant qui tombe provoque l’arrêt complet.
Exemples :
- Redis / Memcached
- Brokers de messages (Kafka, RabbitMQ, SQS, etc.)
- APIs externes (paiement, authentification, notifications, etc.)
- Stockage de fichiers/Images
Les services dépendants subissent souvent des vérifications, déploiements et tâches planifiées. Vérifiez les pages d’état et les canaux d’alerte.
9. Test de réception des notifications d’erreur
Avoir un système de notification n’est pas la même chose que recevoir réellement les alertes.
- Générer un faux incident
- Vérifier que l’e‑mail/Slack/Webhook arrive
- S’assurer qu’il n’est pas filtré par le niveau de gravité
Le plus gros problème d’incident en fin d’année est souvent que personne ne le voit.
10. Document « où commencer en cas de problème »
Le dernier point est un document.
- Liste des services principaux
- Méthodes d’accès serveur/conteneur
- Emplacement des logs (nginx, app, DB, queue, etc.)
- Procédure de redémarrage/rollback
- Ordre d’intervention d’urgence
Un tel document passe la difficulté de l’incident de mode hard à mode normal.
Checklist de fin d’année
Voici un tableau simple pour vérifier rapidement.
| Élément | Vérification | Exemple de vérification | État recommandé |
|---|---|---|---|
| Utilisation du disque | Vérifier l’espace libre | df -h, taille de /var/log |
> 20 % d’espace libre |
| Rotation des logs | Rotation et suppression | logrotate, paramètres Docker |
Rotation régulière |
| Backup / restauration | Dernier backup et test | Restaurer dans un environnement de test | Succès dans les 24–48 h |
| Certificat SSL | Date d’expiration et renouvellement | certbot, logs de renouvellement |
> 30 jours d’avance |
| Pare‑feu / ports | Ports inutiles fermés | ufw, iptables |
Autorisations minimales |
| Accès SSH | Authentification par clé, clés inutiles supprimées | sshd_config, liste de clés |
Clés uniquement, pas de mot‑de‑passe |
| Planificateur | Pas d’erreurs récentes | Logs cron/systemd | Aucun échec récent |
| Utilisation des pics | CPU, mémoire, connexions | Dashboard, htop |
Espace suffisant même en pic |
| Services dépendants | État et alertes | Pages d’état, logs | Alertes instantanées |
En suivant ces points, vous pourrez profiter des vacances en toute sérénité. N’oubliez pas d’avoir un petit ordinateur portable ou une tablette pour vous connecter en cas de besoin. Vous avez déjà réduit les risques, maintenant il suffit de savoir comment réagir si quelque chose se produit.
Aucun commentaire.