Leandro Baldan

integração · Python · Django · Celery · PostgreSQL

Fazer 6 portais falarem a mesma língua

Cada usina reporta por um lugar: portais cloud de fabricantes, SCADA local na própria usina ou API do inversor. Escrevo os coletores que buscam esse dado, os pipelines que reconciliam o que chegou de fontes diferentes e os backfills que recuperam o histórico quando uma fonte fica fora do ar.

• Falha é o caso normal: OAuth, retry e fallback para rate limit, indisponibilidade e dado faltando. O desenho assume consistência eventual e falha parcial.
• Fuso e calendário: cada usina tem o seu, e o dia solar real não é o dia do calendário do servidor.
• Entrega: séries temporais em PostgreSQL/TimescaleDB, servidas para dashboard, alertas, exportações CSV/Excel e relatórios.

visão simplificada do fluxo de dados

qualidade de dados · SQL · LaTeX

Auditar o dado antes de confiar nele

Montei um framework de auditoria que compara, usina por usina, três versões da mesma medição: a gravada localmente, a do SCADA e a da API cloud. Quando elas divergem, uma hierarquia de confiança entre as fontes decide quem está certo, e o relatório diz o que corrigir e como.

• 45 usinasauditadas com o mesmo método
• 0,5% / 1 kWhcritério de aceite entre as fontes
• PDFrelatório automático com plano de remediação

O que costuma aparecer: lacunas de captura, sensor travado, drift de calibração e janelas em que a API ficou fora do ar.

machine learning · LightGBM · scikit-learn

Modelo onde ajuda, regra onde é mais confiável

Implementei de ponta a ponta o classificador de alertas de inversores em 5 classes. As features vêm do domínio solar: razão de potência e de irradiância contra uma baseline móvel, detecção de flatline, dia solar real e comparação entre inversores da mesma usina. O cuidado principal foi não me enganar: treino e teste separados por usina, com validação cruzada agrupada, para o modelo não decorar a planta.

• 0,94de F1 na detecção de anomalia (binário)
• 0,82 a 0,99de F1 nas classes do multiclasse
• 5 classescom SMOTE no desbalanceamento

desenho do ciclo de inferência e de melhoria contínua

operação · SSH · VPN · Windows · Linux · Docker

Vigiar a usina e agir antes da coleta parar

Parte das usinas grava em um SCADA local (Scada-LTS sobre Tomcat e MySQL no Windows, ou em containers Docker no Linux). Estruturei o acesso SSH a essas máquinas via VPN, com inventário e runbooks, e escrevi um watchdog que vigia serviços, captura, memória, disco e banco. Quando algo falha, ele salva um pacote de diagnóstico na própria máquina e manda um e-mail curto explicando o que viu.

Nas máquinas Windows, uma tarefa separada de auto-restart age em casos específicos, para a coleta não ser interrompida:

• Scada parado ou travado (página de login sem responder por 10 minutos): sobe o MySQL se precisar e reinicia o Scada.
• Vazamento de memória: amostra o consumo a cada hora e, quando a tendência confirma o vazamento, faz um reinício preventivo de madrugada. Em memória crítica, reinicia na hora.
• Freios: no máximo 3 tentativas por hora, e nenhum reinício se o banco estiver com problema (sem resposta, somente leitura ou com sinal de corrupção), para não piorar o que já está ruim.
• Nasceu de um incidente real, em que uma usina ficou dias sem gravar sem ninguém perceber.
• Versionado em SemVer, com o hash de cada release anotado por usina, e testes de regressão que rodam isolados na máquina da usina, com SMTP falso.

o watchdog só observa e guarda evidência; quem age é o auto-restart, com limite e trava de banco · no Linux, só reporta

entrega · Docker · GitHub Actions

Colocar no ar sem susto

Mantenho os deploys Dockerizados de Django e Celery, com CI/CD no GitHub Actions: lint, type checking, testes unitários e de integração, deploy automático em staging e produção, rollback, health checks e logs estruturados. Cada tarefa roda numa stack Docker Compose isolada, com banco, broker e volumes próprios.