O que IT support parece por dentro
Meu primeiro emprego em tecnologia foi suporte de TI na Oi. Não era o que eu imaginava. Foi melhor — porque me ensinou o que a maioria dos devs nunca aprende.
Antes de escrever a primeira linha de código profissionalmente, passei anos mantendo redes de telecom funcionando.
Isso não foi desvio de rota. Foi fundação.
O que IT support parece de fora: pessoa que resolve "o computador não liga" e reseta senha. O que parece por dentro, quando você está nele de verdade: engenharia de sistemas distribuídos em miniatura, com usuário real esperando e tolerância a erro próxima de zero.
Primeiro mês na Oi, fui chamado para resolver um problema de conectividade num escritório regional. Equipamentos ligados, cabos conectados, luz verde onde deveria ser verde. Mas nada funcionava.
Passou uma hora. Depois duas. Meu supervisor chegou, olhou por três minutos, e perguntou: "você verificou a tabela de roteamento?"
Não tinha. Não sabia o que era tabela de roteamento.
Ele abriu o terminal, rodou um comando, mostrou a saída. Uma rota estática configurada errada estava mandando o tráfego para lugar nenhum. Dois minutos de correção. Funcionou.
Essa cena se repetiu em variações diferentes durante meses. O padrão era sempre o mesmo: eu olhava para o sintoma, ele olhava para o sistema.
O que aprendi que nenhum tutorial de dev cobre:
Rede não é abstração. Quando você escreve fetch('https://api.exemplo.com'), existe uma cadeia inteira de coisas físicas que têm que funcionar: cabo ou sinal, switch, roteador, DNS, firewall, load balancer, servidor, resposta voltando pelo mesmo caminho. Qualquer um desses pode falhar. Dev que nunca trabalhou com infra tende a assumir que a rede é confiável. Não é.
Fault isolation é uma habilidade. Problema em sistema distribuído raramente está onde parece estar. A disciplina de isolar — "funciona nesse segmento mas não nesse?" — é a mesma que uso hoje para diagnosticar problemas em plataforma com 200+ serviços.
Documentação salva mais do que memória. Rede de telecom tem configurações que ninguém lembra de cabeça. Runbook existe por razão. O dev que "sabe de cabeça" como o sistema funciona é o gargalo quando vai de férias.
Monitoramento é diferente de logging. Logging diz o que aconteceu. Monitoramento diz o que está happening agora e o que vai acontecer se continuar assim. Aprendi a diferença antes de saber os nomes formais.
Tinha uma frase que o meu supervisor usava que ficou:
"Se você não consegue explicar o caminho que o pacote faz do ponto A ao ponto B, você não entende a rede."
Substituí "pacote" por "request" e uso essa frase até hoje. Se você não consegue traçar o caminho completo de uma requisição — do cliente até o banco de dados e de volta — você não entende o sistema que opera.
Essa habilidade, aprendi no suporte. Não em dev.
A maioria dos engenheiros de software que conheço nunca fez suporte. Poucos nunca viram o interior de um rack. Ainda menos sabem o que traceroute produz e o que fazer com a saída.
Isso não é crítica — é lacuna. Lacuna que cria engenheiros que sabem escrever código mas não sabem onde o código falha quando o ambiente não coopera.
Os três anos que passei em TI antes de virar dev foram investimento. Demorei para entender isso. Na época parecia que estava perdendo tempo enquanto todo mundo "programava de verdade".
Na primeira vez que precisei debugar um problema de latência que não era no código — era num hop de rede entre dois serviços — entendi o que aqueles anos valeram.
Essa semana: qual é a camada do sistema que você opera que você nunca olhou por dentro?