Que signifie pour vous le terme "administrateur système" ou "administrateur système" ? Que fait un administrateur système ? Comment savez-vous que vous en êtes un ?
Des questions existentielles comme celle-ci ont rarement des réponses concrètes, et les réponses qui se présentent peuvent être assez fluides. Les réponses sont également considérablement différentes pour différentes personnes et dépendent de leur expérience professionnelle.
Êtes-vous un administrateur système ?
Dans mon livre, "The Linux Philosophy for SysAdmins , » J'essaie de répondre à la dernière question. J'ai créé cette courte liste pour vous aider à déterminer si vous êtes un administrateur système. Vous êtes peut-être administrateur système si :
- Vous pensez que mes livres pourraient être une lecture amusante.
- Les gens vous demandent souvent de les aider avec leur ordinateur.
- Vous vérifiez les serveurs tous les matins avant de faire quoi que ce soit d'autre.
- Vous écrivez des scripts shell pour automatiser même des tâches simples.
- Vous partagez vos scripts shell.
- Vous autorisez vos scripts shell avec une licence Open Source.
- Vous savez ce que signifie open source.
- Vous documentez tout ce que vous faites.
- Vous avez piraté le routeur sans fil pour installer le logiciel Linux.
- Vous trouvez les ordinateurs avec lesquels il est plus facile d'interagir que la plupart des humains.
- Vous comprenez :(){ :|:&}; :
- Vous pensez que la ligne de commande est amusante.
- Vous aimez avoir le contrôle total.
- Vous êtes root.
- Vous dites toujours "non" lorsque quelqu'un vous demande si quelque chose peut être fait ou non.
- Après discussion et découverte de ce que la personne veut vraiment accomplir, vous savez que cela peut être fait en 30 secondes avec un script shell que vous avez déjà écrit, mais vous lui dites qu'il faudra "quelques jours" avant de pouvoir y arriver ça.
- Vous comprenez la différence entre "libre comme dans la bière" et "libre comme dans la parole" lorsqu'il est appliqué à un logiciel.
- Vous avez installé un ordinateur dans un boîtier rack.
- Vous avez remplacé le ventilateur de refroidissement standard du processeur par un ventilateur qui dissipe plus de chaleur.
- Vous achetez les pièces et construisez vos propres ordinateurs.
- Vous utilisez un refroidissement liquide pour votre CPU.
- Vous installez Linux sur tout ce que vous pouvez.
- Vous avez un Raspberry Pi connecté à votre téléviseur.
- Vous utilisez un Raspberry Pi comme pare-feu pour votre réseau domestique.
- Vous gérez vos propres serveurs de messagerie, DHCP, NTP, NFS, DNS et/ou SSH.
- Vous avez piraté votre ordinateur personnel pour remplacer le processeur par un plus rapide.
- Vous avez mis à jour le BIOS d'un ordinateur.
- Vous laissez les capots de votre ordinateur car vous remplacez fréquemment des composants.
- Le routeur fourni par votre FAI est en mode "pass-through".
- Vous utilisez un ordinateur Linux comme routeur.
Vous avez eu l'idée. Je pourrais énumérer bien d'autres choses qui pourraient faire de vous un administrateur système, mais il y aurait des centaines d'éléments. Je suis sûr que vous pouvez penser à beaucoup d'autres qui s'appliquent à vous.
Cette liste vous concerne en tant que personne qui s'occupe de toutes les tâches d'administration système plutôt qu'une véritable définition. Mais existe-t-il vraiment une définition unique qui convient à tous ? Ma propre expérience montre que les administrateurs système ne peuvent pas être facilement définis.
Mon histoire
J'ai travaillé pour le gouvernement de mon État d'origine pendant environ cinq ans, engagé pour maintenir et réécrire presque complètement un ensemble imbriqué de programmes Perl existants. Environ vingt-cinq de ces programmes s'exécutaient sur un petit ordinateur de bureau Intel. Ces programmes ont généré des pages Web CGI basées sur des données stockées dans des fichiers plats. Ces pages Web constituaient l'interface de gestion du système de messagerie de l'État qui englobait plusieurs grandes agences à l'échelle de l'État. Le système de messagerie lui-même fonctionnait sur plusieurs serveurs Sun Microsystems.
Comme cela a commencé comme un projet pilote, un seul ordinateur a été utilisé pour ma partie du projet. Cet ordinateur était un vieux rebut d'un autre département lorsqu'il a été « offert » au projet et installé sur mon bureau. Il a également servi de mon poste de travail personnel. Je ne me souviens pas des spécifications exactes, mais il avait un processeur Pentium 32 bits d'origine fonctionnant à 33 MHz avec 16 Mo de RAM et deux disques durs. Il exécutait une première version de Red Hat Linux.
Il devenait impossible de maintenir ces programmes pour ajouter de nouvelles fonctions et localiser et corriger les bogues en raison de la complexité du code. Ma tâche consistait à corriger les bogues et à ajouter des fonctionnalités supplémentaires à ces programmes.
Lorsque j'ai commencé à essayer de donner un sens à la complexité du code, il est devenu clair que ma première priorité devait être de simplifier le code. Après avoir abondamment commenté le code et corrigé quelques bogues au fur et à mesure, j'ai commencé à collecter du code qui avait été inséré dans deux ou plusieurs de ces programmes et je les ai rassemblés dans des bibliothèques Perl. Cela facilitait la résolution des problèmes car ils ne devaient être résolus qu'à un seul endroit :la bibliothèque. J'ai redressé d'autres codes, simplifiant les chemins d'exécution courants.
Mais j'étais également responsable de la maintenance des anciens systèmes, à la fois matériels et logiciels. J'ai installé des mises à jour, mis à niveau vers quelques versions plus récentes de Red Hat Linux au fil des ans et résolu un bon nombre de problèmes de configuration Linux causés par un manque de connaissances de la part de l'administrateur précédent. J'ai regardé les journaux et les performances du système en permanence et j'ai apporté des ajustements au réglage aussi souvent que nécessaire.
J'ai également géré la sécurité de cet hébergeur. J'ai fait tout cela avec un seul ordinateur, sans sauvegarde, en direct, en ligne, avec des clients utilisant toujours le site Web. Finalement, nous avons convaincu la direction que nous avions besoin d'un deuxième ordinateur que nous pourrions utiliser pour un environnement de test. C'était des moments amusants.
Grande entreprise
J'ai travaillé environ cinq ans dans une grande entreprise, assez tard dans ma carrière. C'était un travail amusant, en partie parce qu'il comportait deux éléments liés.
Une partie du travail consistait à rédiger des scénarios de test pour les appliances Linux que l'entreprise développait. J'ai utilisé Tcl/Expect, qui s'intégrait bien avec l'infrastructure de test déjà en place. En tant que testeur, j'ai écrit du code une bonne partie du temps, mais j'ai également dû tester la suite de tests, puis exécuter les tests réels.
La deuxième partie de ce travail consistait en tant qu'assistant administrateur de laboratoire pour plusieurs rangées de racks qui constituaient notre laboratoire de test, soit environ la moitié de mon temps. Des équipements de toutes sortes s'y trouvaient, des serveurs Linux 1U aux énormes routeurs couvrant un rack entier et des dizaines d'hôtes Linux et Solaris.
Mes tâches en tant qu'administrateur du laboratoire m'ont amené à commander de nouveaux équipements, à les mettre en rack et à les câbler à leur arrivée, et à installer Linux sur tous les boîtiers Intel. Nous n'avions pas la responsabilité de la gestion du réseau dans le laboratoire, mais les différents départements travaillaient bien ensemble et le groupe réseau nous a fourni une certaine automatisation. Nous avons rempli un formulaire Web demandant une adresse IP à partir de la liste d'adresses statiques gérée par DHCP et une entrée DNS, configurant ces deux éléments immédiatement et nous avons ensuite pu procéder à nos installations Linux.
Pour accélérer l'installation de la configuration spéciale de Red Hat Linux, j'ai écrit un script pour automatiser ce processus. J'en ai parlé dans un article publié dans Linux Magazine en juin 2008. Cet article est désormais disponible sur mon site Web personnel : Complete Kickstart et sur Linux Today.
En utilisant ces procédures développées avec les autres groupes, nous avons pu déballer, monter en rack, câbler et installer Linux sur six à huit nouveaux serveurs en une journée.
J'ai également créé plusieurs sessions de formation Lunch-n-Learn pour aider les autres employés à se familiariser avec Linux.
Silos
Le dernier emploi W-2 que j'ai jamais eu en tant que soi-disant administrateur système a duré environ un an dans une organisation particulière qui constitue un exemple fantastique de l'échec de la méthodologie traditionnelle «d'équipe» poussée à son extrême. Le pire, c'est que c'était aussi un horrible trajet quotidien.
Dans cette organisation, qui restera sans nom, la direction avait créé des silos très étroits, très hauts pour tout contenir.
Il y avait plusieurs équipes, l'équipe Unix, l'équipe d'application, l'équipe réseau, l'équipe matériel, l'équipe DNS, l'équipe rack, l'équipe câble, l'équipe puissance - à peu près n'importe quelle équipe à laquelle vous pouvez penser. Et les procédures étaient ahurissantes. Par exemple, un de mes projets était d'installer Linux sur plusieurs serveurs qui devaient être utilisés pour divers aspects du site Web de l'organisation. La première étape consistait à commander les serveurs, mais la demande a mis des semaines à cheminer dans la bureaucratie administrative.
Une fois les serveurs livrés, l'équipe Unix les rangeait dans le laboratoire d'installation et installait le système d'exploitation. Nous avons eu cette partie très bien. Mais d'abord, nous avons dû demander une adresse IP. Nous ne pouvions pas le faire avant la livraison des serveurs, car la demande d'adresse IP nécessitait les numéros de série des serveurs et les adresses MAC des cartes réseau.
Le problème ici était que chaque silo devait avoir un accord de niveau de service (SLA) avec tous les autres silos et que le temps de réponse défini par le SLA était d'au moins deux semaines. Et chaque silo n'a pas mis moins de temps à répondre que celui spécifié dans le SLA. Cependant, nous ne pouvions pas obtenir l'adresse IP tant qu'un emplacement de rack n'avait pas été attribué dans la salle des serveurs, car les adresses IP étaient attribuées par rack et par emplacement dans le rack. Nous avons donc dû envoyer une demande d'affectation de rack et attendre deux semaines pour que cela soit fourni.
Ainsi, la prochaine étape après avoir obtenu l'adresse IP consistait à l'envoyer au silo qui gérait la configuration DHCP. Ensuite, c'est au moins deux semaines après avoir obtenu l'adresse IP que nous avons dû attendre avant que le DHCP ne soit configuré.
Ce n'est que lorsque les données de configuration réseau du serveur ont été configurées sur le serveur DHCP que la demande de déplacement du serveur de notre rack vers la salle des serveurs peut être envoyée. Un autre délai de deux semaines.
Une fois la demande de déplacement approuvée, et seulement après, nous pouvions alors envoyer une demande d'installation de l'ordinateur dans le rack. Une fois l'installation terminée, nous pouvions envoyer la demande pour câbler le serveur avec le réseau et l'alimentation. Une fois cette opération terminée, nous pouvions envoyer une requête pour allumer le serveur.
Sauf pour l'installation du système d'exploitation, nous ne pouvions pas toucher au serveur. Nous n'étions même pas autorisés à entrer dans la salle des serveurs. Jamais.
Inutile de dire qu'il a fallu des mois pour installer chaque serveur et le faire fonctionner et prêt pour que les équipes de production prennent le relais. Je pourrais continuer sur de nombreuses autres façons dont cet endroit était un désastre fonctionnel, mais je pense que vous avez compris l'idée. Leurs équipes étaient principalement des fiefs politiques protégés par des silos impénétrables.
Travail indépendant et conseil
Au fil des ans, j'ai eu deux entreprises à moi que j'ai utilisées pour la consultation alors que j'étais entre d'autres emplois. Cela a évité des trous dans mon CV qui soulèveraient des questions lors des entretiens. J'ai eu de bons clients pendant cette période et j'ai beaucoup appris.
Dans ce rôle, j'ai pratiquement tout fait, de la planification de nouvelles installations à la formation et à la réalisation de mises à jour. J'ai facturé des frais exorbitants pour passer quelques minutes à réinitialiser le mot de passe root sur certains systèmes Linux dans plus d'un cas. Il semble que les patrons aux cheveux pointus aient tendance à licencier les administrateurs système sans comprendre la nécessité d'une transition en douceur au cours de laquelle ils obtiendraient tous les mots de passe.
Retraite - en quelque sorte
Je suis maintenant soi-disant à la retraite, mais je semble être plus occupé que jamais. J'écris des articles et des livres et j'ai quelques ordinateurs Linux à prendre en charge.
J'ai entretenu de quatre à dix ordinateurs qui m'appartenaient ou appartenaient à l'une de mes entreprises dans mon propre laboratoire à domicile. Bien sûr, ils tournent tous sous Linux. Actuellement, j'ai 12 ordinateurs dans mon laboratoire à la maison, mais cela inclut trois sur lesquels je travaille sur divers projets pour mon église. Je gère également les ordinateurs et le réseau de mon église et de quelques amis que j'ai convaincus d'essayer Linux.
Donc, je suis l'administrateur système pour la plupart de ces ordinateurs, le support matériel et logiciel complet pour les autres. Je dispense également des formations à diverses personnes dans mon rôle actuel.
[ Vous souhaitez en savoir plus sur l'automatisation du système ? Démarrez avec The Automated Enterprise, un livre gratuit de Red Hat. ]
Conclusion
Un administrateur système est beaucoup de choses, parfois toutes en même temps.
Mon expérience a parcouru toute la gamme. Je n'ai jamais eu un travail que je considérerais comme un travail d'administrateur système "pur". Chaque organisation a des besoins uniques, et la plupart du temps, l'administrateur système est "volontaire" pour remplir des rôles jamais mentionnés dans l'entretien ou la description de poste. Les administrateurs système ont généralement les connaissances et les compétences nécessaires pour faire presque tout ce qui est nécessaire. Les personnes avec lesquelles nous travaillons et pour lesquelles nous travaillons le comprennent généralement, c'est pourquoi nous nous chargeons de ces tâches difficiles.
J'aime ça.