Casos de trabalho profissional em ambiente industrial, reescritos de forma genérica. Identificadores, quantidades exatas, modelos de equipamentos, topologia, datas e o estado de pendências foram omitidos ou aproximados. Os casos descrevem método e raciocínio, não a situação atual de nenhum ambiente.
Implantação de autenticação por conta de máquina em rede Wi-Fi corporativa, cobrindo dezenas de access points e bloqueando dispositivos pessoais.
NPS · Active Directory · UniFi · GPO · PEAP-MSCHAPv2
Investigação de um notebook que deixou de autenticar no Wi-Fi: hipóteses, quatro fontes de log, causa raiz e correção definitiva.
802.1X · NPS · NTLM · Active Directory · análise de logs
Rede sem documentação levantada do zero: VLANs inconsistentes, redundância, drift de configuração e roteiro de regularização por risco.
HPE Aruba · FortiGate · SD-WAN · VLAN · Python
Um sintoma, seis frentes de investigação e correções em rodadas: quedas diárias reduzidas em 90%, caso encerrado.
UniFi · tcpdump · Linux · Python · análise de RF
PoC para substituir o VMware com critérios de avaliação e de rollback definidos antes, e acionados quando o risco se confirmou.
Virtualização · HCI · Backup · Critérios de rollback
Robôs com sinal ótimo e alarme de “fora da rede”: quatro hipóteses descartadas e causa raiz no tempo de ar do canal, ocupado por celulares distantes.
ESP32 · Wi-Fi 2,4 GHz · UniFi · Zabbix · Grafana · RSSI mínimo
VM crítica migrada de KVM para VMware com três bloqueios em cadeia: acesso, rede e HTTP 503, resolvidos sem rollback.
VMware · KVM · Linux · GRUB · Docker · Apache
Automação que recebe as respostas dos formulários de briefing, registra cada uma em planilha e me avisa na hora pelo Telegram. O fluxo foi usado nos formulários de briefing do próprio portfólio.
Tally · Google Sheets · Telegram · APIs · Automação
Outros três trabalhos de infraestrutura (offboarding seguro, monitor de quedas Wi-Fi e sessões WMS) estão em Todos os projetos de infraestrutura.
Arquivo completo dos trabalhos técnicos, com tipo e status. Projetos menores trazem os detalhes aqui mesmo.
2026
Infraestrutura · também na trilha de Educação
802.1X em dezenas de access points, substituindo senha compartilhada; inclui versão didática sobre autenticação de rede.
2026
Infraestrutura de TI
Troubleshooting com hipóteses, quatro fontes de log, causa raiz, contorno e correção definitiva.
2026
Infraestrutura de TI
Levantamento físico, parser de configurações, drift, VLANs, redundância e matriz de achados por risco.
2026
Infraestrutura de TI
Seis frentes de investigação para um mesmo sintoma, com hipóteses, cinco fontes de evidência e correções em rodadas com rollback. Quedas diárias reduzidas em 90%, caso encerrado.
2026
Infraestrutura de TI
PoC de substituição da plataforma de virtualização, com alternativa open source, critérios de rollback e redesenho do backup.
2026
Infraestrutura de TI
Migração a frio de KVM para VMware com senha de root recusada, interface renomeada e Port Group divergente e proxy reverso em 503; causa raiz por camada e três recomendações preventivas.
2026
Infraestrutura de TI
Runbook em blocos que revoga todos os acessos durante a conversa de desligamento, com evidência auditável e cuidado extra para contas privilegiadas.
Runbook estruturado em blocos para que, no desligamento, todos os acessos sejam revogados de forma consistente e auditável. O procedimento distingue o perfil comum do colaborador com acesso privilegiado, onde os riscos são maiores.
O bloqueio acontece durante a conversa de desligamento, não depois. O chamado do RH formaliza o horário e o analista fica de prontidão.
O risco é tudo o que a pessoa sabe. Além do perfil comum: rotação das credenciais compartilhadas e de serviço que ela conhecia, auditoria de alterações recentes em contas e grupos privilegiados, revisão de tarefas e scripts executados com a credencial dela, e remoção de chaves e tokens.
Inventário próprio por plataforma, bloqueio equipamento por equipamento, preservando contas de contingência definidas no procedimento.
# Bloco do diretório: evidência de grupos, bloqueio e movimentação para a OU de inativos $u = Get-ADUser $sam -Properties MemberOf $u.MemberOf | Out-File "C:\Offboarding\$sam-grupos-$(Get-Date -f yyyyMMdd).txt" # Senha aleatória com gerador criptográfico (não usar $pwd: é variável automática) $bytes = [byte[]]::new(32) [Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes) $novaSenha = [Convert]::ToBase64String($bytes) Set-ADAccountPassword $sam -Reset -NewPassword (ConvertTo-SecureString $novaSenha -AsPlainText -Force) Disable-ADAccount $sam Set-ADUser $sam -Description "Desligado $(Get-Date -f dd/MM/yyyy) - $chamado - $env:USERNAME" $u.MemberOf | ForEach-Object { Remove-ADGroupMember $_ -Members $sam -Confirm:$false } Move-ADObject $u.DistinguishedName -TargetPath "OU=Inativos,DC=exemplo,DC=local"
2026
Infraestrutura de TI
Agente Python open source com testes automatizados, CI multiversão e validação TLS por padrão, que transformou relatos de queda em métrica por coletor, AP e hora.
Coletores de dados Android em um SSID dedicado ao WMS apresentavam quedas cuja frequência e padrão eram difíceis de medir objetivamente. Sem métrica, era impossível saber se uma mudança na configuração do Wi-Fi havia melhorado ou piorado o cenário. Desenvolvi um agente Python que consulta a API do UniFi, detecta quando cada coletor some e volta e registra duração, AP e RSSI em CSV.
As quedas eram relatadas pelos operadores de armazém, mas sem dados objetivos: não se sabia quantas quedas por hora ocorriam, qual coletor caía mais, em qual AP, com que RSSI. Sem uma linha de base, qualquer ajuste no rádio era um chute.
O script consulta a API legada do UniFi a cada 60 segundos e compara o estado anterior com o atual. Quando um coletor desaparece, grava um evento de queda com o AP e o RSSI do último registro. Na reconexão, calcula a duração. Toda saída vai para um CSV em dados/eventos.csv; um segundo comando gera um relatório Markdown diário com top coletores, quedas por hora e alertas configuráveis. Sem dependências externas — stdlib Python 3.10 apenas.
Os coletores são identificados por prefixo OUI do fabricante (configurável) ou por um inventário em config.json. Dispositivos Android com MAC aleatório são sinalizados separadamente — importante para não confundir quedas de coletor com dispositivos pessoais no mesmo SSID.
Com a linha de base em mãos, foi possível correlacionar as quedas com métricas de rádio (TX Retry por AP, Canal Busy) e validar, com dados, o efeito de cada ajuste de configuração — canais, largura de banda e taxas mínimas. O script ficou genérico o suficiente para qualquer ambiente UniFi com coletores no Wi-Fi.
A suíte cobre classificação por OUI, queda e reconexão, SSID com espaço extra, geração e migração do CSV, duração, alertas sem repetição, nome das APs e demonstração sem controladora. Os testes TLS verificam certificado e hostname por padrão, CA interna, rejeição de configurações ambíguas e falha sem fallback inseguro. O workflow está configurado para pushes na main e pull requests, em Python 3.10 a 3.13.
A suíte tem 177 testes e roda no GitHub Actions em Python 3.10, 3.11, 3.12 e 3.13 a cada push na main (versão de 23/10/2026, commit 963d838). O resultado de cada execução está nas execuções do workflow ↗ (abre em nova aba).
Os testes simulam a API da controladora; o comportamento em produção está medido no estudo de caso das quedas dos coletores.
2026
Infraestrutura de TI
Cada briefing enviado pelo site vira uma linha de planilha e uma notificação no Telegram, sem servidor próprio e sem digitação manual.
Os briefings da página de serviços (pedagógico, diagnóstico de suporte e projeto de desenvolvimento) são formulários Tally. Montei a integração que leva cada resposta para uma planilha Google Sheets e dispara um aviso no Telegram, para que nenhum pedido fique esperando alguém abrir a caixa de entrada.
Pedidos chegando por formulário ficam parados até alguém lembrar de olhar. Para cumprir o prazo de resposta prometido na página (proposta em até 1 ou 2 dias úteis), o aviso precisa chegar no momento do envio e o histórico precisa ficar em um lugar só.
Serviços gerenciados no lugar de um servidor próprio: nada para manter no ar e menos superfície de ataque para um site estático. Tokens, webhooks e identificadores da planilha ficam só nas configurações das plataformas, fora do código do site.
Em produção nos briefings do portfólio. Cada envio aparece na planilha e gera a notificação, o que dá um registro auditável de todos os pedidos recebidos.
2026
Infraestrutura de TI
Causa raiz em canal 2,4 GHz saturado por celulares distantes; RSSI mínimo em −80 dBm e os alarmes não se repetiram.
Robôs industriais (ESP32) em uma área operacional geravam alarmes recorrentes de "fora da rede" no sistema de monitoramento. Os eventos vinham se repetindo por dias, com avisos de lentidão de ping e perda de pacotes — mesmo com o sinal Wi-Fi ótimo, entre −53 e −58 dBm, e sem qualquer reinicialização da antena.
O sistema de monitoramento testava a porta de aplicação de cada robô a cada 30 segundos. Dois testes consecutivos sem resposta (1 minuto) abriam um card de "fora da rede". O card só fechava após quatro respostas positivas com menos de quatro mudanças em 30 minutos — regra pensada para evitar oscilação, mas que esticava o alarme muito além da falha real.
O canal da antena da área operacional operava normalmente a 42 % de ocupação. Em uma janela de cerca de 6 minutos, celulares corporativos com sinal fraco (−80 a −107 dBm) conectados à mesma antena elevaram o uso do canal para 61–75 %. Aparelhos distantes transmitem mais devagar e ocupam o canal por mais tempo por pacote. Com o canal saturado, os robôs — mesmo com sinal ótimo — precisavam aguardar para transmitir, e o tempo de resposta ao teste de porta saltou de ~3 ms para 70–150 ms, no mesmo intervalo das falhas consecutivas que abriram o alarme.
Análise inteiramente passiva: leitura da controladora Wi-Fi (somente leitura) para estado dos robôs, log de conexões da antena e log de administração; monitoramento com dados de ping (a cada 3 min), teste TCP de porta (a cada 30 s) e ocupação do canal 2,4 GHz (a cada 1 min). Nenhuma configuração foi alterada durante a investigação.
Ativado o RSSI mínimo (≈ −80 dBm) no rádio 2,4 GHz da antena da área operacional. Aparelhos com sinal abaixo desse limiar são desassociados; a reconexão a um AP mais próximo depende do cliente e da cobertura disponível e não é garantida. Os robôs industriais, com sinal entre −53 e −58 dBm, não são afetados. Após a configuração, o canal voltou à faixa normal de ocupação e os alarmes desse tipo não se repetiram.
Infraestrutura de TI
Fim dos bloqueios de coletores pelo servidor: sessões mortas encerradas em menos de 2 minutos com TCP keep-alive.
Coletores Android de uma operação logística perdiam a sessão com o sistema de gestão de armazém (WMS) e acabavam bloqueados pelo próprio servidor. Diagnostiquei a causa, ajustei o servidor Linux e escrevi a instrução de trabalho para padronizar o procedimento.
O roaming entre antenas Wi-Fi gerava micro-quedas. O aplicativo do coletor perdia a sessão, mas o servidor mantinha o processo vivo. Na reconexão, as tentativas em rajada eram tratadas pelo xinetd como ameaça e o IP do coletor era bloqueado.
Análise de logs do xinetd e monitoramento da rede, cruzando os bloqueios connections limit per_source com os momentos de troca de antena.
Logs passaram a mostrar encerramentos limpos de sessão e nenhum bloqueio por limite de origem.
# Exemplo temporário; o serviço precisa habilitar SO_KEEPALIVE no socket sysctl -w net.ipv4.tcp_keepalive_time=60 sysctl -w net.ipv4.tcp_keepalive_intvl=10 sysctl -w net.ipv4.tcp_keepalive_probes=3 # Persistência: /etc/sysctl.d/99-wms-keepalive.conf # Depois de criar o arquivo, aplicar e verificar: sysctl --system sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
sysctl -w vale até o próximo reinício. Para tornar a configuração permanente, os valores vão em /etc/sysctl.d/ e são aplicados com sysctl --system.
Analista Sênior de Infraestrutura de TI com foco em virtualização, redes e automação.
Condução de prova de conceito para avaliar plataformas de virtualização e HCI como alternativa à plataforma atual, com critérios de rollback formalizados antes da implantação e acionados quando o risco se confirmou. Análise de rede Wi-Fi com Python e API do UniFi. Automação com PowerShell e GPO. Backup Veeam e Dell PowerProtect.
Aulas de infraestrutura e redes, hardware e manutenção, tecnologia alinhada à BNCC Computação e Excel avançado, sempre partindo de casos reais. Como ensino.
Infraestrutura de TI para fábricas e centros de distribuição: switches Aruba e TP-Link, Wi-Fi Ubiquiti, firewall, VMware + KVM, monitoramento Zabbix/Grafana e backup Dell PowerProtect.
Suporte de infraestrutura, gestão de usuários AD, antivírus, Wi-Fi Ubiquiti, VMware vSphere e KVM Oracle, monitoramento com Zabbix e Grafana.
Crédito PF/PJ, câmbio, contas a receber/pagar e relatórios gerenciais — antes da transição definitiva para TI.
Help Desk N1/N2, manutenção de computadores e rede local.
Desenho e operação de redes corporativas e Wi-Fi, segmentação por VLAN, autenticação 802.1X/RADIUS integrada ao Active Directory e firewalls.
Avaliação, operação e migração de hipervisores e servidores Windows e Linux, com critérios de teste e plano de rollback.
Backup e recuperação de dados, monitoramento com alertas e análise de logs para separar falha real de alarme falso.
Scripts para coletar dados, padronizar tarefas e diagnosticar falhas, incluindo integração com APIs de equipamentos.
Última atualização: 25 de outubro de 2026