Oportunidades remotas / Times internacionais
Vitor Schiavo
Platform e Site Reliability Engineer Sênior
Sistemas confiáveis.
Times mais fortes.
Plataformas em nuvem e inferência de IA confiáveis, com ganhos medidos em entrega, resiliência e custo.
Aberto a oportunidades Senior e Staff em Platform Engineering e SRE.
Compile uma vez. Promova com confiança.
Um preview isolado, a mesma imagem testada e um caminho de limpeza explícito.
Piloto em dois repositórios · 34 verificações automatizadas
Explorar este casoTrabalhos selecionados
Infraestrutura de IA & serving de LLMs
Operando LLMs multimodais entre engines e nuvens
Construí fluxos de serving com vLLM e llama.cpp, isolei runtimes de modelos incompatíveis e validei o fallback autenticado entre ambientes. O trabalho abrange um POC de router e, depois, a integração em produção.
Ler as decisões e os resultados ↗Dois engines de serving. Rollout de produção validado separadamente do POC do router.
FinOps & engenharia de custos
Menos desperdício em nuvem. Mais valor de engenharia.
Reduzi gastos de infraestrutura com rightsizing de Kubernetes, uma migração de monitoramento e a desativação segura de serviços legados. Cada resultado está vinculado à sua própria baseline e moeda.
Explorar as economias e decisões ↗Iniciativas separadas de 2025–2026. Reduções mensais × 12.
Observabilidade & migração
Encontrando a falha por trás de um dashboard verde
Uma migração de runtime deixou filtros de alerta correspondendo silenciosamente a nada. Rastreei as mudanças de logging e verifiquei cada correção contra mensagens que se sabe existirem.
Ler as decisões e os resultados ↗Valide contra uma mensagem que se sabe existir.
Profundidade em toda a plataforma.
As disciplinas por trás do trabalho. Explore os projetos que as colocam em prática.
Plataforma & entrega
Fluxos de trabalho reutilizáveis que conectam o código à produção.
Kubernetes · Terraform · ArgoCDVer trabalhosConfiabilidade & observabilidade
Sinais que os engenheiros podem usar para diagnosticar e agir.
Prometheus · Grafana · JenkinsVer trabalhosEngenharia de custos
Entenda a conta. Mude a arquitetura.
Faturamento em nuvem · Rightsizing · ArmazenamentoVer trabalhosSegurança & confiança
Controles práticos embutidos na plataforma.
mTLS · IAM · Rede privadaVer trabalhosInfraestrutura de IA
Serving, inicialização e caminhos de falha sob escrutínio.
vLLM · GPU serving · POC de fallbackVer trabalhosArquitetura em nuvem
Ambientes conectados com fronteiras claras.
GCP · AWS · AzureVer trabalhosExperiência construída em ambientes exigentes
Facilitar o trabalho do próximo engenheiro.
Minha vivência em desenvolvimento de software molda a forma como trabalho em infraestrutura. Busco causas comuns, construo capacidades reutilizáveis e documento decisões para que os times possam operar de forma independente.
Como eu trabalho ↗Trabalho de engenharia
Explore resultados, arquitetura e lições operacionais. Trabalhos profissionais e projetos pessoais são rotulados separadamente.
Restaurando a confiança no pipeline de QA
40 falhas de plataforma a zero
O defeito nos relatórios compartilhados foi reparado; as falhas da aplicação permaneceram como uma investigação separada.
O que mudou
Um defeito nos relatórios compartilhados fazia testes aprovados parecerem quebrados. Rastreei a falha comum, reparei a plataforma de agentes e separei as falhas reais de teste do ruído de infraestrutura. Rodada de validação com 65 jobs; as falhas de teste da aplicação remanescentes foram identificadas separadamente.
Um lugar seguro para testar cada funcionalidade
Ambientes de preview com ciclo de vida completo
Piloto em dois repositórios: promova a imagem testada e, depois, remova os recursos de preview quando o PR é fechado.
O que mudou
Construí um piloto em dois repositórios que cria ambientes isolados a partir de pull requests, promove a mesma imagem testada e remove os recursos de preview quando o PR é fechado. 16 verificações em Go e 18 em Node antes dos builds; digest da imagem verificado durante a promoção.
Encontrando a falha por trás de um dashboard verde
22 políticas de alerta e 2 métricas reparadas
Mudar apenas o tipo de recurso era insuficiente; os filtros também precisavam corresponder a formatos de log específicos do runtime.
O que mudou
Uma migração de runtime deixou filtros de alerta correspondendo silenciosamente a nada. Rastreei as mudanças de logging e verifiquei cada correção contra mensagens que se sabe existirem. Controles positivos comprovaram que substituir apenas o tipo de recurso ainda deixaria de capturar logs estruturados do Go.
Cloud Functions: migração escalonada para Gen2
Modernizando runtimes e pipelines de deployment; o acompanhamento em produção expôs e corrigiu uma mudança implícita de identidade do runtime.
Uma migração escalonada; o acompanhamento em produção também verificou a conta de serviço do runtime.
O que mudou
Modernizando runtimes e pipelines de deployment; o acompanhamento em produção expôs e corrigiu uma mudança implícita de identidade do runtime.
Modernizando Grafana e Prometheus
Upgrades de versão maior, recording rules e um stack de monitoramento mais sustentável.
O trabalho combinou upgrades de versão, recording rules e validação operacional.
O que mudou
Upgrades de versão maior, recording rules e um stack de monitoramento mais sustentável.
Rede no GKE: Dataplane V2 e um bootstrap repetível
Uma migração escalonada fora de produção com rollback e validação explícitos; a produção ficou de fora dessa entrega.
Entrega fora de produção com verificações e rollback explícitos; a produção ficou fora deste escopo.
O que mudou
Uma migração escalonada fora de produção com rollback e validação explícitos; a produção ficou de fora dessa entrega.
Reconstruindo o GKE sem reemitir certificados
Setembro de 2026 · Um ensaio real de reconstrução expôs falhas que a revisão de código não pegou e, em seguida, viabilizou três reconstruções de cluster sem consumir a cota de emissão de certificados.
O ensaio adotou 49 de 49 certificados sem reemissão. É um teste de recuperação, não um SLA de tempo de recuperação em produção.
Minha contribuição e resultado
Ensaiei uma reconstrução completa de cluster, reparei defeitos de ordem de restauração e de ciclo de vida do controlador e, em seguida, reutilizei o processo ao renumerar três ambientes.
Encontrando a latência escondida no DNS do Kubernetes
Julho de 2026 · Separar o tempo de lookup de DNS do tempo de conexão TCP revelou por que uma API saudável continuava disparando alertas de latência.
A melhoria de cerca de 9× descreve o lookup de DNS medido, não cada requisição de API nem uma garantia sustentada de nível de serviço.
Minha contribuição e resultado
Isolei o overhead de DNS da latência de rede do banco de dados, alterei a configuração de DNS no Helm compartilhado e verifiquei o rollout de produção contra a medição original.
Observando uma frota efêmera de inferência de IA
Abril de 2026 · A descoberta dinâmica do Prometheus manteve os workers de GPU e os pods de inferência visíveis à medida que os endereços do provedor mudavam.
Cinco targets estavam UP no snapshot do rollout. Esta entrega adicionou visibilidade; as regras de paging foram um acompanhamento à parte.
Minha contribuição e resultado
Conectei o inventário do router à service discovery via HTTP do Prometheus e a um dashboard da frota, eliminando a necessidade de manter uma lista estática de targets após cada deployment de GPU.
Tornando jobs agendados observáveis
Agosto de 2026 · Um wrapper de execução reutilizável tornou jobs de vida curta visíveis sem mudar sua lógica de negócio nem deixar que falhas de telemetria os quebrassem.
24 de 26 entradas ativas foram instrumentadas. Os limiares de atualidade refletem cada agendamento; falhas de telemetria não substituem o resultado do job.
Minha contribuição e resultado
Instrumentei 24 de 26 entradas de cron ativas, adicionei regras de atualidade cientes do agendamento e testei que o monitoramento preservava o resultado real de cada job.
Corrija o worker antes de escalar a frota
Setembro de 2026 · Um rollout de autoscaling baseado em fila expôs workers de navegador travados; o escalonamento só se tornou útil depois que o vazamento de recursos foi contido.
O KEDA estava ativo em quatro ambientes. O teto de 50 réplicas em produção é configuração, não capacidade de throughput demonstrada.
Minha contribuição e resultado
Rastreei o backlog e os OOMs até processos filhos travados, corrigi seu ciclo de vida e substituí o escalonamento por CPU/memória por um gatilho de backlog via Pub/Sub em quatro ambientes.
Engenharia de custos em nuvem por todo o stack
Kubernetes, observabilidade e desativação de legado · 2025–2026
Preserve os dados exigidos e o comportamento do serviço; meça cada iniciativa contra sua própria baseline de faturamento.
Redução de custos como disciplina de engenharia
Equivalentes anualizados documentados: aproximadamente US$30.1K para uma desativação de legado, £26.5K para um snapshot de rightsizing de Kubernetes e £14K para uma linha de ingestão de monitoramento. Moedas e baselines diferentes são mantidas separadas.
Tornando o custo do Kubernetes visível
Alocação de custo por namespace, resource requests e consolidação de nós.
A alocação de custo orienta os resource requests e a consolidação; as economias precisam de uma baseline de faturamento.
O que mudou
Alocação de custo por namespace, resource requests e consolidação de nós.
Movendo workloads entre clusters Kubernetes
Migração escalonada de aplicação e dados, cutover de DNS, validação e rollback.
Prepare a migração de aplicação e dados antes do cutover de DNS e, depois, valide o destino.
O que mudou
Migração escalonada de aplicação e dados, cutover de DNS, validação e rollback.
Um upgrade escalonado de versão maior do Strapi
Adaptando lifecycle hooks e validando a compatibilidade antes do cutover em produção.
As mudanças de versão maior incluíram lifecycle hooks e verificações de comportamento antes do cutover em produção.
O que mudou
Adaptando lifecycle hooks e validando a compatibilidade antes do cutover em produção.
Mantendo o Metabase útil em produção
Carga controlada do dashboard: ~49.7 s → ~3.1 s; upgrades, acesso somente leitura e isolamento de queries.
Uma carga controlada em produção melhorou de ~49.7 s para ~3.1 s; um gargalo separado de filtro no MongoDB permaneceu.
O que mudou
Carga controlada do dashboard: ~49.7 s → ~3.1 s; upgrades, acesso somente leitura e isolamento de queries.
Postura de segurança como um sistema observável
Scans de segurança, alcançabilidade de probes verificada e controles reversíveis de secrets, com escopos de rollout documentados.
A visibilidade em lote inclui dimensões de risco e a atualidade dos scans; não é detecção de ameaças em tempo real.
O que mudou
Conectei os scans de segurança ao Prometheus e ao Grafana, melhorei a confiabilidade do scanner e verifiquei probes de exposição de configuração. Um trabalho relacionado adicionou entrega de secrets com escopo e controles de versão reversíveis.
Reduzindo o gasto com ingestão de monitoramento
£1,165.80/month removidos de uma linha de faturamento de ingestão do Prometheus.
A linha de ingestão gerenciada foi removida; compute, armazenamento e manutenção autogeridos ainda têm custos.
O que mudou
Substituí o caminho de ingestão gerenciada preservando os targets de monitoramento e os dashboards. O equivalente anualizado é £13,989.60; os custos de hospedagem e manutenção permanecem fora dessa linha de faturamento.
Ciclo de vida e retenção de armazenamento no GCP
Tiering de armazenamento ciente de acesso e revisão de retenção.
Um ciclo de vida simplificado: a versão efetiva da política e os requisitos de exclusão precisam ser validados.
Escopo e resultado
O portfólio histórico reportou uma redução de 95.9%. As economias absolutas ficam omitidas até que moeda, baseline de faturamento e versão da política sejam reconciliadas.
Consolidação do Airflow — 86% menos recursos alocados
Consolidando um deployment superprovisionado.
A alocação de recursos registrada caiu; isso não significa que a plataforma tenha custo operacional zero.
Escopo e resultado
A alocação registrada mudou de 100 para 14 pods, de 20 para 2.8 vCPUs e de 200 para 28 GB de memória. São reduções de alocação, não uma afirmação de custo operacional zero.
mTLS com Cloudflare — Arquitetura Zero-Trust
2024–2025 · Segurança avançada · Arquitetura de rede
Certificados, rotação e revogação complementam os controles de rede.
Problema
O TLS padrão autentica apenas o servidor perante o cliente. Era necessária a autenticação mútua, em que cliente e servidor verificam a identidade por certificados, algo crítico para a segurança de APIs e a conformidade com a ISO 27001.
Solução
- Configurei o Cloudflare para Mutual TLS; agora os dois lados apresentam certificados, não só o servidor
- Gerei e distribuí certificados de cliente para cada serviço autorizado
- Adicionei revogação e rotação de certificados para que certificados comprometidos possam ser derrubados imediatamente
- A validação de certificados adiciona um controle de identidade ao lado das restrições de rede
- Automatizei o ciclo de vida dos certificados para que a rotação não exija passos manuais
Fluxo mTLS
Cliente (com cert) → Cloudflare (valida o cert do cliente) → Servidor de origem (valida o cert da CF)
Verificação mútua em cada camada · Criptografado e autenticado de ponta a ponta
Impacto no negócio
- Toda requisição autenticada por certificado; nada passa apenas por posição de rede
- Conformidade com a ISO 27001 atendida
- Proteção contra ataques MITM e abuso de API
- Revogação instantânea se um certificado for comprometido
AWS-GCP HA VPN — Conectividade Multi-Cloud
2024 · Rede Multi-Cloud · Alta disponibilidade
O BGP provê roteamento e failover; o IPSec criptografa o tráfego transportado pela VPN.
Problema
Era necessária uma comunicação segura e confiável entre AWS e GCP para workloads híbridas. O roteamento pela internet pública era inaceitável para dados sensíveis. Exigia-se redundância para alta disponibilidade.
Solução
- Construí HA VPN entre AWS e GCP com túneis redundantes dos dois lados
- Configurei o BGP para que o failover seja automático, sem intervenção manual quando um túnel cai
- Atribuí IPs privados e configurei tabelas de roteamento internas para que o tráfego use endereçamento privado por túneis VPN criptografados
- O tráfego dentro dos túneis VPN é criptografado com IPSec
- Adicionei monitoramento e alertas de saúde dos túneis para que os problemas sejam detectados antes de afetar as workloads
Impacto no negócio
- Conectividade redundante por múltiplos túneis VPN
- Failover automático via BGP (<30 segundos)
- Endereçamento privado de serviços por túneis VPN criptografados
- Conectividade entre nuvens com endpoints privados e túneis monitorados
Sistema de Canary Deployment personalizado
2024–2025 · Entrega progressiva · Automação
Cada gate de release pode interromper a progressão e devolver o tráfego para a versão estável.
Problema
Deployments blue-green tradicionais exigem uma troca de 100% do tráfego, o que é arriscado. Ferramentas prontas não se encaixavam no nosso ambiente Kubernetes multi-ambiente. Era necessário um rollout gradual com rollback automático baseado em métricas.
Solução
- Escrevi do zero a automação de canary deployment personalizada; ferramentas prontas não se encaixavam no ambiente multi-ambiente
- Divisão progressiva de tráfego: 10% → 25% → 50% → 100%, com um gate em cada estágio
- Health checks rodam em cada estágio antes de o tráfego avançar
- O rollback automático entra em ação quando a taxa de erros ou a latência ultrapassa os limiares definidos
- Integrado aos pipelines do Jenkins, funciona da mesma forma para todos os times
Impacto no negócio
- Contenção de falhas: health gates e rollback automatizado limitam a exposição durante a entrega progressiva
- Frequência de deploy aumentada: os times entregam com mais frequência porque o custo de um release ruim caiu drasticamente
- Integração com o pipeline: a automação personalizada se encaixa no fluxo de entrega existente
Hardening de segurança de bancos de dados — 60+ bancos de dados
2023–2025 · Arquitetura de segurança · Conformidade
Rede privada, transporte criptografado e controles de acesso formam camadas separadas de defesa.
Problema
Bancos de dados expostos com IPs públicos, conexões sem criptografia e autenticação apenas por senha. Não conformes com a ISO 27001. Vulneráveis a sniffing de rede e acesso não autorizado.
Impacto no negócio
- 60+ bancos protegidos (MongoDB Atlas + PostgreSQL)
- Controles de plataforma posteriores: pilotei o External Secrets em três repositórios; fiz as atualizações de secrets preservarem os campos existentes; desabilitei de forma reversível 133 versões antigas em 97 secrets em quatro projetos. As exceções de identidade em produção permaneceram documentadas.
- Zero incidentes de segurança após a implementação
- Certificação ISO 27001 obtida
Kong Gateway — Gestão de APIs em escala
2023–2024 · Gestão de APIs · Arquitetura
O gateway centraliza autenticação, limites de taxa e roteamento para o tráfego das aplicações.
Problema
160+ aplicações com nginx ingress direto e sem gestão centralizada de APIs, limitação de taxa ou camada de autenticação. Era difícil aplicar políticas ou monitorar o uso das APIs de forma consistente.
Impacto no negócio
- 160+ aplicações agora passam por um único gateway, dando um só lugar para aplicar políticas
- Limitação de taxa configurada centralmente; sem necessidade de implementação por serviço
- Auth, CORS e headers aplicados globalmente; os desenvolvedores não lidam com isso por app
- Logging e tracing centralizados reduzem significativamente o tempo de troubleshooting
ArgoCD GitOps — Entrega contínua multi-cluster
Março de 2026 · GitOps · Kubernetes multi-cluster
O GitOps separa o estado desejado no Git de sua aplicação controlada aos clusters.
Problema
Deployments em quatro clusters GKE (dev · stg · prd · sandbox) eram manuais, inconsistentes e propensos a erros. Não havia uma fonte única de verdade para o estado dos clusters, nem trilha de auditoria, e havia alto risco de drift de configuração entre ambientes. Os times precisavam de acesso ao kubectl para fazer deploy, sem nenhum modelo de autoatendimento.
Solução — Implementação em 9 fases
- Fase 0: Instalei o ArgoCD no cluster GKE PRD via Helm com valores de produção
- Fase 1: Defini a estrutura do repositório GitOps: hierarquia apps/environments/charts com templates de Helm chart e overrides de valores por ambiente
- Fase 2: Configurei Applications e AppProjects do ArgoCD com fronteiras de RBAC por time e namespace
- Fase 3: Registro multi-cluster; todos os quatro clusters GKE (dev · stg · prd · sandbox) como targets do ArgoCD, com as credenciais dos clusters armazenadas em Secrets
- Fase 4: Integração do pipeline de CI/CD via image updater do GitHub Actions para propagação automática de tags de imagem, com promoção de branch dev → stg → prd
- Fase 5: SSO/OIDC com Google Workspace + políticas de RBAC por time
- Fase 6: Métricas do Prometheus + dashboards do Grafana para observabilidade de GitOps
- Fase 7: Migração incremental das workloads existentes; auditei todos os namespaces, converti para Helm charts e habilitei self-heal e prune fora de produção
- Fase 8: Entrega progressiva com Argo Rollouts, canary deployments com divisão de tráfego e rollback automatizado
Impacto no negócio
- 4 clusters GKE gerenciados como uma única frota GitOps (dev · stg · prd · sandbox)
- Gestão de drift: o Git fornece o estado desejado, com reconciliação e self-healing onde habilitado
- Trilha de auditoria completa: toda mudança de deployment registrada como um commit Git assinado
- Rollback instantâneo: reverta um commit Git e o cluster se reconcilia em segundos
- Autoatendimento para desenvolvedores: os engenheiros fazem deploy via PR, sem necessidade de acesso ao kubectl
- Promoção automatizada: o image updater do GitHub Actions envia novas tags entre os ambientes sem edições manuais de YAML
Infraestrutura GKE — Terraform de nível de produção + Shared VPC
Fevereiro de 2026 · Infrastructure as Code · GKE · Terraform
Módulos Terraform reutilizáveis provisionam fronteiras de rede e recursos GKE de forma consistente.
Problema
Os clusters GKE e a infraestrutura de rede subjacente eram provisionados manualmente, sem IaC. Não havia uma estratégia multi-ambiente consistente, nem proteção prevent-destroy nos recursos críticos de rede, e a configuração Terraform era monolítica e impossível de reutilizar entre ambientes.
Solução — Entrega em 8 fases
- Fase 1 — Projeto de arquitetura: Defini a topologia de Shared VPC, a estratégia de subnets e os requisitos dos clusters GKE para 4 ambientes
- Fase 2 — Configuração dos projetos GCP: Criei projetos, habilitei APIs e configurei contas de serviço IAM com bindings de privilégio mínimo
- Fase 3 — Infraestrutura de rede: Implantei o projeto host da Shared VPC, subnets, Cloud NAT e regras de firewall via Terraform
- Fase 4 — Terraform modular: Refatorei de recursos inline monolíticos para módulos reutilizáveis; converti a configuração raiz em chamadas de módulo com arquivos de variáveis específicos por ambiente
- Fase 5 — Automação de CI/CD: Workflows do GitHub Actions para terraform plan no PR e terraform apply no merge; workflows separados por ambiente
- Fase 6 — Deploy dos clusters GKE: Implantei todos os quatro clusters GKE (dev · stg · prd · sandbox) usando os pipelines automatizados
-
Fase 7 — Salvaguardas de segurança: Adicionei blocos de lifecycle
prevent_destroy = truena VPC, nas subnets e no Cloud NAT para proteger contra um terraform destroy acidental - Fase 8 — Documentação: Diagramas de arquitetura, runbooks operacionais e documentação dos módulos para transferência de conhecimento
Impacto no negócio
- 100% infraestrutura como código: todo recurso de rede e de cluster gerenciado via Terraform
- 4 clusters GKE implantados em uma única execução de pipeline automatizada
- Zero provisionamento manual: novos ambientes criados apenas a partir de arquivos de variáveis
-
Salvaguardas de produção:
prevent_destroyevita a perda acidental de infraestrutura de rede crítica - Shared VPC + Cloud NAT validados: todos os projetos de serviço roteiam a saída por um gateway NAT centralizado
Serving de LLM multimodal entre engines e nuvens
Seleção de runtime ciente do modelo, verificações da revisão servida e fallback autenticado.
O POC do router e a posterior integração de fallback em produção têm medições e escopos de rollout separados.
Escopo e resultado
Construí caminhos de serving com vLLM e llama.cpp cientes do modelo, reparei deployments que serviam uma revisão antiga e validei o fallback autenticado da aplicação em quatro ambientes. O router anterior, de três provedores, permanece como um POC separado.
Defendendo o Kubernetes contra ataques de supply-chain
Segurança · Kubernetes · Defesa de supply-chain
Combine verificações no pipeline com detecção de anomalias no nível do nó e um procedimento de contenção explícito.
A ameaça
Uma dependência comprometida pode contrabandear um cryptominer (como o xmrig) para dentro de um build e passar pela revisão de código, e então consumir CPU silenciosamente em um nó de produção sem sintomas na aplicação. O código malicioso nunca aparece em um diff, porque entra através de um pacote transitivo e é montado no bundle no momento do build.
Detecção & defesa em profundidade
- Detectar no nó: alertas de anomalia de CPU no nível do nó (janela de limiar curta) são o gatilho quando a própria aplicação parece saudável
- Conter rápido: isole (cordon) o nó afetado, faça drain e reagende em nós limpos, depois remedie a origem e fixe as versões transitivas
-
Proteger o pipeline:
npm audit --audit-level=highmais o scan de imagens com Trivy em cada build pré-deploy - Impor lockfiles: lockfiles commitados são obrigatórios; o CI falha se estiverem ausentes ou alterados sem revisão
- Restringir o runtime: Pod Security Standards (restricted) em todos os namespaces para bloquear escalonamento de privilégios
- Egress com negação padrão: network policies bloqueiam a saída para mining pools e endpoints desconhecidos, de modo que uma intrusão não leva a lugar nenhum
Resposta a incidentes em produção — Indisponibilidade P1 & falha de autenticação de parceiro
Março de 2026 · Resposta a incidentes · Confiabilidade em produção
Um modelo de resposta simplificado para incidentes de dependência e de autenticação; o trabalho de recuperação é compartilhado.
Incidente A — Carregador de CMS de terceiros [P1]: HTTP 500 em dois mercados regionais
- Impacto: 100% dos carregamentos de página retornando HTTP 500 a partir das 13:08 UTC; indisponibilidade total de produção em dois mercados regionais
- Causa raiz: A dependência da API de CMS de terceiros ficou indisponível; todas as páginas falharam na renderização no servidor
- Resposta: Identifiquei a falha de dependência, implementei um fallback estático de emergência e escalei para o suporte do fornecedor
- Resolução: Serviço restaurado; adicionei o padrão circuit-breaker e monitoramento de saúde para as dependências externas de CMS
Incidente B — API de parceiro [P2]: rotação de credenciais causando falha de autenticação
- Impacto: Todas as chamadas de autenticação do parceiro retornando 401 a partir de ~14:30 UTC, após a rotação de senha do lado do parceiro
- Causa raiz: O parceiro rotacionou as credenciais sem notificação coordenada; a senha antiga foi revogada no meio do dia
- Resposta: Diagnostiquei a falha de autenticação pelos logs, obtive novas credenciais, atualizei o GCP Secret Manager e disparei um rolling restart
- Hardening: Estabeleci um runbook de rotação de credenciais e um SLA de notificação previamente acordado com o parceiro
Princípios de SRE aplicados
- Resposta operacional: ambos os incidentes foram resolvidos no mesmo dia útil
- Post-mortems sem culpados: causas raiz documentadas, correções sistêmicas implementadas
- Lacunas de monitoramento fechadas: health checks de dependências externas adicionados após cada incidente
Migração do Elastic Stack — de EC2 para Kubernetes em escala
2020–2021 · Observabilidade · Modernização de infraestrutura
O design no Kubernetes separa os papéis de master, data e ingest com backups baseados em snapshots.
Problema
- 2 clusters legados do Elastic Stack: Elasticsearch 5 no EC2 e Elasticsearch 6 no ECS, ambos via docker-compose
- Sem separação de papéis: cada nó fazia eleição de master, armazenamento de dados e ingest simultaneamente
- Escalonamento manual, sem self-healing, pontos únicos de falha
- Gargalo de armazenamento: sem snapshots no S3, sem políticas de retenção automatizadas
Solução
- Consolidei ambos os clusters em 1 cluster EKS unificado no Elasticsearch 7.8
- Projetei uma arquitetura multi-nó com papéis dedicados: 3 master (8 GB), 3 data (16 GB, 50 TB), 3 ingest (16 GB)
- Imagem ECR personalizada com plugin de snapshot no S3 para backup e retenção automatizados
- Implantado via Helm Charts com rolling updates, PDB (maxUnavailable: 1) e soft anti-affinity
- Construí 9 pipelines Logstash especializados para diferentes fontes de logs (GELF, K8s, NiFi, PHP, portal, serviços, relatórios)
- Filebeat DaemonSet com enriquecimento de metadados do Kubernetes para coleta de logs de contêineres
- Fluent Bit como coletor alternativo leve com filtragem em nível de kernel
- Kibana com 3 réplicas e relatórios em CSV (1 GB máx.), APM Server para tracing e Metricbeat para a saúde do cluster
Impacto no negócio
- Consolidação histórica: substituí uma frota legada de dois clusters por um node pool EKS menor
- Consolidei 2 → 1 cluster: eliminei toda a frota legada de instâncias e volumes, substituindo-a por um punhado de nós EKS
- Upgrade de versão v5/v6 → v7.8: salto de versão maior, desbloqueando ILM, recursos de segurança e gerenciamento do ciclo de vida de índices
- Migração EBS GP2 → Standard: migrei toda a frota de volumes em duas regiões da AWS, reduzindo custos de armazenamento
- Análise de custos multi-região: o preço regional orientou a decisão de consolidação
- Limpeza de S3: apaguei um grande bucket S3 não utilizado (dezenas de TB) e automatizei a retenção de snapshots via imagem ECR personalizada com o plugin repository-s3
- 9 pipelines Logstash dedicados: cada pipeline ajustado para sua fonte específica, permitindo escalonamento e troubleshooting independentes
- Infraestrutura com self-healing: StatefulSets do Kubernetes com PDB, rolling updates e recuperação automatizada substituíram a gestão manual no EC2
Streaming de eventos com Kafka — Pipeline em tempo real para BI
2020–2021 · Engenharia de dados · Arquitetura orientada a eventos
Os filtros do Logstash alimentam o Elasticsearch e os tópicos Kafka para os consumidores de BI a jusante.
Problema
- O time de business intelligence não tinha acesso em tempo real aos dados de eventos de APIs e serviços
- Os dados de log ficavam isolados no Elasticsearch, inacessíveis para analytics a jusante
- Várias fontes de eventos (GELF, RabbitMQ, HTTP) precisavam de roteamento unificado para tópicos Kafka
- Não havia um pipeline padronizado para transmitir eventos filtrados aos sistemas de analytics
Solução
- Projetei pipelines Logstash de saída dupla: eventos indexados no Elasticsearch E encaminhados para tópicos Kafka
- Integrei com o AWS MSK (Managed Streaming for Apache Kafka) com compressão gzip
- Construí roteamento condicional: eventos de API filtrados por nome de serviço e encaminhados para tópicos Kafka dedicados ao consumo de BI
- Plugin de input do RabbitMQ para eventos de fila de mensagens, ao lado de GELF e roteamento pipeline-to-pipeline
- Producer Kafka configurado com rastreamento de client_id e estratégia de um tópico por domínio
Impacto no negócio
- Pipeline de BI em tempo real: o time de business intelligence obteve acesso a eventos de API ao vivo pela primeira vez, viabilizando analytics em tempo real
- Arquitetura de escrita dupla: todo evento indexado no Elasticsearch para busca operacional E transmitido ao Kafka para analytics a jusante, sem duplicação de dados na origem
- Roteamento condicional: apenas eventos relevantes encaminhados ao Kafka, reduzindo o ruído para os consumidores e o volume de tópicos
- Integração com AWS MSK: o Kafka gerenciado com compressão gzip reduziu custos de rede e simplificou as operações
- Unificação de múltiplas fontes: inputs de GELF, RabbitMQ, HTTP e pipeline-to-pipeline consolidados em uma única camada de processamento
Integração de ferramentas de IA — Produtividade do time
2024–2025 · Adoção de IA · Experiência do desenvolvedor
Adoção de ferramentas e avaliação do fluxo de revisão; ganhos de produtividade não foram medidos aqui.
Solução
- Dez 2024: Habilitei o Claude AI para todo o time
- Ago 2024: Integrei os times de QA e dev ao GitHub Copilot
- Ago 2025: Avaliei o Claude Code para revisões automatizadas de PR nos pipelines do Bitbucket
- Criei guias de boas práticas para desenvolvimento assistido por IA
Impacto no negócio
- Adotei ferramentas de IA cedo: Claude AI em dez 2024, Copilot em ago 2024, antes da maioria dos times na organização
- Revisões de PR automatizadas via Claude Code; os revisores gastam tempo com lógica, não com estilo
- Desenvolvedores juniores evoluem mais rápido: o desenvolvimento assistido por IA reduz a distância entre seniores e juniores em tarefas rotineiras
Pokémon GO Friend Code — SaaS por assinatura
2025–2026 · Full-Stack · Next.js · GCP · Multipagamento ·
Produto pessoal: o estado do pagamento controla quais códigos de treinador permanecem ativos para envio.
O que faz
Um serviço por assinatura para que jogadores de Pokémon GO tenham seus códigos de treinador enviados automaticamente, todos os dias, para sites de listagem da comunidade. Os usuários escolhem um plano, pagam, e o código é enviado todo dia sem nenhuma ação manual.
Como foi construído
- Next.js 16 full-stack com App Router, Server Components, Server Actions e build Docker multi-stage implantado no Cloud Run (scale to zero)
- Gateway de pagamento duplo: Mercado Pago para assinantes PT/BRL, Stripe para EN+ES/USD; mesma base de código, roteamento guiado por locale via middleware
- i18n com
/pt,/en,/esem subpaths; o middleware Accept-Language redireciona automaticamente na primeira visita - Máquina de estados de webhooks com processamento idempotente e a tabela
submission_logsrastreando cada evento de pagamento - Zero credenciais estáticas: GCP Secret Manager em runtime, Workload Identity Federation para autenticação GitHub → GCP no CI
- Painel admin (sessões HMAC-SHA256 no servidor) para gestão de assinaturas e inspeção de webhooks
- Confirmações por e-mail via Resend com templates do React Email · Migrações de banco de dados via Drizzle ORM
Destaques técnicos
- Cloud Run southamerica-east1: auto-escala, HTTPS via domínio customizado (pokemongofriendscode.com)
- Workload Identity Federation: sem chaves de conta de serviço de longa duração no CI; o GitHub Actions troca tokens OIDC com o GCP
- Testado com Jest (unitário/integração) e Playwright (E2E)
Pokémon GO GCP — Engine automatizado de envio de códigos
2025–2026 · Automação de backend · Cloud Run Jobs · Web Scraping ·
Um backend agendado verifica as assinaturas ativas, envia os códigos e confirma que eles apareceram.
O que faz
O backend de automação do serviço por assinatura. Um Cloud Run Job agendado que lê os códigos de treinador ativos do Cloud SQL e os envia para dois sites da comunidade todos os dias às 15:00 BRT, totalmente headless e sem intervenção manual.
Como foi construído
- Dois scrapers independentes: Puppeteer + stealth plugin para pokemongofriendcodes.com, Playwright para pogocodes.com (formulário baseado em React)
- Contorno para componente controlado do React no pogocodes.com; dispara eventos de input com
bubbles: truepara acionar os handlers de eventos sintéticos - Passo de verificação após cada envio: navega até a página de listagens para confirmar que o código realmente aparece
- Processamento em lote (3 códigos simultaneamente) com atrasos configuráveis por tipo de ação para evitar rate limiting
- Orientado a banco de dados: códigos obtidos da tabela
trainer_codesdo Cloud SQL (fonte única de verdade, sincronizada a partir dos webhooks de pagamento) - IaC completo em Terraform para Cloud SQL, Cloud Run Jobs, Cloud Scheduler, Secret Manager e IAM
Destaques técnicos
- Modelo de execução: os jobs agendados escalam para baixo entre execuções; o custo total do serviço também inclui seus outros recursos de nuvem
- Detecção de rate limit: o pokemongofriendcodes.com bloqueia reenvios dentro de 24h; o script detecta e para de forma elegante
- Alertas do Cloud Monitoring em exit code ≠ 0; uma execução de job que falha aciona o dono
AmigoSecreto — App Android (Google Play)
2024–2026 · Android · Kotlin · MVVM · Google Play ·
App Android nativo com regras de exclusão, persistência local e revelação segura do resultado.
O que faz
Um app Android completo para organizar sorteios de amigo secreto. Suporta múltiplos grupos, regras de exclusão, listas de desejos, revelação segura e compartilhamento de resultados via WhatsApp, Telegram, SMS ou e-mail. Disponível no Google Play.
Como foi construído
- Totalmente migrado para Kotlin (a partir de Java) com arquitetura MVVM: AndroidViewModel + LiveData + padrão Repository
- Hilt para injeção de dependências · Coroutines para operações assíncronas de banco de dados na thread IO
- Room ORM com banco de dados de dupla camada (Room + DAOs legados coexistem; a inicialização eager do Room garante que as migrações terminem primeiro)
- Algoritmo de sorteio por backtracking extraído para uma função pura (
SorteioEngine.kt): testável, sem efeitos colaterais, lida de forma elegante com cenários de restrições impossíveis - Consultas em lote com INNER JOIN para eliminar o problema N+1 na contagem de listas de desejos · Todas as escritas no banco em transações atômicas
- Layout Edge-to-Edge (Android 15), exportação de PDF (PDFKit), geração de QR code, notificações locais, backup/restauração em JSON
- CI/CD com GitHub Actions: push para master → track interno do Play; tag
v3.x→ track de produção
Destaques técnicos
-
297 testes unitários + testes de integração com Espresso ·
UnconfinedTestDispatcherpara testes determinísticos de coroutines - Min SDK 21 (Android 5.0+) · Target SDK 35 (Android 15) · minificação R8 em builds de release
- Proteção contra spoiler no compartilhamento pelo WhatsApp: 30 linhas em branco antes da atribuição para impedir que as prévias revelem o resultado
Secret Santa — App iOS (SwiftUI)
2025–2026 · iOS 17+ · Swift · SwiftUI · SwiftData ·
SwiftUI e SwiftData mantêm a interface, a persistência e o fluxo de sorteio dentro de frameworks nativos.
O que faz
A versão iOS do AmigoSecreto, o mesmo conceito de produto reconstruído nativamente em Swift e SwiftUI para iPhone. Múltiplos grupos, regras de exclusão, listas de desejos, revelação segura, QR codes, exportação de PDF e notificações locais. Zero dependências externas.
Como foi construído
- SwiftUI + SwiftData apenas, sem pacotes de terceiros; persistência, UI, PDF, QR codes e notificações, tudo via frameworks nativos da Apple
- MVVM via
@Querye@Environment(\.modelContext)do SwiftData, sem precisar de classes ViewModel separadas - Contorno de serialização JSON para relações muitos-para-muitos (limitação do SwiftData): exclusões e pares de sorteio armazenados como campos
Datacom decoders em computed properties - Algoritmo de sorteio por backtracking com limite de 200 tentativas; a mesma lógica do Android, adaptada para Swift
-
SequentialShareView: contorno para a limitação do iOS que impede abrir múltiplos esquemas de URL simultaneamente; mostra botões sequenciais para WhatsApp, SMS, Email - Onboarding de 6 páginas, histórico de sorteios, estatísticas, backup/restauração com compatibilidade futura em JSON
Destaques técnicos
-
30+ testes unitários usando o framework Swift Testing (
@Suite,@Test) -
iOS 17+ no mínimo: usa
ContentUnavailableView,@Bindable, e outras APIs modernas por toda parte - Geração de PDF via
UIGraphicsPDFRenderer· QR codes via Core ImageCIQRCodeGenerator· feedback háptico na revelação
Experiência
Do desenvolvimento de software à confiabilidade e a plataformas de engenharia compartilhadas.
VerifyMy
Site Reliability Engineer
Jun 2021 – Atual · 5 anos e 4 meses
Platform engineering para segurança online regulada.
- Construí e operei infraestrutura em nuvem, pipelines de entrega e monitoramento em múltiplos ambientes.
- Desenvolvi um piloto de ambientes de preview efêmeros e testei a promoção de imagens sem rebuilds.
- Diagnostiquei falhas na plataforma de CI compartilhada e reparei lacunas de alerta introduzidas por migrações de runtime.
- Contribuí com controles de infraestrutura, evidências operacionais e procedimentos de recuperação para auditorias de segurança.
Intelipost
Site Reliability Engineer
Fev 2020 – Jun 2021
Confiabilidade e modernização de infraestrutura para tecnologia de logística.
- Consolidei deployments legados do Elastic Stack no Kubernetes com papéis de nó dedicados e backups automatizados.
- Construí pipelines de log especializados e streaming de eventos para monitoramento operacional e business intelligence.
- Apoiei o planejamento de capacidade e a preparação de infraestrutura para picos de demanda sazonal.
Dasa
Site Reliability Engineer
Jan 2018 – Fev 2020
Operações em nuvem em um grande ambiente de saúde.
- Provisionei ambientes Kubernetes e redes usando Terraform e pipelines de deployment automatizados.
- Atuei em Azure e AWS em observabilidade, automação de infraestrutura e resposta a incidentes.
- Criei descoberta de monitoramento e documentação operacional para melhorar a cobertura e a transferência de conhecimento.
Carreira anterior · desenvolvimento de software e TI
- Dasa · Desenvolvedor de software
- Jul – Dez 2017
API Gateway e integração REST/SOAP. - PRÓPONTO · Desenvolvedor de software
- Jan – Jul 2017
Web services e integração contínua. - Microdata Sistemas · Desenvolvedor Java
- Jan – Dez 2016
Web services em Java e e-commerce. - Microdata Sistemas · Analista de sistemas
- Nov 2014 – Dez 2015
Delphi, SQL Server e suporte corporativo. - GZ Sistemas · Analista de suporte de TI júnior
- Mar 2013 – Jul 2014
Suporte ao cliente, bancos de dados, redes e Linux. - Coca-Cola FEMSA · Assistente administrativo & supervisor
- Fev 2012 – Mar 2013
Operações de entrega, relatórios e fechamento mensal.
A perspectiva de um operador.
A abordagem de um desenvolvedor.
Trabalho onde a infraestrutura, o software e o dia a dia do time de engenharia se encontram.
Meu caminho até a platform engineering começou no suporte de TI e no desenvolvimento de software. Essa bagagem me faz prestar atenção aos dois lados de uma abstração: como um sistema se comporta em produção e com que facilidade outro engenheiro consegue entendê-lo e alterá-lo.
Meu melhor trabalho transforma uma correção pontual em uma capacidade repetível: um fluxo de deployment, uma abordagem de diagnóstico, um sinal confiável ou um procedimento operacional documentado.
Capacidades, com evidências
| Capacidade | Aplicada a | Evidência |
|---|---|---|
| Plataforma & entrega | Kubernetes, Terraform, GitHub Actions, ArgoCD, Helm | Ambientes de preview e promoção de imagens |
| Confiabilidade & observabilidade | Jenkins, Prometheus, Grafana, Cloud Monitoring | Reparo de alertas ciente do runtime |
| Arquitetura em nuvem | GCP, AWS, Azure; redes compartilhadas e ambientes isolados | Terraform e Shared VPC |
| Operações de segurança | Automação de scans, enriquecimento de métricas, controles operacionais | Visibilidade da postura de segurança |
| Engenharia de custos | Consolidação de recursos, alocação de custos, caminhos de ingestão | Uma redução medida no faturamento de monitoramento |
| Infraestrutura de IA | GPU serving, otimização de inicialização, experimentos de failover | Serving de LLM multimodal e fallback operado |
Liderança técnica na prática
Três exemplos de transformar uma investigação individual em algo que o time pode reutilizar. O escopo abaixo reflete o trabalho entregue; uma adoção mais ampla não é presumida.
Tornar um procedimento de recuperação executável
Reparei defeitos de bootstrap e teardown durante um ensaio completo de cluster e, em seguida, reutilizei o processo em três reconstruções de ambiente. O ensaio restaurou 35 aplicações GitOps e adotou 49 certificados sem reemiti-los.
Decisões e validação da recuperação ↗Colocar a correção na plataforma compartilhada
Isolei o overhead de DNS, tornei a configuração do resolver ajustável no Helm chart compartilhado e verifiquei oito combinações de aplicação/ambiente antes do rollout de produção.
Do diagnóstico a uma configuração reutilizável ↗Projetar para o próximo engenheiro
Construí um piloto de preview em dois repositórios com uma convenção de ambiente compartilhada, promoção de imagem testada e limpeza automática. O ciclo de vida faz da criação e da remoção parte da mesma capacidade.
O piloto e seu limite de adoção ↗Demonstração independente de portfólio · Python
Leia o caminho da falha e depois o execute.
Um pequeno cliente de inferência demonstra requisições autenticadas, timeouts por tentativa, leituras de resposta limitadas e resultados de fallback explícitos. Os testes de integração usam servidores HTTP locais reais; não é necessário GPU, assinatura de API nem download de modelo.
Este é um novo exemplo educacional criado para este portfólio, separado do código do empregador. Ele exercita o comportamento de transporte com respostas de modelo simuladas, não a qualidade do modelo nem a capacidade de produção.
- Validar a configuração e autenticar
- Tentar o primário dentro do seu timeout
- Fazer fallback em falha transitória ou resposta vazia
- Retornar uma resposta ou uma falha explícita
Como contribuo além do código
- Oriento engenheiros em resposta a incidentes, mudanças de infraestrutura e revisões de prontidão para produção.
- Coordeno migrações e mudanças de plataforma com os times de desenvolvimento, QA e segurança.
- Documento decisões, caminhos de rollback e runbooks para que o trabalho continue utilizável após a passagem de bastão.
Formação
MBA em Engenharia de Software
Wyden Educacional · 2015–2016
Análise e Desenvolvimento de Sistemas
Anhanguera Educacional · 2012–2014
Idiomas
Português — nativo
Espanhol — profissional pleno
Inglês — proficiência profissional de trabalho
Cursos e aprendizado contínuo
- Google Cloud Platform Fundamentals: Core Infrastructure
- Logging, Monitoring and Observability in Google Cloud
- Desenvolvimento ágil avançado com Java
- Programação em TypeScript e fundamentos de SQL
Vamos falar sobre a sua plataforma.
Tenho interesse em vagas Senior e Staff em Platform Engineering e SRE, com foco em entrega confiável, infraestrutura de IA e eficiência de custos em nuvem.
Trabalhar juntos internacionalmente
- Vagas
- Senior ou Staff · Platform Engineering · Site Reliability Engineering
- Idiomas de trabalho
- Inglês — proficiência profissional de trabalho
Português — nativo · Espanhol — profissional pleno - Planejando uma conversa
- Inclua na sua mensagem a localização da vaga, a sobreposição de fuso horário necessária e o modelo de contratação, para que possamos conversar sobre aderência, autorização de trabalho e eventuais requisitos de realocação.
Os estudos de caso mostram como abordo problemas. Se algum desafio específico parecer familiar, inclua-o na sua mensagem.