titulo: "De Designer a DevOps: Uma Jornada Improvável" descricao: "Como passei por design, neurociências e ciência de dados até chegar ao DevOps — e as lições que aprendi deployando minha primeira infraestrutura direto em produção." data: "2025-12-03" autor: "Rany" tags: ["DevOps", "Carreira", "Kubernetes", "Terraform", "Aprendizado"] tempoLeitura: "12 min"
Introdução: O Caminho Improvável
A história aqui não é exatamente sobre mim, até porque, se fosse, seria longa demais, como todas as histórias de vida. Mas quero trazer um recorte, algo que faça sentido dentro dessa dinâmica de carreira e explique como cheguei até aqui.
Lá em 2010 saí da faculdade como Designer Gráfico e, no ano seguinte, fiz MBA em Marketing. Entre 2013 e 2015, fiz mestrado em tecnologias digitais e neurociências, passando por temas como games, semiótica, cognição, percepção e filosofia, até chegar a um assunto que realmente conectava todas essas áreas e fazia sentido pra mim naquele momento: os impactos dos ambientes digitais na cognição humana.
Naquele momento, nada indicava que alguns anos depois eu estaria lidando com clusters Kubernetes, Terraform e infra em produção.
A virada começou só em 2020, quando entrei na pós-graduação em Ciência de Dados. Ali tive a minha primeira experiência com código e tive a oportunidade de entender o que era e como funcionava uma infraestrutura em cloud (obrigado Google Skills Boost). Não era só criar dashboards ou brincar com visualizações, era Python, APIs, automação, infraestrutura. Então adotei a ideia de conectar as peças soltas do caminho e seguir.
A partir de 2022, comecei a mergulhar de fato no mundo da tecnologia. Fiz os treinamentos da LINUXtips: Linux básico, Terraform Essential, Terraform Avançado e, mais tarde, o PICK (Programa Intensivo de Container e Kubernetes), focado em containers e Kubernetes. Foi ali que DevOps deixou de ser um conceito distante para virar algo vivo, prático e cheio de desafios reais. O PICK é um programa realmente intenso e completo e definitivamente não é sobre só dar play, mas é o senso de comunidade que a escola, o treinamento e o time de professores emana, e isso é o grande diferencial. E aqui faço questão de abrir um grande parênteses para agradecer imensamente ao Jeferson Fernando e ao time de professores e mentores que foram essenciais nessa jornada, além dos amigos queridos que essa comunidade me trouxe.
E então veio 2025. Entrei em um novo trabalho em julho, ainda tentando juntar tudo que eu tinha aprendido. Em agosto, fiz meu primeiro deploy direto em produção, sem staging, sem ambiente espelhado, sem rede de segurança. Desculpa aos instrutores :-) mas foi o que o tempo mandou fazer na hora. Em setembro, eu estava reconstruindo tudo do zero porque, sinceramente, era necessário.
Não foi uma trajetória linear, planejada ou óbvia. Foi mais como tropeçar no caminho certo enquanto tentava fazer sentido de várias escolhas anteriores. Mas, olhando agora, cada parte, do design à neurociência, da análise de ambientes digitais ao DevOps tudo acabou se encaixando de um jeito que eu nunca teria previsto lá atrás.
Parte 1: "Move Fast and Break Things" (Agosto 2025)
O Deploy Arriscado
Agosto de 2025. Subi um cluster EKS em produção para testar. Arriscado? Muito. Mas era a única opção: não havia budget para staging, nem tempo para ambientes espelhados. Era produção ou nada.
O que existia na V2:
- EKS com dois nós m5.large
- PostgreSQL rodando como pod (e sem persistência digna)
- Um cemitério de YAMLs de "correções"
- S3 com credenciais dummy
- VPN conectando recursos on-premises
- Monitoramento praticamente inexistente
Os Cinco Problemas Que Quase Me Derrubaram (não é bait)
1. O Inferno do SSL/Ingress
Uma pasta cheia de arquivos com nomes como fix_ssl_ingress_03.yaml e a cada fix eu tinha outro problema. Nada funcionava, CORS quebrava, WebSocket não conectava, assets sumiam.
2. Upload failures erro 413
Arquivos maiores que 1MB eram rejeitados. O culpado? client_max_body_size no ingress controller. Levei três dias para notar.
3. Conflito de Portas
Cada parte da aplicação acreditava que deveria rodar em uma porta diferente. Confusão total.
4. Proxy Errado no Frontend
O frontend apontava para serviços que simplesmente não existiam no cluster.
5. URLs Hardcoded (fui piada entre os devs… rs)
Túnel de desenvolvimento usado no build de produção. A cada expiração, a aplicação morria.
O Teste Que Quebrou Tudo
Em agosto de 2025, rodei um load test com 100 usuários simultâneos.
Resultado: 70% de taxa de erro.
Foi doloroso, mas necessário. Descobri que o limite real na época era cerca de 50 usuários simultâneos, e definitivamente isso mudou toda a estratégia.
Parte 2: Sobrevivendo ao Caos
A Documentação de Emergência
No meio da bagunça, criei dois arquivos que viraram meus salva-vidas:
devops_doc.mdplano_emergencia.md
Eles nasceram de situações reais, às 23h, quando tudo estava quebrando, e no fim, funcionaram. Documentar era quase terapêutico. Na real, é uma dinâmica de anotar tudo que aprendi na academia, e que me salvou em organizar ideias.
Load Testing com Progressão
Aprendi a testar com calma: 10 → 25 → 50 → 100 usuários.
Cada fase mostrava um limite novo. Aos poucos, comecei a perceber o fluxo do cluster.
Scripts de Validação
Scripts simples, mas essenciais, rodavam antes e depois de cada deploy. Eles salvaram meu tempo e minha sanidade.
Parte 3: A Reconstrução — V4 (Setembro 2025)
Dois meses depois do primeiro deploy, decidi começar tudo de novo. Mas dessa vez com calma, estrutura e modularidade.
O Antes (V2): A Selva de YMLs
O Depois (V4): Terraform Modularizado
A nova versão separava ambientes, criava módulos reutilizáveis, automatizava validações e colocava ordem no caos.
Mudanças Cruciais
- PostgreSQL migrado para RDS
- Prometheus + Grafana para observabilidade
- Ambientes separados por pasta (dev, homolog, prod)
- Scripts automatizados para validar estados
O impacto foi real: error rate caiu, tempo de deploy despencou e o sistema ficou mais previsível.
Parte 4: O Que a Neurociência Me Ensinou Sobre DevOps
Essa é a parte da minha trajetória que não tem muito por aí.
1. Aprender Sob Estresse Controlado Funciona
Minha pesquisa mostrava que o cérebro consolida memória mais rápido quando há estresse controlado. Deployar sem staging? Estresse controlado total.
Foi caótico, mas o aprendizado ficou.
2. Documentar É Reforçar Memória
Cada documentação era na verdade uma forma de fixar o que eu tinha acabado de aprender. Isso reduzia minha carga cognitiva e melhorava minha clareza.
3. O Erro Como Feedback
Do ponto de vista cognitivo, o erro é um dos melhores professores. E em DevOps, isso é exponenciado.
4. Staging Não Reproduz a Realidade
É útil, claro, mas não cria o mesmo tipo de atenção e foco que a produção gera. Produção é "verdade". Staging é "simulação".
Parte 5: Para Quem Está Fazendo Transição de Carreira
Você vai começar "errado", e tudo bem
A V2 era cheia de problemas. Mas se eu não tivesse criado a V2, a V4 não existiria. Seu primeiro projeto não precisa ser bonito. Precisa existir.
Documente tudo
Seu futuro agradece. E futuros recrutadores também.
(Sim, sou prolixo quando falo de coisas que gosto, mas isso é feature, não bug.)
Reconstruir é normal
Infraestrutura não nasce pronta. Ela evolui, quebra, é refeita. Isso é esperado e é extremamente saudável.
Sua bagagem importa
O design me deu visão sistêmica. A neurociência me deu entendimento sobre aprendizado. O marketing me deu comunicação.
Tudo isso virou ferramenta em DevOps.
Conclusão: Aprendendo no hard mode
Em agosto de 2025, eu fazia deploy direto em produção sem ter total clareza do que estava fazendo. Em dezembro, tinha uma infraestrutura modularizada, monitorada, segura e pronta para escalar.
O que mudou?
Prática. Erro. Reconstrução. Documentação. Coragem.
Se você está começando:
- Você nunca estará 100% pronto.
- Comece pequeno, mas comece.
- Documente tudo, até conversas com seu superior e time (ou vozes na sua cabeça).
- Reconstruir faz parte.
- Sua história é um diferencial, use ela.
Se um designer que estudou neurociência conseguiu virar DevOps, você também consegue.
É só fazer o primeiro deploy, mesmo que seja torto, e que não estoure seu cartão de crédito.