Eu sou o administrador do sistema FirstVDS, e este é o texto da primeira palestra introdutória do meu breve curso sobre como ajudar colegas novatos. Profissionais que começaram recentemente a se envolver na administração de sistemas enfrentam vários problemas iguais. Para propor soluções, comprometi-me a escrever esta série de palestras. Algumas coisas nele são específicas para hospedar suporte técnico, mas, em geral, podem ser úteis, se não para todos, para muitos. Então adaptei o texto da palestra para compartilhar aqui.
Não importa como sua posição é chamada - é importante que você esteja administrando de fato. Portanto, vamos começar com o que o administrador do sistema deve fazer. Sua principal tarefa é colocar em ordem, manter a ordem e preparar-se para futuros aumentos em ordem. Sem um administrador do sistema, uma bagunça começa no servidor. Os logs não são gravados ou os errados, os recursos não são alocados da melhor maneira possível, o disco é preenchido com todos os tipos de lixo e o sistema começa a se curvar lentamente de tanto caos. Calma Os administradores de sistema em sua pessoa começam a resolver problemas e eliminar a bagunça!
Pilares de administração do sistema
No entanto, antes de começar a resolver problemas, vale a pena se familiarizar com os quatro principais pilares da administração:
- Documentação
- Templating
- Otimização
- Automação
Este é o fundamento do básico. Se você não desenvolver seu fluxo de trabalho com base nesses princípios, será ineficiente, improdutivo e geralmente não muito semelhante à administração real. Vamos lidar com cada um separadamente.
A documentação
Documentação não significa ler a documentação (embora sem ela em nenhum lugar), mas também mantê-la.
Como manter registros:
- Diante de um novo problema que você nunca viu antes? Anote os principais sintomas, métodos de diagnóstico e princípios de eliminação.
- Você criou uma nova solução elegante para um problema típico? Anotá-lo para que você não precise reinventá-lo em um mês.
- Você foi ajudado a lidar com uma pergunta em que não entendeu nada? Anote os principais pontos e conceitos, faça um diagrama para si mesmo.
A idéia principal: não confie completamente em sua própria memória no desenvolvimento e aplicação de uma nova.
O formato em que você fará isso depende apenas de você: pode ser um sistema com anotações, um blog pessoal, um arquivo de texto, um caderno físico. O principal é que seus registros atendam aos seguintes requisitos:
- Não demore muito . Destaque idéias, métodos e ferramentas principais. Se a compreensão do problema requer mergulhar na mecânica de baixo nível da alocação de memória do Linux, não reescreva o artigo a partir do qual você o aprendeu - forneça um link para ele.
- As entradas devem ser compreensíveis para você. Se a linha de
race cond.lockup não permitir que você entenda imediatamente o que você descreveu com esta linha - explique. Uma boa documentação não precisa ser entendida por meia hora. - A pesquisa é um recurso muito bom. Se você estiver blogando, adicione tags; se estiver em um caderno físico - cole um pequeno post-it com descrições. Não há muito sentido na documentação se você gastar tanto tempo procurando uma resposta nela quanto gastaria na solução de um problema do zero.
É assim que a documentação pode parecer: das entradas primitivas do bloco de notas (figura acima) até uma base de conhecimento multiusuário completa com tags, pesquisa e todas as comodidades possíveis (abaixo).
Não apenas você não precisará procurar as mesmas respostas duas vezes: a documentação será uma grande ajuda para aprender novos tópicos (notas!), Seu senso de aranha será aprimorado (a capacidade de diagnosticar um problema difícil com um olhar superficial) adicionará organização às suas ações. Se a documentação estiver disponível para seus colegas, permitirá que eles descubram o que e como você empilhou lá em cima quando não está no lugar.
Templating
Padronizar é a criação e o uso de padrões. Para resolver a maioria das perguntas típicas, vale a pena criar um modelo de ação específico. Uma sequência padronizada de ações deve ser usada para diagnosticar a maioria dos problemas. Quando você reparou / instalou / otimizou algo, o desempenho desse item deve ser verificado em relação às listas de verificação padronizadas.
A criação de modelos é a melhor maneira de organizar seu fluxo de trabalho. Usando 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 a operação e descartar os diagnósticos de funcionalidades sem importância. E procedimentos padronizados minimizarão o arremesso desnecessário 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ê apenas confiar na memória, poderá pular alguns testes ou operações realmente importantes e estragar tudo. O segundo ponto importante é que todas as práticas de modelo podem e devem ser modificadas se a situação exigir. Não existem modelos perfeitos e absolutamente universais. Se houver um problema, mas uma verificação de modelo não o revelou, isso não significa que não há problema. No entanto, antes de realizar a verificação de alguns problemas hipotéticos improváveis, você deve sempre fazer uma verificação rápida do modelo primeiro.
Otimização
A otimização fala por si. O fluxo de trabalho precisa ser otimizado o máximo possível em termos de tempo e mão de obra. Existem inúmeras opções: aprenda atalhos de teclado, abreviações, expressões regulares, ferramentas disponíveis. Procure opções para um uso mais prático dessas ferramentas. Se você chamar um comando 100 vezes por dia, desligue-o em um atalho de teclado. Se você precisar se conectar regularmente aos mesmos servidores, escreva o alias em uma palavra, que o conectará lá:
Confira as diferentes opções para as ferramentas disponíveis - talvez exista um cliente de terminal, DE, gerente de área de transferência, navegador, cliente de email e sistema operacional mais conveniente. Descubra quais ferramentas seus colegas e conhecidos usam - talvez eles as escolham por um motivo. Depois de pegar as ferramentas, aprenda como usá-las: aprenda as chaves, abreviações, dicas e truques.
Faça o melhor uso das ferramentas padrão - coreutils, vim, expressões regulares, bash. Nos últimos três, há um grande número de manuais e documentação maravilhosos. Com a ajuda deles, você pode rapidamente mudar do estado de "Eu me sinto como um macaco que poda nozes com um laptop - para" Eu sou um macaco que usa um laptop para pedir um biscoito de noz ".
Automação
A automação transferirá operações pesadas de nossas mãos cansadas para as mãos incansáveis da automação. Se algum procedimento padrão for executado logo após o mesmo tipo de comando, por que não agrupar todos esses comandos em um arquivo e não chamar um comando que baixa e executa esse arquivo?
A automação em si consiste em 80% da escrita e otimização de suas próprias ferramentas (e outros 20% de tentativas para fazê-las funcionar como deveriam). Pode ser apenas uma ferramenta avançada de uma linha ou uma enorme ferramenta onipotente com uma interface da Web e API. O principal critério aqui é que a criação de uma ferramenta não deve demorar mais tempo e esforço do que a quantidade de tempo e esforço que essa ferramenta poupará. Se você escrever um script por cinco horas que você nunca precisará novamente, para uma tarefa que levaria uma ou duas horas para ser resolvida sem um script - essa é uma otimização muito ruim do fluxo de trabalho. Você pode gastar cinco horas criando uma ferramenta apenas se o número, o tipo de tarefas e o tempo permitirem, o que acontece com pouca frequência.
Automação não significa necessariamente escrever scripts completos. Por exemplo, para criar um monte de objetos do mesmo tipo a partir da lista, uma linha inteligente é suficiente para fazer automaticamente o que você faria com as mãos, alternando entre janelas, com montes de copiar e colar.
Na verdade, se você desenvolver o processo de administração nesses quatro pilares, poderá aumentar rapidamente sua eficiência, produtividade e qualificações. No entanto, essa lista precisa ser complementada com mais um item, sem o qual é quase impossível trabalhar em TI - auto-educação.
Auto-educação com sysadmin
Para ser pelo menos um pouco competente nessa área, você precisa constantemente aprender e aprender coisas novas. Se você não tem o menor desejo de se deparar com o desconhecido e entender, acordará muito rapidamente. Todo tipo de novas soluções, tecnologias e métodos estão aparecendo constantemente em TI, e se você não estudá-los pelo menos superficialmente, estará perdendo. Muitas áreas da tecnologia da informação são muito complexas e volumosas. Por exemplo, operação de rede. As redes e a Internet estão por toda parte, você as encontra todos os dias, mas se você se aprofundar nas tecnologias por trás delas, encontrará uma disciplina enorme e muito complexa, cujo estudo nunca é um passeio no parque.
Não incluí este item na lista, porque é a chave para a TI em geral, e não apenas para a administração do sistema. Naturalmente, você não poderá aprender absolutamente tudo de uma só vez - simplesmente não tem tempo suficiente fisicamente. Portanto, na auto-educação, é preciso lembrar os níveis necessários de abstração.
Você não precisa aprender imediatamente como o gerenciamento de memória interna de cada utilitário individual funciona e como ele interage com o gerenciamento de memória do Linux, mas não é ruim saber o que a RAM é esquematicamente e por que é necessária. Você não precisa saber como os cabeçalhos TCP e UDP são estruturalmente diferentes, mas seria bom entender as principais diferenças de protocolo na operação. Você não precisa estudar o que é a atenuação do sinal na óptica, mas seria bom saber por que as perdas reais são sempre herdadas pelos nós. Não há nada errado em saber como certos elementos funcionam em um certo nível de abstração e não é necessário analisar absolutamente todos os níveis quando não há abstração (você simplesmente fica louco).
No entanto, discutir em seu campo no nível da abstração "bem, isso é algo 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 sistemas deve lidar em níveis mais baixos de abstração. Tentarei limitar a quantidade de conhecimento revisada a um nível mínimo de abstração.
Os 10 mandamentos da administração do sistema
Assim, aprendemos os quatro principais pilares e bases. Posso começar a resolver problemas? Ainda não. Antes disso, é aconselhável familiarizar-se com as chamadas "melhores práticas" e as regras de boa forma. Sem eles, é provável que você faça mais mal do que bem. Então, vamos começar:
- Alguns de meus colegas acreditam que a primeira regra é "não faça mal". Mas eu tendem a discordar. Quando você tenta não prejudicar, não pode fazer nada - muitas ações são potencialmente destrutivas. A regra mais importante que considero é "fazer um backup" . Mesmo se você se machucar, sempre pode reverter e tudo não será tão ruim.
Você precisa fazer backup sempre que a hora e o local o permitirem. Você precisa fazer backup do que vai mudar e do que corre o risco de perder com uma ação potencialmente destrutiva. É aconselhável verificar o backup quanto à integridade e disponibilidade de todos os dados necessários. Um backup não deve ser excluído imediatamente após a verificação de tudo, se você não precisar liberar espaço em disco. Se o espaço exigir, faça backup no seu servidor pessoal e exclua-o em uma semana. - A segunda regra mais importante (que eu mesmo quebro frequentemente) é "não esconda" . Se você fez um backup, escreva - onde, para que seus colegas não precisem procurá-lo. Se você fez alguma ação complexa ou não óbvia, escreva: você voltará para casa, mas o problema poderá ocorrer novamente ou outra pessoa o terá e sua solução será encontrada por palavras-chave. Mesmo se você fizer algo que conhece bem, talvez seus colegas não saibam.
- Não há necessidade de explicar a terceira regra: "nunca faça as conseqüências que você não conhece, não imagina ou entende" . Não copie comandos da Internet; se você não souber o que está fazendo, ligue para o homem e analise primeiro. Não use soluções prontas se não conseguir entender o que elas estão fazendo. Minimize a execução do código ofuscado. Se não houver tempo para entender, você está fazendo algo errado e deve ler o próximo parágrafo.
- "Teste" . Novos scripts, ferramentas, one-liners e comandos devem ser verificados em um ambiente controlado, e não na máquina cliente, se houver pelo menos um potencial mínimo para ações destrutivas. Mesmo se você fizer backup de tudo (e fez), o tempo de inatividade não é a coisa mais legal. Obtenha um servidor / máquina virtual / chroot separado para este caso e teste lá. Nada quebrou? Então você pode correr na "batalha".
- "Controle" . Minimize todas as operações que você não controla. Uma curva de dependência em um pacote pode arrastar metade do sistema para trás, e o sinalizador -y definido para yum remove oferece a oportunidade de treinar suas habilidades de recuperação do sistema a partir do zero. Se a ação não tiver alternativas não controladas, o próximo ponto e um backup pronto.
- "Confira . " Verifique as conseqüências de suas ações e se você precisa reverter para o backup. Verifique se o problema realmente foi resolvido. Verifique se o erro é reproduzido e sob quais condições. Verifique se você pode interromper suas ações. Confiar em nosso trabalho é supérfluo, mas nunca verificar.
- "Comunicar" . Se você não conseguir resolver o problema, pergunte a seus colegas se eles encontraram esse problema. Deseja aplicar uma decisão controversa - descubra a opinião dos colegas. Talvez eles ofereçam uma solução melhor. Não há confiança em suas ações - discuta-as com os colegas. Mesmo que essa seja sua área de especialização, uma nova visão da situação pode esclarecer muito. Não tenha vergonha de sua própria ignorância. É melhor fazer uma pergunta estúpida, parecer um tolo e obter uma resposta para ela, do que não fazer essa pergunta, não obter uma resposta e ficar no frio.
- "Não recuse ajuda irracionalmente . " Este item é o outro lado do anterior. Se você fez uma pergunta estúpida, esclareça e explique. Peça o impossível - explique que é impossível e por que, ofereça alternativas. Se não houver tempo (realmente não há tempo, não desejo) - diga que você tem uma pergunta urgente e uma grande quantidade de trabalho, mas descobrirá mais tarde. Se seus colegas não tiverem tarefas urgentes, ofereça-se para contatá-los e delegar a pergunta.
- "Vamos lá, feedback . " Alguns colegas começaram a aplicar uma nova técnica ou um novo script, e você encontra as consequências negativas dessa decisão? Relatar isso. Talvez o problema seja resolvido em três linhas de código ou em cinco minutos de aprimoramento da metodologia. Tropeçou em um bug no software? Relatar um bug. Se estiver sendo reproduzido ou se não for necessário reproduzi-lo, provavelmente será corrigido. Expresse desejos, sugestões e críticas construtivas, envie perguntas para discussão, se parecer que são relevantes.
- "Peça feedback . " Todos somos imperfeitos, assim como nossas decisões, e a melhor maneira de verificar a exatidão de nossa decisão é trazê-la para discussão. Otimizamos algo no cliente - peça para acompanhar o trabalho, talvez o “gargalo” do sistema não esteja onde você estava procurando. Eles escreveram um script de ajuda - mostre a 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 fakaps, mas também terá a oportunidade de corrigir erros (em face de backups e colegas que o aconselharão a fazer backup). Além disso, apenas detalhes técnicos, nos quais, como você sabe, o diabo está.
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 fácil? Pesquisa de texto e edição de texto. No entanto, grep e vim são poderosas ferramentas multifuncionais multifuncionais 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ê pode fazer quase qualquer coisa com texto. Não acredite - chame o comando vimtutor no terminal e comece a aprender. Quanto ao grep, sua principal força está nas expressões regulares. Sim, a própria ferramenta permite definir condições de pesquisa e gerar dados de maneira bastante flexível, mas sem o RegExp, não faz muito sentido. E você precisa conhecer expressões regulares! Pelo menos em um nível básico. Para começar, recomendo que você assista a este
vídeo , ele compreende o básico do básico de expressões regulares e seu uso em conjunto com o grep. Ah, sim, quando você os combina com o vim, você obtém
PODER FINAL a capacidade de fazer essas coisas com o texto que você precisa para pendurá-las com mais de 18 ícones.
Dos 50% restantes, 40% são coreutils. Para coreutils, você pode ver a lista na
Wikipedia e o manual da lista inteira no site
GNU . O que não é coberto por este conjunto está nos utilitários
POSIX . Não é necessário memorizar isso com todas as chaves de cor, mas pelo menos aproximadamente o que as ferramentas básicas podem fazer é útil. Não há necessidade de reinventar a roda de muletas. De alguma forma, eu tive que substituir quebras de linha por espaços na saída de alguma utilidade, e o cérebro doente deu origem a uma construção da forma
sed ':a;N;$!ba;s/\n/ /g' , um colega que se aproximou de mim me levou com uma vassoura a partir da consola e, em seguida, resolveu o problema escrevendo
tr '\n' ' ' .
Eu recomendo que você lembre-se de que cada ferramenta individual e as teclas dos comandos mais frequentemente utilizados são executadas aproximadamente, para todo o resto que existe. Sinta-se livre para ligar para o homem se tiver alguma dúvida. E não deixe de ler o homem sobre o próprio homem - ele contém informações importantes sobre o que você encontra.
Conhecendo essas ferramentas, você pode efetivamente resolver uma parte significativa das tarefas que encontrará na prática. Nas palestras seguintes, consideraremos quando aplicar essas ferramentas e as estruturas dos principais serviços e aplicativos aos quais elas são aplicadas.
O administrador do sistema FirstVDS, Kirill Tsvetkov, estava com você.