Administrateur systèmes

Mon premier réflexe est de confirmer le périmètre et l'impact avant de toucher à quoi que ce soit : s'agit-il d'un seul service ou de quelque chose de plus large, et combien d'utilisateurs sont touchés. Je publie une mise à jour courte sur notre canal d'incident dans les cinq premières minutes, même si elle se limite à dire que nous investiguons, car le silence est pire qu'un honnête 'nous ne savons pas encore'. Une fois que j'ai une hypothèse de travail, je cherche la mitigation la plus rapide et sûre, souvent un rollback ou un redémarrage de service, plutôt que la correction définitive la plus rapide. Dans mon précédent poste, un pool de connexions à la base de données s'est épuisé pendant un pic lié à une campagne marketing ; j'ai augmenté le pool et redémarré le service concerné pour rétablir l'accès en onze minutes, puis j'ai passé le reste de la journée à identifier la vraie limite à revoir. Après l'incident, je rédige un compte rendu : chronologie, impact, cause racine et le changement précis qui évite que cela se reproduise, et je le partage avec toute l'équipe, pas seulement mon manager.

Je traite les correctifs comme un processus planifié et gradué selon le risque, pas comme quelque chose de réactif. Les correctifs de sécurité critiques, surtout liés à une CVE active, sont testés dans un environnement de préproduction et déployés sous 48 à 72 heures via une fenêtre de changement accélérée. Les correctifs de routine suivent un rythme mensuel : je les teste d'abord sur un groupe pilote de machines non critiques, j'observe pendant quelques jours, puis je déploie sur le reste du parc par lots. Chaque fenêtre de correctifs a un plan de rollback documenté avant même de commencer, jamais improvisé en plein incident. Je maintiens aussi un inventaire précis de ce qui tourne où, car on ne peut pas corriger ce qu'on n'a pas cartographié : un tableur ne suffit pas à grande échelle, donc j'utilise des outils comme WSUS et Ansible pour suivre et automatiser le déploiement. La seule chose sur laquelle je ne transige jamais, c'est désactiver une politique de correctifs pour tenir un délai ; cette dette revient toujours au pire moment.

Je fais passer la maintenance par un système de tickets avec des SLA convenus, pour qu'elle ne soit pas silencieusement reléguée chaque fois que quelqu'un me sollicite directement. Je bloque du temps récurrent chaque semaine pour le travail planifié comme les correctifs, les revues de capacité et le nettoyage, et je protège ce temps comme je protégerais une réunion. Quand une demande urgente arrive, je la trie selon l'impact business réel plutôt que selon l'urgence perçue par la personne qui la formule : une imprimante en panne n'a rien à voir avec un système de paie à l'arrêt. Si une demande doit vraiment passer devant, je le dis ouvertement et je replanifie la maintenance au lieu de l'abandonner discrètement, et je signale à mon manager quand les urgences empiètent trop régulièrement sur le travail planifié, car c'est souvent un signal d'effectif ou de processus, pas quelque chose à simplement absorber.

J'écris la documentation au moment où je construis ou modifie quelque chose, pas comme une tâche à faire plus tard, car les détails sont les plus frais à ce moment-là et le 'plus tard' arrive rarement. Mon exigence est qu'une personne ayant des connaissances générales en administration système, mais sans historique sur ce système précis, puisse suivre la documentation pendant une panne à deux heures du matin. Cela veut dire des schémas clairs de comment les services communiquent entre eux, des commandes exactes plutôt que des descriptions vagues, et une section 'problèmes connus' pour les particularités qui ne sautent pas aux yeux depuis l'architecture. Je conserve la documentation dans un wiki partagé plutôt que dans des notes locales, et je la relis à chaque fois que je touche au système concerné pour qu'elle ne devienne pas obsolète. Dans une équipe précédente, j'ai hérité d'un ensemble de scripts sans aucune documentation ; j'ai passé deux semaines à les décortiquer et à les documenter correctement avant de laisser qui que ce soit s'appuyer dessus, parce qu'une automatisation non documentée est un point de défaillance unique portant mon nom.

Chaque lundi, je vérifiais manuellement l'espace disque, l'état des services et l'expiration des certificats sur une quarantaine de serveurs, ce qui prenait environ deux heures et était exactement le genre de tâche où un oubli fait manquer quelque chose. J'ai écrit un script PowerShell qui récupérait les indicateurs clés de chaque serveur, signalait en rouge tout ce qui sortait des seuils, et envoyait automatiquement un rapport récapitulatif par email à 6h du matin, avant même que je me connecte. Il m'a fallu environ une semaine pour le construire et le tester correctement, y compris gérer les serveurs hors ligne ou injoignables sans faire planter tout le script. Au-delà des deux heures gagnées chaque semaine, il a détecté un certificat à cinq jours de son expiration que j'aurais probablement raté lors d'un passage manuel pendant une semaine chargée. Je l'ai ensuite étendu pour publier des alertes en temps réel sur notre canal Teams au lieu d'attendre le rapport hebdomadaire, ce qui a permis de repérer un problème d'espace disque trois jours avant qu'il ne provoque une panne.

J'ai remarqué que le taux de réussite de nos sauvegardes était discrètement passé de 100 % à environ 92 % sur quelques semaines, sans qu'aucune alerte ne se déclenche car le monitoring ne signalait qu'un job en échec, pas un job réussi avec des avertissements. En creusant dans les logs, j'ai découvert qu'un volume de stockage approchait de sa capacité maximale, ce qui provoquait des sauvegardes tronquées de façon intermittente sur trois serveurs. Si je n'avais pas repéré cela, nous l'aurions découvert le jour où nous aurions eu réellement besoin de restaurer quelque chose, le pire moment possible. J'ai étendu le volume, corrigé les jobs de sauvegarde concernés, puis reconstruit l'alerting pour qu'un statut 'terminé avec avertissements' soit traité comme un signal à examiner, pas comme un succès silencieux. J'ai aussi mis en place un rappel récurrent pour tester la restauration d'une sauvegarde au hasard chaque mois, parce qu'une sauvegarde qu'on n'a jamais testée en restauration n'est pas vraiment une sauvegarde.

Nous avions un problème récurrent de coupure des connexions VPN sur notre pare-feu en cas de forte charge, et après deux tentatives de diagnostic en interne, nous avons ouvert un ticket auprès du support de l'éditeur. J'ai veillé à leur transmettre un dossier propre et précis : horodatages exacts, version de configuration, captures de paquets sur la période concernée, et ce que nous avions déjà écarté, car un ticket vague ne reçoit qu'une réponse vague et fait perdre des jours. Leur premier correctif n'a pas résolu le problème, alors j'ai insisté pour une escalade vers un ingénieur senior, en appuyant ma demande sur les données montrant que le schéma était constant et reproductible, pas ponctuel. Il s'agissait en réalité d'un bug connu sur une version spécifique de firmware. J'ai appliqué leur correctif lors d'une fenêtre de maintenance, en le testant d'abord sous charge simulée, puis j'ai documenté tout l'échange dans notre wiki interne pour que la prochaine personne n'ait pas à reconstituer l'historique du dossier si le problème revient.

Ma base repose sur un mélange d'administration Linux et Windows Server, car la plupart des environnements dans lesquels j'ai travaillé sont hybrides. Côté Windows, je gère Active Directory, les stratégies de groupe, et j'utilise PowerShell pour tout ce qui est répétitif. Côté Linux, je suis à l'aise avec les outils shell classiques, cron, et je passe par la gestion de configuration via Ansible plutôt que de modifier chaque machine à la main, car les changements manuels ne passent pas à l'échelle et sont difficiles à auditer. Pour le monitoring, j'ai utilisé Nagios et Datadog : Nagios pour de l'alerting simple de type up/down et seuils sur une infrastructure que je maîtrise entièrement, Datadog quand j'ai besoin de meilleurs tableaux de bord et d'intégration avec des services cloud. Je travaille aussi avec la virtualisation via VMware et, plus récemment, avec des workloads conteneurisés, ce qui change certaines hypothèses autour des correctifs et du cycle de vie, puisque l'hôte et la couche applicative sont gérés différemment. Je choisis l'outil selon ce dont l'environnement a réellement besoin, pas par réflexe vers ce que je connais le mieux.

Je pars du besoin métier : quel est le temps de reprise et la perte de données acceptables pour chaque système, car c'est cela qui détermine la stratégie de sauvegarde, pas l'inverse. Un serveur de fichiers avec un RPO de 24 heures n'a pas besoin de la même approche qu'une base de données transactionnelle qui ne peut tolérer que quelques minutes de perte. Je combine sauvegardes complètes et incrémentales selon le système, je stocke des copies hors site ou dans une région cloud distincte pour qu'une panne sur un seul site n'emporte pas à la fois la production et sa sauvegarde, et je chiffre tout ce qui contient des données sensibles. Ce que la plupart des équipes négligent, c'est le test des restaurations : je planifie des exercices trimestriels où l'on remonte réellement une sauvegarde dans un environnement isolé et où l'on vérifie qu'elle fonctionne de bout en bout, pas seulement que le job de sauvegarde s'est terminé sans erreur. Cette pratique a permis de détecter une chaîne de sauvegardes corrompue sur un système, six mois avant qu'on en ait réellement besoin pour une restauration réelle.

J'applique le principe du moindre privilège par défaut : les utilisateurs et les comptes de service reçoivent exactement l'accès requis par leur rôle, rien de plus large par simple confort. Les nouvelles demandes d'accès passent par un processus d'approbation documenté avec un approbateur nommé, pas un simple message informel sur Slack, pour garder une traçabilité. Je mène des revues d'accès tous les trimestres, en particulier pour tout ce qui dispose de droits élevés ou administratifs, et je retire l'accès immédiatement dans le cadre du départ d'un collaborateur plutôt que par lots, car un compte qui traîne trois semaines après le départ de quelqu'un est exactement le type de faille exploitée. Pour les comptes partagés ou de service, j'évite les mots de passe statiques quand c'est possible, au profit d'identifiants gérés ou de jetons à courte durée de vie. Je maintiens aussi une séparation claire entre mon compte quotidien et mon compte administrateur, en n'utilisant ce dernier que pour du travail d'administration réel, pour qu'un compte quotidien compromis ne donne pas automatiquement accès aux droits d'administrateur du domaine.