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

Na minha organização, trabalho com um grupo de funcionários da NOC, desenvolvendo engenheiros juniores e um punhado de engenheiros seniores; tudo com foco no Linux. Um passo interessante na maneira como a empresa desenvolve talentos é que existe um caminho desde o NOC até os altos escalões de engenharia. Vendo o conjunto de talentos como um recém-chegado relativo, vejo que há uma divisão nos conjuntos de habilidades que tende a crescer ao longo do 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 ...
• Outros são generalistas e podem navegar em várias tecnologias.
• Todos aprendem Linux (comandos, processos) suficientes para fazer o que precisam e usar diariamente.

Um fator diferenciador entre alguns 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 do Amazon AWS CloudFormation e outro que lida com a maior parte da infraestrutura do Puppet . Talvez um quarto dos engenheiros seja especialista em scripts de shell BASH.

Observando isso no contexto da demanda incrivelmente alta por habilidades de DevOps no mercado de trabalho , estou curioso para saber como outras organizações fomentam o desenvolvimento dessas habilidades e aumentam seu talento interno. O script não parece ser um conceito particularmente ensinável.

• Como um administrador de sistemas aprimora seus scripts de shell?
• Ainda existe um lugar para engenheiros que não conseguem / não conseguem acompanhar o paradigma do DevOps?
• Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que essas tecnologias evoluem? Tudo bem?

Tenho o benefício de entender o tamanho e a complexidade do seu ambiente. Como você trabalha para um provedor de nuvem / hospedagem, é seguro supor que você tenha um grande número de ambientes de pequeno e médio porte (10 a 100 servidores). Certamente existem 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 existem algumas coisas manuais que são feitas pelo sr. engenheiros como instalar o ESXi em um novo hardware ou configurar coisas como MPIO ou instalar módulos VMware para conjuntos específicos de hardware. Todas essas coisas podem e devem ser automatizadas.

Se sua equipe é capaz de executar a maior parte da carga de trabalho sem automatizar, na minha opinião você está sobrecarregado. Qualquer equipe de TI que possa trabalhar um dia inteiro, consistindo principalmente de 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.

Portanto, em algum momento da sua organização, você aumentará para um tamanho em que se atrapalhará e desmoronará ou começará a automatizar quase tudo e se destacar. Certamente, os engenheiros seniores devem liderar a carga aqui, e talvez até trabalhando com os engenheiros juniores e a equipe do 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 podem ser ajustados 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á a eles um impulso para resolver um problema real . O que me leva ao meu ponto final. Livros e exemplos são muito bons, mas háproblema que eles enfrentam. Dê a eles uma meta, como todos os novos servidores para o inquilino x devem ter determinados módulos ESXi instalados e, em seguida, trabalhem com eles para alcançá-lo. Em seguida, adapte o script para trabalhar em um ambiente com vários participantes.

Como um administrador de sistemas aprimora seus scripts de shell?

Por precisar , como descrito acima.

Ainda existe um lugar para engenheiros que não conseguem / não conseguem acompanhar o paradigma do DevOps?

Claro, existem muitas organizações que não podem ou não mudarão para a metodologia DevOps. Eles parecem ser opções cada vez mais chatas , mas são opções mesmo assim.

Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que essas tecnologias evoluem?

Como com qualquer nova tecnologia - sim.

Você nunca terá alguém realmente investindo em aprendê-lo até ver o valor nele. Se eles podem realizar suas tarefas diárias manualmente, você fica sobrecarregado e não há incentivo.

• Como um administrador de sistemas aprimora seus scripts de shell?

Prática, misturada com unidade. Parece banal, mas você tem que querer ficar melhor, além de prática. Se você realmente não gosta de scripts, pode ser forçado a fazê-lo por anos quando precisar, e nunca ficará realmente bom nisso. Se você não quiser melhorar, pode sentar-se ao lado do melhor roteirista do mundo todos os dias no trabalho e não adquirir uma fração da habilidade que poderia ter.

Conheço aquelas pessoas que, apesar de trabalharem em TI, se recusam teimosamente a aprender qualquer tipo de script. Em breve não haverá lugar para essas pessoas nesta indústria. Eles fazem parte de uma geração moribunda.

( Não estou falando de pessoas idosas, quero dizer figurativamente.: P )

• Ainda existe um lugar para engenheiros que não conseguem / não conseguem acompanhar o paradigma do DevOps?

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

Eu argumentaria que talvez nunca devêssemos chamá-los de 'engenheiros'. É ruim o suficiente para que a indústria de TI apropriada a palavra 'engenheiro' para nós mesmos, que na minha opinião é uma espécie de insulto aos verdadeiros engenheiros que anos passados em programas de ensino superior e obtendo certificações legais para que pudessem projetar pontes, arranha-céus, aceleradores hádron , etc ... esses são os verdadeiros engenheiros.

Mas há uma semelhança ... Se você quiser se chamar de 'engenheiro' no setor de TI, isso significa pelo menos que você cria coisas. Você é inventivo e conecta os pontos de novas maneiras que ninguém jamais pensara antes. Você constrói coisas que ninguém mais sabia o quão valioso seria até que você o fizesse.

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

• Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que essas tecnologias evoluírem?

O mercado vai se adaptar. Pode ser que algumas pessoas não recebam salários de seis dígitos quando na verdade não os merecem, o que acontece bastante nesse setor.

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 encontra escrevendo algo apenas depois que seu chefe manda, talvez você não tenha a motivação ou a criatividade de que eu estava falando ... e essas são duas qualidades que são muito difíceis, talvez impossíveis, de ensinar.

Como um administrador de sistemas aprimora seus scripts de shell?

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

Ainda existe um lugar para engenheiros que não conseguem / não conseguem acompanhar o paradigma do DevOps?

É difícil responder dentro do escopo deste site (onde há um requisito para respostas claras / definidas às perguntas feitas.) Podemos prever que sim, mas há problemas com o modelo DevOps. Eu sinto que é muito difícil para uma pessoa ser extremamente proficiente em ambas as disciplinas. A economia de custo de um funcionário 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.

Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que essas tecnologias evoluem?

No ritmo atual de como as coisas estão indo, sim. A maioria de vocês provavelmente está observando isso em seus próprios locais de trabalho. Você definitivamente deve acompanhar as listagens de emprego e saber o que o mercado está exigindo atualmente. (Existem muitas listas de empregos para o Hadoop na sua área? Aprenda o Hadoop.) Se você não acompanhar o mercado, corre o risco de ser deixado para trás.

Geralmente, não se envia engenheiros juniores para um ambiente de produção complexo que é essencial para a missão. Você tem engenheiros seniores para isso. As fileiras juniores devem ter permissão para trabalhar em caixas de areia de desenvolvimento / teste.

Se você precisa de um engenheiro para a Tecnologia X e deseja desempenhar a função internamente, encontre alguém disposto a aprendê-la, encontre treinamento estruturado e combine os dois.

Descubra quais habilidades você precisa em um departamento. Encontre alguém disposto a aprendê-los. Ensinar / Distribuir dinheiro para treinamento.

Ainda existe um lugar para engenheiros que não conseguem / não conseguem acompanhar o paradigma do DevOps?

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

Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que essas tecnologias evoluem?

Muito pelo contrário. Com o passar do tempo, há cada vez mais necessidade de pessoal técnico. Qualquer pessoa com algum tipo de conhecimento de engenharia e habilidades técnicas terá um local para trabalhar.