Como um administrador Linux pode melhorar suas habilidades de script e automação de shell?

Question

Na minha organização, trabalho com um grupo de funcionários da NOC, engenheiros juniores e um punhado de engenheiros seniores; tudo com foco no Linux. Um passo interessante na forma como a empresa desenvolve talentos é que existe um caminho desde o NOC até os altos escalões de engenharia. Vendo o pool de talentos como um novato relativo, vejo que há uma divisão nos conjuntos de habilidades que tendem a crescer com o tempo ...

• Existem engenheiros que conhecem bem uma ou várias tecnologias específicas e estão constantemente imersos ... por exemplo, MySQL, firewalls, armazenamento SAN, balanceadores de carga ...
• Existem outras pessoas que são generalistas e podem navegar em várias tecnologias.
• Todos aprendem Linux (comandos, processos) o suficiente para fazer o que precisam e usam diariamente.

Um fator diferenciador entre alguns dos funcionários é o quão bem eles adotam as metodologias de gerenciamento de scripts, automação e configuração. Por exemplo, temos dois engenheiros que fazem a maior parte do trabalho da Amazon, e outro que lida com a maior parte dos href AWS CloudFormation ="https://puppetlabs.com"> Infraestrutura do Puppet . Talvez um quarto dos engenheiros seja adepto dos scripts de shell da BASH.

Olhando para isso no contexto da incrivelmente alta demanda por Habilidades de DevOps no mercado de trabalho , estou curioso sobre como outras organizações fomentam o desenvolvimento dessas habilidades e aumentam seus talentos internos. O script não parece ser um conceito particularmente ensinável.

• Como um sysadmin aprimora seus scripts de shell?
• Existe ainda um lugar para engenheiros que não / não podem acompanhar o paradigma de DevOps?
• Vamos simplesmente presumir que algumas pessoas serão deixadas para trás enquanto essas tecnologias evoluem? Tudo bem?

Answer 1

Tenho o benefício de entender o tamanho e a complexidade do seu ambiente. Visto que você trabalha para um provedor de nuvem / hospedagem, é seguro assumir que você tem um grande número de ambientes de pequeno e médio porte (10 a 100 servidores). Certamente há tarefas diárias que são feitas pelo jr. engenheiros e funcionários do NOC que são repetitivos (criando contas de usuário, configurando agentes de backup, etc). Da mesma forma, provavelmente há algumas coisas manuais que são feitas pelo sr. engenheiros como instalar o ESXi em um novo hardware ou configurar coisas como o MPIO ou instalar módulos VMware para conjuntos específicos de hardware. Todas essas coisas podem e devem ser automatizadas.

Se sua equipe for capaz de realizar a maior parte de sua carga de trabalho sem automatizar, você terá excesso de pessoal na minha opinião. Qualquer equipe de TI que trabalhe um dia inteiro e consista principalmente em processos manuais não tem motivação para automatizar. Por que aprender uma nova habilidade que não é vista como necessária e pode até ser assustadora ? Afinal, a necessidade é a mãe se a inovação.

Assim, em algum ponto da sua organização, você crescerá para um tamanho em que você vai fracassar e desmoronar, ou você começará a automatizar quase tudo e a se destacar. Certamente, os engenheiros seniores deveriam estar liderando a carga aqui, e talvez até trabalhando com os engenheiros juniores e a equipe da NOC para automatizar parte de sua carga de trabalho. Isso dá o jr. engenheiros a oportunidade de ter a estrutura de muitos scripts para trabalhar, que eles podem ajustar para cada inquilino e nova revisão de hardware, conforme necessário. Isso remove o pensamento assustador de "Oh meu Deus, por onde eu começo?" da equação e dá-lhes um começo para resolver um problema real . O que me leva ao meu ponto final. Livros e exemplos são bons e bons, mas não há nada que possa substituir o sentimento de realização de um problema real que eles enfrentam. Dê a eles uma meta, como todos os novos servidores para o locatário x, devem ter certos módulos ESXi instalados e, em seguida, trabalhe com eles para realizá-lo. Em seguida, adapte o script para trabalhar em um ambiente multilocatário.

How does a sysadmin improve their shell scripting?

Por precisar , conforme descrito acima.

Is there still a place for engineers who do not/cannot keep up in the DevOps paradigm?

Claro, há muitas organizações que não podem ou não mudarão para a metodologia DevOps. Eles parecem ser mais e mais opções chatas , mas ainda assim são opções.

Are we simply to assume that some people will be left behind as these technologies evolve?

Como acontece com qualquer nova tecnologia - sim.

tl; dr Você nunca terá alguém que realmente invista em aprendê-lo até que ele veja o valor nele. Se eles podem realizar suas tarefas diárias manualmente, então você está com excesso de pessoal e não há incentivo.

    

Answer 2

• How does a sysadmin improve their shell scripting?

Pratique, misturado com o drive. Parece banal, mas você precisa querer para melhorar, além de praticar. Se você não gosta verdadeiramente de scripts, você pode ser forçado a fazê-lo por anos quando precisar e nunca realmente ficar bom nisso. Se você não quer melhorar, você pode se sentar ao lado do melhor roteirista do mundo todos os dias no trabalho e não pegar uma fração da habilidade que você poderia ter.

Eu conheço essas pessoas que, apesar de trabalharem em TI, teimosamente se recusam a aprender qualquer tipo de script. Em breve não haverá lugar para as pessoas desta indústria. Eles são parte de uma geração que está morrendo.

( eu não estou falando de pessoas velhas, quero dizer isso figurativamente.: P )

• Is there still a place for engineers who do not/cannot keep up in the DevOps paradigm?

Não. Tudo o que eles fazem pode ser e eventualmente será automatizado.

Eu diria que talvez nunca devêssemos chamá-los de "engenheiros". Já é ruim o suficiente que a indústria de TI tenha se apropriado da palavra 'engenheiro' para nós mesmos, o que na minha opinião é um tipo de insulto aos engenheiros que passaram anos em programas de ensino superior e obtendo certificações legais para que pudessem pontes de design, arranha-céus, colecionadores de hádrons, etc ... esses são os engenheiros reais .

Mas há uma semelhança ... Se você quiser se chamar de 'engenheiro' na indústria de TI, isso significa que você cria coisas. Você é inventivo e conecta os pontos de novas maneiras que ninguém jamais imaginou antes. Você constrói coisas que ninguém mais sabia como valioso seria até que você fizesse isso.

Se você não codifica ou script, então não há como fazer muito com computadores além de apenas mantê-los, e talvez instalar um pacote de software ou dois. Talvez jogue um novo disco rígido na velha MSA. E nesse caso, eu chamaria você de administrador, claro, mas não necessariamente de engenheiro. E eu diria que muito do seu trabalho está em risco de ser automatizado.

• Are we simply to assume that some people will be left behind as these technologies evolve?

O mercado se adaptará. Pode ser que algumas pessoas não estejam fazendo salários de 6 dígitos quando não as merecem, o que acontece um pouco nesta indústria.

Eu acho que a criatividade, e não apenas a habilidade de codificação / script, é um fator chave. É essa criatividade que você precisa dizer para si mesmo: " Oh, ei, eu poderia automatizar isso! " e então a habilidade só entra em jogo depois disso. Se você se encontrar fazendo um script apenas depois que seu chefe lhe disser, então você pode não ter essa motivação ou essa criatividade que eu estava falando ... e essas são duas qualidades que são muito difíceis, talvez impossíveis para ensinar.

    

Answer 3

How does a sysadmin improve their shell scripting?

Como se melhora em alguma coisa? Leia livros, participe de aulas e aplique os princípios aprendidos. (Ou uma combinação dos métodos.) Isso é intencionalmente simplificado, já que não há nada de especial em aprender a escrever sobre aprender a cozinhar ou a consertar um carro.

Is there still a place for engineers who do not/cannot keep up in the DevOps paradigm?

Isso é difícil de responder dentro do escopo deste site (onde há uma necessidade de respostas claras / definidas às perguntas feitas.) Podemos prever que sim, mas há problemas com o modelo de DevOps. Eu sinto que é muito difícil para uma pessoa ser extremamente proficiente em ambas as disciplinas. A economia de custos de um funcionário de 2 por 1 é muito atraente para as empresas no momento, mas é difícil dizer se essa tendência chegou para ficar. Certamente é para o curto prazo.

Are we simply to assume that some people will be left behind as these technologies evolve?

No ritmo atual de como as coisas estão indo, sim. A maioria de vocês provavelmente está observando em seus próprios locais de trabalho. Você deve definitivamente estar acompanhando as listas de empregos e saber o que o mercado está exigindo atualmente. (Há muitas listagens de empregos para o Hadoop na sua região? Aprenda sobre o Hadoop.) Se você não acompanhar o mercado, estará se arriscando a ficar para trás.

    

Answer 4

Geralmente, não envia engenheiros juniores para um ambiente de produção complexo que é de missão crítica. Você tem engenheiros seniores para isso. Os ranks juniores devem ter permissão para trabalhar em sandboxes de desenvolvimento / teste.

Se você precisar de um engenheiro para a Tecnologia X e quiser preencher o papel internamente, encontre alguém disposto a aprendê-lo, encontrar treinamento estruturado e combinar os dois.

Descubra quais habilidades você precisa em um departamento. Encontre alguém disposto a aprendê-las. Ensine / distribua dinheiro para treinamento.

    

Answer 5

Is there still a place for engineers who do not/cannot keep up in the DevOps paradigm?

"devops" é apenas uma nova palavra para algo que os administradores de sistemas vêm fazendo há décadas.

Are we simply to assume that some people will be left behind as these technologies evolve?

Muito pelo contrário. Conforme o tempo passa, há apenas mais e mais necessidade de pessoas técnicas. Qualquer pessoa com algum tipo de conhecimento de engenharia e habilidades técnicas terá um lugar para trabalhar.