Je suis administrateur système chez FirstVDS, et ceci est le texte de ma première introduction à mon bref cours d'aide à mes nouveaux collègues. Les spécialistes qui viennent de commencer à travailler dans l'administration système rencontrent un certain nombre de problèmes communs. Pour offrir des solutions, j'ai décidé d'écrire cette série de conférences. Certaines parties sont spécifiques au support technique d'hébergement, mais dans l'ensemble, elles peuvent s'avérer utiles, si ce n'est pour tous, alors pour beaucoup. J'ai donc adapté le texte de la conférence pour le partager ici.
Peu importe le nom de votre poste — ce qui compte, c'est que vous êtes en réalité impliqué dans l'administration. Commençons donc par ce qu'un administrateur système doit faire. Sa tâche principale consiste à organiser, maintenir l'ordre et se préparer à une augmentation future de cet ordre. Sans administrateur système, le serveur devient rapidement chaotique. Les journaux ne s'écrivent pas, ou ne contiennent pas les bonnes informations, les ressources sont réparties de manière sous-optimale, le disque se remplit de toutes sortes de déchets et le système commence à s'effondrer lentement sous ce poids de chaos. Pas de panique ! Les administrateurs système, comme vous, se mettent à résoudre les problèmes et à rétablir l'ordre !
Les piliers de l'administration système
Cependant, avant de commencer à résoudre les problèmes, il vaut la peine de se familiariser avec les quatre piliers principaux de l'administration :
- Documentation
- Modularisation
- Optimisation
- Automatisation
Ce sont les bases fondamentales. Si vous ne construisez pas votre flux de travail sur ces principes, il sera inefficace, improductif et en général, peu ressemblant à une véritable administration. Analysons chaque point séparément.
Documentation
Documentation Cela implique non seulement lire la documentation (même si c'est indispensable), mais aussi la tenir à jour.
Comment tenir la documentation :
- Vous êtes confronté à un nouveau problème que vous n'avez jamais rencontré auparavant ? Notez les principaux symptômes, les méthodes de diagnostic et les principes de résolution.
- Vous avez trouvé une nouvelle solution élégante à un problème courant ? Notez-la, pour éviter de la réinventer dans un mois.
- On vous a aidé à comprendre un sujet qui vous semblait obscur ? Notez les principaux points et concepts, esquissez un schéma.
L'idée principale : il ne faut pas faire entièrement confiance à sa propre mémoire lors de l'apprentissage et de l'application de nouvelles connaissances.
Le format que vous choisirez dépend entièrement de vous : cela peut être un système de notes, un blog personnel, un fichier texte, un carnet physique. L'essentiel est que vos notes répondent aux exigences suivantes :
- Ne pas être excessivement longues.Mettez en avant les idées principales, les méthodes et les outils. Si la compréhension d'un problème exige de plonger dans les mécanismes bas niveaux de la gestion de la mémoire sous Linux, ne réécrivez pas l'article dont vous vous êtes inspiré — faites simplement un lien vers celui-ci.
- Les notes doivent être compréhensibles pour vous. Si la ligne
race cond.lockupne vous permet pas de comprendre immédiatement ce que vous décrivez par cette ligne — expliquez-le. Une bonne documentation ne doit pas nécessiter de longues recherches. - La recherche est une fonctionnalité très utile. Si vous tenez des notes dans un blog, ajoutez des étiquettes ; si c'est dans un carnet physique, collez des petits post-it avec des descriptions. Il n'y a pas de sens à avoir de la documentation si vous passez autant de temps à y chercher des réponses que vous en passeriez à résoudre le problème depuis le début.
Voici à quoi peut ressembler la documentation : des notes primitives dans un carnet (image ci-dessus), à une base de connaissances multi-utilisateurs complète avec des étiquettes, un moteur de recherche et tout le confort imaginable (en bas).
Vous n'aurez non seulement pas à chercher les mêmes réponses deux fois : la documentation sera un excellent soutien dans l'apprentissage de nouveaux sujets (ce sont des résumés !), affinera votre instinct (la capacité à diagnostiquer un problème complexe d'un simple coup d'œil), et ajoutera de l'organisation à vos actions. Si la documentation est accessible à vos collègues, cela leur permettra de comprendre ce que vous avez fait en votre absence.
La modélisation
La modélisation est la création et l'utilisation de modèles. Pour résoudre la plupart des questions types, il est utile de créer un certain modèle d'action. Pour diagnostiquer la plupart des problèmes, il convient d'utiliser une séquence d'actions standardisée. Lorsque vous avez réparé/installé/optimisé quelque chose, il est important de vérifier son fonctionnement selon des listes de contrôle standardisées.
La modélisation est la meilleure méthode pour organiser le flux de travail. En utilisant des procédures standards pour résoudre les problèmes les plus fréquents, vous obtenez de nombreux avantages. Par exemple, l'utilisation de check-lists vous permettra de diagnostiquer toutes les fonctions importantes pour le travail et d'écarter le diagnostic de la fonctionnalité peu importante. Des procédures standardisées réduiront au minimum les hésitations inutiles et diminueront la probabilité d'erreur.
Le premier point important est que les procédures et les check-lists doivent également être documentées. Si l'on se fie simplement à la mémoire, il est possible de passer à côté d'un contrôle ou d'une opération vraiment importante, ce qui pourrait tout compromettre. Le deuxième point important est que toutes les pratiques standard peuvent et doivent être modifiées si la situation l'exige. Il n'y a pas de modèles parfaits et absolument universels. Si un problème existe et qu'une vérification standard ne l'a pas révélé, cela ne signifie pas qu'il n'y a pas de problème. Cependant, avant de se lancer dans la vérification de problèmes hypothétiques peu probables, il est toujours judicieux de faire d'abord un contrôle standard rapide.
Optimisation
Optimisation parle d'elle-même. Le flux de travail doit être optimisé au maximum en termes de temps et d'efforts. Il existe une multitude d'options : apprenez les raccourcis clavier, les abréviations, les expressions régulières, les outils accessibles. Cherchez des moyens d'utiliser ces outils de manière plus pratique. Si vous invoquez une commande 100 fois par jour, associez-la à un raccourci clavier. Si vous devez régulièrement vous connecter aux mêmes serveurs, enregistrez un alias en un mot qui vous y connectera :
Découvrez les différentes options d'outils disponibles — il se peut qu'il existe un client terminal, un environnement de bureau, un gestionnaire de presse-papiers, un navigateur, un client de messagerie ou un système d'exploitation plus pratique. Renseignez-vous sur les outils utilisés par vos collègues et amis — peut-être les choisissent-ils pour une bonne raison. Une fois que vous aurez sélectionné les outils, apprenez à les utiliser : maîtrisez les clés, les abréviations, les astuces et conseils.
Utilisez de manière optimale les outils standard - coreutils, vim, expressions régulières, bash. Pour les trois derniers, il existe une multitude de manuels et de documentation extraordinaires. Grâce à cela, on peut rapidement passer de l'état « je me sens comme un singe qui casse des noix avec un ordinateur portable » à « je suis un singe qui utilise un ordinateur portable pour commander un casse-noix ».
Automatisation
Automatisation transférera les opérations pesantes de nos mains fatiguées vers les mains infatigables de l'automatisation. Si une procédure standard est réalisée par un ensemble de cinq commandes similaires, pourquoi ne pas regrouper toutes ces commandes dans un fichier et n'appeler qu'une seule commande pour exécuter ce fichier ?
En fait, l'automatisation consiste à 80 % à écrire et optimiser ses propres outils (et à 20 % à tenter de les faire fonctionner correctement). Cela peut être un simple one-liner avancé ou un énorme outil puissant avec une interface web et une API. Le critère principal ici est que la création de l'outil ne doit pas prendre plus de temps et d'efforts que le temps et les efforts que cet outil vous fera économiser. Si vous passez cinq heures à écrire un script qui ne vous sera plus jamais utile pour une tâche que vous auriez pu accomplir sans script en une ou deux heures, c'est une très mauvaise optimisation du flux de travail. On peut consacrer cinq heures à la création d'un outil seulement si le nombre, le type de tâches et le temps le permettent, ce qui est rare.
L'automatisation ne nécessite pas obligatoirement l'écriture de scripts complets. Par exemple, pour créer une multitude d'objets similaires à partir d'une liste, il suffit d'un one-liner astucieux qui fera automatiquement ce que vous feriez manuellement en basculant entre les fenêtres, avec des tas de copier-coller.
En fait, si l'on construit le processus d'administration sur ces quatre piliers, on peut rapidement améliorer son efficacité, sa productivité et ses qualifications. Cependant, cette liste doit être complétée par un point supplémentaire, sans lequel le travail dans l'informatique est pratiquement impossible - l'autoformation.
Autoformation d'un administrateur système
Pour être un peu compétent dans ce domaine, il faut constamment apprendre et découvrir de nouvelles choses. Si vous n'avez aucun désir d'affronter l'inconnu et de comprendre, vous « sombrerez » très rapidement. Dans l'IT, de nouvelles solutions, technologies et méthodes apparaissent sans cesse, et si vous ne les étudiez pas au moins en surface, vous êtes sur la voie de l'échec. De nombreux domaines des technologies de l'information reposent sur des bases complexes et volumineuses. Par exemple, le fonctionnement des réseaux. Les réseaux et Internet sont partout, vous les côtoyez tous les jours, mais il suffit de gratter un peu les technologies qui les sous-tendent pour découvrir une discipline immense et très complexe, dont l'étude n'est pas une promenade dans le parc.
Je n'ai pas inclus ce point dans la liste parce qu'il est clé pour l'informatique en général, et pas seulement pour l'administration système. Naturellement, il n'est pas possible d'apprendre absolument tout d'un coup — vous n'aurez tout simplement pas le temps. Donc, lors de l'auto-apprentissage, il faut garder à l'esprit les niveaux d'abstraction nécessaires.
Vous n'avez pas besoin d'apprendre immédiatement comment fonctionne la gestion interne de la mémoire de chaque outil particulier, et comment elle interagit avec la gestion de la mémoire de Linux, mais savoir schématiquement ce qu'est la mémoire vive et à quoi elle sert est une bonne chose. Vous n'avez pas à connaître les différences structurelles des en-têtes TCP et UDP, mais comprendre les principales différences de fonctionnement des protocoles serait utile. Vous n'avez pas besoin d'étudier ce que sont les atténuations de signal en optique, mais il serait bon de comprendre pourquoi les pertes réelles se propagent toujours par les nœuds. Il n'y a rien de mal à connaître le fonctionnement de certains éléments à un niveau d'abstraction donné, et il n'est pas nécessaire de décortiquer absolument tous les niveaux, surtout quand l'abstraction est inexistante (vous finiriez par devenir fou).
Cependant, dans votre domaine, raisonner à un niveau d'abstraction tel que « c'est un truc qui permet d'afficher des sites » n'est pas très bon. Les prochaines leçons seront consacrées à un aperçu des principaux domaines auxquels un administrateur système est confronté dans son travail à des niveaux d'abstraction plus bas. J'essaierai de limiter le nombre de connaissances à examiner au niveau minimum d'abstraction.
Les 10 commandements de l'administration système
Ainsi, nous avons assimilé quatre piliers fondamentaux. Peut-on commencer à résoudre des problèmes ? Pas encore. Avant cela, il est souhaitable de se familiariser avec ce qu'on appelle les « meilleures pratiques » et les règles de bonne conduite. Sans cela, le risque est de causer plus de dommages que de bénéfices. Commençons donc :
- Certains de mes collègues estiment que la première règle est « ne pas nuire ». Mais je tends à ne pas être d'accord. En essayant de ne pas nuire, on ne peut rien faire — trop d'actions sont potentiellement destructrices. La règle la plus importante, selon moi, est « faites une sauvegarde ». Même si vous causez des dommages, vous pourrez toujours revenir en arrière, et tout ne sera pas si mauvais.
Il est toujours nécessaire de sauvegarder lorsque le temps et l'espace le permettent. Sauvegardez ce que vous êtes sur le point de modifier et ce que vous risquez de perdre lors d'une action potentiellement destructive. Il est préférable de vérifier l'intégrité et la présence de toutes les données nécessaires dans la sauvegarde. Ne supprimez pas la sauvegarde immédiatement après l'avoir vérifiée, sauf si vous devez libérer de l'espace sur le disque. Si l'espace est requis, sauvegardez sur votre serveur personnel et supprimez-la après une semaine.
- La deuxième règle en importance (que je viole moi-même souvent) est « ne cachez pas ». Si vous avez fait une sauvegarde, indiquez où, afin que vos collègues n'aient pas à la chercher. Si vous avez effectué des actions peu évidentes ou complexes, notez-les : vous rentrerez chez vous, et le problème peut se reproduire ou survenir chez quelqu'un d'autre, et votre solution sera retrouvée par des mots-clés. Même si vous faites quelque chose que vous maîtrisez bien, cela peut ne pas être le cas pour vos collègues.
- La troisième règle ne nécessite pas d'explication : « ne jamais faire quelque chose dont vous ne connaissez pas, ne comprenez pas ou n’imaginez pas les conséquences ». Ne copiez pas des commandes sur internet si vous ne savez pas ce qu'elles font, consultez d'abord le manuel. N'appliquez pas des solutions toutes faites si vous ne comprenez pas ce qu'elles font. Réduisez au minimum l'exécution de code obscur. Si vous n'avez pas le temps de comprendre, vous faites quelque chose de mal et vous devriez consulter le point suivant.
- « testez ». Les nouveaux scripts, outils, lignes de commande et commandes doivent être testés dans un environnement contrôlé, et non sur une machine client, s'il existe au moins un potentiel minimal de comportements destructeurs. Même si vous avez tout sauvegardé (et vous l'avez fait), le temps d'arrêt n'est jamais agréable. Créez un serveur/VM/chroot dédié pour cela et testez-y. Rien n'est cassé ? Alors vous pouvez le lancer en production.
- «Contrôlez». Minimisez toutes les opérations que vous ne contrôlez pas. Une dépendance défaillante dans un paquet peut tirer vers le bas toute la moitié du système, et le drapeau -y utilisé pour yum remove vous permet de mettre en pratique vos compétences de récupération du système à partir de zéro. S'il n'y a pas d'alternatives incontrôlées pour l'action — passez au point suivant et à la sauvegarde disponible.
- «Vérifiez». Vérifiez les conséquences de vos actions et si vous devez revenir à une sauvegarde. Vérifiez si le problème a été vraiment résolu. Vérifiez si l'erreur se reproduit et dans quelles conditions. Vérifiez ce que vous pouvez casser par vos actions. Faire confiance dans notre travail est superflu, mais vérifier ne l'est jamais.
- «Communiquez». Si vous n'arrivez pas à résoudre le problème, demandez à vos collègues s'ils ont déjà été confrontés à cela. Si vous souhaitez appliquer une solution discutable, renseignez-vous sur l'avis de vos collègues. Ils pourraient proposer une solution meilleure. Vous n'êtes pas confiant dans vos actions — discutez-en avec vos collègues. Même si c'est votre domaine d'expertise, un regard neuf sur la situation peut éclaircir beaucoup de choses. N'hésitez pas à admettre votre ignorance. Il vaut mieux poser une question stupide, passer pour un imbécile et obtenir une réponse, que de ne pas poser cette question, ne pas recevoir de réponse et rester dans l'ignorance.
- «Ne refusez pas d'aider sans raison». Ce point est l'opposé du précédent. Si on vous pose une question stupide — clarifiez et expliquez. Si on demande l'impossible — expliquez pourquoi il est impossible, et proposez des alternatives. Si vous n'avez pas le temps (réellement pas de temps, pas de volonté) — dites que vous avez une question urgente ou une grande charge de travail, mais que vous vous occuperez de cela plus tard. Si vos collègues n'ont pas de tâches urgentes, proposez de vous adresser à eux et déléguez la question.
- «Faisons le retour». Un collègue a-t-il commencé à appliquer une nouvelle méthode ou un nouveau script, et vous faites face aux conséquences négatives de cette décision ? Faites-en part. Peut-être que le problème se résout en trois lignes de code ou cinq minutes de travail sur la méthode. Vous avez trouvé un bug dans le logiciel ? Signalez le bug. S'il se reproduit ou s'il n'est pas nécessaire de le reproduire, il sera probablement corrigé. Faites part de vos souhaits, suggestions et critiques constructives, soumettez les questions à discussion si vous pensez qu'elles sont pertinentes.
- « Demandez des retours ». Nous ne sommes tous pas parfaits, tout comme nos décisions, et le meilleur moyen de vérifier la validité de sa décision est de la soumettre à discussion. Vous avez optimisé quelque chose pour un client ? Demandez à suivre son fonctionnement, il se peut que le « goulet d'étranglement » du système ne soit pas là où vous cherchiez. Vous avez écrit un petit script d'assistance ? Montrez-le à vos collègues, ils pourraient trouver un moyen de l'améliorer.
Si vous appliquez constamment ces pratiques dans votre travail, la plupart des problèmes cessent d'être des problèmes : vous ne réduirez pas seulement le nombre de vos propres erreurs et faux pas au minimum, mais vous aurez aussi la possibilité de corriger les erreurs (grâce aux sauvegardes et aux collègues qui vous conseilleront de faire une sauvegarde). Ensuite, ce ne sont que des détails techniques où, comme on le sait, se cache le diable.
Les principaux outils avec lesquels vous devrez travailler plus de 50 % du temps sont grep et vim. Quoi de plus simple ? Recherche de texte et édition de texte. Cependant, grep et vim sont des outils multitâches puissants qui permettent de rechercher et d'éditer du texte efficacement. Si un notepad Windows vous permet simplement d'écrire/supprimer une ligne, dans vim, vous pouvez faire presque n'importe quoi avec le texte. Vous ne me croyez pas ? Appelez la commande vimtutor depuis le terminal et commencez à apprendre. En ce qui concerne grep, sa force réside dans les expressions régulières. Oui, l'outil lui-même permet de définir assez flexiblement les conditions de recherche et les données à afficher, mais sans RegExp, cela n'a pas beaucoup de sens. Et il est essentiel de connaître les expressions régulières ! Au moins à un niveau de base. Pour commencer, je vous conseille de visionner cette , il explore les principes fondamentaux des expressions régulières et leur utilisation conjointe avec grep. Ah oui, en les combinant avec vim, vous obtenez le pouvoir ultime de faire des choses avec le texte qu'il faut qualifier de 18+.
Sur les 50% restants, 40% concernent le paquet d'outils coreutils. Pour le liste des coreutils, vous pouvez consulter , et le manuel complet est disponible sur le site . Ce qui n'est pas couvert par cet ensemble se trouve dans les utilitaires . Il n'est pas nécessaire de mémoriser tous les arguments par cœur, mais il est utile de savoir ce que peuvent faire les outils principaux. Vous n'aurez pas à réinventer la roue avec des béquilles. Un jour, j'ai dû remplacer les sauts de ligne par des espaces dans la sortie d'un utilitaire, et mon cerveau fatigué a produit une construction du type sed ':a;N;$!ba;s/n/ /g', mais un collègue compatissant m'a éloigné de la console avec un balai, puis a résolu le problème en écrivant tr 'n' ' '.
Je vous conseillerais de retenir ce que fait chaque outil séparément et les options des commandes les plus couramment utilisées, pour le reste, il y a man. N'hésitez pas à appeler man si vous avez le moindre doute. Et assurez-vous de lire man sur le man lui-même — il contient des informations importantes sur ce que vous trouverez.
En connaissant ces outils, vous serez en mesure de résoudre efficacement une grande partie des tâches auxquelles vous serez confronté dans la pratique. Dans les prochaines leçons, nous examinerons quand utiliser ces outils et les structures des principaux services et applications auxquels ils s'appliquent.
Vous a présenté l'administrateur système de FirstVDS, Kirill Tsvetkov.
Source : habr.com
