A cada poucos meses um serviço importante falha de um jeito que arrasta boa parte da internet junto, e a causa acaba sendo algo na camada que todo mundo presumia ter sido abstraída.
Abstração esconde a camada, não a apaga
A história contada sobre infraestrutura nos últimos quinze anos é que ela desapareceu dentro da nuvem. Servidores viraram instâncias, depois contêineres, depois funções. Redes viraram configuração. Armazenamento virou uma interface.
Cada um desses movimentos é real e útil, e nenhum deles eliminou nada. O pacote ainda precisa chegar a um destino. O nome ainda precisa ser resolvido. O certificado ainda precisa ser válido e estar em dia. O disco ainda tem capacidade. O relógio ainda precisa concordar com outros relógios.
O que mudou foi quem percebe quando um desses falha, e o quão difícil é enxergar isso.
Abstração afasta a falha de quem a sofre, o que torna o defeito mais difícil de encontrar e a pessoa capaz de encontrá-lo mais valiosa.
Esse é o argumento prático para essa trilha. Não é nostalgia de montar servidores em rack, mas a constatação de que o número de pessoas capazes de raciocinar sobre o que realmente está acontecendo por baixo caiu mais rápido do que a necessidade delas.
O que a trilha cobre
O escopo: sistemas operacionais, hardware, redes, servidores, administração e depuração.
Quatro áreas.
Redes. Endereçamento, roteamento, resolução de nomes, balanceamento de carga, firewalls e o caminho que uma requisição de fato percorre.
Sistemas operacionais. Processos, permissões, sistemas de arquivos, serviços e logs, nas plataformas que a organização roda.
Identidade e diretório. Autenticação, autorização, certificados e os sistemas que os emitem.
Operações. Monitoramento, backup e recuperação, capacidade, correções e depuração estruturada.
É sempre o DNS, e por que essa piada é verdadeira
A piada recorrente entre engenheiros de infraestrutura aponta para algo real sobre como os sistemas falham.
A resolução de nomes está por baixo de quase tudo, é invisível quando funciona, e produz sintomas que parecem problemas completamente diferentes. Uma aplicação parece lenta quando a resolução está expirando. Um serviço parece fora do ar quando um registro aponta para um endereço desativado. Uma mudança se propaga de forma desigual por causa de cache em várias camadas, então o sistema está quebrado para alguns usuários e funcionando para outros, o padrão de falha mais difícil de diagnosticar.
Outros três membros da mesma família causam uma parcela parecida de incidentes pelo mesmo motivo.
Certificados. Eles expiram. Numa data conhecida com anos de antecedência. Apagões importantes em grandes organizações já foram causados exatamente por isso, repetidas vezes, porque a renovação era manual e a pessoa que sabia disso saiu da empresa.
Tempo. O desvio de relógio quebra protocolos de autenticação, invalida verificações de certificado, corrompe a correlação de logs e faz sistemas distribuídos se comportarem de forma incoerente. Aparece como problema de autenticação, então as pessoas investigam autenticação.
Roteamento e caminho. Rotas assimétricas, mudanças de caminho, regras de firewall adicionadas para um propósito e afetando outro. Os sintomas aparecem de forma intermitente e só para algumas origens.
O que une esses casos é que cada um é infraestrutura da qual todo mundo depende e que ninguém é dono, e cada um produz sintomas em uma camada bem distante da causa. Engenheiros que sabem verificar isso primeiro resolvem em minutos o que, de outra forma, levaria um dia.
Onde isso se encaixa no domínio
Sistemas de TI e redes de computadores é a sétima de oito trilhas no domínio de IA, dados e computação da Astra Trainer, e funciona como linha de suprimento para o resto dele. Computação em nuvem e DevOps, cibersegurança e platform engineering recrutam todos daqui, e todos se apoiam no entendimento que essa trilha constrói.
Conecta-se mais diretamente com ciência da computação pelo modelo de sistema operacional e rede, e com cibersegurança, onde a capacidade de raciocinar sobre o que um sistema realmente está fazendo é a base da detecção e resposta. Você pode ver as oito trilhas aqui.
Depuração é um método, não um talento
A capacidade mais transferível e menos ensinada dessa trilha. É tratada como algo que as pessoas têm ou não têm, e é um procedimento.
Estabeleça o que realmente mudou. Sistemas que funcionavam ontem e falham hoje geralmente mudaram, mesmo quando todo mundo diz que nada mudou. Implantações, renovações de certificado, atualizações de regras, credenciais expiradas, um disco cheio cruzando um limite.
Defina o escopo com precisão. Todos os usuários ou alguns. Todos os locais ou um. O tempo todo ou de forma intermitente. Cada resposta elimina categorias inteiras de causa, e a imprecisão aqui é o motivo pelo qual as investigações se perdem.
Trabalhe ao longo do caminho. Uma requisição atravessa uma sequência conhecida de componentes. Teste em pontos ao longo dela e determine onde o comportamento deixa de corresponder ao esperado. Isso converte um problema aberto em uma busca com resposta finita.
Mude uma coisa de cada vez. Mudar várias coisas e descobrir que funcionou deixa você sem saber por quê, o que significa que não dá para prevenir nem consertar da próxima vez.
Leia os logs de verdade. Não o último erro, que costuma ser um efeito colateral, mas a primeira anomalia e a sequência ao redor dela, com horários correlacionados entre sistemas.
Saiba quando restaurar em vez de diagnosticar. Durante um apagão, restaurar o serviço e investigar depois costuma ser correto. Confundir recuperação com causa raiz é o motivo de o mesmo incidente se repetir.
Ensinado de forma explícita, isso torna engenheiros comuns dramaticamente mais eficazes. Deixado implícito, as pessoas desenvolvem isso ao longo de anos, ou nunca.
O problema de carreira que essa trilha realmente tem
Vale a pena nomear com clareza, porque é a restrição real e não é técnica.
O trabalho de infraestrutura é tratado como despesa indireta. Aparece nos orçamentos como custo, é medido pela ausência de problemas, e é notado quase exclusivamente quando algo falha. Desenvolvimento constrói coisas que são anunciadas. Infraestrutura mantém as coisas funcionando, o que não gera anúncio nenhum.
Quatro consequências decorrem disso.
Salário e status ficam atrás de funções adjacentes com dificuldade comparável ou menor, o que empurra gente capaz para fora da área.
O investimento chega depois dos incidentes e recua em seguida, então a capacidade é construída de forma reativa.
A terceirização eliminou o terreno de formação. As funções juniores onde o entendimento de infraestrutura era construído foram, em muitas organizações, terceirizadas, o mesmo bloqueio de funil descrito na trilha de cibersegurança.
O conhecimento não é documentado e é pessoal. Quais sistemas importam, o que é normal, onde está a dependência estranha. Ele vai embora com a pessoa, e o substituto o reconstrói devagar e a um custo alto.
Uma organização que quer capacidade em nuvem, segurança e plataforma deveria reconhecer que está atualmente subinvestindo na população da qual essas disciplinas recrutam, e que essa é uma decisão que pode reverter a baixo custo.
As funções, nomeadas
Administradores de sistemas, nas principais plataformas.
Engenheiros e arquitetos de rede.
Engenheiros de infraestrutura.
Especialistas em identidade e diretório.
Engenheiros de armazenamento e backup, cuja importância fica óbvia exatamente uma vez.
Especialistas em virtualização.
Engenheiros de computação de usuário final e endpoint.
Service desk e suporte técnico, a porta de entrada mais comum para todo o domínio.
Técnicos de data center, uma população que voltou a crescer com a expansão da capacidade computacional.
Quem pode ser treinado para isso
Equipe de service desk e suporte. O caminho clássico e ainda o melhor. Já enxergam todo o parque de máquinas, sabem o que quebra e têm instinto de depuração que o treinamento estruturado transforma em método.
Técnicos de telecomunicações. Para redes, trazendo a camada física e de transmissão.
Pessoal de comunicações e sistemas de informação das Forças Armadas. Frequentemente excelentes, chegando com habilidade técnica e disciplina operacional.
Eletricistas e técnicos de sistemas prediais. Para trabalho de data center e infraestrutura física.
Qualquer pessoa que já administrou sistemas informalmente, em uma pequena empresa ou como a pessoa a quem os outros recorrem. Capacidade real sem reconhecimento formal.
Desenvolvedores. Para funções de infraestrutura e plataforma, precisando da metade operacional que nunca tiveram.
Pessoas em transição de carreira vindas de funções operacionais em logística, fabricação ou utilidades, onde disciplina de processo e trabalho em turnos se transferem diretamente.
Acesso, controle de mudanças e obrigações de continuidade. Acesso administrativo a sistemas de produção é uma posição de alto privilégio, governada por requisitos de gestão de mudanças, registro e segregação de funções, e em setores regulados por arcabouços de controle específicos. A capacidade de backup e recuperação está sujeita a obrigações legais e contratuais em muitos setores, e backups não testados já falharam repetidas vezes quando foram necessários. A Astra Trainer constrói capacidade técnica e consciência sobre onde esses deveres se aplicam. Não confere autorização para acessar nenhum sistema e não substitui os requisitos de controle organizacional.
O que levar disso
As abstrações de nuvem moveram a infraestrutura para trás de uma interface sem eliminá-la, o que tornou as falhas mais difíceis de localizar e as pessoas capazes de localizá-las mais valiosas.
Resolução de nomes, certificados, tempo e roteamento causam uma parcela desproporcional dos apagões porque são invisíveis até falharem e apresentam sintomas bem longe da causa.
Depuração é um método ensinável, não um talento, e ensiná-lo explicitamente é uma das intervenções técnicas de maior retorno disponíveis.
A restrição real aqui é status e funil de pessoas, não demanda, e a terceirização eliminou as funções juniores onde esse entendimento costumava ser construído.
E toda equipe de nuvem, DevOps e segurança recruta dessa população. Subinvestir aqui é subinvestir em todas elas.
A nuvem tornou as habilidades de infraestrutura obsoletas?
Não. Ela moveu a infraestrutura para trás de uma interface. Redes, sistemas operacionais, resolução de nomes e armazenamento continuam existindo e continuam falhando, e a abstração afasta a falha do sintoma, o que dificulta o diagnóstico.
Por que DNS, certificados e tempo causam tantos apagões?
Porque tudo depende deles, ninguém é dono deles, são invisíveis enquanto funcionam, e suas falhas produzem sintomas em uma camada completamente diferente. A expiração de certificados, em particular, já causou apagões importantes repetidos em datas conhecidas com anos de antecedência.
Depuração pode ser ensinada?
Sim. Estabeleça o que mudou, defina o escopo com precisão, teste ao longo do caminho da requisição, mude uma coisa de cada vez, leia os logs a partir da primeira anomalia em vez do último erro, e distinga restaurar o serviço de encontrar a causa raiz.
Por que a infraestrutura é subvalorizada?
Porque é medida pela ausência de problemas e notada só durante falhas, então aparece nos orçamentos como custo. Salário e status ficam atrás de funções adjacentes, o investimento chega de forma reativa após incidentes, e a terceirização eliminou as funções juniores que construíam essa habilidade.
Quem converte bem para funções de infraestrutura?
Equipe de service desk e suporte primeiro, depois técnicos de telecomunicações para redes, pessoal de comunicações das Forças Armadas, eletricistas para trabalho de data center, administradores informais, e desenvolvedores precisando da metade operacional.