L’administration systèmes, c’est tenir l’infrastructure dans le temps : éviter les pannes quand c’est possible, limiter l’impact quand ça arrive, rendre les systèmes compréhensibles pour l’équipe — et s’améliorer en continu à chaque incident.
Ce que tu sauras faire à la fin
Section intitulée « Ce que tu sauras faire à la fin »Ce module te donne les bases pour ne plus improviser quand quelque chose ne va pas. Concrètement, tu seras capable de :
Opérations quotidiennes :
- Documenter ce qui compte : écrire des procédures claires (appelées runbooks) pour que n’importe qui puisse intervenir à ta place. Exemple : “Le serveur web ne répond plus → voici les 5 étapes à suivre.”
- Réagir avec méthode quand ça casse : un incident à 3h du matin, ça stresse. Avoir une méthode (qui prévenir, par quoi commencer, comment communiquer) évite de paniquer.
- S’améliorer après chaque incident : un problème résolu, c’est bien. Un problème qui ne reviendra plus, c’est mieux. Après chaque incident, on prend 5 minutes pour se demander : “Comment éviter ça la prochaine fois ?”
- Automatiser pour réduire les corvées : chaque tâche répétitive est un candidat à l’automatisation. La règle des 50% : pas plus de la moitié du temps sur les tâches manuelles, le reste pour améliorer la situation.
Sécurité :
- Appliquer les bases de sécurité : qui a accès à quoi ? Les mises à jour sont-elles faites ? Ces deux questions simples évitent 80% des problèmes de sécurité.
Observer et diagnostiquer :
- Surveiller sans te noyer : savoir quels indicateurs regarder (CPU, mémoire, espace disque…) et surtout comprendre ce qu’ils signifient. Une alerte utile, c’est une alerte qui t’aide à agir.
Continuité et résilience :
- Garantir qu’on peut redémarrer : faire des sauvegardes, c’est bien. Savoir les restaurer quand tout est cassé, c’est mieux. On teste avant d’en avoir besoin.
D’admin sys à SRE : comment le métier a évolué
Section intitulée « D’admin sys à SRE : comment le métier a évolué »Le métier d’administrateur système n’est pas né hier. En 50 ans, il s’est transformé radicalement — et comprendre cette évolution aide à situer les pratiques actuelles.
Les années mainframe (1970-1990)
Section intitulée « Les années mainframe (1970-1990) »À l’origine, les « opérateurs » surveillaient des machines monumentales dans des salles climatisées. Un seul ordinateur pour toute l’entreprise, des cartes perforées, et chaque opération était manuelle.
Ce qu’on retenait : fiabilité du matériel, procédures strictes, zéro improvisation.
L’ère des réseaux (1990-2000)
Section intitulée « L’ère des réseaux (1990-2000) »L’arrivée des PC et des réseaux locaux (LAN) change la donne. Au lieu d’un mainframe, l’entreprise déploie des dizaines de machines connectées. L’administrateur doit maîtriser TCP/IP, gérer des utilisateurs, et — nouveauté — penser sécurité face aux premiers virus.
Ce qu’on retenait : interconnexion, gestion des droits, premiers réflexes sécurité.
La révolution virtualisation (2000-2010)
Section intitulée « La révolution virtualisation (2000-2010) »VMware et Hyper-V permettent de faire tourner plusieurs serveurs virtuels sur une seule machine physique. Une application = un serveur physique ? Terminé. L’administrateur ne gère plus seulement du matériel, mais des environnements virtuels.
Les concepts de haute disponibilité et de redondance deviennent essentiels.
Ce qu’on retenait : abstraction du matériel, optimisation des ressources, premiers PRA sérieux.
Cloud et conteneurs (2010-2020)
Section intitulée « Cloud et conteneurs (2010-2020) »AWS, Azure, GCP changent les règles : pourquoi acheter des serveurs quand on peut les louer à la demande ? Docker (2013) et Kubernetes (2014) transforment le déploiement — on empaquète les applications dans des conteneurs légers et portables.
L’administrateur doit maintenant maîtriser :
- L’Infrastructure as Code (IaC) : décrire l’infrastructure dans des fichiers
- Les pipelines CI/CD : automatiser les déploiements
- Les conteneurs et leur orchestration
- Travailler avec les développeurs (mouvement DevOps)
Ce qu’on retenait : automatisation, code, collaboration dev/ops.
L’émergence du SRE (2020+)
Section intitulée « L’émergence du SRE (2020+) »Google formalise en 2016 le concept de Site Reliability Engineering (SRE) : appliquer les principes de l’ingénierie logicielle aux problèmes d’infrastructure.
La pyramide de Dickerson (Hierarchy of Reliability) définit les étapes de maturité :
| Niveau | Ce que ça signifie |
|---|---|
| 1. Monitoring | Savoir ce qui se passe — métriques, logs, alertes |
| 2. Incident Response | Réagir vite et de façon coordonnée aux pannes |
| 3. Postmortem Culture | Apprendre des incidents sans chercher de coupable |
| 4. Testing & Release | Déployer en confiance grâce aux tests et au CI/CD |
| 5. Capacity Planning | Anticiper la charge et dimensionner correctement |
| 6. Product | Intégrer la fiabilité dès la conception du produit |
On ne peut pas sauter d’étapes : sans monitoring solide, impossible de faire de l’incident response efficace. Sans postmortems, on répète les mêmes erreurs.
L’admin sys traditionnel et le SRE ne s’opposent pas — le SRE est une évolution naturelle pour les environnements à grande échelle.
Ce qu’on retient aujourd’hui : construire la fiabilité étape par étape, mesurer, automatiser, apprendre.
Les 4 piliers (la carte mentale)
Section intitulée « Les 4 piliers (la carte mentale) »
Ces 4 piliers couvrent tout ce qu’un administrateur système doit maîtriser. Chaque guide répond à un besoin concret du quotidien.
1) Opérations quotidiennes
Section intitulée « 1) Opérations quotidiennes »Objectif : garder les services disponibles sans improvisation.
C’est le cœur du métier — ce que tu fais tous les jours. L’idée centrale : ne jamais réinventer la roue quand quelque chose tombe en panne à 3h du matin.
- Runbooks : des procédures écrites pour les situations connues. “Le serveur web ne répond plus” → tu ouvres le runbook, tu suis les étapes. Pas de réflexion sous pression.
- Checklists : pour les tâches répétitives (déploiement, mise en prod, ajout de serveur). Tu coches, tu ne rates rien.
- Gestion des incidents : quand ça casse vraiment. Comment qualifier la gravité, qui prévenir, comment coordonner la résolution.
- Postmortems : après l’incident, on analyse. Pas pour punir, mais pour éviter que ça se reproduise.
- Astreintes (on-call) : organiser les rotations, gérer la fatigue, définir les escalades. Qui répond à 3h du matin — et comment éviter l’épuisement.
- Gestion des changements : déployer une modification sans casser la prod. Évaluer le risque, planifier le rollback, tracer ce qui a changé.
- Documentation opérationnelle : au-delà des runbooks — cartographie des services, diagrammes d’architecture, wiki technique. Savoir où chercher.
2) Sécurité
Section intitulée « 2) Sécurité »Objectif : réduire le risque en continu.
La sécurité n’est pas un projet ponctuel — c’est une hygiène quotidienne. Ces trois sujets sont les fondamentaux que tout admin doit maîtriser, même sans être expert sécu.
- Patch management : les failles de sécurité sont publiées tous les jours. Si tu ne patches pas, tu laisses des portes ouvertes. Mais patcher sans méthode, c’est risquer de casser la prod.
- Accès privilégiés : qui a les clés du royaume ? Tracer qui fait quoi avec les comptes root/admin. Sans ça, impossible de savoir qui a fait une erreur (ou une malveillance).
- Baselines & drift : tu configures un serveur “propre”, mais avec le temps il dérive. Des packages s’ajoutent, des configs changent. Détecter ces dérives, c’est prévenir les problèmes.
- Hardening : durcir la configuration par défaut. Désactiver les services inutiles, fermer les ports, appliquer les recommandations CIS. Réduire la surface d’attaque.
- Gestion des secrets : mots de passe, clés API, certificats. Comment les stocker, les distribuer, les renouveler — sans les exposer dans le code ou les logs.
3) Observer et diagnostiquer
Section intitulée « 3) Observer et diagnostiquer »Objectif : comprendre ce qui se passe pour diagnostiquer vite.
Tu ne peux pas réparer ce que tu ne vois pas. L’observabilité, c’est la capacité à comprendre l’état de tes systèmes sans te connecter à chaque machine.
- Observer (vue d’ensemble) : les trois piliers — logs, métriques, traces. Ce qu’il faut collecter au minimum pour ne pas être aveugle.
- Stratégie de logs : tous les logs ne se valent pas. Lesquels garder, combien de temps, comment les exploiter quand tu cherches une aiguille dans une botte de foin.
- Métriques système : CPU, RAM, disque, réseau — les indicateurs de base. Comprendre ce qui est normal pour détecter ce qui ne l’est pas.
- Alerting : une alerte qui sonne tout le temps, personne ne la regarde. Une alerte bien calibrée te réveille uniquement quand c’est nécessaire.
- Tracing distribué : suivre une requête de bout en bout à travers plusieurs services. Indispensable dès que tu as plus d’une application.
- SLI / SLO / Error Budget : le langage commun entre ops et métier. Définir ce qui est “acceptable” en termes de disponibilité et de performance.
4) Continuité et résilience
Section intitulée « 4) Continuité et résilience »Objectif : survivre aux pannes et redémarrer après un gros incident.
Tout casse un jour. La question n’est pas “si” mais “quand”. Ces guides préparent l’après — comment limiter l’impact et redémarrer vite.
- Sauvegardes & restauration : faire des backups, c’est facile. Restaurer sous pression quand tout est cassé, c’est autre chose. Le guide insiste sur les tests de restauration.
- PRA / PCA : Plan de Reprise d’Activité, Plan de Continuité. Que faire si le datacenter brûle ? Si un ransomware chiffre tout ? Ces scénarios se préparent à froid.
- Haute disponibilité : éliminer les points de défaillance unique (SPOF). Si un serveur tombe, un autre prend le relais automatiquement.
- Capacity planning : anticiper la croissance. Quand ajouter des ressources avant que ça casse ? Comment prévoir la charge des 6 prochains mois ?
- Tests de résilience : game days, exercices de bascule, chaos engineering light. Tester que le PRA fonctionne vraiment — avant d’en avoir besoin.
Ta première mission (choisis-en une)
Section intitulée « Ta première mission (choisis-en une) »Pour débuter, l’idée n’est pas de tout apprendre. Choisis une mission simple et fais-la bien :
-
Mission A — “Je rends l’exploitation plus sûre” → écrire 1 runbook + 1 checklist + 1 procédure de rollback
-
Mission B — “Je réduis le risque sécurité” → définir une cadence de patching + tracer les exceptions
-
Mission C — “Je rends les pannes moins douloureuses” → mettre en place des sauvegardes + faire un test de restauration documenté
Ces missions te forcent à apprendre la technique au bon moment, dans un contexte clair.
À retenir
Section intitulée « À retenir »- Le métier se comprend d’abord par le run : routines, incidents, changements, preuves.
- La technique vient ensuite, au service d’un objectif.
- L’amélioration continue est le moteur : chaque incident est une occasion d’apprendre. Un bon admin ne fait pas deux fois la même erreur — il documente, il automatise, il partage.
- Ce module te donne une progression : piliers → missions → mise en pratique → retour d’expérience → amélioration.