Systèmes et annuaires : identité, serveurs, sauvegardes

L’administration système consiste à maintenir les machines, les comptes et les données dans un état où l’entreprise a le droit de les oublier. Cela couvre l’identité, les serveurs qui la portent, la supervision qui signale qu’une chose a bougé, et les sauvegardes qui décident de la gravité d’une mauvaise journée. Acheter les pièces est simple. Les exploiter ensemble est la discipline.

Pensez à un immeuble plutôt qu’à une baie. Il y a un accueil qui sait qui travaille ici et quelles portes s’ouvrent avec quel badge ; tout le reste de l’immeuble fait confiance à cet accueil. Il y a des machines au sous-sol qui fournissent chaleur et eau : ennuyeuses jusqu’à la panne. Il y a un gardien qui relève les compteurs chaque matin et remarque un chiffre qui monte avant que quiconque sente la fumée. Et il y a un escalier de secours dont personne ne se sert pendant des années et dont tout le monde a besoin en même temps : il vaut exactement la dernière vérification qu’il s’ouvre.

Ce guide est la carte. Chaque section dit ce que fait une partie de l’infrastructure, où elle échoue sur le terrain et où aller plus loin. Deux parties ont déjà leur propre article : la supervision et les alertes pour décider quoi regarder, et la règle 3-2-1 pour l’escalier de secours.

L’annuaire est le sol sur lequel tout repose

Un annuaire répond pour tous les autres systèmes à une seule question : qui est cette personne et qu’a-t-elle le droit de faire. Quand il existe, une salariée s’authentifie une fois et atteint le partage, l’imprimante et l’application métier sans qu’aucun des trois ne tienne sa propre liste d’utilisateurs. Quand il manque, ils la tiennent, et les listes se contredisent en un mois.

Le coût n’apparaît qu’au départ de quelqu’un. Avec une identité centrale, désactiver un compte met fin à l’accès partout au même instant. Sans elle, l’accès s’arrête là où l’on a pensé à regarder, ce qui n’est jamais partout, et les comptes oubliés sont ceux qui réapparaissent deux ans plus tard dans un rapport d’incident.

Deux dépendances restent invisibles et expliquent la plupart des pannes. La première est la résolution de noms : les membres du domaine trouvent leurs contrôleurs par DNS, pas par adresse. Un poste pointé vers un résolveur public interroge le mauvais serveur et signale le résultat comme un problème d’ouverture de session, de stratégie ou de partage. La seconde est l’horloge : si elle dérive trop, les tickets sont refusés, et aucun message ne mentionne le temps.

Les serveurs en dessous

La plupart des petites infrastructures sont mixtes, et la répartition suit la charge, pas la préférence. Identité, stratégies de groupe, services de fichiers et applications Windows vivent sur Windows Server. Supervision, collecte de journaux, proxys et la majeure partie de l’infrastructure libre vivent sur Linux, où ils coûtent moins cher à exploiter et s’automatisent plus facilement. Les deux sont normaux ; ce qui ne l’est pas, c’est d’exploiter l’un ou l’autre sans une personne nommée qui applique les correctifs.

Une remarque sur la virtualisation, parce qu’elle est sous tout le reste : presque toute charge d’une petite infrastructure a sa place sur un hyperviseur plutôt que sur son propre matériel. Les exceptions forment une courte liste et non un pourcentage — travail à forte composante GPU, traitement média spécialisé, licences ancrées au matériel, et exigences de latence assez strictes pour figurer dans un contrat. Si aucune de ces quatre n’est sur la table, la discussion est tranchée en faveur de la virtualisation.

Regarder : des chiffres et des événements

La supervision n’est pas un outil que l’on installe, c’est une décision sur ce que vous devez savoir et à quelle vitesse. Cette décision vient en premier et prend plus de temps que l’installation : c’est pourquoi la supervision et les alertes la traite séparément.

La forme des données compte. Les chiffres viennent d’interrogations à intervalle régulier et donnent des courbes ; les courbes montrent des tendances, comme ce lien montant qui frôle sa limite chaque après-midi depuis trois semaines. Les événements arrivent au moment où ils se produisent et montrent des instants : un port tombé, une authentification échouée, une configuration modifiée à 02:14. Une infrastructure qui ne collecte que l’un des deux cache la moitié de chaque incident, et souvent la moitié qui explique l’autre.

Une règle inconfortable garde l’ensemble utile : une alerte sur laquelle personne n’agit doit être supprimée ou rétrogradée en courbe. Les alertes sans conséquence apprennent aux gens à ignorer le canal, et un canal ignoré est pire que pas de canal, parce qu’il ressemble à une couverture.

Garder ce que vous exploitez

Les sauvegardes sont l’escalier de secours, et la seule question qui compte est de savoir s’il s’ouvre. Un travail de sauvegarde qui annonce un succès prouve que des données ont été écrites. Il ne prouve pas qu’elles reviennent. Seule une restauration le prouve.

La règle 3-2-1 est la forme de départ : trois copies, deux types de supports, une hors site. Elle a bien vieilli parce que chaque chiffre répond à une défaillance différente — la suppression, le support et le bâtiment. Face aux rançongiciels, deux termes se sont ajoutés : une copie qui ne peut plus être modifiée une fois écrite, et zéro erreur lors d’un test de restauration ayant laissé une preuve.

La conservation appartient à la même conversation et, au regard du RGPD, elle n’est pas facultative. Sauvegardes et journaux contenant des données personnelles demandent une durée définie, écrite et appliquée. Tout garder indéfiniment donne un sentiment de sécurité et produit l’inverse : cela agrandit la surface de tout incident et ne s’explique à personne qui demande pourquoi la boîte aux lettres d’une personne partie depuis quatre ans existe encore.

Ce qui tombe réellement en panne

Quatre schémas expliquent la plupart des pannes dans des infrastructures de cette taille, et aucun n’est exotique.

La dérive d’horloge. Kerberos refuse les tickets trop décalés, et aucun message ne nomme l’heure. Une source de temps faisant autorité, et tous les équipements pointés dessus.

Une machine pour trois rôles. L’hôte qui porte le contrôleur de domaine, le partage de fichiers et la cible de sauvegarde est un point de défaillance unique qui n’a jamais été décidé, seulement accumulé.

Personne de nommé. Correctifs, vérification des sauvegardes et expiration des certificats échouent non par désaccord mais par absence de responsable. Chaque tâche récurrente a besoin d’un nom, pas d’une équipe.

Une restauration jamais testée. C’est la panne qui transforme un incident en crise, et la moins chère à éviter. Un test coûte un après-midi.

Conclusion : l’exploitation est une habitude, pas un achat

Chaque section de ce guide décrit de l’entretien, pas de la construction. L’annuaire n’est pas terminé quand il est installé ; il est juste tant que les comptes disparaissent au départ des personnes. La supervision n’est pas terminée quand les courbes apparaissent ; elle est utile tant que quelqu’un les lit. Les sauvegardes ne sont pas terminées quand le travail passe au vert ; elles sont réelles tant qu’une restauration a été testée assez récemment pour qu’on y croie.

• Identité : désactiver un compte met fin à l’accès partout, et vous pouvez le démontrer.
• Résolution de noms : chaque membre du domaine interroge des serveurs internes, avec des redirecteurs choisis.
• Temps : une source, tous les équipements pointés dessus.
• Serveurs : chacun a une personne nommée et une note sur ce qui dépend de lui.
• Supervision : chaque alerte a un responsable, et celles qui se déclenchent donnent lieu à une action.
• Sauvegarde : trois copies, deux supports, une hors site, une immuable, et un test de restauration daté avec preuve.