Na minha organização, trabalho com um grupo de funcionários do NOC, jovens engenheiros juniores e um punhado de engenheiros seniores; tudo com foco em Linux. Um passo interessante na forma como a empresa desenvolve talentos é que existe um caminho desde o NOC até os cargos de engenharia sênior. Vendo o conjunto de talentos como relativamente novo, vejo que há uma divisão nos conjuntos de habilidades que tende 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 outros que são generalistas e podem navegar em múltiplas tecnologias.
- Todos aprendem Linux (comandos, processos) suficiente para fazer o que precisam e usam diariamente.
Um fator diferenciador entre alguns membros da equipe é o quão bem eles adotam metodologias de script, automação e gerenciamento de configuração. Por exemplo, temos dois engenheiros que fazem a maior parte do trabalho da AmazonAWS CloudFormationtrabalho, e outro que lida com a maior parte doFantochea infraestrutura. Talvez um quarto dos engenheiros seja adepto de scripts de shell BASH.
Olhando para isso no contexto doincrivelmentealta demanda porHabilidades DevOps no mercado de trabalho, estou curioso para saber como outras organizações promovem o desenvolvimento dessas habilidades e aumentam seu talento interno. O script não parece um conceito particularmente ensinável.
- Como um administrador de sistema melhora seu script de shell?
- Ainda há lugar para engenheiros que não conseguem/não conseguem acompanhar o paradigma DevOps?
- Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que estas tecnologias evoluem? Tudo bem?
Responder1
Tenho o benefício de compreender 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 a médio porte (10 a 100 servidores). Certamente existem tarefas diárias que são realizadas pelo jr. engenheiros e funcionários do NOC que são repetitivos (criação de contas de usuário, configuração de agentes de backup, etc.). Da mesma forma, provavelmente existem algumas coisas manuais que são feitas pelo sr. engenheiros gostam de instalar ESXi em 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 realizar a maior parte de sua carga de trabalho sem automatizar, então, na minha opinião, você está com excesso de pessoal. Qualquer equipe de TI que consiga 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 comonecessárioe pode até serapavorante? Afinal, a necessidade é a mãe da inovação.
Então, em algum momento da sua organização, você crescerá até um tamanho em que irá tropeçar e desmoronar, ou começará a automatizar quase tudo e se destacar. Certamente, os engenheiros seniores deveriam liderar o ataque aqui, e talvez até mesmo trabalhar com os engenheiros juniores e a equipe do NOC para automatizar parte de sua carga de trabalho. Isso dá ao jr. engenheiros a oportunidade de ter a estrutura de muitos scripts para trabalhar, que podem ser ajustados para cada locatário e nova revisão de hardware conforme necessário. Isso elimina o pensamento assustador de "Oh meu Deus, por onde eu começo?" da equação e dá-lhes um impulso para resolver umrealproblema. O que me leva ao meu ponto final. Livros e exemplos são muito bons, mas não há nada que possa substituir a sensação de realização de resolver um problema.realproblema que enfrentam. Dê a eles uma meta, como todos os novos servidores do locatário x, devem ter determinados módulos ESXi instalados e, em seguida, trabalhe com eles para alcançá-la. Em seguida, adapte o script para funcionar em um ambiente multilocatário.
Como um administrador de sistema melhora seu script de shell?
Porprecisandopara, conforme descrito acima.
Ainda há lugar para engenheiros que não conseguem/não conseguem acompanhar o paradigma DevOps?
Claro, existem muitas organizações que não podem ou não querem mudar para a metodologia DevOps. Eles parecem estar cada vez maistediosoopções, mas ainda assim são opções.
Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que estas tecnologias evoluem?
Como acontece com qualquer nova tecnologia – sim.
dr Você nunca terá ninguém realmente investindo em aprender até que veja o valor disso. Se eles conseguirem realizar suas tarefas diárias manualmente, você terá excesso de pessoal e não haverá incentivo.
Responder2
• Como um administrador de sistema melhora seu script de shell?
Prática, misturada com motivação. Parece banal, mas você tem quequererpara melhorar, além de praticar. Se você realmente não gosta de escrever scripts, pode ser forçado a fazê-lo durante anos, quando necessário, e nunca ficar bom nisso. Se você nãoquererpara melhorar, você poderia 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 com 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 que está morrendo.
(Não estou falando de idosos, quero dizer isso figurativamente. :P)
• Ainda há lugar para engenheiros que não conseguem/não conseguem acompanhar o paradigma DevOps?
Não. Tudo o que eles fazem pode ser e eventualmente será automatizado.
Eu diria que talvez nunca devêssemos tê-los chamado de “engenheiros”. Já é suficientemente mau que a indústria das TI se tenha apropriado da palavra “engenheiro”, o que, na minha opinião, é um pouco insultuoso para orealengenheiros que passaram anos em programas de ensino superior e obtiveram certificações legais para que pudessem projetar pontes, arranha-céus, colisores de hádrons, etc... esses são osrealengenheiros.
Mas há uma semelhança... Se você quiser se autodenominar um 'engenheiro' no setor de TI, isso significa pelo menos que vocêcriarcoisas. Você éinventivoe você conecta os pontos de novas maneiras que ninguém jamais imaginou antes. Você constrói coisas que ninguém mais sabia o quão valiosas seriam até que você as fizesse.
Se você não codifica ou cria scripts, não há como fazer muito com os computadores além de apenas mantê-los e talvez instalar um ou dois pacotes de software. Talvez coloque um novo disco rígido no antigo MSA. E nesse caso, eu chamaria você de administrador, claro, mas não necessariamente de engenheiro. E eu diria que grande parte do seu trabalho corre o risco de ser automatizado.
• Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que estas tecnologias evoluem?
O mercado vai se adaptar. Pode ser que algumas pessoas não ganhem salários de 6 dígitos quando na verdade não os merecem, o que acontece bastante neste 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 ação depois disso. Se você estiver escrevendo algoapenasdepois que seu chefe mandar, você pode não ter aquele ímpeto ou criatividade de que estava falando... e essas são duas qualidades que são muito difíceis, talvez impossíveis, de ensinar.
Responder3
Como um administrador de sistema melhora seu script de shell?
Como alguém fica melhor em alguma coisa? Leia livros, assista às aulas e depois aplique os princípios aprendidos. (Ou uma combinação dos métodos.) Isso é simplificado demais intencionalmente, pois não há nada de especial em aprender scripts em vez de aprender a cozinhar ou a consertar um carro.
Ainda há lugar para engenheiros que não conseguem/não conseguem acompanhar o paradigma DevOps?
É difícil responder a isso no escopo deste site (onde há um requisito de respostas claras/definidas às perguntas feitas). Podemos prever que sim, mas há problemas com o modelo DevOps. Sinto que é muito difícil para uma pessoa ser extremamente proficiente em ambas as disciplinas. A economia de custos de um funcionário 2 por 1 é muito atraente para as empresas no momento, mas é difícil dizer se essa tendência veio para ficar. Certamente é para o curto prazo.
Devemos simplesmente assumir que algumas pessoas serão deixadas para trás à medida que estas tecnologias evoluem?
No ritmo atual de como as coisas estão, sim. A maioria de vocês provavelmente está observando isso em seus próprios locais de trabalho. Definitivamente, você deve acompanhar as listas de empregos e saber o que o mercado está exigindo atualmente. (Há muitas listas de empregos para o Hadoop na sua área? Aprenda Hadoop.) Se você não acompanhar o mercado, corre o risco de ficar para trás.
Responder4
Ainda há lugar para engenheiros que não conseguem/não conseguem acompanhar o paradigma DevOps?
“devops” é apenas uma palavra nova 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 estas tecnologias evoluem?
Muito pelo contrário. Com o passar do tempo, há cada vez mais necessidade de pessoal técnico. Qualquer pessoa com qualquer tipo de conhecimento de engenharia e habilidades técnicas terá um lugar para trabalhar.