Les responsabilités de l'administrateur système

Une fois les serveurs installés, le travail de l'administrateur système commence vraiment : il doit les garder disponibles, sûrs et à jour pendant des années. Cette page décrit ses responsabilités d'exploitation, une par une, à destination de qui débute dans le métier ou reprend un parc existant : surveillance, mises à jour, housekeeping, incidents, sauvegardes, documentation et participation aux plans de continuité.

La documentation est le fil qui relie toutes ces tâches, et c'est la plus souvent négligée. Un administrateur tient à jour une trace claire des actions, des configurations et des procédures : c'est ce qui permet la traçabilité, les audits et la reprise du parc par un collègue ou un prestataire, sans tout redécouvrir.

Ce que vous allez apprendre

Cette leçon décrit le métier, pas encore la technique : chaque responsabilité renvoie vers la leçon qui la traite en profondeur dans la formation.

• Lister les responsabilités d'exploitation d'un administrateur système.
• Choisir les indicateurs à surveiller sur un serveur.
• Distinguer les sauvegardes complètes, incrémentielles et différentielles.
• Situer le rôle de l'administrateur dans le PCA, le PRA et le PCS.
• Expliquer pourquoi une sauvegarde non restaurée ne prouve rien.
• Identifier les qualités humaines du poste, les certifications qui le valident et les métiers vers lesquels il mène.

Surveillance et gestion des performances

La surveillance consiste à mesurer en continu l'état des serveurs pour repérer un problème avant qu'il ne devienne une panne. L'objectif n'est pas de réagir plus vite, c'est d'anticiper : maintenir un haut niveau de disponibilité et intervenir pendant que l'impact est encore nul pour les utilisateurs.

Trois familles d'indicateurs couvrent l'essentiel de ce qu'il faut suivre :

• Utilisation des ressources : le CPU, la mémoire et l'espace disque. Une ressource saturée ralentit le serveur ou interrompt le service. Suivre ces valeurs permet d'ajuster la configuration, d'allouer plus de ressources ou de prévoir de nouveaux serveurs.
• Temps de réponse des services : un temps de réponse qui augmente traduit souvent une surcharge ou une mauvaise configuration, et l'utilisateur le perçoit avant toute panne franche.
• Erreurs et incidents : les journaux (logs) révèlent des erreurs qui passent sinon inaperçues, comme des tentatives d'accès non autorisées ou les signes avant-coureurs d'une panne matérielle.

Une surveillance utile regarde des tendances, pas seulement des valeurs instantanées. Un disque qui se remplit de quelques pour cent par mois ne déclenche aucune alerte aujourd'hui, mais sa pente dit quand il sera plein : c'est l'objet de la leçon Gestion des capacités, qui transforme cette tendance en date de saturation.

Gestion des mises à jour et sécurité

La gestion des mises à jour protège les serveurs contre les failles connues : un correctif de sécurité non appliqué laisse ouverte une porte que les attaquants savent déjà exploiter. Elle doit pourtant rester prudente, car une mise à jour peut aussi casser un service en production.

Une vulnérabilité est une faille identifiée dans un système d'exploitation ou un logiciel, qui peut donner un accès non autorisé ou permettre une action malveillante. Pour la connaître avant l'attaquant, l'administrateur suit les bulletins de sécurité des éditeurs et les avis des services spécialisés, comme le CERT-FR en France.

Avant la production, chaque mise à jour passe par un environnement hors production, souvent appelé préproduction, aussi proche que possible du réel. Ce test vérifie que le correctif ne change pas un comportement dont un service dépend et n'introduit pas d'incompatibilité. Une mise à jour validée en amont évite les interruptions imprévues.

Les campagnes de patch organisent ce travail dans le temps : un cycle régulier, par exemple mensuel ou trimestriel, plutôt qu'une suite d'urgences. Chaque campagne priorise les correctifs de sécurité critiques sans oublier les autres mises à jour. La leçon Patch management décrit une stratégie complète, de la veille au retour arrière.

Automatisation des tâches de housekeeping

Le housekeeping regroupe les tâches d'entretien courant qui gardent un serveur propre et performant : nettoyage des fichiers inutiles, gestion de l'espace disque, arrêt de ce qui ne sert plus. Ces tâches paraissent mineures, mais un disque plein suffit à arrêter un service entier.

Avec le temps, un serveur accumule des fichiers temporaires, des caches et d'anciens paquets. Ils ne servent plus, occupent de la place et finissent par provoquer des erreurs quand le disque est saturé. Les caches de paquets et les fichiers temporaires se nettoient donc périodiquement.

La gestion de l'espace disque garantit qu'il reste toujours assez de place pour que les services fonctionnent : suppression des données obsolètes, archivage des journaux anciens, vérification des volumes. Des seuils d'alerte préviennent l'administrateur avant que la capacité ne devienne critique.

Les journaux sont indispensables au diagnostic, mais ils grossissent sans fin. La rotation des journaux limite leur taille : elle conserve les fichiers récents et archive ou supprime les plus anciens. Sur Linux, c'est le rôle de logrotate, configuré dans /etc/logrotate.d/, et de la directive SystemMaxUse= de journald pour le journal de systemd.

Des processus ou des services qui ne servent plus continuent souvent de consommer des ressources. Les repérer et les arrêter libère de la mémoire et du CPU, et réduit en même temps la surface d'attaque : un service arrêté n'expose plus aucune faille.

Ces tâches s'oublient dès qu'elles dépendent de la mémoire de quelqu'un. On les confie donc à des scripts automatisés, planifiés par cron ou par un timer systemd, qui nettoient et archivent sans intervention manuelle, avec la même régularité chaque semaine.

Gestion des incidents : de la détection à la résolution

Un incident est une interruption ou une dégradation d'un service, et aucune maintenance ne les supprime tous : panne matérielle, erreur humaine, bug logiciel ou attaque. La gestion des incidents vise à réduire leur impact et à rétablir le service au plus vite.

Tout commence par la détection. Elle repose sur la surveillance et sur des alertes déclenchées dès qu'un seuil critique est franchi, comme une mémoire saturée ou une rafale d'accès refusés. Il faut ensuite qualifier l'origine : matérielle, logicielle ou malveillante.

Un incident détecté se communique. Une procédure d'escalade définit qui prévenir et dans quel ordre, pour que les bonnes personnes agissent vite. Les utilisateurs sont informés dès que la disponibilité du service est touchée, et l'équipe traite les incidents par ordre de gravité.

L'objectif suivant est de rétablir le service, avant même de tout comprendre : redémarrer un service, remplacer un matériel défectueux, revenir à la version précédente d'un logiciel après une mise à jour défectueuse. Une solution temporaire peut rendre le service pendant que la correction définitive se prépare.

Une fois le service rétabli vient l'analyse post-incident : comprendre la cause profonde et décider des actions qui empêchent la répétition, qu'il s'agisse de configuration, de surveillance ou de procédures. La leçon Incidents et postmortems détaille cette démarche et son retour d'expérience sans blâme.

Sauvegarde et restauration

La sauvegarde permet de reconstruire un serveur et ses données après un désastre, par exemple la perte d'un disque sur une machine critique. L'administrateur doit pouvoir restaurer le serveur à l'identique, que la perte vienne d'une panne, d'une erreur humaine ou d'une attaque.

La reconstruction est plus sûre quand le serveur est reproductible : décrit en code (avec Ansible par exemple) plutôt que retouché à la main au fil des années, il se refait à l'identique sur une machine neuve. Un serveur unique que plus personne n'ose toucher, à l'inverse, ne se reconstruit pas après un incident. La configuration se reconstruit ainsi, les données, elles, se restaurent depuis la sauvegarde : l'une ne dispense pas de l'autre.

Une stratégie de sauvegarde se juge sur une seule question : peut-on récupérer les données à temps et sans perte majeure ? Les quatre sous-sections suivantes en donnent les composantes : fréquence, type, stockage et test.

Fréquence et planification

La fréquence de sauvegarde découle de la quantité de données qu'on accepte de perdre, le RPO (Recovery Point Objective). Les données critiques se sauvegardent souvent, parfois en continu, quand d'autres se contentent d'un rythme hebdomadaire ou mensuel. Le RTO (Recovery Time Objective) fixe de son côté la durée d'interruption acceptable, comme l'explique la leçon Résilience.

Types de sauvegardes

Trois types de sauvegarde se combinent. Une sauvegarde complète copie toutes les données. Une sauvegarde incrémentielle ne copie que ce qui a changé depuis la dernière sauvegarde, quel que soit son type. Une sauvegarde différentielle copie tout ce qui a changé depuis la dernière sauvegarde complète.

La différence se paie à la restauration. Avec des incrémentielles, il faut la sauvegarde complète puis toutes les incrémentielles qui ont suivi, dans l'ordre. Avec une différentielle, la complète et la dernière différentielle suffisent, au prix de sauvegardes qui grossissent chaque jour.

Stockage des sauvegardes

Les sauvegardes se stockent dans des lieux sécurisés et diversifiés. On combine une copie locale, sur un serveur ou un disque externe, avec une copie distante, sur un autre site ou dans le cloud : un sinistre qui détruit la salle serveur ne détruit pas aussi la sauvegarde.

Tests de restauration

Une sauvegarde qui n'a jamais été restaurée n'est qu'un espoir. Seul un test de restauration régulier prouve que les fichiers sont lisibles, complets et récupérables dans le délai prévu. Mieux vaut découvrir une sauvegarde corrompue pendant un test que pendant une crise.

Gestion de la documentation

La documentation centralise ce qu'il faut savoir pour exploiter l'infrastructure et facilite la communication dans l'équipe. Tenue à jour, elle garantit la continuité de service, accélère la gestion des incidents et simplifie les audits.

Pourquoi documenter ?

La documentation rend trois services que rien d'autre ne rend, et chacun se mesure le jour où l'auteur d'une configuration est absent :

• Suivi des modifications : chaque changement de configuration, mise à jour ou modification des droits d'accès est consigné. L'historique évite de répéter une erreur déjà commise.
• Facilitation des interventions : pendant un incident, une procédure écrite fait gagner du temps. Un nouveau membre de l'équipe ou un prestataire comprend l'architecture sans tout redécouvrir.
• Transparence et traçabilité : chaque action sur le serveur est traçable, ce que demandent les audits de sécurité et de conformité.

Ce que doit contenir la documentation

Une documentation d'exploitation couvre au minimum quatre sujets, du plus général au plus sensible :

• Architecture du système : vue d'ensemble des serveurs, des bases de données, des réseaux et des services déployés.
• Configurations importantes : les fichiers de configuration critiques, les ports utilisés et les paramètres réseau de chaque serveur.
• Procédures d'interventions : les étapes des opérations courantes, comme redémarrer un service ou gérer un utilisateur, et celles des incidents, comme une reprise après panne ou une restauration.
• Liste des accès et des droits : qui a accès à quoi, avec quels droits, pour appliquer le principe du moindre privilège.

Mise à jour régulière

Une documentation périmée est plus dangereuse qu'une documentation absente, parce qu'on lui fait confiance. Elle se met donc à jour à chaque changement d'infrastructure : nouvelle configuration, nouveau service, mise à jour de sécurité.

Centralisation et accessibilité

La documentation est centralisée et accessible à toute l'équipe qui en a besoin, sur un outil documentaire ou une plateforme collaborative. Des règles d'accès protègent les informations sensibles. La leçon Documentation opérationnelle montre comment la structurer pour la retrouver sous pression.

Participation aux plans de continuité : PCA, PRA et PCS

Les plans de continuité décrivent comment l'organisation traverse un sinistre majeur. Le PCA (Plan de Continuité d'Activité) maintient l'activité pendant la crise, souvent en mode dégradé ; le PRA (Plan de Reprise d'Activité) organise le redémarrage après une interruption ; le PCS (Plan de Continuité de Service) applique cette logique à un service informatique précis.

Ces plans ne concernent pas que la direction ou la cellule de crise. L'administrateur système connaît l'infrastructure, ses dépendances et ses points faibles : son expertise technique est indispensable pour anticiper les risques et maintenir les services critiques.

Contribution à l'élaboration des plans

L'administrateur participe à la conception des plans et à leur mise à jour, et quatre apports lui reviennent parce que personne d'autre ne connaît aussi bien le parc :

1. Connaissance des systèmes critiques : il connaît l'architecture, les dépendances entre services et les points faibles du parc. Il aide donc à choisir les services critiques du PCS et du PRA, et leur priorité de reprise.
2. Identification des besoins en ressources : il recense ce qu'il faut pour restaurer, matériel, licences logicielles et documentation, et estime le temps de redémarrage des systèmes critiques.
3. Réalisation de scénarios de récupération : il propose les mécanismes de sauvegarde, de redondance et de basculement (failover) qui rendent la reprise possible.
4. Définition des procédures techniques : il écrit les procédures de restauration et de redémarrage, assez précises pour être exécutées vite en pleine crise.

Participation aux exercices réguliers

Un plan qui n'a jamais été exercé ne vaut pas mieux qu'une sauvegarde jamais restaurée. Les exercices de simulation vérifient que les solutions fonctionnent et que l'équipe sait réagir, et l'administrateur y apporte les quatre mêmes compétences qu'à la conception :

1. Validation des processus de reprise : le test vérifie que les procédures tiennent les délais, que les sauvegardes se restaurent, que les serveurs redémarrent et que le basculement fonctionne.
2. Identification des points d'amélioration : l'exercice révèle ce qui n'était pas prévu, une restauration plus lente qu'annoncé ou une dépendance oubliée, qu'on corrige avant le vrai sinistre.
3. Formation des équipes : l'administrateur guide ses collègues dans les étapes techniques et assure la coordination pendant la simulation.
4. Amélioration continue des plans : chaque exercice nourrit une mise à jour, car les menaces, les systèmes et les besoins de l'entreprise évoluent sans cesse.

Quelles qualités humaines le poste demande-t-il ?

Toutes ces responsabilités s'exercent sur des systèmes dont d'autres dépendent, souvent sous pression : la technique ne suffit pas. Quatre qualités font la différence entre un administrateur qui subit son parc et un administrateur qui le maîtrise.

• Rigueur et méthode : une commande lancée sur le mauvais serveur peut arrêter un service entier. La rigueur se voit dans des gestes simples : vérifier où l'on est, préparer un retour arrière avant chaque changement, noter ce qu'on a fait. Une gestion des changements formalise cette discipline : chaque modification est décrite, validée et réversible.
• Calme sous pression : pendant une panne, tout le monde attend. L'administrateur garde une démarche de diagnostic ordonnée au lieu de multiplier les essais au hasard, qui brouillent les pistes, et dit clairement ce qu'il sait et ce qu'il ignore.
• Curiosité et autonomie : un message d'erreur inconnu est le cas courant. Lire une page de manuel, la documentation officielle, un journal ligne par ligne, puis tester sur une machine de laboratoire avant la production : l'autonomie du poste repose sur cette curiosité.
• Communication : ce que l'administrateur sait, l'équipe doit pouvoir le retrouver quand il est absent. Il écrit des procédures de reprise, les runbooks, et explique sans jargon pourquoi un changement est refusé ou reporté.

Comment devient-on administrateur, et vers quoi évoluer ?

On devient administrateur Linux sans diplôme imposé : ce qui compte est le savoir-faire, et de pouvoir le prouver. Le chemin le plus direct commence par les fondamentaux (terminal, fichiers, droits, processus), puis passe par un laboratoire de quelques machines virtuelles où l'on installe, casse et répare. La configuration se versionne avec Git dès le début, et Ansible prend le relais dès qu'un geste se répète sur plusieurs machines. Mieux vaut maîtriser à fond une famille de distribution, Red Hat et ses dérivées ou Debian et Ubuntu, que survoler les deux : les notions se transposent, seuls le gestionnaire de paquets (dnf ou apt) et quelques outils changent.

Trois certifications pratiques valident ensuite le métier : on y administre de vrais systèmes, en temps limité, sans questionnaire à choix multiples. La RHCSA (EX200, Red Hat) porte sur un système RHEL ; la LFCS (Linux Foundation) valide la même administration en 2 heures, en ligne sous surveillance, sans distribution imposée ; la RHCE (EX294) valide son automatisation avec Ansible. La leçon Choisir une certification Linux compare les deux premières.

Le métier est le socle des autres rôles de l'infrastructure, et chaque évolution prolonge une compétence déjà acquise :

Vers	Ce qui s'ajoute au socle Linux
Ingénieur fiabilité (SRE)	La programmation, des objectifs de fiabilité mesurés, Kubernetes
Ingénieur cloud	Terraform en profondeur et un fournisseur cloud
Ingénieur DevSecOps	Les pipelines CI/CD et la sécurité de la chaîne de livraison
Ingénieur plateforme	Kubernetes, GitOps et l'outillage pour les développeurs

Glissez pour voir

Le parcours administrateur Linux traduit le métier en formations du site, dans l'ordre du terrain, avec le niveau attendu à chaque étape.

À retenir

1. Le métier d'administrateur système commence après l'installation : garder le parc disponible, sûr et à jour.
2. La surveillance suit les ressources, les temps de réponse et les journaux, et regarde les tendances pour anticiper.
3. Les mises à jour passent par la préproduction et s'organisent en campagnes régulières qui priorisent la sécurité.
4. Le housekeeping (rotation des journaux, nettoyage, services inutiles) s'automatise, sinon il s'oublie.
5. Un incident se détecte, se communique, se rétablit, puis s'analyse pour ne pas se reproduire.
6. Une sauvegarde ne vaut que si sa restauration a été testée ; sa fréquence découle du RPO.
7. La documentation et la participation aux plans PCA, PRA et PCS font partie du poste, pas d'un à-côté.
8. La rigueur, le calme sous pression, la curiosité et la communication comptent autant que la technique.
9. RHCSA et LFCS valident l'administration en conditions réelles, RHCE son automatisation avec Ansible ; le métier mène au SRE, au cloud, au DevSecOps et à l'ingénierie de plateforme.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes

Ces réponses courtes reprennent les questions que posent le plus souvent les personnes qui envisagent le métier : ses missions, l'accès sans diplôme, le choix d'une certification et les évolutions possibles.

Que fait un administrateur Linux ?

Faut-il un diplôme pour devenir administrateur Linux ?

RHCSA ou LFCS : quelle certification choisir ?

Vers quels métiers évolue un administrateur Linux ?

×

📖 Voir la documentation →