Currículo afirma. Código prova.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros, com equipe de 23 pessoas distribuídas em quatro empresas. Respondo pela disponibilidade e pela continuidade dos sistemas críticos, e o mandato reúne resposta a incidente, controle de mudança em produção, confiabilidade da infraestrutura e o custo dela, que costumam viver em áreas separadas e por isso se contradizem. Cheguei com a sustentação operando por reação: monitoramento só de infraestrutura, sem APM e sem SLO, centenas de falsos positivos por mês, norma de mudança vencida desde 2024 e nenhuma fronteira definida entre operação e produto. Estruturei o N2 dentro da TI, cobrindo a etapa Observe do SDLC, escrevi as normas de incidentes, problemas e mudanças, e troquei o monitoramento por 9 SLOs com error budget e burn rate. O efeito que interessa não é o processo existir, é o incidente ter dono desde o primeiro minuto e o time de produto parar de ser interrompido por aquilo que a operação resolve. O critério que eu aplico é sempre o mesmo: processo definido, owner nomeado, fluxo em uso, evidência registrada e indicador em acompanhamento. Sem os cinco, não conta como entregue. Em paralelo, como fundador e CTO da Ohr AI, eu não paro no diagrama: desenho e escrevo o produto, um console que organiza oito frentes de automação com IA que só avança sob gate de confiança e deixa trilha de auditoria. É a mesma tese provada em outro contexto, do código que roda ao cliente que assina.
Minha carreira foi feita atravessando camadas, e cada uma deixou algo que a anterior não dava. Comecei em suporte N1, N2 e N3 em telecom, redes e hardware, atendendo chamado com SLA correndo e gente do outro lado esperando. Depois virei Gerente de TI numa rede de varejo farmacêutico, com infraestrutura on-premise 24x7, link entre lojas, matriz e centro de distribuição, e disponibilidade contratada com fornecedor, que é quando você descobre que uptime tem preço e cláusula. Fui para desenvolvimento backend e mobile porque precisava saber escrever o que até ali eu só sustentava. Em 2015 entrei em cibersegurança em tempo integral por uma Autoridade Certificadora, onde criptografia, confiança e conformidade são literalmente o produto que a empresa vende. Hardware, código e governança, nessa ordem. É de onde vem a leitura de ponta a ponta que eu uso hoje.
O que cresceu depois disso foi o tamanho do problema. No Itaú era privilégio excessivo em banco regulado, que caiu 42%, com a remoção de acesso saindo de cinco dias para menos de 48 horas. No Mercado Pago, a biblioteca core mobile usada em quatro países derrubava a conversão do checkout, e as falhas críticas caíram 55%. Na PagoNxt eu peguei uma maquininha com 65% de sucesso transacional, ou seja, um a cada três lojistas sem receber, e levei para 92% em oito meses. No PicPay, um checkout em que a segurança tinha entrado depois do desenho e precisou voltar para dentro dele. Na Compass UOL eram quinze engenheiros e uma conta de cloud fora de controle, com corte de 20% a 35% sem perder disponibilidade. Na Creditas, IAM e AppSec sob regulação com SailPoint no núcleo do IGA, e 45% menos acesso acima do necessário. Na Luby, a maturidade de engenharia era o maior risco de um programa estratégico, e a esteira construída do zero levou a cobertura de teste de 0 para 82% em três meses, com o lead time caindo de 14 dias para 2.
Boa parte dessas passagens é consultoria e fábrica de software, onde o ciclo pertence ao programa e não ao contrato de trabalho. No resto existe um padrão que eu assumo: sou chamado quando o número está ruim e alguém precisa responder por ele, e trabalho de virada tem começo e fim. O que eu meço não é quanto tempo fiquei, é se o time seguiu sem mim e se o número continuou de pé depois. Por isso o que eu construo sai com gate, evidência e documentação, para não virar dependência de quem escreveu.
Lidero pessoas e arquitetura com o mesmo cuidado. Times de 10 a 15 engenheiros entre desenvolvimento, segurança, QA e dados, com ritual de time, 1:1, PDI, trilha de carreira, OKR desdobrado e DORA reportado a C-Level. Transito da conversa com o engenheiro para a conversa com auditoria e diretoria sem precisar de intérprete em nenhuma das duas pontas, porque já trabalhei nas duas. E não lidero de fora do código: escrevo do frontend ao backend, desço à infraestrutura, ao cloud, à cibersegurança e à IA, e é por isso que a arquitetura que eu proponho aguenta a pergunta difícil, venha ela do engenheiro, do cliente, do comercial ou do conselho. O tempo que sobra eu devolvo, no que escrevo em público sobre o que opero, na organização de eventos, na palestra e na mentoria de jovens que ainda não tiveram a primeira porta.
Sem os cinco, não conta como entregue. O mesmo critério vale para processo, arquitetura e IA.
Seis coisas aparecem em tudo que eu construo, e são o que eu levo para um time.
Primeiro a solução explicável, depois a medição de quanto o modelo agrega sobre ela. Num incidente às 3h da manhã eu preciso de uma conclusão que dê para contestar linha por linha, e é justamente aí que um score sem rastro não ajuda ninguém a decidir.
Precisão e recall que não dão para calcular são opinião com aparência de número. Por isso os meus geradores de dado sintético plantam o problema de propósito: eu sei onde ele está antes de rodar a detecção, então dá para dizer o que passou e o que escapou.
Benchmark, cobertura e qualidade de saída de LLM entram como gate de regressão: se o número piora, o Pull Request reprova. Sem isso o README vira a foto de um dia bom que ninguém revalidou desde então.
Superfície de ataque se decide no desenho. Threat modeling antes da primeira linha, identidade e menor privilégio dentro do modelo de domínio, segredo fora do código, e SAST, SCA e DAST configurados para bloquear merge. Quando uma vulnerabilidade chega em produção, quase sempre a decisão que a permitiu foi tomada meses antes, num diagrama que ninguém questionou.
Em fintech e banking a operação é 24x7 e a auditoria não marca hora. ISO 27001, PCI-DSS, LGPD e BACEN entram como gate de CI, com a trilha de evidência gerada pelo próprio pipeline no momento em que a coisa acontece, e não reconstruída depois. O que sustenta plantão é SLO com erro orçado, rollback já ensaiado e postmortem que procura causa, não culpado.
OKR desdobrado até a tarefa, DORA reportado a C-Level e PDI com trilha que a pessoa consegue enxergar sem precisar me perguntar. Uso KPI de time para achar gargalo no fluxo, nunca para ranquear gente. Conduzi de 10 a 15 engenheiros entre desenvolvimento, segurança, QA e dados.
IAM e IGA (SailPoint, ciclo JML, RBAC, ABAC, SoD, PAM) · SSO com SAML, OAuth 2.0 e OIDC · AppSec e SSDLC com SAST, DAST e SCA como gate de merge · Zero Trust · threat modeling · TLS 1.3, mTLS, certificate pinning · Active Directory, Microsoft Entra ID, Azure PIM · ISO 27001, PCI-DSS, LGPD, NIST CSF, BACEN
Agentes com orquestração autônoma e auditável · RAG · MCP · LLMOps e MLOps · prompt engineering seguro e segurança de LLM · AWS Bedrock, OpenAI, Anthropic, LangChain, n8n · Python
SLI, SLO, incident response e postmortem · Datadog (APM, logs, métricas), CloudWatch, New Relic · AWS e Azure · Kubernetes, Docker · Terraform · GitHub Actions, Jenkins e SonarQube como quality gate · deploy canary e blue-green com rollback automático
Clean Architecture, Hexagonal, DDD, SOLID · microsserviços e event-driven · Java e Java EE, Kotlin, Spring, Python, C# e ASP.NET · mobile nativo Android e iOS, Jetpack Compose, SwiftUI, KMP
Times de 10 a 15 pessoas · OKR e métricas DORA reportadas a C-Level · 1:1, PDI, trilha de carreira, recrutamento, capacity planning e code review
