Qual futuro dos sysadmins?

Standard

Nesse texto será apresentado uma tendência que aponta para uma possível transformação, ou até mesmo extinção, do papel de Sysadmin como ele é entendido hoje. Será apresentado alguns dados que evidenciam essa reflexão, assim como caminhos para a ressignificação do papel de operações na TI.

Nos últimos anos se tornou relevante uma mudança drástica de como criamos, mantemos, configuramos e operamos os serviços de TI, pois até então existia uma grande dependência de um trabalho, muitas vezes puramente manual, para disponibilização de ambientes para servir aplicações em geral.

A automação de infraestrutura trouxe uma nova perspectiva para esses trabalhos, pois agora é possível transcrever em código o ambiente necessário para suportar sua aplicação, e as ferramentas escolhidas para esse trabalho se encarregam de configurar toda infraestrutura necessária, sem a necessidade de qualquer intervenção humana, na maioria dos casos.

A título de padronização do texto, será usado o termo “operações” sempre que nos referirmos ao Sysadmin como uma área da TI e não apenas como um cargo.

De acordo o “Ministério do Trabalho dos EUA” a definição do sysadmin é:

  • Determinar o que é necessário para configurar sistemas computacionais e rede antes de configurá-los
  • Instalar todo equipamento de rede e software, fazendo a manutenção necessária como também mantê-los atualizados
  • Manter sistemas computacionais e rede seguros e garantir que todos sistemas estão operando corretamente
  • Coletar dados na ordem para avaliar e otimizar a performance de sistemas ou rede
  • Adicionar usuários numa rede, atribuir e atualizar permissões de segurança na rede
  • Treinar usuários para o uso adequado dos equipamentos e sistemas

Levando em consideração a velocidade com que o negócio tem demandado a equipe de desenvolvimento mudanças constantes no seu serviço, todo impacto para alterações na infraestrutura para suportá-las sempre recaiam sobre o time responsável por esse ambiente, que nesse caso eram os Sysadmins, o que os tornavam um gargalo para inovação do negócio, uma vez que raramente eles conseguiam entregar as mudanças em um tempo esperado.

Não é o ponto estigmatizar essa área que foi tão importante para TI de uma empresa, até porque estamos falando de um setor no qual a maior inovação para a manipulação desses ambientes praticamente se resumiu à máquina virtual, que na prática não proporcionou um aumento relevante para replicação em larga escala de ambientes complexos, muito menos abstraiu o trabalho ou até mesmo criou mecanismos que pessoas menos qualificadas pudessem colaborar sem necessariamente ter perfis administrativos no sistema.

No modelo de automação de infraestrutura, que daqui pra frente chamaremos de “infraestrutura como código”, é possível:

Abstrair o trabalho de criação, manutenção e destruição dos ambientes, uma vez que usando determinada sintaxe de alto nível de programação, aliada a aplicativos específicos, é possível manipular os ambiente necessários em interações realizadas por processos automáticos ou com baixa interação humana especializada. Nesse caso, a especialização é necessária apenas no momento da concepção e manutenção do código e não do ambiente em si, que pode ser manipulado sempre a partir do conjunto de necessidades passada no código fonte.

Acesso de pessoas menos qualificadas para manipulação desses ambientes, uma vez que os códigos podem ser alvo de auditoria de pessoas mais especializadas antes do mesmo ser colocado no que chamamos de “produção”, que basicamente é alterar ambientes que impactam diretamente no negócio da empresa. Vale salientar que até mesmo parte do processo de validação desse código de um iniciante pode ser automatizado.

Não bastasse o processo de automação da infraestrutura, uma nova tendência – que é a nuvem – acrescenta mais elementos para essa análise. De acordo com o wikipedia nuvem é:

“Um tipo de computação baseada na internet, que provê recursos de processamento computacional compartilhado, armazenamento para computadores e outros dispositivos por demanda.”

Com base nessa definição, podemos dizer que a nuvem é uma espécie de datacenter por demanda, e, por conta disso, talvez seja correto pensar que o modelo de empresas tradicionais no Brasil, que inicia suas atividades adquirindo servidores, pagando contrato de manutenção, depreciação e afins, agora tem a oportunidade de comprar apenas parcelas dessa infraestrutura à medida que seu negócio demanda crescimento.

De acordo com o Gartner em 2011, na média as empresas dedicavam 70% da sua TI para Operações, enquanto 25% era para modificar essa infraestrutura e apenas 5% para inovação da TI, mas que esses números tendem a mudar drasticamente com o passar do tempo e sua projeção para 2020 é que operação seja apenas 35%, quando a modificação passaria a 50% e inovação 15%.

De acordo com o Registro Anual de Informações Sociais do Ministério do Trabalho para trabalhadores de TI do Estado de São Paulo, o número de empregados na área de “Desenvolvimento de Software” em geral praticamente triplicou (213,27%) entre 2006 e 2015, quando a área de “Suporte Técnico” aumentou em uma proporção bem menor (59,70%) na mesma época.

Esses movimentos não parece estar descontextualizado, pois ao que parece as empresas estão tentando focar nas áreas que estão mais próximas do negócio e tentando automatizar ou abstrair áreas mais distantes. Nesse cenário podemos dizer que o desenvolvedor está intimamente ligado ao negócio de TI por definição, pois cabe a ele implementar as mudanças nos serviços, quando para operação cabe o papel de manter a infraestrutura mínima para o negócio se estabelecer.

Em um mundo onde essa infraestrutura pode ser comprada por demanda, criada, testada, mantida e destruída via código, que é afinal de contas o domínio dos desenvolvedores, a tarefa de operações perde um pouco a sua relevância quando falamos de presença em escala.

Levando em consideração que a infraestrutura não vai simplesmente sumir, fica evidente que será ainda necessário a existência de pessoas responsáveis por grandes salas de infraestrutura, mas o que esse texto fala é sobre oportunidades para sysadmin em escala e não pontualmente em alguns poucos datacenters espalhados pelo mundo que compõe a nuvem computacional.

Tendo em mente que os espaços onde se concentrará a infraestrutura serão cada vez em menor quantidade e mais automatizados, a demanda em larga escala para esse tipo de profissional será cada vez menor e mais especializada.

Não quero com isso afirmar que o desenvolvedor hoje é capaz de criar, testar, manter e destruir de forma eficaz e segura toda infraestrutura com base em código, mas acredito que com o passar do tempo alguns desenvolvedores (Ou quem sabe QA?) poderão ter como especialização a manipulação de código de infraestrutura e assim esses novos profissionais poderão atender a área de operações, que afinal de contas acabaria com o problema fundamental que a cultura DevOps busca resolver, comunicação entre as áreas distintas. Nesse caso seria uma grande área única com suas mais diferentes especializações no time.

É possível afirmar que hoje um desenvolvedor mais “antenado” às novidades da automação tem reais capacidades para viabilizar rapidamente ao menos seu ambiente de desenvolvimento, assim como ajudar de forma bem efetiva no estabelecimento desse ambiente em homologação e até mesmo produção. E é nesse momento que parece existir uma saída para a área de operações.

Operações pode se transformar em uma espécie de consultoria interna, que estaria focada em validar, ajudar e/ou disseminar tudo que seja relacionado a assuntos de infraestrutura, claro que esse caminho não seria o suficiente para abarcar todo contingente de sysadmins tradicionais que temos hoje, o que nos leva ao segundo caminho.

Uma outra possibilidade para área de operações é se aproximar mais do negócio, ou seja, naturalmente trabalhar com aspectos mais dinâmicos e menos operacionais, pois essa parte seria automatizada. Estar mais perto das inovações e mudanças do negócio implica estar mais perto do código, o que não necessariamente implica em virar desenvolvedor de software.

O sysadmin, no contexto de uma pessoa que domina muito a infraestrutura, aliado com conhecimento de automação de infraestrutura e um adendo do processo de desenvolvimento de software pode ser um ótimo QA, pois esse normalmente tem um papel de mantenedor da qualidade, automação, processo de deploy e afins, dessa forma podem ser considerados nesse conjunto de atividades já exercidas por esse papel.

Tanto desenvolvedor como QA são caminhos com demanda o suficiente para atender a migração dos sysadmins convencionais em relação tanto a quantidade de vagas, como salários equivalentes.

Vale salientar que em momento algum eu falo sobre os cargos que algumas pessoas denominam como “DevOps”, pois por definição esse cargo não existe, ao menos não nos termos que maioria das empresas o denomina. Normalmente DevOps é a pessoa responsável por cuidar do deploy, automação e afins. Basicamente um Sysadmim em migração para QA ou gestor de configuração.

O caminho para Sysadmin daqui para frente é relativamente tortuoso, pois demanda uma escolha e mudança relativamente drástica de como ele previamente se preparava, pois não é somente aprender as sintaxes das ferramentas de automação de infra e sim se debruçar sobre anos de estudos da engenharia de software, que passa por padrões de projeto, testes automatizados e afins.

Enfim, há possibilidades para os sysadmins se resignificar enquanto profissionais relevantes e bem pagos para o mercado que se demonstra há médio prazo. Basta acreditarem nessa análise e iniciarem os estudos o quanto antes.

Fontes:

http://www.infoworld.com/article/2999240/devops/beyond-devops-embrace-infrastructure-as-code.html
https://www.quora.com/Does-system-administration-have-any-future
https://community.spiceworks.com/topic/1265732-infrastructure-as-code-devops-the-cloud-and-you
https://www.gartner.com/doc/1855718/executive-summary-new-skills-new