Engenharia e operações de produção
Observabilidade, Kubernetes, análise de incidentes e automação com resultados documentados.
Explorar casos técnicosALEXANDRE PAIVA SRE · DEVOPS · PLATFORM
Clareza sob pressão.
Sigo o alerta até a causa raiz. Evidência acima de suposições.
Sou engenheiro de confiabilidade (SRE/DevOps) e trabalho com infraestrutura em nuvem, Kubernetes e automação na Elven Works. Ajudo empresas a manter sistemas estáveis, encontrar gargalos e melhorar seus ambientes de produção — da implantação ao monitoramento e à investigação de incidentes. Meu objetivo é tornar a operação mais confiável, eficiente e fácil de manter.
PostgreSQL de produção: CPU acima de 80%Disparando
97%do limite de CPU, com 88% de throttling
- Throttling da CPU confirmado no Prometheus. Memória sobrando: o gargalo não é RAM.
- EXPLAIN ANALYZE nas queries quentes e leitura de 122 queries lentas do log.
- Causa raiz: a paginação por OFFSET lia 119.145 linhas para devolver 15.
- Correção dividida em duas frentes: código (paginação por cursor) e banco (autovacuum por tabela).
38/38alertas sintéticos entregues em testes de roteamento
871regras de alerta auditadas em 6 ambientes de produção
249 GBrestaurados com integridade validada
17casos documentados de engenharia e operações
Casos em destaque
Cada caso segue o mesmo formato: o contexto, o que eu fiz, o que mudou e o que aprendi, sempre com o número que foi medido.
-
96 tabelascom isolamento por tenant no próprio PostgreSQL (RLS)
Ignity: do MVP à produção, com isolamento de tenant no próprio banco
Capyvara, minha startup. Ignity é a nossa plataforma de governança de projetos e inovação para universidades e institutos federais -
14riscos de capacidade e confiabilidade mapeados, com custo e gatilho
Ranggo: quantas escolas cabem antes de cair? Capacidade, SLA e permissões para a auditoria da merenda escolar
Capyvara, minha startup. Ranggo é o nosso sistema de auditoria participativa da merenda escolar, vendido a secretarias municipais de educação -
119.145linhas lidas para devolver 15: a causa de 4 incidentes
O incidente que se resolvia sozinho: banco de produção saturado por paginação
plataforma SaaS de API de mensagens; o mesmo padrão apareceu depois numa plataforma de agentes de IA -
50 diasde metade da telemetria perdida, até o shard voltar a gravar
Metade da telemetria sumiu por 50 dias, e ninguém percebeu
plataforma SaaS de mensageria -
249 GBrestaurados em 2h41 para provar que o backup funciona
Backup só conta se o restore foi testado: RPO, RTO e recuperação de desastres
empresa com várias plataformas SaaS em produção -
38/38alertas de teste entregues depois de religar o roteamento
Alerta que não chega a ninguém não existe: monitoramento de serviços críticos
empresa com várias plataformas SaaS em produção -
4 serviçospromovidos em lote com blue/green, em produção
Comissão não pode falhar: containers, IaC e deploy blue/green para um SaaS de remuneração variável
SaaS de gestão de comissões e remuneração variável -
4,8 TBde espaço morto por trás da queda de 14 nós
War room: o disco do hipervisor encheu e derrubou 14 nós de produção
plataforma SaaS de atendimento multicanal
Todos os casos
Organizados pelo tipo de trabalho, do construir ao proteger. Os clientes da consultoria foram anonimizados e aparecem pelo segmento; Ignity e Ranggo são produtos da minha startup.
Construir
Infraestrutura nova, do zero ou migrada, que o cliente consegue operar.
Operar
Fazer o que já existe funcionar todo dia e avisar quando não funciona.
- Ranggo: quantas escolas cabem antes de cair? Capacidade, SLA e permissões para a auditoria da merenda escolar14
- Alerta que não chega a ninguém não existe: monitoramento de serviços críticos38/38
- Do alerta ao gráfico certo: dashboards de infraestrutura e RED para aplicações4,6%
- O pipeline que "funcionava": confiabilidade do fluxo de dados para o data lake~6 h
- Plataforma para quem entrega: DevOps de plataforma numa fintech100%
- Um robô que testa a plataforma como um cliente: observabilidade multicloud para um SaaS B2B2 nuvens
Diagnosticar
Ir do sintoma até a causa, com número em cada passo.
- O incidente que se resolvia sozinho: banco de produção saturado por paginação119.145
- Metade da telemetria sumiu por 50 dias, e ninguém percebeu50 dias
- Saímos do New Relic: migração das visões de APM para o SigNoz, com paridade provada6/6
- Check-up completo de uma plataforma SaaS internacional: do diagnóstico à apresentação executiva7
Recuperar
Provar que dá para voltar, e aprender quando algo cai.
Proteger
Reduzir a superfície de ataque sem quebrar a produção.
Experiência profissional
Engenharia de confiabilidade e operações de produto: duas perspectivas que se complementam.
Como trabalho
Hábitos que aparecem em todos os casos.
Medir antes de concluir
Uma hipótese só vira causa raiz quando tem um número por trás: EXPLAIN, métricas de cgroup, tamanho por tabela, contagem por tentativa.
Separar infra de código
Deixo claro o que o DevOps resolve e o que precisa ir para o time de desenvolvimento, com evidência, para ninguém esperar a coisa errada.
Alerta que ninguém recebe não existe
Cuido do caminho inteiro: a regra, a rota, o destino, o link para o painel certo e o teste que prova que chega.
Somente leitura primeiro, e tudo versionado
Diagnostico sem mexer em produção, mudo com plano de reversão, e o que só existia no cluster volta para o Git.
Vamos conversar sobre confiabilidade.
Estou aberto a oportunidades em SRE, DevOps e engenharia de plataforma.