Alternativas ao VMware em 2026: conheça o Huawei FusionCompute
Quem trabalha com virtualização já entendeu que o VMware virou uma discussão diferente depois da Broadcom. A pauta saiu do “qual recurso eu preciso?” e foi para “quanto isso vai custar na próxima renovação?”. Em muitos clientes, essa conversa abriu espaço para o Proxmox. Faz sentido. Mas existe uma terceira opção que quase nunca aparece nas primeiras reuniões: o Huawei FusionCompute. A plataforma não é nova nem experimental. Está na versão 8.10, tem documentação técnica extensa e casos de uso em telcos, bancos e órgãos governamentais ao redor do mundo. No Brasil, ele ainda aparece pouco nas conversas sobre substituição do VMware. E talvez esteja na hora de olhar para ele com mais calma. O que é o FusionCompute? O FusionCompute é a camada de virtualização da Huawei para data center. Ele roda sobre servidores físicos, entrega VMs, gerencia CPU, memória, rede e storage, e faz parte da solução DCS da Huawei. A arquitetura gira em torno de dois componentes: CNA (Computing Node Agent): roda em cada servidor físico, implementa o hypervisor UVP e gerencia as VMs localmente. VRM (Virtual Resource Manager): O VRM é o cérebro central e concentra a gestão do cluster. Ele controla agendamento de recursos, ciclo de vida das VMs, alocação de IP e VLAN, e entrega a interface web de administração. Roda em modo ativo/standby com failover automático em 1 a 2 minutos se o nó ativo cair. O hypervisor UVP tem base em KVM, assim como o Proxmox, mas opera em arquitetura bare-metal sem OS host intermediário, parecido com o ESXi. Tabela comparativa das três plataformas A tabela abaixo ajuda a separar o que é diferença real de arquitetura e o que é apenas diferença de empacotamento comercial. Funcionalidade VMware ESXi / vSphere 8 Proxmox VE 9.2 Huawei FusionCompute 8.10 Tipo de hypervisor Bare-metal (ESXi) Type-1 (KVM + QEMU) Bare-metal (UVP/KVM) Hosts por cluster até 96 Sem limite explícito* até 128 VMs por cluster até 8.000 Sem limite explícito até 8.000 Licenciamento Assinatura obrigatória; mín. 72 cores/CPU Open-source (suporte pago opcional) Licença comercial Huawei VM HA ✅ ✅ ✅ automático, independente do nó de gestão Live Migration ✅ vMotion ✅ ✅ Storage Live Migration ✅ Storage vMotion ✅ ✅ Balanceamento de carga automático ✅ DRS (incluso no bundle) ✅ Dynamic Load Balancer (desde PVE 9.2) ✅ DRS + DPM integrados Economia de energia automática (DPM) ✅ ❌ ✅ desliga hosts ociosos automaticamente Memory Overcommit inteligente ✅ ✅ (ballooning) ✅ (ballooning + sharing + swapping; x86 e Arm) Thin Provisioning ✅ ✅ ✅ Virtual Switch distribuído ✅ vDS (no bundle pago) ✅ OVS/SDN ✅ DVS nativo SR-IOV Limitado ✅ ✅ GPU Passthrough ✅ ✅ ✅ GPU Virtualization ✅ (NVIDIA vGPU) ✅ (NVIDIA vGPU, desde 2025) ✅ (Intel vGPU integrado) Containers / K8s nativo ❌ (Tanzu, separado e pago) ✅ (LXC; sem K8s nativo) ✅ K8s integrado Multi-tenant completo ✅ (com add-ons) ❌ ✅ (VPC, ECS, ELB, NAT, etc.) DR orquestrado ✅ SRM (pago) ❌ ✅ UltraVR integrado Backup agentless com CBT ✅ (via terceiros) ✅ Proxmox Backup Server ✅ eBackup nativo Suporte a Arm ❌ ❌ ✅ Black Box de diagnóstico ❌ ❌ ✅ A documentação oficial do Proxmox não define um limite de nós por cluster. O teto prático depende de hardware de rede e latência; há relatos de clusters com mais de 50 nós em produção com hardware enterprise. O que chama atenção no FusionCompute Escala de cluster O FusionCompute suporta 128 hosts e 8.000 VMs por cluster lógico, com até 4.096 hosts e 80.000 VMs gerenciadas por instância. O VMware chega a 96 hosts por cluster no vSphere 8. O Proxmox não tem um teto documentado, mas a estabilidade em clusters muito grandes depende bastante de como a rede de gerenciamento foi projetada. Para data centers corporativos grandes, o suporte a 128 hosts por cluster com escala total de 80.000 VMs é um grande diferencial. DRS e DPM: agendamento que poupa energia O DRS do FusionCompute monitora a carga dos hosts em tempo real e migra VMs automaticamente para equilibrar o uso de CPU e memória no cluster, sem intervenção manual. Isso equivale ao que o VMware oferece no bundle do vSphere e ao que o Proxmox passou a oferecer com o Dynamic Load Balancer do PVE 9.2. O diferencial do FusionCompute aqui é o DPM (Dynamic Power Management): quando a carga do cluster cai, o sistema consolida as VMs em menos hosts e desliga automaticamente os servidores ociosos. Quando a demanda sobe, os hosts são religados. Para ambientes com carga variável ao longo do dia ou da semana, isso representa economia real de energia sem precisar de automação externa. Memory Overcommitment com três camadas O FusionCompute combina ballooning, memory sharing (páginas idênticas entre VMs são consolidadas em uma cópia física) e swapping para permitir que um servidor ofereça mais memória virtual do que a física disponível. O Proxmox usa ballooning, mas não implementa memory sharing entre VMs de forma nativa. O resultado prático é uma densidade maior de VMs por host no FusionCompute, especialmente quando as cargas têm perfil de uso de memória parecido. Esse recurso funciona tanto em x86 quanto em Arm, o que é um diferencial em ambientes com servidores Kunpeng ou similares. QoS de recursos por VM com três dimensões Enquanto o Proxmox tem controles básicos de CPU shares e limites, o FusionCompute permite configurar três parâmetros independentes por VM: Quota: a proporção de CPU que a VM recebe durante disputa de recursos entre VMs no mesmo host. Reservation: o mínimo garantido de CPU que a VM sempre receberá, mesmo sob alta contenção. Limit: o teto absoluto de CPU que a VM pode consumir, mesmo com o host ocioso. O mesmo modelo se aplica a memória, rede e IOPS de storage. Isso importa quando o mesmo cluster mistura produção, homologação e carga menos previsível. Sem política de recurso bem definida, uma VM barulhenta pode virar problema para outra área. Isolamento de VMs em cinco camadas O hypervisor UVP implementa isolamento entre VMs em cinco dimensões: recursos físicos, agendamento de vCPU (via VMCS), memória (com três níveis
Como configurar Geofeed no Registro.br
No artigo anterior falamos sobre geofeed, RFC 8805, RFC 9632, RDAP e por que isso importa para provedores. Agora vamos para a prática. A ideia aqui é montar um exemplo simples de publicação de geofeed usando o Registro.br, com arquivo CSV publicado em HTTPS e validação via WHOIS e RDAP. Para não usar nenhum bloco real, os exemplos abaixo usam blocos reservados para teste e documentação. Em produção, naturalmente, você deve substituir pelos blocos reais do ASN. Cenário de exemplo Vamos imaginar que o provedor tenha um bloco IPv4 /22 e use cada /24 em uma cidade diferente. Para o exemplo IPv4, vamos usar: Esse bloco faz parte de um espaço reservado para testes/benchmarking. Ele não deve ser usado em produção na Internet. Aqui ele serve apenas para deixar o exemplo com cara de operação real, sem expor prefixo. A divisão operacional seria: No IPv6, vamos usar o bloco de documentação: E separar em /40: Essa abordagem fica mais próxima do mundo real: um bloco maior cadastrado e, dentro dele, divisões por cidade ou região. Um arquivo por bloco Por enquanto, o Registro.br mantém uma política mais restrita para publicação de geofeed. Na prática, o caminho mais seguro é trabalhar com um arquivo por bloco cadastrado, contendo apenas o próprio bloco ou sub-blocos dele. Então, se o bloco cadastrado é: faz sentido ter um único arquivo para esse /22, contendo os /24 internos: Conteúdo: Perceba o ponto principal: todas as linhas estão dentro do bloco 198.18.0.0/22. Isso é diferente de misturar blocos independentes no mesmo arquivo. Por exemplo, se você tivesse dois blocos diferentes cadastrados no Registro.br, como: não seria uma boa ideia colocar tudo no mesmo CSV neste momento. O mais seguro seria criar um arquivo para cada bloco. Arquivo IPv6 Para o IPv6, seguindo a mesma lógica, o bloco cadastrado seria: O arquivo poderia se chamar: Conteúdo: Aqui também vale a mesma regra: os /40 estão dentro do /32. Em um provedor real, a granularidade pode variar. Você pode usar /40, /44, /48 ou outro tamanho, dependendo de como o IPv6 foi planejado. O importante é que o geofeed represente a operação de forma coerente e não tente ser mais preciso do que a rede realmente permite. Formato correto do CSV A RFC 8805 define o formato base do geofeed [1]: Mas no arquivo publicado, normalmente você não coloca cabeçalho. Então não faça assim: Faça assim: Alguns detalhes importantes: O arquivo deve estar em UTF-8. O prefixo precisa estar em formato CIDR. O país do Brasil é BR. O estado precisa seguir ISO 3166-2. Paraná é BR-PR, São Paulo é BR-SP, Rio Grande do Sul é BR-RS. A cidade não deve conter vírgula. O campo de código postal deve ficar vazio, mas a vírgula final deve permanecer. Onde consultar os códigos dos estados Para o campo de região, use ISO 3166-2. Alguns exemplos: A fonte oficial é a ISO Online Browsing Platform [4]. Para consulta rápida, a página ISO 3166-2:BR também lista os códigos dos estados brasileiros [5]. Publicando o arquivo Você pode publicar o CSV no próprio site do provedor, em um servidor web, em um bucket público ou usando GitHub Pages. O ponto principal é que a URL precisa baixar o arquivo diretamente. Exemplo para IPv4: Exemplo para IPv6: Ou, usando GitHub Pages: Cuidado com links do tipo: Esse link abre uma página HTML do GitHub, não o arquivo diretamente. Para o Registro.br, a URL precisa entregar o CSV direto. Exemplo com GitHub Pages Um caminho simples para laboratório ou pequenos provedores é usar GitHub Pages. O fluxo é: O arquivo IPv4 ficaria assim: A URL final poderia ficar assim: Se ao abrir essa URL o navegador baixar ou mostrar somente o conteúdo CSV, está no caminho certo. Se abrir uma página do GitHub, com layout, botões, menu e preview, está errado. Content-Type O Registro.br pode validar o tipo de conteúdo publicado. O ideal é que o servidor responda com: ou: A RFC 9877 registra o tipo application/geofeed+csv para arquivos geofeed [3]. Para validar: Exemplo de resposta esperada: ou: Validando a sintaxe Antes de cadastrar no Registro.br, vale passar o arquivo em um validador. Uma opção prática é: Ele ajuda a pegar erro bobo, como: Exemplo errado: Problemas: Correto: Configurando no Registro.br Depois de publicar e validar o arquivo, acesse o portal do Registro.br. O fluxo geral é: 3. selecionar o bloco e abrir a opção Configurar Geofeed; 4. informar a URL HTTPS do arquivo; Exemplo IPv4: Exemplo IPv6: Lembrando novamente: estes blocos são apenas exemplos para documentação. Em produção, você usaria os blocos reais. Validando no WHOIS Depois de configurar, valide se o geofeed apareceu no WHOIS. Exemplo IPv4: Resultado esperado: Exemplo IPv6: Resultado esperado: Em produção, substitua pelos IPs reais dos blocos configurados. Validando no RDAP Também dá para validar via RDAP. IPv4: Resultado esperado: IPv6: Resultado esperado: O RDAP é importante porque é o caminho mais estruturado para sistemas automatizados descobrirem o geofeed. A RFC 9877 foi criada justamente para padronizar esse link de geofeed dentro das respostas RDAP [3]. Validando se ficou descobrível Além de WHOIS e RDAP, uma ferramenta útil é o GeolocateMuch: Em ambiente real, use o prefixo ou IP. Essa ferramenta ajuda a verificar se o geofeed está sendo descoberto a partir dos dados públicos. Checklist final Antes de considerar finalizado, revise: Erros comuns Misturar blocos diferentes no mesmo arquivo Errado: Se o arquivo é do bloco 198.18.0.0/22, o prefixo 198.18.8.0/24 está fora dele. Usar estado sem o prefixo do país Errado: Correto: Esquecer a vírgula final Errado: Correto: Usar link de preview do GitHub em vez do arquivo direto Errado: Correto, usando GitHub Pages: Boas práticas operacionais Depois de configurar, não esqueça que isso precisa ser mantido. Revise o geofeed quando houver: O ideal é que a informação venha de uma fonte confiável: IPAM, documentação de POPs, inventário de blocos ou base interna da operação. Geofeed feito “de cabeça” até funciona no começo, mas vira problema quando a rede cresce. Conclusão Configurar geofeed no Registro.br não é complicado. O que exige atenção é o detalhe. Um arquivo por bloco cadastrado.Somente o bloco ou sub-blocos dele.CSV em UTF-8.URL HTTPS baixando direto.Estado no padrão ISO 3166-2.Validação
Geofeed: por que seus IPs aparecem na cidade errada e como começar a corrigir isso
Quem trabalha com provedor de Internet provavelmente já viu esse tipo de reclamação: “Meu cliente está no Paraná, mas o site acha que ele está em São Paulo.”“O streaming está dizendo que estou em outro país.”“O banco bloqueou o acesso porque achou estranho o local do IP.”“O Google está mostrando previsão do tempo de outra cidade.” É uma situação meio ingrata, porque na maior parte das vezes a rede está funcionando. O cliente navega, o BGP está ok, o DNS responde, o traceroute chega, a latência está aceitável. Mas, para o usuário final, a percepção é simples: alguma coisa está errada com a Internet dele. E, muitas vezes, está mesmo. Não na conectividade, mas na forma como aquele endereço IP está sendo geolocalizado por terceiros. IP não tem cidade gravada dentro dele A primeira coisa importante é entender que um IP não nasce com uma cidade dentro dele. Não existe, no protocolo IP, um campo dizendo: ou: A geolocalização por IP é uma inferência. Empresas de conteúdo, bancos, CDNs, plataformas antifraude, buscadores, serviços de streaming e bases comerciais tentam descobrir onde aquele IP provavelmente está sendo usado. Para isso, elas cruzam várias informações: dados de registros de Internet, comportamento de tráfego, medições, histórico, informações de usuários, bases comerciais, DNS, BGP, entre outras coisas. Na maioria dos casos funciona bem o suficiente. Mas quando erra, incomoda bastante. Um provedor pode receber um bloco novo, comprar ou transferir recursos, mudar prefixos entre cidades, ativar um POP novo, reorganizar CGNAT, dividir IPv6 por região, trocar upstreams ou simplesmente começar a usar um bloco que antes estava associado a outra localidade. Só que as bases externas podem demorar para aprender isso. E aí começam os chamados. Onde entra o geofeed O geofeed é uma forma padronizada do próprio operador da rede dizer: “Estes prefixos IP estão sendo usados nestas localidades.” Ele não muda o roteamento. Não mexe no BGP. Não anuncia nada para a Internet. Não é uma sessão com upstream. É só um arquivo CSV publicado em HTTPS, seguindo um formato definido na RFC 8805 [1]. Um exemplo simples: 192.0.2.0/24,BR,BR-PR,Apucarana,198.51.100.0/24,BR,BR-PR,Londrina,203.0.113.0/24,BR,BR-SP,Sao Paulo,2001:db8:100::/48,BR,BR-RS,Porto Alegre, Cada linha associa um prefixo a uma localização aproximada. O formato é: Na prática: quer dizer: A vírgula no final é importante. Ela representa o último campo, postal_code, vazio. O que cada campo significa O primeiro campo é o prefixo IP. Pode ser IPv4 ou IPv6, em formato CIDR. Exemplos: O segundo campo é o país, usando ISO 3166-1 alpha-2. Para Brasil, usamos BR. O terceiro campo é a região, usando ISO 3166-2. No caso dos estados brasileiros: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul A lista oficial pode ser consultada na plataforma da ISO [4]. Para consulta rápida, também existe a página ISO 3166-2:BR, que lista os códigos dos estados brasileiros [5]. O quarto campo é a cidade. O quinto campo é o código postal. Ele existe no formato, mas normalmente não recomendo usar para provedor. A própria RFC trata esse campo com cuidado, porque ele pode dar uma granularidade exagerada [1]. Para ISP, na maioria dos casos, país, estado e cidade já são suficientes. Geolocalização é aproximação, não GPS Esse ponto é mais importante do que parece. Quando falamos de geofeed, é fácil cair na tentação de tentar ser preciso demais. Mas geolocalização por IP não é GPS. Na NANOG 96, o Sid Mathur apresentou uma palestra chamada High-quality IP Geofeeds using AI Coding Assistants and MCP. Uma das mensagens mais úteis da apresentação é justamente essa: geolocalização IP é estatística e inexata. O ideal é pensar em regiões geográficas, não em um ponto exato no mapa [6]. Ele dá uma provocação boa: mais precisão nem sempre significa mais qualidade. Para um ISP fixo, que sabe que determinado prefixo atende uma cidade específica, faz sentido informar a cidade: Mas se o mesmo prefixo atende várias cidades próximas, talvez seja melhor parar no estado: Isso evita resolver o problema de um cliente e criar problema para outro. Na mesma apresentação, ele também comenta casos bem reais: usuários bloqueados por conteúdo regional, streaming achando que a pessoa está em outro país, site mostrando clima errado e ISPs recebendo reclamações por algo que, muitas vezes, está fora da camada de conectividade [6]. Quem vive operação sabe que isso acontece. O geofeed resolve tudo? Não. E é importante ser honesto aqui. Publicar geofeed não obriga Google, Netflix, bancos, MaxMind, IPinfo, Cloudflare ou qualquer outro consumidor a aceitar imediatamente aquela informação. A RFC 8805 trata o geofeed como uma fonte publicada pelo operador. Os consumidores podem coletar, validar, cruzar com outras bases e decidir se vão usar ou não [1]. Mesmo assim, publicar corretamente melhora muito sua posição. Antes, você dependia de abrir chamado manual em várias bases diferentes, cada uma com um processo. Com geofeed, você cria uma fonte pública, padronizada e descobrível automaticamente. Não é garantia de correção instantânea, mas é uma prática operacional muito melhor. Como os outros descobrem seu geofeed? Publicar o arquivo em uma URL é só parte da história. Você precisa indicar, nos registros do bloco IP, onde está esse arquivo. É aí que entra a RFC 9632 [2]. Ela define como associar um arquivo geofeed aos objetos de registro de recursos IP, como inetnum e inet6num. Existem duas formas principais. A forma mais nova é usar o atributo próprio: A forma compatível com ambientes que ainda não suportam o atributo específico é usar remarks: O importante é que o consumidor consiga olhar para o registro do bloco e descobrir que existe um arquivo geofeed associado a ele. E o RDAP? O RDAP é o caminho mais moderno para consulta de dados de registro. Enquanto o WHOIS tradicional retorna texto, o RDAP retorna JSON. Isso facilita muito para automação. A RFC 9877 define como um servidor RDAP pode informar links de geofeed dentro da resposta de um objeto IP [3]. Um exemplo seria algo assim: Ou seja: o consumidor consulta o RDAP de um IP, encontra o link geofeed, baixa o CSV e processa a informação. O mais específico vence Aqui a
Made4Flow 2.11.1: exportação de NetFlow para mitigação DDoS, novos alertas e muito mais
Veja o que há de novo no Made4Flow 2.11.1: exporte NetFlow V5, V9 e sFlow para plataformas de mitigação DDoS, configure alertas por roteador e integre com sistemas externos via API REST. Quem opera uma rede de médio ou grande porte sabe que visibilidade de tráfego não é diferencial — é sobrevivência. Identificar um ataque DDoS em andamento, saber de qual país está vindo o tráfego anômalo, ou integrar o analisador de NetFlow com a plataforma de mitigação da operadora sem precisar reconfigurar roteadores: essas são dores reais de times de NOC e segurança no dia a dia. A versão 2.11.1 do Made4Flow, disponível a partir de 27 de fevereiro de 2026, endereça exatamente essas demandas. Neste artigo, detalhamos cada novidade e o que ela resolve na prática. O que é o Made4Flow e para quem é esta atualização? O Made4Flow é um analisador de NetFlow e sFlow desenvolvido pela Made4it para provedores de internet, operadoras e equipes de NOC que precisam de visibilidade detalhada sobre o tráfego de rede. Ele coleta flows exportados pelos roteadores (NetFlow V5, V9, sFlow, IPFIX), aplica inteligência sobre esses dados e entrega gráficos, alertas e análises em tempo real. Esta atualização é relevante especialmente para quem: Como exportar NetFlow para uma plataforma de mitigação DDoS — sem mexer nos roteadores Esta é a novidade mais aguardada da versão 2.11.1 por equipes que operam plataformas de mitigação DDoS. O cenário anterior era assim: para enviar flows para uma solução de mitigação de terceiros, era necessário configurar o roteador para exportar simultaneamente para dois destinos — o coletor do Made4Flow e o coletor da plataforma de mitigação. Em muitos ambientes, isso não é simples, é arriscado ou simplesmente inviável. Com o novo replicador de flows do Made4Flow, o roteador continua exportando normalmente para o Made4Flow. A partir daí, a própria plataforma replica e encaminha os flows para qualquer destino externo, nos formatos: A configuração é feita diretamente na interface do Made4Flow — sem downtime, sem janela de manutenção nos roteadores, sem risco operacional. Para provedores que usam soluções como Wanguard, NSFOCUS, Arbor ou qualquer outra plataforma que consuma NetFlow ou sFlow, esta funcionalidade elimina uma dependência complexa e acelera a integração. Integre sua plataforma de mitigação DDoS ao Made4Flow e replique NetFlow V5, V9, IPFIX ou sFlow com apenas uma configuração. Análise de ameaças: nova visualização para identificar ataques internos A página de Análise de Ameaças do Made4Flow recebeu uma reformulação completa na versão 2.11.1. O novo layout consolida em uma única tela as principais métricas de segurança: total de ameaças detectadas, IPs suspeitos, volume de tráfego malicioso, distribuição temporal dos incidentes e os principais alvos. A visão geográfica de ameaças também foi aprimorada, facilitando a correlação entre origem do ataque e impacto na rede. Para times de segurança que precisam responder rapidamente a incidentes, isso representa menos cliques e mais contexto disponível no momento crítico. Descubra quem está causando ataques dentro da sua rede interna em UM CLIQUE. Alertas de sampling rate e por roteador: pare de analisar dados distorcidos Um dos problemas mais silenciosos no monitoramento com NetFlow é a incompatibilidade de sampling rate. Quando o valor configurado na ferramenta de análise é diferente do que o roteador está efetivamente aplicando, todos os gráficos de tráfego ficam distorcidos — e a equipe pode tomar decisões baseadas em dados errados sem perceber. A versão 2.11.1 adiciona dois tipos de alertas específicos para esse cenário: Alerta de incompatibilidade de sampling rate Notifica automaticamente quando o valor de amostragem configurado no Made4Flow diverge do que o roteador está reportando. Isso é especialmente útil em ambientes com múltiplos roteadores de fabricantes diferentes (Cisco, Huawei, MikroTik, Juniper), onde o padrão de sampling pode variar. Alertas explícitos por roteador Cada roteador cadastrado no Made4Flow agora pode ter seus próprios alertas ativos, visíveis diretamente na listagem de equipamentos e na página de edição. Isso facilita a gestão em ambientes com dezenas ou centenas de roteadores monitorados. Seja alertado antes que o problema afete seus dados — configure em minutos. Tráfego por país e App por prefixo: visibilidade geográfica em tempo real Para provedores de internet e operadoras, saber de onde vem o tráfego é tão importante quanto saber quanto tráfego existe. Um pico vindo de determinado país pode indicar um ataque volumétrico em andamento; um prefixo específico consumindo banda fora do padrão pode sinalizar um cliente comprometido. A versão 2.11.1 adiciona uma nova tela de visualização com gráficos de tráfego segmentados por: Essa visibilidade estava disponível nos dados brutos, mas agora ganha formato visual nativo, sem necessidade de exportar dados, cruzar planilhas ou usar ferramentas externas. Veja em segundos qual país ou prefixo está gerando tráfego fora do padrão — e aja antes que o ataque escale. Agregação por TCP Flags e países: detecte padrões de ataque DDoS com precisão Ataques DDoS modernos muitas vezes se disfarçam em volume de tráfego aparentemente normal. A análise de TCP Flags — como floods de SYN, ACK ou RST — é uma das formas mais eficazes de identificar tráfego malicioso antes que ele impacte os serviços. A versão 2.11.1 adiciona novas abas de agregação nos dados brutos do Made4Flow: Para equipes de segurança que investigam incidentes, a combinação de análise por flags e por origem geográfica é especialmente poderosa para correlacionar técnica de ataque com origem. Identifique ataques por padrão de TCP Flags e origem geográfica em segundos, sem ferramentas externas. API REST do Made4Flow: integre com qualquer sistema A versão 2.11.1 marca a chegada da API REST oficial do Made4Flow, abrindo a plataforma para integrações programáticas com outros sistemas. A API oferece: Na prática, isso possibilita integrações com Zabbix, Grafana, sistemas de ticketing, SIEM, painéis externos e qualquer sistema que consuma dados via HTTP. Conecte o Made4Flow ao seu ecossistema e automatize dados de rede com sua própria stack. Outras melhorias da versão 2.11.1 Correções da versão 2.11.1 Perguntas frequentes sobre o Made4Flow 2.11.1 O Made4Flow consegue exportar NetFlow para a minha plataforma de mitigação DDoS?Sim. A partir da versão 2.11.1, o
BOTNET KIMWOLF: Ataques DDoS Internos e como Mitigar agora (2026)
Mais uma vez, as redes dos ISPs estão sendo atacadas… mas agora o inimigo vem de dentro. Você já viu o call-center explodir com reclamações de lentidão sem explicação? Mal nos recuperamos do ataque que explorou as vulnerabilidades no SDK Realtek onde roteadores e ONUs eram comprometidos e usados para DDoS contra terceiros, e já estamos lidando com uma ameaça muito mais perigosa e disseminada: a botnet AISURU/Kimwolf. Essa botnet explora principalmente aparelhos Android baratos de IPTV, SmartTV e set-top-box instalados na casa dos usuários. Esses dispositivos viram zumbis que vendem proxy residencial e, em menor escala, participam de ataques DDoS a terceiros. O resultado? Problemas generalizados em várias frentes: RESULTADO: clientes frustrados, custo alto de suporte e risco de reputação pro ISP inteiro. Um ciclo vicioso que ninguém quer e que está crescendo rápido. UM VERDADEIRO CAOS! Abaixo deixo um compilado de perguntas e respostas do que já sabemos sobre o assunto. E no final algumas dicas de como se proteger ou mitigar. 1) De onde vem esse ataque, e por quê? Segundo os sites de segurança Xlab e Synthient, os atores envolvidos na botnet a utilizam para ganhar dinheiro com alguns tipos de serviço: Como eles têm controle completo de todos os dispositivos, utilizam os servidores de comando-controle para criar túneis para navegação, instalar apps e iniciar ataques DDoS contra terceiros. Já houve reportes também de coisas além da segurança, como passar imagens e vídeos de assuntos controversos (políticos, geo-políticos, etc.). 2) Já tem muita gente infectada? Dados da Synthient e da XLab indicam que, embora seja apenas uma fração das comunicações, foram mais de 12 milhões de IPs únicos (estimam cerca de 2 milhões de dispositivos). E a maior parte deles vem do Brasil (~15%), seguidos por Vietnã, Índia, EUA e Argentina. A empresa chinesa de segurança XLab identificou que a botnet Kimwolf havia comprometido entre 1,8 e 2 milhões de dispositivos, com forte concentração no Brasil, Índia, Estados Unidos da América e Argentina. Imagem: blog.xLab.qianxin.com 3) Como os equipamentos são infectados? Você já deve ter se perguntado como esses equipamentos podem ser tão baratos, né? Pois é. Algumas imagens de dispositivos que já vem infectados. Fonte: Synthient. Também já se constatou que eles não passam por um processo rigoroso de correção de vulnerabilidades, patches de segurança e atualizações/melhorias. É o prato cheio nas mãos de criminosos. A principal forma de infecção da Kimwolf é explorando uma falha nas SDKs dos aplicativos de proxy-residencial (como Byteconnect, IPIDEA e PYPROXY). O atacante aluga um proxy legítimo desses serviços, usa o túnel para “voltar” pela conexão do próprio aparelho e acessar a rede local interna onde encontra o ADB (Android Debug Bridge) exposto sem autenticação (porta 5555 e similares). Em segundos, ele manda comandos remotos, baixa o malware e instala tudo. Topologia de infecção via proxy residenciais. Fonte: Synthient. Existem algumas formas que o equipamento pode ser infectado (mas todas acabam convergindo nesse mecanismo principal): 1º) Vindo de fábrica Muitos aparelhos saem de fábrica já com aplicativos de proxy-residencial pré-instalados (sem o usuário saber), para monetizar a banda depois. Quando o dispositivo entra no pool de proxy (ex: IPIDEA, Byteconnect, PYPROXY), o atacante explora exatamente essa porta aberta.Este é o jeito principal de infecção é assim que a botnet Kimwolf mais se espalhou, com milhões de dispositivos comprometidos em meses. 2º) Através de instalação de apps não confiáveis Os usuários instalam aplicativos de terceiros (não verificados), e estes silenciosamente adicionam o SDK de proxy, ativando o caminho para a exploração via ADB. 3º) Portas vulneráveis ADB/Telnet Alguns desses IPTV já vêm com ADB exposto por padrão. Mesmo sem o SDK inicial, um pequeno scan/brute force em portas como 5555, 3222 ou 5858 permite acesso shell e instalação do malware. 4) O que são estes apps de proxy-residenciais? Basicamente são empresas que vendem navegação à internet através de seus “proxies” ao redor do mundo. Quando você compra um serviço com eles, você estabelece uma “VPN” até os seus servidores, e então a sua navegação sai pelo pacote escolhido (por exemplo, navegação por IPs residenciais do Brasil, do Vietnã, etc.). Eles ganham dinheiro cobrando alguns dólares por GB trafegado. Mas e o que fazer? Se quer uma resposta fácil, você não terá. Vamos ter que enfrentar esse problema em diversas frentes. Afinal, diferente de outras botnets onde o dispositivo estava no controle do ISP (o roteador, a ONU, etc), neste caso os equipamentos infectados em 99% dos casos são do próprio cliente. Na perspectiva do ISP, podemos enfrentar o problema em 4 ações: Ação 1: identificar clientes/equipamentos ofensores No github da Synthient (o link vai estar mais abaixo), há uma fração da lista de IPs/portas utilizadas na botnet. Mas eles já são a primeira etapa para identificação. Utilize esta lista e compare com as comunicações no seu software de netflow (de preferência o made4flow), vindos do seu BNG. Com isto, você já vai conhecer quem internamente está infectado. Ação 2: mitigar / contornar impactos Aqui entra a criatividade técnica. O básico é o bloqueio em firewall ou blackhole das comunicações (mas elas não duram por muito tempo e servem no máximo como band-aid – pois a botnet é tão capaz de trocar de IPs/redes quanto as TVs piratas de contornar bloqueios da Anatel). Feito isto, comece a pensar em soluções mais elaboradas. Se precisar de ajuda, nos chame! Ação 3: corrigir equipamentos infectados As recomendações dos sites de segurança são: destrua estes aparelhos. Ponto final. Mas sabemos da realidade. Não tem como destruir o aparelho de um cliente, e sim trabalhar na conscientização. Desenvolva um roteiro, tenha jogo de cintura, e vá visitar seu cliente. Mostre como a rede dele está sendo utilizada para cometer crimes. Mostre os sites, os artigos. Tente atualizar, resetar, remover aplicativos suspeitos. Use o site https://synthient.com/check para mostrar ao cliente que ele foi pego nas varreduras da botnet. Ação 4: implementar monitoramento constante Se você está lidando com isso na sua rede e quer trocar ideia sobre filtros, PBR ou monitoramento automático, me manda mensagem ou comentário aqui. Estamos ajudando vários ISPs a mapear e isolar esses dispositivos sem dor de cabeça extra. QUERO AJUDA #CyberSecurity #DDoS #Botnet #ISP #Kimwolf #ProvedorInternet #SegurancaDigital Referências do artigo https://synthient.com/blog/a-broken-system-fueling-botnetshttps://blog.xlab.qianxin.com/kimwolf-botnet-en/#backgroundhttps://synthient.com/checkhttps://github.com/synthient/public-research/blob/main/2026/01/kimwolf/README.mdhttps://krebsonsecurity.com/2026/01/the-kimwolf-botnet-is-stalking-your-local-network/https://krebsonsecurity.com/2026/01/who-benefited-from-the-aisuru-and-kimwolf-botnets/https://krebsonsecurity.com/2025/11/is-your-android-tv-streaming-box-part-of-a-botnet/
Testes de Desempenho CGN/BNG em Plataforma Huawei NE8000
Aprenda com Luiz Puppin, especialista em Huawei, como fazer uma análise técnica dos testes de desempenho (Forwarding Performance) realizados em um ambiente de laboratório com a plataforma Huawei NE8000, validando a capacidade do equipamento em operar como BNG+CGN integrado em alta carga. Os testes buscaram verificar: Objetivo dos Testes de Desempenho O objetivo foi comprovar que a solução Huawei consegue sustentar: Essas características são fundamentais para operações de ISPs e operadoras com alta concentração de assinantes atrás de CGN. Arquitetura Utilizada A topologia utilizada conecta: Metodologia 5. Evidências e Resultados A seguir estão as comprovações extraídas diretamente do arquivo de teste. 5.1. Assinantes autenticados com sucesso O relatório confirma a autenticação simultânea de milhares de assinantes PPPoE: O total validado foi de: 5.2. Criação de 32 milhões de sessões NAT O DUT atingiu o limite de escalabilidade previsto pelo fabricante: Ou seja, o equipamento suportou 32 milhões de fluxos simultâneos, sem degradação perceptível. 5.3. Tráfego Sustentado a 50 Gbps – Sem Perda de Pacotes Ou seja: 5.4. Tráfego Bidirecional 50 Gbps (25G + 25G) O laboratório validou a operação simultânea upstream e downstream: Novamente, com zero perda de pacotes: 5.5. Estabilidade da CPU A CPU permanece em níveis estáveis, sem atingir limites críticos. 5.6. Conclusão dos Testes de Desempenho Com base nas evidências, é possível concluir que: Portanto, a plataforma demonstra capacidade real para operar CGN/BNG em ambientes de larga escala, com alto volume de tráfego e grande densidade de assinantes. Este artigo foi desenvolvido em colaboração com a equipe de Gerentes de Produtos IP para ISP da Huawei Brasil, com agradecimento especial ao Thiago Sério e ao Natan Fernandes. Precisa de ajuda na configuração dos seus equipamentos Huawei? Nós podemos te ajudar! Quero conhecer mais
MC-LAG em roteadores Huawei
Como configurar MC-LAG na Huawei: E-Trunk, Eth-Trunk, LACP e BFD passo a passo. Aprenda MC-LAG em Huawei, hoje mostramos o porquê do E-Trunk (multi-chassis), quando usar Eth-Trunk (agregação), como ajustar LACP para portas ativas/backup e como o BFD encurta o MTTR. Incluímos recomendações de hash em cenários MPLS e um roteiro de testes para validar o comportamento em falhas. O link-aggregation (LAG), chamado de Trunk na Huawei (Eth-Trunk quando é Ethernet), é uma tecnologia que combina múltiplas interfaces físicas em uma única interface lógica. Com link-aggregation ganhamos: O LAG tradicional é sempre entre dois dispositivos, ponto a ponto: Tipos de LAG para Huawei De forma bem simples, na Huawei temos três jeitos principais de usar Eth-Trunk: No contexto de MC-LAG, o que importa pra nós são basicamente: Vamos simplificar: Manual Static LACP Como o Trunk balanceia o tráfego O Eth-Trunk não “soma portas” como uma porta gigante. O equipamento decide por qual membro mandar cada fluxo usando algoritmos de balanceamento. Isso define dois comportamentos principais: Load-balance baseado em hash É o padrão na maioria dos roteadores/switches. Funciona assim: O hash pode usar vários critérios, por exemplo: Com hash, o modo padrão é per-flow: Hash tem uma consequência importante: Nem sempre distribui banda de forma uniforme.Dependendo da distribuição dos fluxos (hash), um membro pode ficar no gargalo enquanto outro quase sem tráfego. Isso é normal. Load-balance dinâmico Alguns equipamentos suportam o modo dynamic, que monitora a carga instantânea de cada membro e realoca fluxos entre links que estejam subutilizados ou sobrecarregados. Um equipamento que usa esse tipo de balanceamento são os switches da Datacom. E o que os chips conseguem usar para o hash? Esse ponto quase ninguém fala, mas é crucial. Dependendo do ASIC, o roteador pode olhar: No caso de MPLS: Isso importa porque: Exemplos práticos: Em resumo: Quanto maior a profundidade MPLS que o ASIC enxerga, melhor será a distribuição dos fluxos MPLS no LAG. O que o LACP faz O LACP (Link Aggregation Control Protocol, IEEE 802.3ad) é o cara que: Na Huawei, quando o Eth-Trunk está em static LACP, as interfaces membros: O lado com maior prioridade de sistema (menor valor numérico) vira o Actor. A partir daí: O que precisa estar “OK” para o LAG subir direito Pra um Eth-Trunk com LACP funcionar como esperado, alguns pontos precisam estar alinhados entre os dois lados: O que o LACP faz é usar system priority + system ID + interface priority + interface number para: Entrando no MC-LAG Até aqui falamos de LAG “normal”, ou seja, entre dois dispositivos apenas. O MC-LAG (Multi-Chassis LAG) entra quando você quer ter: A ideia é simples: Objetivo principal do MC-LAG: É basicamente levar a ideia de redundância do nível de porta/link para o nível de dispositivo. Ativo/ativo vs ativo/backup Em muitos vendors você encontra MC-LAG em dois sabores: Na Huawei, para esse cenário específico com E-Trunk/mLACP, o comportamento é ativo/backup: MC-LAG na Huawei: E-Trunk vs mLACP Em Huawei, existem duas formas principais de implementar MC-LAG: A diferença está no mecanismo de controle entre os PEs: Neste artigo, vamos focar no E-Trunk, que é a forma “clássica” de MC-LAG em muitos cenários de PE–CE. Como o E-Trunk funciona Não confundir E-Trunk (a tecnologia de sync entre chassis) com o Eth-Trunk (o link-aggregation em si). Pense no seguinte cenário: Os PEs então: Com isso: Quando acontece uma falha: Opcionalmente, você pode: Conectividade CE ↔ PEs com E-Trunk Alguns pontos importantes de design: Casos de uso Na topologia abaixo, iremos abordar dois casos de uso para o MC-LAG (existem muitos outros). 1) MC-LAG protegendo VPLS (camada 2) No topo do desenho, o CE1 está multihomed em PE1 e PE2 usando MC-LAG, todos na mesma instância VPLS-1.Do lado da rede, PE1/PE2 fecham a VPLS com o PE3, que entrega o mesmo serviço para o CE2. É uma proteção L2 fim-a-fim da VPLS, com redundância de equipamento e de POP. 2) MC-LAG protegendo /30 L3 (camada 3) Na parte de baixo do desenho, o CE3 recebe um /30 L3 via MC-LAG, dual-homed em PE2 e PE3. Configurando o ambiente Agora que você já conhece todos os conceitos por trás do MC-LAG, vamos para o laboratório. Vamos utilizar o ambiente virtual PNETLAB, com a imagem Huawei NE40 V22. As portas físicas e ligações entre dispositivos estão descritas na topologia abaixo. A configuração dos CEs é simples: um mikrotik (ROS 7.6) usando interfaces bonding, com LACP fast (em 1s). O CE3 é simplesmente uma interface física com VLAN. CE1 CE2 CE3 A configuração dos PEs compreende as interfaces ponto a ponto, ativas com OSPF, MPLS. Nas interfaces de acesso, as configurações de LAG e de sincronização e-trunk. E na camada de serviços, colocamos o VPLS (VSI) e também o gateway L3 (com o macete do mac-address e mesmo IP). PE1 – Camada Core Serviço MLAG e E-trunk Aqui neste ponto está o grande diferencial do MLAG. Vamos primeiramente criar um Eth-Trunk comum, e depois associamos ele a uma configuração e-trunk, que faz a mágica do MLAG acontecer. Com o LAG criado, agora precisamos criar a configuração do e-trunk. Para configurá-lo, precisamos: No nosso laboratório, iremos fechar entre a loopback do PE1 com o PE2 – estes fazem parte do MLAG na perspectiva do CE1. A prioridade de master será do PE2, com prioridade 5. Os timers configurados são 9 para hello e 30 para hold-timer. Por fim, é hora de associar a interface LAG com o e-trunk, criando assim um MLAG na perspectiva do CE1. Serviços VPLS PE2 – Camada Core As configurações CORE e VPLS do PE2 são similares às do PE1 Serviço MLAG e E-trunk Serviços Gateway redundante Para o serviço de gateway redundante para o CE3, iremos: PE3 – Camada Core As configurações CORE do PE3 são similares às do PE1. Serviços VPLS Diferente dos PE1 e PE2 que tem um MLAG com o CE, neste caso a comunicação PE3xCE2 ocorre diretamente na interface física com a vlan 10. As configurações de VPLS permanecem iguais, a diferença está nos peers, que fechamos o VPLS com o PE1 e PE2 ao mesmo tempo. Serviços Gateway redundante Validando as configurações e redundância MC-LAG entre dispositivos Na visão do CE1, ele tem duas portas ativas no LAG bond2, sendo a porta ether2 – que fala com PE2 – a principal. A outra fica pronta
Como a Pontonet saiu do caos de servidores e reduziu custos com Proxmox
Descubra como a Made4it transformou um cenário de falha total em uma infraestrutura moderna, resiliente e mais barata. 16/09/2025 • Por Made4it A cena é familiar para qualquer gestor de TI: fim do mês, boletos a emitir, sistema rodando… até que tudo cai. Foi exatamente isso que aconteceu com a Pontonet, quando uma falha simultânea em um servidor físico colocou em risco todo o negócio. Pare e pense: se todos os seus discos quebrassem hoje, quanto custaria recuperar informações de um ano inteiro? Foi nessa hora que a Made4it entrou em ação para transformar o desastre em oportunidade. O problema: falha simultânea e ausência de backup Esse é o tipo de risco que muitas empresas ignoram até ser tarde demais. Soluções na mesa: manter VMware ou migrar? Diante do desastre, avaliamos duas alternativas: Continuar no VMware Migrar para Proxmox Por que Proxmox? O Proxmox é mais do que uma alternativa gratuita. Ele oferece: Quando comparado ao VMware, o Proxmox provou ser mais ágil, econômico e seguro. O papel da Made4it nessa virada A Pontonet já era cliente de redes e servidores da Made4it. Ao ocorrer a falha, tomamos as seguintes ações: Esse processo evidenciou nosso domínio técnico e capacidade de transformar crises em oportunidades de inovação. Resultados: segurança e economia Após a migração: Proxmox e Made4it: a combinação vencedora Essa história mostra que tecnologia e estratégia caminham juntas. De nada adianta investir em licenças caras se o projeto não contempla redundância e backup; da mesma forma, uma solução open source requer expertise para ser aplicada com segurança. A Made4it entrega ambos: conhecimento aprofundado e soluções acessíveis. Você conhece alguém que ainda depende de um servidor velho e sem backup? Envie este artigo! E se você não quer descobrir no susto que sua empresa está vulnerável, converse com nossos especialistas.
Por que as empresas líderes têm NOC: e você também deveria ter
15/08/2025 • Por Emerson Martins A internet é o coração das empresas hoje. Basta uma queda de rede para vendas pararem, equipes ficarem improdutivas e a reputação ir por água abaixo. Quantas vezes isso já aconteceu com você? Se a resposta for “mais de uma”, é sinal de que você está apostando na sorte e sorte não é estratégia. Vamos te mostrar por que ter um NOC (Network Operations Center) e escolher um provedor de internet que também opera um NOC são decisões que podem salvar sua operação. O que é um NOC e por que ele importa? O NOC é o centro nervoso da sua rede. É onde especialistas monitoram tráfego, analisam indicadores de desempenho e tomam medidas preventivas para evitar falhas. Funciona 24 horas por dia, sete dias por semana, para garantir que nada escape aos olhos de quem cuida da sua infraestrutura. Sem um NOC, sua empresa fica à mercê de imprevistos. Com ele, você antecipa problemas e transforma incidentes em oportunidades de melhoria. NOC corporativo: seu negócio protegido o tempo todo Empresas de todos os tamanhos dependem de sistemas online, nuvem e serviços que não podem parar. Um NOC interno oferece: Ter um NOC interno não é luxo; é a base de uma operação estável e escalável. NOC do ISP: o diferencial que todo provedor deveria oferecer Não adianta sua infraestrutura estar impecável se o link do seu provedor cai. Um ISP com NOC próprio é garantia de estabilidade e segurança. O que você ganha: Um provedor com NOC é um parceiro que cuida da sua operação junto com você. NOC interno + NOC do provedor: a união que faz a força Quando sua empresa tem um NOC e o provedor também, você soma controle interno com estabilidade externa. Isso reduz drasticamente o risco de downtime e oferece suporte de ambos os lados. É a combinação perfeita para quem não aceita ficar fora do ar. Ter um NOC por trás da sua operação é sinônimo de controle, agilidade e prevenção.E quando o seu ISP também tem um NOC eficiente, você ganha ainda mais estabilidade e suporte. Juntos, esses dois pontos garantem uma rede mais segura, disponível e pronta para crescer com o seu negócio. Se a internet e a tecnologia são parte fundamental do seu dia a dia, ficar à mercê da sorte não é uma opção. Se a sua empresa precisa contratar ou expandir seu monitoramento, você precisa conhecer o Made4NOC criado para ser uma alternativa eficaz, confiável e adaptada às suas necessidades, garantindo que sua operação seja monitorada no que mais importa para você. Conheça o Made4NOC Conheça todas as vantagens que você ganha ao ter o Made4NOC na sua operação Vantagens do Made4NOC Se quiser, fale com nosso time agora mesmo Comercial (WhatsApp)
IPv6 para ISPs: Segurança, Performance e Escalabilidade
IPv6: A Chave para o Futuro da Conectividade em Provedores de Internet A internet global está passando por uma transição inevitável. Com a explosão de dispositivos conectados — de smartphones e IoT a aplicações 5G — o esgotamento dos endereços IPv4 deixou de ser uma previsão distante e passou a ser um gargalo real. Desde 2011, a IANA já alertava sobre o fim dos blocos IPv4, e no Brasil, desde 2020, não há mais endereços disponíveis para alocação. Diante disso, muitos ISPs recorreram ao CGNAT como solução paliativa. Funciona no curto prazo, mas cobra um preço alto: perda de conectividade fim a fim, impacto em aplicações sensíveis e sérios desafios de rastreabilidade e segurança. Nesse cenário, o IPv6 deixa de ser apenas uma alternativa tecnológica. Ele se torna o único caminho viável para garantir escalabilidade, estabilidade e competitividade na nova geração de redes. Por que o IPv6 é mais que necessário? É estratégico para o seu provedor! Adotar o IPv6 vai muito além de uma atualização técnica: é uma decisão estratégica que impacta diretamente o presente e o futuro do seu negócio. Ao eliminar as limitações do IPv4, o IPv6 libera um novo patamar de conectividade, com endereçamento amplo, mais segurança, menor latência e desempenho superior. Tudo isso com mais controle e escalabilidade da rede. Provedores que já migraram estão colhendo resultados: operações mais eficientes, menor dependência de soluções paliativas como o CGNAT e muito mais preparo para tecnologias como 5G, IoT, automação e aplicações em tempo real. O cliente final também sente a diferença com uma navegação mais rápida, conexões mais estáveis e uma experiência otimizada para jogos, chamadas, streamings e acesso remoto. IPv6 não é só o futuro. É vantagem competitiva agora. Como implementar o IPv6 com segurança e eficiência A migração para o IPv6 não precisa ser complexa. Com o planejamento certo, ela acontece de forma gradual, segura e sem impacto para os seus clientes. O segredo está em entender os ganhos reais, preparar sua equipe e seguir uma estrutura bem definida. Veja como o IPv6 entrega valor imediato ao seu provedor — e ao usuário final. Quais são os ganhos reais para o seu provedor? E para seus clientes? Experiência elevada. Como implementar na prática: Passo a passo simplificado Erros comuns que podem comprometer sua transição A transição já começou e quem lidera agora, sai na frente A migração para o IPv6 não é mais uma possibilidade futura. É uma realidade em curso e quem adota agora colhe os benefícios antes dos concorrentes. Mais performance. Mais segurança. Mais escalabilidade. Menos custos operacionais. Provedores que lideram essa mudança entregam mais valor aos seus clientes, evitam gargalos técnicos e se posicionam de forma sólida diante das exigências do mercado, cada vez mais conectado, automatizado e exigente. Com o suporte certo, planejamento técnico e execução estruturada, sua operação pode fazer essa transição de forma segura, gradual e eficiente sem comprometer a qualidade do serviço. A Made4it pode caminhar com você nessa jornada.Fale com nosso time e descubra como podemos acelerar sua evolução para uma infraestrutura pronta para o futuro.
