Um hotel perde o acesso à internet durante o check-in. Os hóspedes não conseguem se autenticar no WiFi, as maquininhas de cartão começam a dar timeout, a equipe perde o acesso aos sistemas em nuvem e a recepção começa a distribuir uma senha compartilhada que ninguém pode revogar. O circuito de backup existe, mas a política de firewall nunca foi testada. O segundo servidor RADIUS está configurado, mas ninguém sabe se os pontos de acesso conseguirão alcançá-lo. O UPS está relatando um estado saudável porque ninguém testou a bateria sob carga.
Isso não é um problema de hardware. É uma falha no planejamento de redundância.
Resiliência de rede significa manter a autenticação, a conectividade e os serviços essenciais disponíveis quando um componente, link, site, alimentação de energia ou dependência de identidade falha. Um switch sobressalente em um armário não cria resiliência. Um caminho testado que mantém uma VLAN de pagamento, aplicativo clínico, login de equipe ou sessão de WiFi de convidados funcionando cria.
O que o Planejamento de Redundância Realmente Significa para Redes Modernas
O planejamento de redundância de rede é uma disciplina de continuidade de negócios, não um exercício de compra de equipamentos. A questão não é se você possui dois switches. É se os usuários ainda conseguem se conectar, autenticar, resolver serviços e alcançar os aplicativos que mantêm a operação funcionando após uma falha definida.
Isso exige uma visão clara dos domínios de falha. Um domínio de falha é um componente ou dependência que pode falhar de forma independente e levar um serviço consigo. Os domínios típicos incluem:
- Infraestrutura de acesso, incluindo switches, pontos de acesso, orçamentos PoE, uplinks e controladoras sem fio.
- Serviços de identidade, incluindo RADIUS, integrações de diretório, certificados, Captive Portals e provedores de identidade.
- Serviços principais, incluindo DHCP, DNS, funções de gateway e política de rede.
- Caminhos externos, incluindo circuitos WAN, equipamentos de ISP, plataformas de nuvem e serviços de autenticação de terceiros.
- Instalações, incluindo distribuição de energia, baterias de UPS, cobertura de geradores e salas de distribuidores intermediários (IDF).
Um design pode ter roteadores principais resilientes e ainda assim falhar na borda. Se a resolução de DNS parar, os usuários podem estar conectados ao WiFi, mas incapazes de alcançar os serviços que precisam. Se o RADIUS parar de responder, uma rede sem fio saudável pode rejeitar cada login de funcionário ou visitante. Se o Captive Portal depender de um caminho de nuvem inacessível, o local pode ter cobertura de rádio sem um acesso de visitante utilizável.
Separe a continuidade do serviço da redundância de componentes
Comece com os serviços, não com os dispositivos. Registre os serviços que a empresa precisa preservar e, em seguida, rastreie cada dependência de cada um deles. A autenticação de WiFi de visitantes, por exemplo, pode depender de pontos de acesso, switching, PoE, plano de controle sem fio, DHCP, DNS, acesso WAN, RADIUS, provedor de identidade e o próprio portal.
Uma referência de planejamento de WiFi para equipes de rede útil deve levar à mesma conclusão: o acesso sem fio é um sistema operacional, não uma camada de rádio acoplada à LAN.
Os empregadores do Reino Unido utilizam um significado estatutário separado para o planejamento de redundância coletiva. Quando um empregador propõe demitir 20 ou mais funcionários em um único estabelecimento dentro de um período contínuo de 90 dias, a consulta coletiva se aplica, com a consulta iniciando pelo menos 30 dias antes da primeira demissão para 20 a 99 redundâncias ou 45 dias antes da primeira demissão para 100 ou mais. O guia de consulta do governo do Reino Unido explica que a consulta deve abordar os motivos das redundâncias propostas, formas de evitá-las e maneiras de reduzir o número de demissões. Esse é um modelo de planejamento de RH. A disciplina de rede descrita aqui se refere a falhas de serviço, mapeamento de dependências e arquitetura de recuperação.
Regra prática: Não conte dispositivos de backup. Conte caminhos independentes do usuário até o serviço.
O restante deste guia utiliza essa perspectiva prática. Identifique os riscos de falha, defina metas de recuperação que reflitam o impacto nos negócios, selecione uma arquitetura que sua equipe possa operar, proteja cada camada, desde a energia até a identidade, e teste o resultado sob condições controladas. Se um componente nunca falhou em uma simulação, trate sua redundância como uma suposição, não como uma capacidade.
Mapeando Riscos de Falha Antes de Projetar a Correção
A maioria das equipes de rede não precisa de uma plataforma de governança para encontrar seus pontos únicos de falha mais perigosos. Elas precisam de um registro curto que nomeie o risco, classifique-o de forma consistente, atribua um proprietário e registre se alguém reduziu o problema.
Use três eixos:
- Probabilidade, ou seja, com que frequência a falha ocorre em ambientes semelhantes ou já ocorreu em seu próprio ambiente.
- Raio de impacto, ou seja, quantos usuários, sites, serviços ou atividades geradoras de receita ficam indisponíveis.
- Dificuldade de recuperação, ou seja, o quão difícil é a restauração com as habilidades, acessos, peças de reposição, suporte do fornecedor e documentação que você possui hoje.
Atribua uma nota para cada eixo em uma escala local, depois multiplique os três valores ou aplique uma fórmula ponderada. A matemática importa menos do que a consistência. Um único circuito de WAN deve se classificar acima de um display de marketing isolado, porque sua falha pode afetar todos os serviços dependentes de uma só vez.
Construa o registro em torno de dependências reais
Inclua ativos que as equipes costumam ignorar. Uma primeira etapa útil deve conter:
- Um único ISP de WAN ou circuito atendendo a todo o local.
- Um único serviço RADIUS ou uma única integração de provedor de identidade.
- Um único caminho de resolvedor de DNS.
- Uma única dependência de controladora sem fio ou gerenciamento em nuvem.
- Uma sala de distribuidor intermediário (IDF) sem cobertura de gerador.
- Baterias de UPS que relatam status, mas nunca foram testadas sob carga real.
- Um Captive Portal sem modo degradado documentado.
- Uma pilha de switches cujos uplinks compartilham uma única rota física.
- Um serviço DHCP sem procedimento de recuperação testado.
O registro também deve conter o proprietário do serviço, proprietário técnico, data da última falha, mitigação atual, data do teste e próxima ação. "Equipe de rede" não é um proprietário. Nomeie a pessoa ou equipe responsável por planejar a mudança e provar que ela funciona.
Exemplo de pontuação do registro de riscos de rede
O modelo a seguir é um template de trabalho, não uma afirmação sobre qualquer propriedade em particular. Use uma escala local consistente para cada eixo e calcule a pontuação final da mesma maneira para cada entrada.
| Cenário de Falha | Probabilidade (1-5) | Raio de Impacto (1-5) | Complexidade de Recuperação (1-5) | Pontuação de Risco |
|---|---|---|---|---|
| Circuito WAN único | Classificar localmente | Classificar localmente | Classificar localmente | Probabilidade × raio de impacto × complexidade de recuperação |
| Serviço RADIUS único | Classificar localmente | Classificar localmente | Classificar localmente | Probabilidade × raio de impacto × complexidade de recuperação |
| Caminho de resolvedor DNS único | Classificar localmente | Classificar localmente | Classificar localmente | Probabilidade × raio de impacto × complexidade de recuperação |
| Controladora wireless única | Classificar localmente | Classificar localmente | Classificar localmente | Probabilidade × raio de impacto × complexidade de recuperação |
| Sala IDF sem gerador | Classificar localmente | Classificar localmente | Classificar localmente | Probabilidade × raio de impacto × complexidade de recuperação |
| Baterias de UPS não monitoradas | Classificar localmente | Classificar localmente | Classificar localmente | Probabilidade × raio de impacto × complexidade de recuperação |
Não espere por um registro perfeito. Uma lista de uma página com proprietários críveis é mais útil do que um sistema de risco sofisticado que ninguém atualiza. O objetivo imediato é a priorização. Classifique as falhas que podem desativar serviços críticos e use esses resultados para definir metas de recuperação e escolher a arquitetura.
As informações oficiais de gestão do Reino Unido mostram por que o planejamento prévio estruturado é importante em um contexto de força de trabalho diferente, mas relacionado. Os empregadores enviaram 368 formulários HR1 cobrindo 29.496 demissões potenciais em janeiro de 2020, e 326 formulários cobrindo 27.804 demissões potenciais em fevereiro de 2020, de acordo com os dados de notificação de demissão do governo. A lição para os líderes de rede é simples: o planejamento formal existe porque grandes mudanças operacionais são difíceis de improvisar. O mesmo se aplica quando uma rede de vários locais perde uma dependência compartilhada.
Definindo Metas de RTO e RPO que Correspondam à Dor Real do Negócio
RTO e RPO são úteis apenas quando os proprietários de negócios conseguem compreendê-los.
Objetivo de tempo de recuperação, ou RTO, é o tempo máximo aceitável que um serviço pode permanecer indisponível. Objetivo de ponto de recuperação, ou RPO, é a perda máxima aceitável de dados, configuração ou estado da sessão desde o último ponto recuperável. Para uma rede, o RPO pode dizer respeito à configuração, política, estado do dispositivo, registros de eventos ou contexto de autenticação ativa, em vez de uma transação de banco de dados tradicional.
Traduza ambas as medidas em consequências operacionais. Pergunte o que para primeiro quando o serviço falha. A recepção acumula filas de hóspedes? Os caixas param de aceitar pagamentos? Os médicos perdem o acesso aos prontuários eletrônicos? Um administrador de propriedade perde o controle de acesso dos inquilinos? O proprietário do serviço deve declarar a consequência para o negócio, não apenas repetir uma meta de TI.
Use níveis de serviço em vez de uma promessa para toda a propriedade
Um mapa de serviços prático separa o acesso crítico dos serviços que podem esperar.
| Nível de Serviço | Exemplos de Serviços | RTO Alvo | RPO Alvo | Implicação na Arquitetura |
|---|---|---|---|---|
| Nível 1 | Autenticação de WiFi para convidados, VLAN de pagamento, acesso a aplicativos clínicos | Minutos, com base na tolerância de negócios | Perda mínima de política e estado de autenticação | Caminhos independentes, failover rápido, identidade resiliente, energia testada |
| Nível 2 | WiFi para funcionários, sistemas de back-office, sincronização de análises | Cerca de uma hora, onde a operação permitir | Configuração recente e estado do serviço | Standby morno, caminhos duplos onde justificado, recuperação documentada |
| Nível 3 | Entretenimento para convidados, telas de login de marketing, relatórios não críticos | Várias horas podem ser aceitáveis | Recuperação baseada em backup pode ser suficiente | Standby de menor custo ou restauração manual |
Estes são exemplos de planejamento, não níveis de serviço universais. O setor financeiro deve validar a meta usando um modelo simples de perda: contribuição estimada de receita por hora, interrupção operacional, exposição de reputação e impacto de conformidade, divididos pelo tempo de inatividade que a empresa pode aceitar. Evite falsas precisões. Um serviço de pagamento pode não ter uma "hora média" significativa, pois uma breve interrupção em uma janela de alto movimento pode prejudicar mais do que uma interrupção mais longa durante a noite.
O RTO também deve incluir o tempo de detecção e decisão. Um failover que é concluído rapidamente após um engenheiro notar a falha ainda pode perder a meta de negócios se o monitoramento demorar muito para emitir um alerta. Inclua o comportamento de propagação de DNS, reautenticação de sessão, reconexão de dispositivo, convergência de firewall e escalonamento humano na estimativa de recuperação.
O RPO merece a mesma disciplina. Se uma alteração de configuração feita pouco antes da falha desaparecer, a equipe conseguirá recriá-la? Se as sessões de convidados precisarem se reautenticar, isso é aceitável? Se um diretório de identidade estiver temporariamente indisponível, a camada de acesso pode usar uma política conhecida como boa sem enfraquecer a segurança?
Metas agressivas de RTO geralmente exigem capacidade ativo-ativo ou geograficamente independente. Um RTO mais flexível pode suportar um standby morno, restauração documentada ou recuperação baseada em backup. Não copie um nível de serviço corporativo de um contrato quando o local ainda depende de um único ISP, de uma única fonte de alimentação ou de um único caminho de identidade. A arquitetura precisa justificar a meta.
Escolhendo a Arquitetura de Failover Correta para a sua Propriedade
Quatro padrões cobrem a maioria das implantações de locais no mundo real. Nenhum é automaticamente correto. A escolha certa depende da tolerância ao tempo de inatividade, tamanho da propriedade, habilidade operacional, independência de falhas e orçamento.
O modelo ativo-ativo mantém dois ou mais componentes capazes atendendo ao tráfego simultaneamente. Controladoras duplas ou clusters de acesso podem compartilhar a demanda, e um lado pode continuar funcionando quando o outro falhar. Isso oferece excelente capacidade durante falhas, mas gera mais sincronização de estado, consistência de políticas e risco de split-brain. Use-o quando o tempo de inatividade for caro e a equipe puder monitorar ambos os lados de forma adequada.
Ativo-passivo mantém um componente de reserva pronto para assumir o controle. É mais fácil de entender do que o ativo-ativo, mas a promoção, transferência de estado e detecção podem criar uma lacuna de recuperação. Um hot standby só é valioso se tiver a configuração atual, dependências acessíveis e um processo de promoção testado.
N+1 fornece uma unidade de capacidade sobressalente para um cluster. É uma resposta sensata quando um site pode tolerar a substituição de um componente, mas não pode justificar um ambiente totalmente duplicado. O N+1 ainda deixa a infraestrutura exposta a falhas compartilhadas, como uma alimentação de energia comum, uplink comum ou configuração incorreta replicada em cada unidade.
A redundância geográfica posiciona uma capacidade completa de serviço em outro site ou região. Ela aborda a perda do site, não apenas a falha de equipamentos, e carrega o maior custo de capital e operacional. É apropriada para serviços compartilhados que oferecem suporte a várias propriedades ou para organizações que não podem aceitar um único edifício como um domínio de falha.
Comparação de arquitetura de failover
| Arquitetura | Custo | Complexidade | RTO Típico | Melhor Adequação |
|---|---|---|---|---|
| Ativo-ativo | Alto | Alto | Muito curto quando operado corretamente | Serviços críticos, propriedades maiores, equipes capazes de gerenciar sistemas sincronizados |
| Ativo-passivo | Médio a alto | Médio | Curto a moderado, dependendo da promoção | Sites que precisam de um standby pronto sem servir tráfego em ambos os lados |
| N+1 | Médio | Médio | Moderado, dependendo da substituição e do provisionamento | Clusters onde um componente pode cobrir um par com falha |
| Redundância geográfica | Mais alto | Mais alto | Curto a estendido, dependendo do roteamento e do estado | Operadores multi-site e serviços expostos a falhas completas do site |
Um grupo hoteleiro com duas propriedades pode usar serviços ativo-ativo entre os sites se o WAN, identidade, DNS, energia e propriedade operacional forem genuinamente independentes. Uma única loja de varejo geralmente obtém mais valor de um firewall resiliente, tráfego segmentado e backup LTE ou 5G do que de um design de segundo data center que ela não pode operar.
Use um atalho de decisão direta. Se os recursos da equipe forem limitados e a empresa puder tolerar uma recuperação moderada, escolha ativo-passivo ou N+1. Se as transações críticas precisarem de continuidade e a equipe puder gerenciar a sincronização, escolha ativo-ativo. Se o risco dominante for a perda de um site inteiro, a redundância geográfica é a resposta. Se o orçamento estiver apertado, remova as dependências de caminho único por ordem de impacto nos negócios, em vez de comprar uma duplicata do dispositivo mais visível.
Projetando Camadas Resilientes de Rede, Autenticação e Identidade
A resiliência falha na dependência mais fraca. Construa a pilha a partir da camada física para cima e atribua a cada camada um domínio de falha independente.
Comece com o acesso e os uplinks
Use clustering de switches e pontos de acesso onde a infraestrutura exigir, mas verifique se os membros do cluster não compartilham um único domínio de falha. Dois switches no mesmo rack ainda podem depender de uma única fonte de alimentação. Dois uplinks ainda podem seguir a mesma calha de cabos. A agregação de links pode fornecer capacidade e resiliência de caminho, enquanto uplinks duplos reduzem a dependência de uma única porta, módulo ou cabo.
No gateway, use VRRP ou um mecanismo de gateway virtual equivalente para que a rota padrão possa se mover entre os dispositivos. Teste o failover de firewall stateful em vez de assumir que um gateway flutuante preserva as sessões ativas. Alguns serviços se reconectam de forma limpa. Outros precisam de tratamento de sessão explícito.
A resiliência da WAN deve combinar circuitos separados com roteamento baseado em políticas que reconheça a integridade do serviço, e não apenas o status do link. Um circuito pode permanecer eletricamente ativo enquanto perde o caminho para os aplicativos que importam. O LTE ou 5G fornece um acesso útil fora de banda para gerenciamento e um caminho de fallback, mas precisa de sua própria cobertura, energia, política de dados e controles de segurança.
Trate o DNS e a energia como dependências de produção
O DNS faz parte da jornada do usuário. Use gerenciamento deliberado de TTL, capacidade de resolução secundária e um design split-horizon onde as respostas internas e externas precisam ser diferentes. Monitore o tempo de resolução e as falhas, e não apenas se o processo do resolvedor responde.
A alimentação elétrica também precisa de camadas. Combine a proteção de UPS com um orçamento PoE realista, alimentações separadas onde o prédio suportar e cobertura de gerador para as salas que hospedam dependências de rede. Um UPS com uma bateria falha não é resiliência. Um gerador que não alcança a camada de acesso também não é.
Proteja a autenticação com o mesmo cuidado que a conectividade
O RADIUS deve ter instâncias de serviço independentes e uma ordem de failover testada. O comportamento do Captive Portal precisa de um modo degradado definido. Pergunte se um usuário que já se autenticou pode continuar, se um novo usuário pode concluir a jornada e o que acontece quando o provedor de identidade está inacessível.
Para o acesso da equipe, um serviço RADIUS gerenciado na nuvem pode reduzir a dependência de um único servidor local, mas ainda precisa de disponibilidade multirregião, endpoints monitorados, certificados atualizados e responsabilidade clara pela recuperação. O serviço RADIUS do Microsoft Entra ID da Purple é uma opção para conectar o acesso à rede com a identidade baseada em diretório, mantendo a camada de autenticação no planejamento de resiliência.
Cada camada deve falhar de forma independente. Se ambos os nós RADIUS usarem o mesmo host virtual, ambos os caminhos de DNS usarem o mesmo resolvedor e ambos os circuitos WAN entrarem pelo mesmo duto, o diagrama é redundante, mas a infraestrutura não é.
Testes, Monitoramento e Manuais que Realmente Detectam Interrupções
Arquitetura no papel não é arquitetura em produção. A única maneira confiável de validar um caminho de failover é testá-lo sob condições controladas, observar a experiência do usuário e corrigir o que quebrar.
Execute um programa trimestral de simulações com um foco de falha diferente a cada ciclo:
- Troca de controladora: Prove que o gerenciamento e o serviço de rede sem fio continuam após a remoção da controladora principal.
- Transição de WAN: Valide a detecção de circuito, roteamento de políticas, estado do firewall e acessibilidade de aplicativos.
- Falha no nó RADIUS: Confirme se os novos logins e a reautenticação utilizam o serviço secundário.
- Degradação do Captive Portal: Verifique se o acesso de visitantes falha de forma segura e se os usuários existentes recebem a experiência pretendida.
O caos controlado supera um exercício de simulação. Em uma noite de baixo risco, desconecte uma pilha de switches, desative um caminho de WAN ou isole um nó de RADIUS com um registro de mudança aprovado. Mantenha o teste delimitado, defina um plano de retorno (rollback) e faça o proprietário do serviço observar o resultado de negócios em vez de apenas o painel de monitoramento.
Monitore sintomas, não a vaidade do dispositivo
Sinais úteis incluem:
- Acessibilidade do controlador e estado do cluster.
- Latência de resposta RADIUS e taxa de falha de autenticação.
- Tempo de resolução de DNS e consultas com falha.
- Estado de associação do ponto de acesso e reassociação do cliente.
- Utilização do uplink, erros e alterações de caminho.
- Acessibilidade sintética do Captive Portal.
- Integridade da WAN baseada em testes de aplicativos, não apenas no status da interface.
Defina limites de alerta com base no impacto ao cliente. Um pequeno aumento nas falhas de autenticação pode indicar uma interrupção de identidade antes que os usuários liguem para o help desk. Um uplink em capacidade sustentada pode ser um precursor para um failover degradado. Não acione engenheiros para cada evento transitório. Acione-os quando vários sinais se combinarem em um sintoma de serviço.
Um runbook deve conter uma árvore de decisão, responsáveis nomeados para escalonamento, ordem de contato com fornecedores, requisitos de acesso, etapas de rollback e metas de tempo vinculadas ao RTO do serviço. Inclua capturas de tela ou localizações exatas do console onde apropriado, mas não dependa do conhecimento informal da equipe. Após cada simulação, registre o tempo de detecção, o tempo de decisão, o tempo de recuperação, o impacto no usuário e a alteração necessária.
O teste de latência e jitter de WiFi da Purple pode apoiar a validação prática da qualidade da rede, mas nenhum teste substitui um exercício real de failover. Se você não falhou uma dependência de propósito, você não a validou.
Considerações Específicas do Setor para Hospitalidade, Varejo, Saúde e WiFi Multi-Tenant
O mesmo modelo de resiliência necessita de prioridades diferentes em ambientes distintos. Comece classificando os serviços e, em seguida, escolha os controles de identidade e rede que protegem a jornada do usuário de maior valor.
| Setor | Serviços Tier-1 | Postura de Failover Recomendada | Principal Risco de Identidade e Rede |
|---|---|---|---|
| Hospitalidade | Autenticação de convidados, acesso a pagamentos, sistemas da propriedade, conectividade da equipe | Dual WAN, RADIUS resiliente, recuperação de Captive Portal testada, energia protegida | A dependência de um portal ou login de convidado compartilhado pode interromper o check-in e a prestação de serviços |
| Varejo | Tráfego de POS, serviços de pagamento, operações de loja, acesso da equipe | VLANs isoladas, borda resiliente, backup LTE ou 5G, comutação de circuito testada | O tráfego de pagamento e operacional pode competir com o acesso de convidados sem uma segmentação rígida |
| Saúde | WiFi clínico, prontuários eletrônicos, telemetria, BYOD aprovado | Camadas de rede com backup de bateria, identidade resiliente, recuperação de criptografia controlada, alterações prontas para auditoria | Uma falha de autenticação ou de energia pode interromper os fluxos de trabalho clínicos e criar riscos de segurança |
| Locais multi-inquilino | Acesso de inquilinos, WiFi de áreas comuns, operações prediais, serviços da equipe | SSIDs segmentados, política com reconhecimento de inquilinos, domínios de autenticação independentes, caminhos diversos | A falha de identidade, DNS ou política de um único operador pode se espalhar em cascata por outros inquilinos |
Os operadores do setor de hotelaria devem tratar o WiFi de visitantes como um canal operacional e comercial, não como um serviço de cortesia. As equipes de varejo devem manter os caminhos de pagamento isolados do tráfego de visitantes e verificar se o circuito de backup suporta o fluxo real de transações. Os administradores de saúde precisam de registros de alterações que resistam a auditorias, ao mesmo tempo em que verificam se os equipamentos alimentados por bateria cobrem o caminho de acesso que os médicos utilizam.
Para estádios, edifícios residenciais, espaços de coworking e outros locais multi-tenant, a segmentação deve se estender até a autenticação e o DNS. SSIDs separados por si só não garantem o isolamento do tenant se as políticas, consultas de identidade ou caminhos de gerenciamento continuarem compartilhados.
Um primeiro passo sensato é um inventário piloto de 30 dias. Catalogue pontos de acesso, switches, controladoras, circuitos WAN, serviços de identidade, DNS, energia e proprietários em uma propriedade ou local representativo. Em seguida, crie um mapa de SLA em camadas para o setor, execute um failover controlado e use os resultados para financiar a próxima redução de riscos. A pressão atual sobre o planejamento da força de trabalho também torna importante o ângulo do risco humano. O CIPD Labour Market Outlook para o verão de 2026 informou que 21% dos empregadores do Reino Unido planejavam demissões nos três meses até setembro de 2026. Menos pessoas significa menos tolerância para trabalhos de recuperação não documentados, portanto, projete runbooks e responsabilidades antes da próxima mudança de equipe.
Os deveres de demissão coletiva do Reino Unido também tornam as propriedades fragmentadas um problema de tempo e dados. As orientações do governo sobre consultas de demissão estabelecem que o limite de 20 ou mais se aplica a um estabelecimento dentro de 90 dias, com o cronograma de notificação vinculado ao intervalo de demissão proposto. Para os líderes de rede, a lição análoga é mapear locais e dependências com precisão. Uma propriedade de vários locais não pode assumir com segurança que edifícios, circuitos ou equipes separados criam domínios de falha separados sem provar como o tráfego, a identidade e as operações se conectam.
A Purple oferece autenticação de WiFi gerenciada em nuvem e acesso baseado em identidade, incluindo capacidade RADIUS projetada com caminhos de serviço redundantes, para que possa fazer parte de um plano de resiliência em vez de deixar o login de visitantes como um ponto único de falha oculto. Revise como a Purple se adapta aos seus requisitos de rede, identidade e failover, e comece com um inventário no nível da propriedade e um teste de autenticação controlado.
