Il y a quelques semaines, j'ai parlé avec le vénérable Ken Hess lors de la diffusion en direct « Red Hat Enterprise Linux Presents… ». Le sujet de la discussion était les pratiques générales d'administration des systèmes, et il est devenu clair que Ken et moi avons des opinions très différentes sur ce que c'est.
Ken et moi avons travaillé dans ce que je ne peux décrire que comme l'âge d'or de l'administration des systèmes. À cette époque, les administrateurs fabriquaient avec amour les systèmes qu'ils administraient. Il y avait littéralement une guilde, qui existe encore aujourd'hui :la Guilde des administrateurs système. De plus, pendant cette période, beaucoup de systèmes étaient incroyablement chers. En conséquence, les administrateurs géraient souvent 5 à 20 serveurs. L'un des facteurs était que le matériel de calcul dans l'espace Unix était extrêmement coûteux. Ma station de travail Silicon Graphics Indy, illustrée ci-dessous, coûtait environ 26 000 $ lorsqu'elle était neuve.
À cette époque, nous avions besoin de différentes compétences pour être des administrateurs efficaces, et nous passions beaucoup de temps à effectuer des tâches telles que :
Planification du stockage :Les grands disques durs étaient de 1 Go et les systèmes de fichiers ne prenaient pas en charge des fonctionnalités telles que le redimensionnement. Lors de l'installation d'un système et de la configuration de sa configuration de stockage, le dimensionnement sélectionné pour les différents systèmes de fichiers et leur placement sur le disque étaient importants pour assurer la longévité de la machine. Si vous choisissez mal, vous vous retrouverez des mois plus tard à tout refaire et à restaurer le contenu à partir d'une sauvegarde.
Gestion des logiciels :L'emballage du logiciel était presque inexistant. Généralement, vous téléchargiez une archive source, la compiliez, puis l'installiez sur la machine. Cependant, comme ce logiciel n'était pas fourni, vous, en tant qu'administrateur, devez également le maintenir. Cela consistait à surveiller le projet que vous aviez téléchargé (comme Apache) pour les mises à jour à publier. Une fois qu'ils l'étaient, vous pouviez alors télécharger la version mise à jour, compiler à nouveau et l'installer. Quel plaisir, n'est-ce pas ?
Recompilation du noyau :Si vous aviez de la chance, lorsque vous aviez besoin d'un périphérique supplémentaire sur votre machine, comme une bibliothèque de bandes, un scanner ou un stockage optique, le noyau du système aurait les pilotes pour cela. Cependant, souvent, ce n'était pas le cas. Cela signifiait que vous deviez recompiler votre noyau pour ajouter le pilote ou, encore une fois, si vous aviez de la chance, créer un module de pilote pour le noyau. Quelle belle façon de passer une journée au travail !
Gestion des processus individuels :Ces systèmes n'étaient souvent pas à usage unique. Souvent, vous disposiez d'un système fonctionnant comme un serveur Web pour certaines informations, mais exécutant également des travaux d'analyse de données ou de rendu, fonctionnant comme serveur de messagerie, fournissant des services DNS pour l'organisation et agissant comme un serveur de fichiers. Étant donné que le système faisait tellement de choses, un processus Bind ou un démon Apache incontrôlable pourrait avoir un impact considérable sur votre organisation. Cela signifiait que vous vérifiiez les systèmes et examiniez leurs processus assez fréquemment pour détecter ces problèmes tôt ou écriviez vos propres scripts à exécuter dans cron travaux pour vous informer des problèmes potentiels. Contrairement à la plupart des choses sur lesquelles nous comptons aujourd'hui, nous n'avions pas d'applications de surveillance complètes. Nous avons dû les écrire nous-mêmes.
Gestion des utilisateurs :Parce que les systèmes étaient multifonctions, ils étaient également utilisés par plusieurs personnes qui faisaient des choses différentes. Cela signifiait que différentes personnes avaient besoin d'accéder à différents systèmes. Par conséquent, vous avez également géré des comptes individuels sur l'ensemble de votre flotte de systèmes. Il y avait quelques services utilisateurs centraux, comme NIS, mais à cette époque, il n'y avait pas beaucoup de contrôle sur les systèmes auxquels un utilisateur particulier était autorisé à accéder. Cela signifiait que les utilisateurs pouvaient accéder à n'importe quel système de l'organisation s'ils se trouvaient dans le service utilisateur central. Si vous travailliez dans un endroit moins ouvert que cela, vous devez passer votre temps à utiliser useradd et userdel pour savoir qui a accès à quels systèmes.
[ Les lecteurs ont également apprécié : Carrières d'administrateur système :votre travail d'administrateur système va-t-il disparaître ? ]
De toute évidence, aujourd'hui, nous disposons de nombreuses technologies qui ont rendu ces tâches obsolètes, de la gestion centralisée des utilisateurs et des services de surveillance aux formats d'emballage et à de meilleurs écosystèmes logiciels et matériels. Cela signifie également que nous passons notre temps au travail à effectuer différentes tâches. Toutes ces améliorations apportées à nos ressources technologiques au fil des ans signifient que nous administrons désormais des populations de systèmes beaucoup plus importantes. Si avant c'était l'âge d'or, c'est maintenant l'âge industrialisé de l'administration système. Des populations plus importantes de systèmes et de modèles de déploiement comme le cloud signifient que nous fonctionnons à une vitesse et une efficacité qui auraient été impossibles à l'époque.
Aujourd'hui, je dirais que les compétences qui permettent aux administrateurs d'effectuer des tâches plus efficacement ou à plus grande échelle sont plus essentielles. Des compétences telles que :
Normalisation :Tout à l'heure, j'ai parlé de systèmes qui avaient plusieurs objectifs. Cependant, avoir des systèmes dédiés à un objectif spécifique signifie que vous pouvez tous les administrer ensemble. Si l'on a besoin d'une mise à jour, ils ont probablement tous besoin de cette mise à jour. Si l'on obtient un nouveau paramètre de configuration, ils ont probablement tous besoin de ce paramètre de configuration.
Automatisation :L'automatisation est également essentielle à la normalisation. Si vous découvrez que vous devez appliquer une mise à jour nginx à tous vos serveurs Web, vous avez besoin d'une méthode pour le faire. Qu'il s'agisse de déployer vos propres outils, scripts ou d'utiliser un framework comme Ansible, vous devez disposer d'un moyen efficace et reproductible d'accomplir des tâches sur l'ensemble de vos systèmes.
Surveillance :Avec de plus grandes populations de systèmes à gérer, vous ne pouvez probablement pas tous les vérifier. L'utilisation d'une méthode de surveillance vous permet d'identifier les problèmes plus tôt. La surveillance, lorsqu'elle est associée à la normalisation et à l'automatisation, permet de détecter rapidement et de résoudre ce qui aurait pu être une défaillance en cascade. Par exemple, si l'un de vos serveurs Web dispose d'un espace disque insuffisant sur l'un de ses systèmes de fichiers, nombre de vos systèmes de ce type sont probablement dans un état similaire (mais peut-être pas encore au-delà du seuil d'alerte de surveillance). Vous pouvez utiliser vos utilitaires d'automatisation pour résoudre le problème du système de fichiers et l'appliquer à la population afin d'éviter que des problèmes futurs ne se produisent.
Rapport :Au fur et à mesure que vous obtenez ces populations plus importantes, vous ne pouvez pas les regarder toutes individuellement. Vous devez collecter des données auprès d'eux sur leur configuration, les packages installés et d'autres fonctionnalités. Encore une fois, lorsqu'il est combiné avec l'automatisation et la normalisation, il s'agit d'un outil puissant car vous pouvez faire des choses comme appliquer des mises à jour à de vastes pans de votre population qui en ont besoin. Il est tout aussi important de savoir ce qui se trouve dans cette population. Récemment, on m'a demandé si nous utilisions le logiciel d'un fournisseur spécifique dans notre environnement. Parce que je collecte régulièrement des données sur ce qui est déployé, j'ai pu signaler, en toute confiance, que ce n'était pas le cas. De plus, j'ai fourni des données supplémentaires sur des choses comme quand les systèmes ont eu leur dernière maintenance et des détails sur ce qu'était cette maintenance. Si nécessaire, je peux fournir un historique des actions effectuées sur les systèmes depuis le niveau de la population jusqu'aux boîtes individuelles.
[ Nouvelle étude de HBR Analytic Services – Stratégie des talents informatiques :de nouvelles tactiques pour une nouvelle ère ]
Conclusion
Alors que d'innombrables industries passent de praticiens individuels à petite échelle à des processus industrialisés plus importants, les administrateurs système doivent s'adapter. Comme le titre de l'article l'indique, l'administration système de l'âge d'or est morte, vive l'administration système de l'ère industrielle !