Poste
Administrateur systèmes
Que ne savez-vous pas de vos systèmes tant que quelque chose n'a pas cessé de fonctionner ? En général lesquels n'ont pas de sauvegarde valide, lesquels tournent sur une version sans support, et qui sait vraiment les reconstruire de zéro.
Entretien préalable
Quatre questions par lesquelles nous commencerions
Que ne savez-vous pas de vos systèmes tant que rien n'est tombé ?
Le plus souvent : que la sauvegarde tournait depuis des mois mais que personne n'a jamais vérifié si l'on pouvait en restaurer quoi que ce soit. Une sauvegarde non testée n'est pas une sauvegarde, c'est un fichier.
Que laisse derrière lui un administrateur qui quitte l'entreprise ?
Si ce sont des mots de passe et de la documentation, beaucoup. Si ce sont des mots de passe, presque rien, parce que la configuration vivait dans sa tête et est partie avec lui.
Quel type de ticket revient le plus souvent ?
En général deux ou trois, qui se répètent depuis des années et qu'on résout de zéro à chaque fois. Personne ne les a comptés, parce que chacun pris à part ressemble à une broutille.
Où va l'information qu'un serveur se remplit ?
Si elle ne va nulle part, vous l'apprendrez au moment où il cessera d'accepter des données, c'est-à-dire le pire possible.
Nous prenons la surveillance et la routine, vous gardez les décisions sur l'infrastructure
Surveiller l'état, veiller sur les sauvegardes et les mises à jour, tenir la configuration documentée et traiter les tickets répétitifs peuvent être retirés du bureau. Les décisions sur ce qu'il faut changer et quand restent à l'administrateur.
- La sauvegarde est vérifiée, pas seulement effectuée. - Une restauration de test est une activité planifiée, pas quelque chose qu'on fait pour la première fois le jour de la panne.
- L'état d'un système parle de lui-même. - Espace, charge, certificats, versions, avec un signal avant le seuil et non après l'avoir franchi.
- La configuration est écrite hors de la tête de l'administrateur. - Non pour le remplacer, mais pour que ses congés cessent d'être un risque opérationnel.
Périmètre
Ce qui peut être retiré de la maintenance des systèmes
Vingt et une tâches à titre d'exemple. Chacune a un point de validation humaine. Ci-dessous une sélection ; le périmètre, nous l'ajustons à ce que vous exploitez.
État et disponibilité
- Surveillance de la disponibilité des services depuis un seul endroit
- Un signal quand une ressource approche de son seuil
- Signalement des services sans aucune surveillance
- Une alerte sur un certificat qui expire
- Un récapitulatif des pannes par service et par cause
Sauvegardes et restaurations
- Vérification que les sauvegardes se sont exécutées comme prévu
- Un signal quand une sauvegarde ne s'est pas terminée correctement
- Un calendrier de restaurations de test (décision sur le périmètre : l'administrateur)
- Un registre des résultats de restauration
- Signalement des systèmes sans politique de sauvegarde affectée (appréciation : l'administrateur)
Mises à jour et versions
- Un inventaire des systèmes avec versions et dates de fin de support
- Un signal quand une version sort du support de l'éditeur
- Un récapitulatif des mises à jour en attente par gravité
- Une fenêtre de maintenance proposée au regard de la charge (décision : l'administrateur)
Documentation de la configuration
- Une description de la configuration générée depuis l'état du système (vérification : l'administrateur)
- Un registre des changements de configuration avec leur auteur et leur date
- Signalement des systèmes sans aucune documentation
- La procédure de reconstruction d'un système de zéro (contenu : l'administrateur)
Tickets répétitifs
- Un récapitulatif des tickets par type et par fréquence
- Signalement des tickets résolus chaque fois par la même étape
- Une proposition pour supprimer la cause définitivement (décision : l'administrateur)
Une journée de travail
Aujourd'hui
- Vous apprenez qu'un disque est plein quand le service cesse de fonctionner
- Les sauvegardes s'exécutent, mais personne n'a vérifié si l'on peut en restaurer quoi que ce soit
- Vos versions et vos dates de support sont dans un tableur d'il y a un an
- Vous vous souvenez de la configuration, donc elle n'est écrite nulle part
- Vous résolvez une fois de plus le même ticket avec la même étape
- Vous négociez la fenêtre de maintenance par courriel avec plusieurs services
Avec l'assistance de l'IA
- Une ressource qui approche de son seuil s'annonce avant la panne
- Une sauvegarde échouée et le résultat d'une restauration de test se voient tous les deux
- Une version qui sort du support de l'éditeur signale son échéance à l'avance
- La description de la configuration est générée depuis l'état du système et vous la vérifiez
- Les tickets répétitifs sont comptés, donc on voit ce qu'il vaut la peine de supprimer définitivement
- La fenêtre de maintenance est proposée au regard de la charge réelle
- Capacité de reprise après une panne
la sauvegarde est une preuve et non une hypothèse
les restaurations de test sont une activité planifiée
- Versions à jour
moins de systèmes hors du support de l'éditeur
les dates de support figurent à l'inventaire et sont signalées
- Alerte avant les pannes
certaines pannes n'ont tout simplement pas lieu
les seuils des ressources alertent avant d'être franchis
- Connaissance de la configuration
les congés de l'administrateur cessent d'être un risque
la configuration est décrite hors de sa mémoire
Nous commençons par les sauvegardes, parce que c'est le seul domaine où une erreur ne se rattrape pas.
- Étape 1
Sauvegardes et restaurations de test
Vérifier qu'elles s'exécutent, un signal pour la sauvegarde échouée, la première restauration de test. Cela montre en général déjà quels systèmes ne sont pas couverts.
- Étape 2
État et seuils
Disponibilité, espace, charge, certificats, avec alerte avant le seuil.
- Étape 3
L'inventaire des versions
Ce que vous avez, sur quelle version, et jusqu'à quand l'éditeur la supporte.
- Étape 4
Documentation et tickets répétitifs
La description de la configuration depuis l'état du système et le récapitulatif des tickets récurrents. En dernier, parce que cela exige un inventaire en ordre.
Questions fréquentes
Les questions qui reviennent à la première réunion
Cela veut-il dire qu'il faut moins d'administrateurs ?
Dans la plupart des entreprises, un administrateur porte plus qu'il ne devrait, et c'est de là que vient la dette en mises à jour et en sauvegardes. Retirer la surveillance du bureau ne réduit pas l'équipe : cela permet enfin le travail repoussé depuis des mois. En général, il s'avère qu'il y a plus de travail qu'il n'y paraissait, pas moins.
En quoi est-ce différent de ce que fait une équipe plateforme ?
Une équipe plateforme construit la route par laquelle un changement part en production. Un administrateur entretient ce qui s'y trouve déjà. Dans les petites entreprises, la même personne fait les deux, et alors la première perd face à la seconde, parce que la maintenance est toujours plus urgente.
Cela relève-t-il du règlement sur l'IA ?
La maintenance des systèmes n'est pas un usage à haut risque. La limite se situe aux données de journalisation, qui peuvent renvoyer à l'activité de personnes précises : elles servent au diagnostic et à la sécurité, pas à l'évaluation du temps de travail ; les utiliser de la seconde manière serait de la surveillance des salariés et exigerait une base légale distincte.
Une question qui ne figure pas ici ? Réservez un appel
Étape suivante
Quand avez-vous restauré pour la dernière fois quelque chose depuis une sauvegarde ?
Nous vous montrerons à quoi ressemble la maintenance des systèmes quand la sauvegarde est vérifiée et qu'une ressource proche de son seuil parle avant la panne.