Je suis administrateur système FirstVDS, et voici le texte de la première conférence d'introduction de mon cours de courte durée sur l'aide aux collègues novices. Les spécialistes qui ont récemment commencé à s'engager dans l'administration système sont confrontés à un certain nombre des mêmes problèmes. Pour proposer des solutions, j'ai entrepris d'écrire cette série de conférences. Certaines choses qu'il contient sont spécifiques à l'hébergement du support technique, mais en général, elles peuvent être utiles, sinon pour tout le monde, du moins 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 soyez effectivement impliqué dans l'administration. Par conséquent, commençons par ce qu'un administrateur système doit faire. Sa tâche principale est de mettre de l'ordre, de maintenir l'ordre et de préparer les futures augmentations d'ordre. Sans administrateur système, le serveur devient un véritable désastre. Les journaux ne sont pas écrits, ou des éléments erronés y sont écrits, les ressources ne sont pas distribuées de manière optimale, le disque est rempli de toutes sortes de déchets et le système commence à mourir lentement à cause de tant de chaos. Calmement! Les administrateurs système en votre personne commencent à résoudre les problèmes et à éliminer le désordre !
Piliers de l’administration système
Cependant, avant de commencer à résoudre des problèmes, il convient de se familiariser avec les quatre principaux piliers de l'administration :
- Documentation
- Modèles
- Optimisation
- Automatisation
C'est la base. Si vous ne construisez pas votre flux de travail sur ces principes, il sera inefficace, improductif et ne ressemblera généralement guère à une véritable administration. Examinons chacun séparément.
Documentation
Documentation ne signifie pas lire la documentation (même si on ne peut pas s'en passer), mais aussi la maintenir.
Comment conserver la documentation :
- Avez-vous rencontré un nouveau problème que vous n’avez jamais vu auparavant ? Notez les principaux symptômes, les méthodes de diagnostic et les principes d'élimination.
- Avez-vous trouvé une solution nouvelle et élégante à un problème courant ? Notez-le pour ne pas avoir à le réinventer dans un mois.
- Vous ont-ils aidé à comprendre une question que vous n'avez pas comprise ? Notez les principaux points et concepts, dessinez vous-même un schéma.
L'idée principale : il ne faut pas se fier entièrement à sa propre mémoire pour maîtriser et appliquer de nouvelles choses.
Le format dans lequel vous ferez cela dépend de vous : il peut s'agir d'un système avec des notes, d'un blog personnel, d'un fichier texte, d'un bloc-notes physique. L'essentiel est que vos dossiers répondent aux exigences suivantes :
- Ne sois pas trop long. Mettez en évidence les principales idées, méthodes et outils. Si la compréhension d'un problème nécessite de plonger dans les mécanismes de bas niveau de l'allocation de mémoire sous Linux, ne réécrivez pas l'article dans lequel vous l'avez appris - fournissez un lien vers celui-ci.
- Les entrées doivent être claires pour vous. Si la ligne
race cond.lockupne vous permet pas de comprendre immédiatement ce que vous avez décrit avec cette ligne - expliquez. Une bonne documentation ne prend pas une demi-heure à comprendre. - La recherche est une très bonne fonctionnalité. Si vous écrivez des articles de blog, ajoutez des balises ; si vous êtes dans un cahier physique, collez des petits post-its avec des descriptions. La documentation ne sert à rien si vous passez autant de temps à y chercher une réponse que vous en auriez passé à résoudre la question à partir de zéro.
Voici à quoi peut ressembler la documentation : des notes primitives dans un bloc-notes (image ci-dessus) à une base de connaissances multi-utilisateurs à part entière avec balises, recherche et toutes les commodités possibles (ci-dessous).
Non seulement vous n'aurez pas à chercher deux fois les mêmes réponses, mais la documentation sera d'une grande aide pour apprendre de nouveaux sujets (notes !), améliorera votre sens de l'araignée (la capacité de diagnostiquer un problème complexe d'un seul coup d'œil superficiel), et ajoutera de l'organisation à vos actions. Si la documentation est à la disposition de vos collègues, elle leur permettra de comprendre ce que vous avez entassé là et comment lorsque vous n'êtes pas là.
Modèles
Modèles est la création et l'utilisation de modèles. Pour résoudre les problèmes les plus courants, il vaut la peine de créer un modèle d'action spécifique. Une séquence standardisée d’étapes doit être utilisée pour diagnostiquer la plupart des problèmes. Lorsque vous avez réparé/installé/optimisé quelque chose, les performances de ce quelque chose doivent être vérifiées à l'aide de listes de contrôle standardisées.
Les modèles sont le meilleur moyen d’organiser votre flux de travail. En utilisant des procédures standard pour résoudre les problèmes les plus courants, vous obtenez beaucoup de choses intéressantes. Par exemple, l'utilisation de listes de contrôle vous permettra de diagnostiquer toutes les fonctions importantes pour votre travail et d'écarter le diagnostic des fonctionnalités sans importance. Et des procédures standardisées minimiseront les lancers inutiles et réduiront le risque d’erreur.
Le premier point important est que les procédures et les listes de contrôle doivent également être documentées. Si vous comptez uniquement sur la mémoire, vous risquez de manquer une vérification ou une opération très importante et de tout gâcher. Le deuxième point important est que toutes les pratiques de modèles peuvent et doivent être modifiées si la situation l'exige. Il n'existe pas de modèles idéaux et absolument universels. S'il y a un problème, mais qu'une vérification du modèle ne l'a pas révélé, cela ne signifie pas qu'il n'y a pas de problème. Cependant, avant de commencer à tester des problèmes hypothétiques improbables, il vaut toujours la peine de faire d’abord un test rapide du modèle.
Optimisation
Optimisation parle de lui-même. Le processus de travail doit être optimisé autant que possible en termes de temps et de coûts de main-d'œuvre. Les options sont innombrables : apprendre les raccourcis clavier, les abréviations, les expressions régulières, les outils disponibles. Recherchez des utilisations plus pratiques de ces outils. Si vous appelez une commande 100 fois par jour, attribuez-la à un raccourci clavier. Si vous avez besoin de vous connecter régulièrement aux mêmes serveurs, écrivez un alias en un mot qui vous y connectera :
Familiarisez-vous avec les différentes options disponibles pour les outils - il existe peut-être un client de terminal plus pratique, DE, un gestionnaire de presse-papiers, un navigateur, un client de messagerie, un système d'exploitation. Découvrez quels outils vos collègues et amis utilisent - peut-être qu'ils les choisissent pour une raison. Une fois que vous avez les outils, apprenez à les utiliser : apprenez les clés, les abréviations, les trucs et astuces.
Utilisez de manière optimale les outils standards - coreutils, vim, expressions régulières, bash. Pour les trois derniers, il existe un grand nombre de merveilleux manuels et documentations. Avec leur aide, vous pouvez rapidement passer de l’état de « Je me sens comme un singe qui casse des noix avec un ordinateur portable » à « Je suis un singe qui utilise un ordinateur portable pour me commander un casse-noix ».
Automation
Automation transférera les opérations difficiles de nos mains fatiguées aux mains infatigables de l’automatisation. Si une procédure standard est exécutée dans cinq commandes du même type, alors pourquoi ne pas regrouper toutes ces commandes dans un seul fichier et appeler une commande qui télécharge et exécute ce fichier ?
L'automatisation elle-même consiste à écrire et à optimiser à 80 % vos propres outils (et à 20 % supplémentaires à essayer de les faire fonctionner comme ils le devraient). Il peut s'agir simplement d'un simple outil avancé ou d'un énorme outil omnipotent doté d'une interface Web et d'une API. Le critère principal ici est que la création d’un outil ne devrait pas prendre plus de temps et d’efforts que le temps et les efforts que l’outil vous fera gagner. Si vous passez cinq heures à écrire un script dont vous n'aurez plus jamais besoin, pour une tâche qui vous aurait pris une heure ou deux à résoudre sans le script, il s'agit d'une très mauvaise optimisation du flux de travail. On peut passer cinq heures à créer un outil seulement si le nombre, le type de tâches et le temps le permettent, ce qui n'est pas souvent le cas.
L'automatisation ne signifie pas nécessairement l'écriture de scripts à part entière. Par exemple, pour créer un tas d'objets du même type à partir d'une liste, tout ce dont vous avez besoin est un one-liner intelligent qui fera automatiquement ce que vous feriez à la main, en passant d'une fenêtre à l'autre, avec des tas de copier-coller.
En fait, si vous construisez le processus administratif sur ces quatre piliers, vous pouvez rapidement augmenter votre efficacité, votre productivité et vos qualifications. Cependant, cette liste doit être complétée par un élément supplémentaire, sans lequel travailler dans l'informatique est presque impossible : l'auto-éducation.
Auto-formation d'administrateur système
Pour être ne serait-ce qu'un peu compétent dans ce domaine, vous devez constamment étudier et apprendre de nouvelles choses. Si vous n’avez pas la moindre envie d’affronter l’inconnu et de le découvrir, vous vous retrouverez très vite coincé. Toutes sortes de nouvelles solutions, technologies et méthodes apparaissent constamment dans l'informatique, et si vous ne les étudiez pas au moins superficiellement, vous êtes sur la voie de l'échec. De nombreux domaines des technologies de l’information reposent sur une base très complexe et volumineuse. Par exemple, l'exploitation du réseau. Les réseaux et Internet sont partout, vous les rencontrez tous les jours, mais une fois que vous aurez exploré la technologie qui les sous-tend, vous découvrirez une discipline immense et très complexe, dont l'étude n'est jamais une promenade de santé.
Je n'ai pas inclus cet élément dans la liste car il est essentiel pour l'informatique en général, et pas seulement pour l'administration système. Naturellement, vous ne pourrez pas absolument tout apprendre tout de suite : vous n’avez tout simplement pas suffisamment de temps physiquement. Par conséquent, lorsque vous vous éduquez, vous devez vous rappeler les niveaux d’abstraction nécessaires.
Vous n'avez pas besoin d'apprendre immédiatement comment fonctionne la gestion de la mémoire interne de chaque utilitaire individuel et comment elle interagit avec la gestion de la mémoire Linux, mais il est bon de savoir ce qu'est schématiquement la RAM et pourquoi elle est nécessaire. Vous n'avez pas besoin de savoir en quoi les en-têtes TCP et UDP sont structurellement différents, mais ce serait une bonne idée de comprendre les différences fondamentales dans le fonctionnement des protocoles. Vous n'avez pas besoin d'apprendre ce qu'est l'atténuation du signal en optique, mais il serait bien de savoir pourquoi les pertes réelles sont toujours héritées entre les nœuds. Il n'y a rien de mal à savoir comment certains éléments fonctionnent à un certain niveau d'abstraction et à ne pas nécessairement comprendre absolument tous les niveaux lorsqu'il n'y a pas d'abstraction du tout (vous deviendrez fou).
Cependant, dans votre domaine, penser au niveau de l'abstraction « eh bien, c'est une chose qui vous permet d'afficher des sites Web » n'est pas très bon. Les conférences suivantes seront consacrées à un aperçu des principaux domaines qu'un administrateur système doit traiter lorsqu'il travaille à des niveaux d'abstraction inférieurs. J'essaierai de limiter la quantité de connaissances examinées à un niveau minimum d'abstraction.
10 commandements de l'administration système
Nous avons donc appris les quatre principaux piliers et fondements. Pouvons-nous commencer à résoudre les problèmes ? Pas encore. Avant de procéder, il est conseillé de se familiariser avec les soi-disant « bonnes pratiques » et les règles de savoir-vivre. Sans eux, vous risquez de faire plus de mal que de bien. Alors commençons :
- Certains de mes collègues pensent que la toute première règle est « ne pas nuire ». Mais je suis enclin à ne pas être d'accord. Lorsque vous essayez de ne pas nuire, vous ne pouvez rien faire : trop d’actions sont potentiellement destructrices. Je pense que la règle la plus importante est... "faire une sauvegarde". Même si vous faites des dégâts, vous pouvez toujours revenir en arrière et tout ne sera pas si grave.
Vous devez toujours effectuer une sauvegarde lorsque le temps et le lieu le permettent. Vous devez sauvegarder ce que vous allez modifier et ce que vous risquez de perdre à cause d'une action potentiellement destructrice. Il est conseillé de vérifier l'intégrité de la sauvegarde et la présence de toutes les données nécessaires. La sauvegarde ne doit pas être supprimée immédiatement après avoir tout vérifié, sauf si vous avez besoin de libérer de l'espace disque. Si l'emplacement l'exige, sauvegardez-le sur votre serveur personnel et supprimez-le après une semaine.
- La deuxième règle la plus importante (que j'enfreins moi-même souvent) est "ne te cache pas". Si vous avez fait une sauvegarde, écrivez où, afin que vos collègues n'aient pas à la chercher. Si vous avez réalisé des actions non évidentes ou complexes, notez-les : vous rentrerez chez vous, et le problème pourra se répéter ou survenir pour quelqu'un d'autre, et votre solution sera trouvée à l'aide de mots-clés. Même si vous faites quelque chose que vous connaissez bien, ce ne sera peut-être pas le cas de vos collègues.
- La troisième règle n’a pas besoin d’être expliquée : « Ne faites jamais quelque chose dont vous ne connaissez pas, n’imaginez ou ne comprenez pas les conséquences ». Ne copiez pas les commandes d'Internet si vous ne savez pas ce qu'elles font, appelez man et analysez-les d'abord. N'utilisez pas de solutions toutes faites si vous ne comprenez pas ce qu'elles font. Limitez au minimum absolu l’exécution de code obscurci. Si vous n’avez pas le temps de le comprendre, alors vous faites quelque chose de mal et vous devriez lire le point suivant.
- "Test". Les nouveaux scripts, outils, one-liners et commandes doivent être testés dans un environnement contrôlé, et non sur la machine client, s'il existe un risque minime d'actions destructrices. Même si vous avez tout sauvegardé (et vous l’avez fait), les temps d’arrêt ne sont pas la chose la plus cool. Créez un serveur/virtuel/chroot distinct pour cela et testez-y. Quelque chose est cassé ? Ensuite vous pourrez le lancer en « combat ».
- "Contrôle". Minimisez toutes les opérations que vous ne contrôlez pas. Une courbe de dépendance d'un package peut entraîner la moitié du système vers le bas, et l'indicateur -y défini pour yum Remove vous donne la possibilité de mettre en pratique vos compétences en matière de récupération du système à partir de zéro. Si l'action n'a pas d'alternatives incontrôlées, le point suivant est une sauvegarde prête à l'emploi.
- "Vérifier". Vérifiez les conséquences de vos actions et si vous devez revenir à une sauvegarde. Vérifiez si le problème a vraiment été résolu. Vérifiez si l'erreur se reproduit et dans quelles conditions. Vérifiez ce que vous pouvez rompre avec vos actions. Il n’est pas nécessaire de faire confiance à notre travail, mais jamais de le vérifier.
- "Communiquer". Si vous ne parvenez pas à résoudre le problème, demandez à vos collègues s'ils ont rencontré ce problème. Si vous souhaitez appliquer une décision controversée, renseignez-vous sur l'avis de vos collègues. Peut-être qu'ils proposeront une meilleure solution. Si vous n'avez pas confiance en vos actions, discutez-en avec vos collègues. Même s’il s’agit de votre domaine d’expertise, un nouveau regard sur la situation peut clarifier beaucoup de choses. N'ayez pas honte de votre propre ignorance. Il vaut mieux poser une question stupide, passer pour un imbécile et obtenir une réponse, que ne pas poser la question, ne pas obtenir de réponse et finir par être un imbécile.
- "Ne refusez pas l'aide de manière déraisonnable". Ce point est l’inverse du précédent. Si on vous pose une question stupide, clarifiez et expliquez. Ils demandent l’impossible – expliquent que c’est impossible et pourquoi, proposent des alternatives. Si vous n'avez pas le temps (vous n'avez vraiment pas le temps, pas l'envie) - dites que vous avez une question urgente, beaucoup de travail, mais que vous la réglerez plus tard. Si vos collègues n'ont pas de tâches urgentes, proposez de les contacter et déléguez la question.
- "Donner votre avis". L’un de vos collègues a commencé à utiliser une nouvelle technique ou un nouveau script, et rencontrez-vous des conséquences négatives de cette décision ? Signalez-le. Peut-être que le problème peut être résolu en trois lignes de code ou en cinq minutes de perfectionnement de la technique. Vous avez rencontré un bug dans votre logiciel ? Signaler un bug. S’il est reproductible ou n’a pas besoin d’être reproduit, il sera très probablement corrigé. Exprimez vos souhaits, suggestions et critiques constructives, et soumettez des questions de discussion si elles semblent pertinentes.
- "Demander des commentaires". Nous sommes tous imparfaits, tout comme nos décisions, et la meilleure façon de tester la justesse de votre décision est d’en discuter. Si vous avez optimisé quelque chose pour un client, demandez-lui de surveiller le travail ; peut-être que le goulot d'étranglement dans le système n'est pas celui que vous recherchiez. Vous avez écrit un script d'aide : montrez-le à vos collègues, ils trouveront peut-être un moyen de l'améliorer.
Si vous appliquez constamment ces pratiques dans votre travail, la plupart des problèmes cesseront d'être des problèmes : vous réduirez non seulement le nombre de vos propres erreurs et falsifications au minimum, mais vous aurez également la possibilité de corriger les erreurs (dans le forme de sauvegardes et des collègues qui vous conseilleront de sauvegarder). De plus, uniquement des détails techniques dans lesquels, comme nous le savons, 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 tous deux de puissants outils multifonctions qui vous permettent de rechercher et de modifier du texte efficacement. Si certains bloc-notes Windows vous permettent simplement d'écrire/supprimer une ligne, alors dans vim, vous pouvez presque tout faire avec du texte. Si vous ne me croyez pas, appelez la commande vimtutor depuis le terminal et commencez à apprendre. Quant à grep, sa principale force réside dans les expressions régulières. Oui, l'outil lui-même vous permet de définir les conditions de recherche et de générer des données de manière assez flexible, mais sans RegExp, cela n'a pas beaucoup de sens. Et vous devez connaître les expressions régulières ! Au moins à un niveau basique. Pour commencer, je vous conseille de regarder ceci , il couvre les bases des expressions régulières et leur utilisation en conjonction avec grep. Oh oui, lorsque vous les combinez avec vim, vous obtenez la capacité ULTIMATE POWER de faire des choses avec du texte que vous devez étiqueter avec plus de 18 icônes.
Sur les 50 % restants, 40 % proviennent de la boîte à outils coreutils. Pour les coreutils, vous pouvez consulter la liste sur , et le manuel de la liste complète est sur le site Web . Ce qui n'est pas couvert dans cet ensemble se trouve dans les utilitaires . Vous n'êtes pas obligé d'apprendre toutes les clés par cœur, mais il est utile de savoir au moins approximativement ce que les outils de base peuvent faire. Vous n'avez pas besoin de réinventer la roue avec des béquilles. D'une manière ou d'une autre, j'avais besoin de remplacer les sauts de ligne par des espaces dans la sortie d'un utilitaire, et mon cerveau malade a donné naissance à une construction comme sed ':a;N;$!ba;s/n/ /g', un collègue est venu et m'a éloigné de la console avec un balai, puis a résolu le problème en écrivant tr 'n' ' '.
Je vous conseille de vous rappeler ce que fait chaque outil individuel et les clés des commandes les plus fréquemment utilisées ; pour tout le reste, il y a l'homme. N'hésitez pas à appeler un homme si vous avez des doutes. Et assurez-vous de lire l'homme lui-même - il contient des informations importantes sur ce que vous trouverez.
Connaissant ces outils, vous pourrez résoudre efficacement une partie importante des problèmes que vous rencontrerez en pratique. Dans les conférences suivantes, nous verrons quand utiliser ces outils et les frameworks pour les services et applications sous-jacents auxquels ils s'appliquent.
L'administrateur système de FirstVDS, Kirill Tsvetkov, était avec vous.
Source: habr.com