À l'administrateur système débutant: comment mettre de l'ordre dans le chaos

Je suis l'administrateur système de FirstVDS, et voici le texte de la première conférence introductive de mon court cours sur l'aide aux collègues débutants. Les professionnels qui ont récemment commencé à se lancer 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 sont spécifiques à l'hébergement du support technique, mais en général, elles peuvent être utiles, sinon pour tout le monde, puis pour beaucoup. J'ai donc adapté le texte de la conférence à partager ici.

Peu importe le nom de votre poste - il est important que vous administriez en fait. Par conséquent, commençons par ce que l'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 dans l'ordre. Sans administrateur système, un désordre commence sur le serveur. Les journaux ne sont pas écrits, ou quelque chose y est écrit, les ressources ne sont pas allouées de manière optimale, le disque est rempli de toutes sortes de déchets et le système commence à se plier lentement à cause de tant de chaos. Calme Les administrateurs système de votre personne commencent à résoudre les problèmes et à éliminer le gâchis!

Piliers d'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:

1. La documentation
2. Templating
3. Optimisation
4. Automatisation

C'est le fondement des bases. Si vous ne construisez pas votre flux de travail sur ces principes, il sera inefficace, improductif et généralement peu similaire à une administration réelle. Traitons chacun séparément.

La documentation

La documentation ne signifie pas lire la documentation (bien que sans elle n'importe où), mais aussi la maintenir.

Comment tenir des registres:

• Face à 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 nouvelle solution élégante à un problème typique? Notez-le pour ne pas avoir à le réinventer en un mois.
• Vous a-t-on aidé à traiter une question dans laquelle vous n'avez rien compris? Notez les principaux points et concepts, dessinez un diagramme pour vous-même.

L'idée principale: ne faites pas entièrement confiance à votre propre mémoire dans le développement et l'application d'une nouvelle.

Le format dans lequel vous le ferez ne dépend que de vous: ce peut être un système avec des notes, un blog personnel, un fichier texte, un cahier physique. L'essentiel est que vos dossiers répondent aux exigences suivantes:

1. Ne soyez pas trop long . Mettez en évidence les idées, méthodes et outils clés. Si la compréhension du problème nécessite de plonger dans la mécanique de bas niveau de l'allocation de mémoire Linux, ne réécrivez pas l'article à partir duquel vous l'avez appris - donnez-lui un lien.
2. Les entrées doivent être compréhensibles pour vous. Si la ligne de race cond.lockup ne vous permet pas de comprendre immédiatement ce que vous avez décrit avec cette ligne - expliquez. Une bonne documentation n'a pas besoin d'être comprise pendant une demi-heure.
3. La recherche est une très bonne fonctionnalité. Si vous bloguez, ajoutez des balises; si dans un cahier physique - collez un petit post-it avec des descriptions. Il n'y a pas beaucoup d'intérêt dans la documentation si vous passez autant de temps à chercher une réponse que vous le feriez pour résoudre un problème à partir de zéro.

Voici à quoi pourrait ressembler la documentation: des entrées de bloc-notes primitives (image ci-dessus) à une base de connaissances multi-utilisateurs à part entière avec des balises, des recherches et toutes les commodités possibles (ci-dessous).



Non seulement vous n'aurez pas à chercher deux fois les mêmes réponses: la documentation sera d'une grande aide pour apprendre de nouveaux sujets (notes!), Votre sens de l'araignée sera gonflé (la capacité de diagnostiquer un problème difficile avec un seul coup d'œil superficiel) ajoutera de l'organisation à vos actions. Si la documentation est à la disposition de vos collègues, elle leur permettra de comprendre quoi et comment vous vous y êtes empilés lorsque vous n'êtes pas en place.

Templating

Le modelage est la création et l'utilisation de modèles. Pour résoudre la plupart des questions typiques, il vaut la peine de créer un modèle d'action spécifique. Une séquence standardisée d'actions 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 par rapport à des 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 trucs sympas. Par exemple, l'utilisation de listes de contrôle vous permettra de diagnostiquer toutes les fonctions importantes pour l'opération et de rejeter les diagnostics de fonctionnalités sans importance. Et les procédures normalisées minimiseront les lancers inutiles et réduiront la probabilité 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 pouvez ignorer certains tests ou opérations vraiment importants et tout gâcher. Le deuxième point important est que toutes les pratiques de modèle peuvent et doivent être modifiées si la situation l'exige. Il n'y a pas de modèles parfaits et absolument universels. S'il y a un problème, mais qu'une vérification de modèle ne l'a pas révélé, cela ne signifie pas qu'il n'y a pas de problème. Cependant, avant d'entreprendre la vérification de certains problèmes hypothétiques improbables, vous devez toujours faire une vérification rapide du modèle en premier.

Optimisation

L'optimisation parle d'elle-même. Le flux de travail doit être optimisé autant que possible en termes de temps et de travail. Il existe d'innombrables options: découvrez les raccourcis clavier, les abréviations, les expressions régulières, les outils disponibles. Recherchez des options pour une utilisation plus pratique de ces outils. Si vous appelez une commande 100 fois par jour, raccrochez-la sur un raccourci clavier. Si vous devez vous connecter régulièrement aux mêmes serveurs, écrivez l'alias en un mot, qui vous y connectera:



Découvrez les différentes options des outils disponibles - il existe peut-être un client terminal plus pratique, DE, un gestionnaire de presse-papiers, un navigateur, un client de messagerie et un système d'exploitation. Découvrez quels outils vos collègues et connaissances utilisent - peut-être les choisissent-ils pour une raison. Après avoir ramassé les outils, apprenez à les utiliser: apprenez les clés, les abréviations, les trucs et astuces.

Faites le meilleur usage des outils standard - coreutils, vim, expressions régulières, bash. Pour les trois derniers, il existe un grand nombre de merveilleux manuels et documentation. Avec leur aide, vous pouvez rapidement passer de l'état "Je me sens comme un singe qui taille des noix avec un ordinateur portable - à" Je suis un singe qui utilise un ordinateur portable pour commander un cracker aux noix ".

Automatisation

L'automatisation transférera les opérations lourdes de nos mains fatiguées aux mains infatigables de l'automatisation. Si une procédure standard est exécutée dans la foulée du même type de commandes, alors pourquoi ne pas envelopper toutes ces commandes dans un fichier et ne pas appeler une commande qui télécharge et exécute ce fichier?

L'automatisation elle-même se compose de 80% d'écriture et d'optimisation de ses propres outils (et encore 20% de tentatives pour les faire fonctionner comme il se doit). Il peut s'agir d'un simple liner avancé ou d'un énorme outil omnipotent avec une interface Web et 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 la quantité de temps et d'efforts que cet outil vous fera économiser. Si vous écrivez un script pendant cinq heures dont vous n'aurez plus jamais besoin, pour une tâche qui vous prendrait une heure ou deux à résoudre sans script - c'est une très mauvaise optimisation du flux de travail. Vous ne pouvez passer cinq heures à créer un outil que si le nombre, le type de tâches et le temps le permettent, ce qui arrive rarement.

L'automatisation ne signifie pas nécessairement écrire des scripts complets. Par exemple, pour créer un tas d'objets du même type à partir de la liste, une ligne intelligente est suffisante pour faire automatiquement ce que vous feriez avec vos mains, basculer entre les fenêtres, avec des tas de copier-coller.

En fait, si vous construisez le processus d'administration 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 autre élément, sans lequel travailler dans l'informatique est presque impossible - l'auto-éducation.

Auto-éducation Sysadmin

Pour être au moins un peu compétent dans ce domaine, vous devez constamment apprendre et apprendre de nouvelles choses. Si vous n'avez pas la moindre envie de tomber sur l'inconnu et de comprendre, vous vous réveillerez très vite. 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 le point de perdre. De nombreux domaines des technologies de l'information sont très complexes et volumineux. Par exemple, le fonctionnement du réseau. Les réseaux et Internet sont partout, vous les rencontrez tous les jours, mais si vous creusez dans les technologies derrière eux, vous trouverez une discipline immense et très complexe, dont l'étude n'est jamais une promenade dans le parc.

Je n'ai pas inclus cet élément dans la liste, car c'est la clé pour l'informatique en général, et pas seulement pour l'administration du système. Naturellement, vous ne pourrez pas tout apprendre à la fois - vous n’avez tout simplement pas assez de temps physiquement. Par conséquent, dans l'auto-éducation, il faut se rappeler les niveaux d'abstraction nécessaires.

Vous n'avez pas à apprendre immédiatement comment fonctionne la gestion de la mémoire interne de chaque utilitaire individuel, et comment il interagit avec la gestion de la mémoire Linux, mais ce n'est pas mal de savoir ce qu'est la RAM de manière schématique et pourquoi elle est nécessaire. Vous n'avez pas besoin de savoir comment les en-têtes TCP et UDP sont structurellement différents, mais il serait bien de comprendre les principales différences de protocole en fonctionnement. Vous n'avez pas besoin d'étudier l'atténuation du signal en optique, mais ce serait bien de savoir pourquoi les pertes réelles sont toujours héritées par les nœuds. Il n'y a rien de mal à savoir comment certains éléments fonctionnent à un certain niveau d'abstraction et il n'est pas nécessaire d'analyser absolument tous les niveaux lorsqu'il n'y a aucune abstraction (vous devenez fou).

Cependant, discuter dans leur domaine au niveau de l'abstraction "eh bien c'est une chose qui permet d'afficher des sites" 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 à des niveaux d'abstraction inférieurs. J'essaierai de limiter la quantité de connaissances examinées à un niveau d'abstraction minimum.

Les 10 commandements de l'administration système

Nous avons donc appris les quatre principaux piliers et fondements. Puis-je commencer à résoudre des problèmes? Pas encore. Avant cela, il est conseillé de se familiariser avec les soi-disant "bonnes pratiques" et les règles de bonne forme. Sans eux, il est probable que vous fassiez plus de mal que de bien. Commençons donc:

1. Certains de mes collègues pensent que la toute première règle est «ne pas nuire». Mais j'ai tendance à être en désaccord. Lorsque vous essayez de ne pas nuire, vous ne pouvez rien faire - trop d'actions sont potentiellement destructrices. La règle la plus importante que je considère est «faire une sauvegarde» . Même si vous vous faites mal, vous pouvez toujours reculer et tout ne sera pas si mal.
   
   Vous devez toujours sauvegarder lorsque le temps et le lieu le permettent. Vous devez sauvegarder ce que vous allez changer et ce que vous risquez de perdre avec une action potentiellement destructrice. Il est conseillé de vérifier la sauvegarde pour l'intégrité et la disponibilité de toutes les données nécessaires. Une sauvegarde ne doit pas être supprimée immédiatement après avoir tout vérifié, si vous n'avez pas besoin de libérer de l'espace disque. Si l'espace l'exige - sauvegardez sur votre serveur personnel et supprimez-le dans une semaine.
2. La deuxième règle la plus importante (que je transgresse souvent moi-même) est «ne le cachez pas» . Si vous avez effectué une sauvegarde, écrivez - où afin que vos collègues n'aient pas à la rechercher. Si vous avez effectué des actions non évidentes ou complexes, notez: vous rentrerez chez vous, mais le problème peut se reproduire ou quelqu'un d'autre l'aura et votre solution sera trouvée par des mots clés. Même si vous faites quelque chose que vous connaissez bien, vos collègues ne le savent peut-être pas.
3. Inutile d'expliquer la troisième règle: "ne faites jamais les conséquences dont vous ne connaissez pas, n'imaginez pas ou ne comprenez pas" . Ne copiez pas les commandes d'Internet, si vous ne savez pas ce qu'elles font, appelez d'abord man et analysez. N'utilisez pas de solutions toutes faites si vous ne comprenez pas ce qu'elles font. Minimisez l'exécution du code obscurci. S'il n'y a pas de temps pour comprendre, alors vous faites quelque chose de mal et vous devriez lire le paragraphe suivant.
4. "Testez-le . " Les nouveaux scripts, outils, monolignes et commandes doivent être vérifiés dans un environnement contrôlé, et non sur la machine cliente, s'il y a au moins un potentiel minimal d'actions destructrices. Même si vous sauvegardez tout (et vous l'avez fait), les temps d'arrêt ne sont pas la chose la plus cool. Obtenez un serveur / machine virtuelle / chroot séparé pour ce cas et testez-le. Rien de cassé? Ensuite, vous pouvez courir sur la "bataille".
   
   
   
   
5. "Contrôle . " Minimisez toutes les opérations que vous ne contrôlez pas. Une courbe de dépendance dans un package peut faire glisser la moitié du système derrière, et l'indicateur -y défini pour yum remove vous donne la possibilité de former vos compétences de récupération du système à partir de zéro. Si l'action n'a pas d'alternatives non contrôlées, le point suivant et une sauvegarde prête.
6. "Vérifiez-le . " Vérifiez les conséquences de vos actions et si vous devez revenir à la sauvegarde. Vérifiez si le problème est vraiment résolu. Vérifiez si l'erreur se reproduit et dans quelles conditions. Vérifiez que vous pouvez rompre avec vos actions. Faire confiance à notre travail est superflu, mais jamais à vérifier.
7. "Communiquez . " Si vous ne pouvez pas résoudre le problème, demandez à vos collègues s'ils ont rencontré un tel problème. Vous voulez appliquer une décision controversée - découvrez l'opinion de vos collègues. Peut-être offriront-ils une meilleure solution. Il n'y a aucune confiance 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 clarifier beaucoup. N'ayez pas peur de votre propre ignorance. Il vaut mieux poser une question stupide, avoir l'air d'un idiot et obtenir une réponse, que de ne pas poser cette question, de ne pas obtenir de réponse et de rester dans le froid.
8. "Ne refusez pas l'aide de manière déraisonnable . " Cet article est le revers de la précédente. Si on vous a posé une question stupide - clarifiez et expliquez. Demandez l'impossible - expliquez qu'il est impossible et pourquoi, proposez des alternatives. S'il n'y a pas de temps (il n'y a vraiment pas de temps, pas de désir) - dites que vous avez une question urgente \ beaucoup de travail, mais vous le découvrirez plus tard. Si vos collègues n'ont pas de tâches urgentes, proposez de les contacter et de déléguer la question.
9. "Venez les commentaires . " Certains collègues ont commencé à appliquer une nouvelle technique ou un nouveau script, et rencontrez-vous les conséquences négatives de cette décision? Signalez cela. Peut-être que le problème est résolu en trois lignes de code ou cinq minutes de raffinement de la méthodologie. Vous êtes tombé sur un bug dans le logiciel? Signaler un bug. S'il est reproduit ou s'il n'est pas nécessaire de le reproduire, il sera très probablement corrigé. Exprimez vos souhaits, suggestions et critiques constructives, soumettez des questions à la discussion si elles semblent pertinentes.
10. "Demandez des commentaires . " Nous sommes tous imparfaits, tout comme nos décisions, et la meilleure façon de vérifier l'exactitude de notre décision est de la soumettre à discussion. Nous avons optimisé quelque chose chez le client - demandez à suivre le travail, peut-être que le «goulot d'étranglement» du système n'est pas là où vous cherchiez. Ils ont écrit un script d'aide - montrez à vos collègues, peut-être qu'ils trouveront 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 réduirez non seulement le nombre de vos propres erreurs et fakaps au minimum, mais vous aurez également la possibilité de corriger les erreurs (face aux sauvegardes et aux collègues qui vous conseilleront de sauvegarder). De plus, seuls les détails techniques, dans lesquels, comme vous le savez, réside le diable.

Les principaux outils avec lesquels vous devrez travailler plus de 50% du temps sont grep et vim. Quoi de plus simple? Recherche et modification de texte. Cependant, grep et vim sont de puissants multitools multifonctionnels qui vous permettent de rechercher et de modifier du texte efficacement. Si certains blocs-notes Windows vous permettent d'écrire / supprimer simplement une ligne, alors dans vim vous pouvez faire presque n'importe quoi avec du texte. Ne le 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 produire 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 de base. Pour commencer, je vous conseille de regarder cette vidéo , elle comprend les bases des bases des expressions régulières et leur utilisation en conjonction avec grep. Oh oui, quand vous les combinez avec vim, vous obtenez PUISSANCE ULTIME la possibilité de faire de telles choses avec le texte que vous devez les accrocher avec plus de 18 icônes.

Sur les 50% restants, 40% sont des coreutils. Pour coreutils, vous pouvez voir la liste sur Wikipedia , et le manuel de la liste entière sur le site web GNU . Ce qui n'est pas couvert par cet ensemble se trouve dans les utilitaires POSIX . Il n'est pas nécessaire de mémoriser cela avec toutes les clés par cœur, mais au moins à peu près savoir ce que les outils de base peuvent faire est utile. Pas besoin de réinventer la roue des béquilles. D'une manière ou d'une autre, j'ai dû remplacer les sauts de ligne par des espaces dans la sortie d'un utilitaire, et le cerveau malade a donné naissance à une construction de la forme sed ':a;N;$!ba;s/\n/ /g' , un collègue qui m'a approché m'a conduit avec un balai à partir de la console, puis a résolu le problème en écrivant tr '\n' ' ' .



Je vous conseille de vous rappeler que chaque outil individuel et les touches des commandes les plus fréquemment utilisées s'exécutent approximativement, pour tout le reste, il y a de l'homme. N'hésitez pas à appeler l'homme en cas de doute. Et assurez-vous de lire l'homme sur l'homme lui-même - il contient des informations importantes sur ce que vous trouvez.

Connaissant ces outils, vous pouvez résoudre efficacement une partie importante des tâches que vous rencontrerez dans la pratique. Dans les conférences suivantes, nous examinerons quand appliquer ces outils et les structures des principaux services et applications auxquels ils sont appliqués.

L'administrateur système de FirstVDS, Kirill Tsvetkov, était avec vous.