S1: o que anos de infra ensinam sobre sistemas antes de você escrever uma linha de código
Saindo da Oi para a universidade, o que carreguei não era certificação nem título — era modelo mental de como sistemas falham, dependem uns dos outros, e precisam de governança para funcionar. Uma síntese da S1.
Em 2016 saí da Oi Telecomunicações depois de alguns anos como analista de TI para ir estudar engenharia de computação.
Sem certificação formal de infraestrutura. Sem título de sênior. Só um conjunto de modelos mentais que levei anos para nomear — e que só reconheci pelo nome depois de anos estudando sistemas de software.
O que carreguei de S1 que voltou em todo papel técnico depois:
Sistemas têm dependências que não estão visíveis de uma perspectiva parcial. Aprendi isso quando removi logs que quebraram serviço que dependia deles. Aprendi de novo cada vez que mudança "simples" em produção causou efeito colateral inesperado. Em software: o serviço que você está modificando tem consumidores que você não conhece.
Estado documentado antes de mudança é pré-requisito, não opcional. Aprendi documentando rede sem inventário. Aprendi quando placa de rede voltou com nome diferente e não lembrava a configuração original. Em software: migration sem rollback é aposta.
Processo de comunicação antes de ação em produção existe para bridgear lacunas de contexto, não para criar burocracia. Aprendi depois de causar downtime com decisão bem-intencionada que ninguém sabia que havia tomado. Em software: change management não é overhead — é protocolo de coordenação.
Menor privilégio é princípio de design, não paranoia. Aprendi criando VLAN de visitante. Aprendi toda vez que configurei GPO com escopo mínimo necessário. Em software: service que tem acesso a mais do que precisa é risco, não conveniência.
Diagnóstico começa com perguntas, não com ações. Aprendi observando colega mais experiente. Aprendi toda vez que fui direto para ação e demorei mais do que se tivesse perguntado "quando começou? alguém fez alguma mudança?" primeiro.
Não vim para a universidade como estudante que nunca havia visto sistema real. Vim como alguém que havia operado infraestrutura real, visto sistemas falhar de formas não-óbvias, entendido que sistema não é só código — é hardware, configuração, processo, e as pessoas que operam tudo isso.
Esse contexto mudou como aprendi engenharia de software. Quando o professor explicava protocolo de rede, eu já tinha visto aquele protocolo falhar de formas específicas. Quando a matéria de sistemas operacionais falava de processo de comunicação entre processos, eu tinha intuição do que acontece quando o canal de comunicação falha.
Infra antes de código não é caminho pior. É caminho que dá textura ao que você aprende depois.
Quando falo com engenheiros que começaram direto em software sem passar por operações, noto que às vezes falta a intuição de que sistema em produção não é o mesmo que sistema funcionando. Produção tem carga real, usuários reais com comportamento não-previsto, hardware que falha, rede que flutua.
Quem operou servidor físico sabe no corpo o que "disponibilidade" significa. Sabe o que é acordar às 3h porque um serviço caiu. Sabe a diferença entre "funciona no meu ambiente" e "funciona em produção."
Isso não é nostalgia de "era melhor quando era mais difícil." É só reconhecimento de que certos modelos mentais são mais fáceis de construir a partir de experiência concreta.
S1 foi a base. S2 foi a teoria. O que aprendi depois faz mais sentido por causa das duas.
Essa semana: qual é a experiência mais "low-level" que você tem — e você já parou para mapear o que ela te ensinou sobre sistemas em geral?