Para um administrador de sistema novato: como criar ordem no caos

Sou administrador de sistema FirstVDS e este é o texto da primeira palestra introdutória do meu minicurso sobre como ajudar colegas novatos. Os especialistas que recentemente começaram a se envolver na administração de sistemas enfrentam vários dos mesmos problemas. Para oferecer soluções, me comprometi a escrever esta série de palestras. Algumas coisas nele são específicas para suporte técnico de hospedagem, mas em geral podem ser úteis, se não para todos, pelo menos para muitos. Então adaptei o texto da palestra para compartilhar aqui.

Não importa como se chama o seu cargo - o que importa é que de fato você está envolvido na administração. Portanto, vamos começar explicando o que um administrador de sistema deve fazer. Sua principal tarefa é colocar as coisas em ordem, manter a ordem e preparar-se para futuros aumentos de ordem. Sem um administrador de sistema, o servidor fica uma bagunça. Os logs não são gravados, ou coisas erradas são escritas neles, os recursos não são distribuídos de maneira ideal, o disco fica cheio de todo tipo de lixo e o sistema começa a morrer lentamente de tanto caos. Calmamente! Os administradores de sistema em sua pessoa começam a resolver problemas e eliminar a bagunça!

Pilares da Administração do Sistema

Porém, antes de começar a resolver problemas, vale a pena se familiarizar com os quatro principais pilares da administração:

1. Documentação
2. Modelagem
3. Otimização
4. Automação

Este é o básico. Se você não construir seu fluxo de trabalho com base nesses princípios, ele será ineficaz, improdutivo e geralmente terá pouca semelhança com a administração real. Vejamos cada um separadamente.

Documentação

Documentação não significa ler a documentação (embora você não possa prescindir dela), mas também mantê-la.

Como guardar a documentação:

• Você encontrou um novo problema que nunca viu antes? Anote os principais sintomas, métodos de diagnóstico e princípios de eliminação.
• Você encontrou uma solução nova e elegante para um problema comum? Anote para não precisar reinventá-lo daqui a um mês.
• Eles ajudaram você a descobrir uma pergunta que você não entendeu? Anote os principais pontos e conceitos, desenhe um diagrama para você.

A ideia principal: você não deve confiar totalmente na sua própria memória ao dominar e aplicar coisas novas.

O formato que você fará isso depende de você: pode ser um sistema com notas, um blog pessoal, um arquivo de texto, um bloco de notas físico. O principal é que seus registros atendam aos seguintes requisitos:

1. Não demore muito. Destaque as principais ideias, métodos e ferramentas. Se a compreensão de um problema exigir um mergulho na mecânica de baixo nível de alocação de memória no Linux, não reescreva o artigo com o qual você aprendeu - forneça um link para ele.
2. As entradas devem ser claras para você. Se a linha race cond.lockup não permite que você entenda imediatamente o que descreveu com esta linha - explique. Uma boa documentação não leva meia hora para ser entendida.
3. A pesquisa é um recurso muito bom. Se você escreve postagens em blogs, adicione tags; se estiver em um caderno físico, cole pequenos post-its com descrições. Não há muito sentido na documentação se você gastar tanto tempo procurando uma resposta nela quanto gastaria resolvendo a questão do zero.

Esta é a aparência da documentação: desde notas primitivas em um bloco de notas (foto acima) até uma base de conhecimento multiusuário completa com tags, pesquisa e todas as conveniências possíveis (abaixo).

Você não apenas não terá que procurar as mesmas respostas duas vezes, mas documentar será uma grande ajuda no aprendizado de novos tópicos (notas!), melhorará seu senso de aranha (a capacidade de diagnosticar um problema complexo com um olhar superficial), e adicionará organização às suas ações. Se a documentação estiver disponível para seus colegas, ela permitirá que eles descubram o que e como você acumulou quando não estava lá.

Modelagem

Modelagem é a criação e uso de modelos. Para resolver os problemas mais típicos, vale a pena criar um modelo de ação específico. Uma sequência padronizada de etapas deve ser usada para diagnosticar a maioria dos problemas. Quando você repara/instala/otimiza algo, o desempenho desse algo deve ser verificado usando listas de verificação padronizadas.

A modelagem é a melhor maneira de organizar seu fluxo de trabalho. Ao usar procedimentos padrão para resolver os problemas mais comuns, você obtém muitas coisas interessantes. Por exemplo, o uso de listas de verificação permitirá diagnosticar todas as funções importantes para o seu trabalho e descartar o diagnóstico de funcionalidades sem importância. E procedimentos padronizados minimizarão lançamentos desnecessários e reduzirão a probabilidade de erro.

O primeiro ponto importante é que os procedimentos e listas de verificação também precisam ser documentados. Se você confiar apenas na memória, poderá perder alguma verificação ou operação realmente importante e estragar tudo. O segundo ponto importante é que todas as práticas modelo podem e devem ser modificadas se a situação assim o exigir. Não existem modelos ideais e absolutamente universais. Se houver um problema, mas a verificação do modelo não o revelar, isso não significa que não haja problema. No entanto, antes de começar a testar alguns problemas hipotéticos improváveis, sempre vale a pena fazer primeiro um teste rápido de modelo.

Otimização

Otimização fala por si. O processo de trabalho precisa ser otimizado tanto quanto possível em termos de tempo e custos de mão de obra. São inúmeras opções: aprender atalhos de teclado, abreviações, expressões regulares, ferramentas disponíveis. Procure usos mais práticos dessas ferramentas. Se você chamar um comando 100 vezes por dia, atribua-o a um atalho de teclado. Se você precisar se conectar regularmente aos mesmos servidores, escreva um alias em uma palavra que conectará você lá:

Familiarize-se com as diferentes opções de ferramentas disponíveis - talvez haja um cliente de terminal mais conveniente, DE, gerenciador de área de transferência, navegador, cliente de e-mail, sistema operacional. Descubra quais ferramentas seus colegas e amigos usam – talvez eles as escolham por um motivo. Depois de ter as ferramentas, aprenda como usá-las: aprenda as teclas, abreviações, dicas e truques.

Faça uso ideal de ferramentas padrão - coreutils, vim, expressões regulares, bash. Para os três últimos, há um grande número de manuais e documentação maravilhosos. Com a ajuda deles, você pode passar rapidamente do estado de “me sinto como um macaco que quebra nozes com um laptop” para “sou um macaco que usa um laptop para pedir um quebra-nozes”.

Automação

Automação transferirá operações difíceis de nossas mãos cansadas para as mãos incansáveis ​​da automação. Se algum procedimento padrão é executado em cinco comandos do mesmo tipo, por que não agrupar todos esses comandos em um arquivo e chamar um comando que baixe e execute esse arquivo?

A automação em si consiste em 80% escrevendo e otimizando suas próprias ferramentas (e outros 20% tentando fazê-las funcionar como deveriam). Pode ser apenas uma linha avançada ou uma ferramenta enorme e onipotente com interface web e API. O principal critério aqui é que a criação de uma ferramenta não exija mais tempo e esforço do que a quantidade de tempo e esforço que a ferramenta irá economizar. Se você passar cinco horas escrevendo um script que nunca mais precisará, para uma tarefa que levaria uma ou duas horas para ser resolvida sem o script, esta é uma otimização de fluxo de trabalho muito ruim. Você pode gastar cinco horas criando uma ferramenta somente se o número, o tipo de tarefas e o tempo permitirem, o que não é frequente.

Automação não significa necessariamente escrever scripts completos. Por exemplo, para criar vários objetos do mesmo tipo a partir de uma lista, tudo o que você precisa é de uma linha inteligente que fará automaticamente o que você faria manualmente, alternando entre janelas, com montes de copiar e colar.

Na verdade, se você construir o processo de administração sobre esses quatro pilares, poderá aumentar rapidamente sua eficiência, produtividade e qualificação. Porém, esta lista precisa ser complementada com mais um item, sem o qual trabalhar em TI é quase impossível - a autoeducação.

Autoeducação do administrador do sistema

Para ser pelo menos um pouco competente nessa área, você precisa estudar e aprender coisas novas constantemente. Se você não tem a menor vontade de enfrentar o desconhecido e descobri-lo, ficará preso muito rapidamente. Todos os tipos de novas soluções, tecnologias e métodos aparecem constantemente em TI e, se você não os estudar, pelo menos superficialmente, estará no caminho do fracasso. Muitas áreas da tecnologia da informação assentam numa base muito complexa e volumosa. Por exemplo, operação de rede. As redes e a Internet estão por toda parte, você as encontra todos os dias, mas depois de se aprofundar na tecnologia por trás delas, você descobrirá uma disciplina enorme e muito complexa, cujo estudo nunca é um passeio no parque.

Não incluí este item na lista porque é fundamental para a TI em geral, e não apenas para administração de sistemas. Naturalmente, você não será capaz de aprender absolutamente tudo de imediato – você simplesmente não tem tempo fisicamente suficiente. Portanto, ao se educar, você deve se lembrar dos níveis de abstração necessários.

Você não precisa aprender imediatamente como funciona o gerenciamento de memória interna de cada utilitário individual e como ele interage com o gerenciamento de memória do Linux, mas é bom saber o que é RAM esquematicamente e por que ela é necessária. Você não precisa saber como os cabeçalhos TCP e UDP são estruturalmente diferentes, mas seria uma boa ideia entender as diferenças básicas no funcionamento dos protocolos. Você não precisa aprender o que é atenuação de sinal em óptica, mas seria bom saber por que as perdas reais são sempre herdadas entre os nós. Não há nada de errado em saber como certos elementos funcionam em um determinado nível de abstração e não necessariamente compreender absolutamente todos os níveis quando não há abstração alguma (você simplesmente enlouquecerá).

Porém, na sua área, pensar no nível de abstração “bom, isso é uma coisa que permite exibir sites” não é muito bom. As palestras a seguir serão dedicadas a uma visão geral das principais áreas com as quais um administrador de sistema deve lidar ao trabalhar em níveis mais baixos de abstração. Tentarei limitar a quantidade de conhecimento revisado a um nível mínimo de abstração.

10 mandamentos da administração do sistema

Então, aprendemos os quatro pilares principais e fundamentos. Podemos começar a resolver problemas? Ainda não. Antes de fazer isso, é aconselhável familiarizar-se com as chamadas “melhores práticas” e regras de bons costumes. Sem eles, é provável que você cause mais danos do que benefícios. Então, vamos começar:

1. Alguns dos meus colegas acreditam que a primeira regra é “não causar danos”. Mas estou inclinado a discordar. Quando você tenta não prejudicar, você não pode fazer nada – muitas ações são potencialmente destrutivas. Acho que a regra mais importante é - “faça um backup”. Mesmo se você causar algum dano, você sempre pode reverter e tudo não será tão ruim.

   Você deve sempre fazer backup quando o tempo e o local permitirem. Você precisa fazer backup do que mudará e do que corre o risco de perder devido a uma ação potencialmente destrutiva. É aconselhável verificar a integridade do backup e a presença de todos os dados necessários. O backup não deve ser excluído imediatamente após verificar tudo, a menos que seja necessário liberar espaço em disco. Se o local exigir, faça backup em seu servidor pessoal e exclua-o após uma semana.

2. A segunda regra mais importante (que eu mesmo quebro com frequência) é "não se esconda". Se você fez um backup, escreva onde, para que seus colegas não precisem procurá-lo. Se você realizou alguma ação não óbvia ou complexa, anote: você irá para casa, e o problema pode se repetir ou surgir para outra pessoa, e sua solução será encontrada por meio de palavras-chave. Mesmo que você faça algo que conhece bem, seus colegas talvez não o façam.
3. A terceira regra não precisa ser explicada: “nunca faça algo cujas consequências você não conheça, imagine ou entenda”. Não copie comandos da Internet se você não sabe o que eles fazem, ligue para man e analise-os primeiro. Não use soluções prontas se não conseguir entender o que elas fazem. Mantenha a execução do código ofuscado ao mínimo absoluto. Se você não tem tempo para descobrir, então você está fazendo algo errado e deve ler o próximo ponto.
4. "Teste". Novos scripts, ferramentas, one-liners e comandos devem ser testados em um ambiente controlado, não na máquina cliente, se houver potencial mínimo para ações destrutivas. Mesmo que você tenha feito backup de tudo (e fez), o tempo de inatividade não é a coisa mais legal. Crie um servidor/virtual/chroot separado para isso e teste lá. Alguma coisa está quebrada? Então você pode iniciá-lo em “combate”.

   
   

5. "Ao controle". Minimize todas as operações que você não controla. Uma curva de dependência de pacote pode arrastar metade do sistema, e o sinalizador -y definido para yum remove oferece a oportunidade de praticar suas habilidades de recuperação do sistema do zero. Se a ação não tiver alternativas não controladas, o próximo ponto é um backup pronto.
6. "Verificar". Verifique as consequências de suas ações e se você precisa reverter para um backup. Verifique se o problema foi realmente resolvido. Verifique se o erro é reproduzido e em que condições. Verifique o que você pode quebrar com suas ações. Não é necessário confiar no nosso trabalho, mas nunca verificar.
7. "Comunicar". Se você não conseguir resolver o problema, pergunte aos seus colegas se eles já encontraram isso. Se você deseja aplicar uma decisão polêmica, conheça a opinião de seus colegas. Talvez eles ofereçam uma solução melhor. Se você não está confiante em suas ações, discuta-as com seus colegas. Mesmo que esta seja a sua área de atuação, um novo olhar sobre a situação pode esclarecer muita coisa. Não tenha vergonha da sua própria ignorância. É melhor fazer uma pergunta estúpida, parecer um tolo e obter uma resposta, do que não fazer a pergunta, não obter uma resposta e acabar sendo um tolo.
8. “Não recuse ajuda injustificadamente”. Este ponto é o inverso do anterior. Se lhe fizerem uma pergunta estúpida, esclareça e explique. Eles pedem o impossível - explicam que é impossível e por quê, oferecem alternativas. Se você não tem tempo (você realmente não tem tempo, nem vontade) - diga que você tem uma pergunta urgente, muito trabalho, mas você resolverá isso mais tarde. Se os colegas não tiverem tarefas urgentes, ofereça-se para contatá-los e delegar a questão.
9. "Dê retorno". Um de seus colegas começou a usar uma nova técnica ou um novo roteiro e você está enfrentando consequências negativas dessa decisão? Denuncie. Talvez o problema possa ser resolvido em três linhas de código ou cinco minutos de refinamento da técnica. Você se deparou com um bug em seu software? Reportar um erro. Se for reproduzível ou não precisar ser reproduzido, provavelmente será corrigido. Expresse seus desejos, sugestões e críticas construtivas e levante questões para discussão, se parecerem relevantes.
10. "Peça feedback". Somos todos imperfeitos, assim como nossas decisões, e a melhor maneira de testar a correção de sua decisão é trazê-la à discussão. Se você otimizou algo para um cliente, peça para ele monitorar o trabalho; talvez o gargalo no sistema não esteja onde você procurava. Você escreveu um script de ajuda – mostre-o aos seus colegas, talvez eles encontrem uma maneira de melhorá-lo.

Se você aplicar constantemente essas práticas em seu trabalho, a maioria dos problemas deixará de ser problemas: você não apenas reduzirá ao mínimo o número de seus próprios erros e falhas, mas também terá a oportunidade de corrigir erros (no forma de backups e colegas que irão aconselhá-lo a fazer backup). Além disso - apenas detalhes técnicos, nos quais, como sabemos, reside o diabo.

As principais ferramentas com as quais você terá que trabalhar mais de 50% do tempo são grep e vim. O que poderia ser mais simples? Pesquisa de texto e edição de texto. No entanto, tanto o grep quanto o vim são ferramentas múltiplas poderosas que permitem pesquisar e editar texto com eficiência. Se algum bloco de notas do Windows permitir que você simplesmente escreva/exclua uma linha, no vim você poderá fazer quase tudo com texto. Se você não acredita em mim, chame o comando vimtutor no terminal e comece a aprender. Quanto ao grep, seu principal ponto forte está nas expressões regulares. Sim, a própria ferramenta permite definir condições de pesquisa e gerar dados com bastante flexibilidade, mas sem o RegExp isso não faz muito sentido. E você precisa conhecer expressões regulares! Pelo menos em um nível básico. Para começar, aconselho você a dar uma olhada nisso vídeo, aborda os fundamentos das expressões regulares e seu uso em conjunto com o grep. Ah, sim, quando você os combina com o vim, você obtém a capacidade ULTIMATE POWER de fazer coisas com texto que precisa rotulá-los com mais de 18 ícones.

Dos 50% restantes, 40% vêm do kit de ferramentas coreutils. Para coreutils você pode ver a lista em wikipedia, e o manual da lista completa está no site GNU. O que não está coberto neste conjunto está nos utilitários POSIX. Você não precisa decorar todas as teclas, mas é útil saber pelo menos aproximadamente o que as ferramentas básicas podem fazer. Você não precisa reinventar a roda com muletas. De alguma forma, precisei substituir as quebras de linha por espaços na saída de algum utilitário, e meu cérebro doente deu origem a uma construção como sed ':a;N;$!ba;s/n/ /g', um colega apareceu e me afastou do console com uma vassoura, e então resolveu o problema escrevendo tr 'n' ' '.

Aconselho você a lembrar o que cada ferramenta individual faz e as chaves dos comandos usados ​​com mais frequência; para todo o resto existe o man. Sinta-se à vontade para ligar para o homem se tiver alguma dúvida. E não deixe de ler o próprio homem — ele contém informações importantes sobre o que você encontrará.

Conhecendo essas ferramentas, você poderá resolver com eficácia uma parte significativa dos problemas que encontrará na prática. Nas palestras a seguir, veremos quando usar essas ferramentas e as estruturas para os serviços e aplicativos subjacentes aos quais elas se aplicam.

O administrador do sistema FirstVDS, Kirill Tsvetkov, estava com você.

Fonte: habr.com