> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/pt/area-do-administrador/architecture-and-design/bcdr-whitepaper.md). # Whitepaper sobre Continuidade Corporativa e Recuperação de Desastres ## **Introdução** Zoom oferece IA em primeiro lugar Comunicações Unificadas como serviço (UCaaS) e Contact Center como serviço (CCaaS) por meio de uma única plataforma integrada. Este documento descreve as inovações e a arquitetura por trás dos serviços e produtos de melhor categoria da Zoom, explicando como entregamos uma experiência consistente, segura e gerenciável para usuários finais e para TI em UCaaS e CCaaS. ## **Construído com base na experiência** A visão da Zoom centrada na nuvem ajuda as organizações a irem além do custo e da complexidade dos sistemas legados no local. Em vez de acrescentar funcionalidades a stacks envelhecidas, investimos em engenharia full-stack em clientes, serviços de media e sistemas de salas para otimizar a qualidade, a resiliência e a usabilidade de ponta a ponta como uma plataforma coesa — ancorada por uma estratégia de cliente único com uma base de código comum em todas as plataformas que tira partido da UX nativa de cada SO. Essa abordagem que prioriza a nuvem aparece no aplicativo Zoom Workplace: um único aplicativo moderno que oferece aos usuários acesso centralizado a Reuniões, chat, Telefone, central de contato, Eventos, Webinars, Salas, quadro de compartilhamento, Canvas e muito mais. O Acessar é regido por licenciamento, para que a TI possa ativar ou desativar produtos e recursos sem implantar uma colcha de retalhos de instaladores separados ou gerenciar versões conflitantes do cliente. Para a TI, o modelo reduz a sobrecarga — menos servidores para comprar, instalar em racks e aplicar patches; menos integrações personalizadas para manter; e sem necessidade de equipes inteiras dedicadas a manter a infraestrutura no local em funcionamento. A capacidade, as atualizações e as melhorias de segurança são entregues a partir da nuvem, para que os administradores possam se concentrar em políticas, adoção e resultados, em vez de manutenção. ## Arquitetura e Resiliência de Mídia em Tempo Real As seções a seguir discutem a abordagem de design do Zoom para Habilitar uma experiência de mídia em tempo real de alto nível. ### Zoom Meetings, seminários web e eventos A base da nossa arquitetura é uma camada de transporte inteligente que seleciona o melhor caminho com base nas condições reais da rede e nas políticas. O UDP é usado quando Disponível, com fallback transparente para TCP/TLS (incluindo HTTPS/443) em ambientes mais restritivos. O compartilhamento de tela usa Reliable UDP para movimento fluido sempre que possível, com fallback automático se necessário. Conectando-se a uma reunião, webinar ou Evento, o aplicativo Zoom Workplace é direcionado por geolocalização para os recursos Disponível mais próximos para minimizar a latência. Quando as políticas organizacionais ou o desempenho exigirem, o tráfego pode atravessar o backbone global do Zoom por meio de links dedicados para diferentes data centers.
Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers.

Uma visão geral da arquitetura e do design Ativo-Ativo de reunião, webinar e eventos do Zoom.

A próxima camada é uma camada reativa de qualidade de serviço que se adapta às condições de rede e do Dispositivo em tempo real. Ela monitora a largura de banda, a perda de pacotes, a latência e a variação de atraso, além de coletar o uso local de CPU, memória e E/S de rede. Esses sinais informam as camadas superiores para que tomem as ações adaptativas apropriadas a fim de manter a qualidade e a confiabilidade. O codec personalizado e adaptativo da Zoom na camada de sessão é ajustado para o desempenho em tempo real. Os algoritmos ao redor otimizam continuamente a taxa de quadros e a resolução para corresponder às condições do Dispositivo e da rede. Para proporcionar a melhor experiência possível conforme as condições permitirem, a Zoom usa vários fluxos simultâneos, e o aplicativo Zoom Workplace seleciona dinamicamente a camada mais apropriada. Graças à compressão eficiente, as sessões permanecem utilizáveis com perda de pacotes de até \~45%; nesses casos, o áudio é priorizado em relação ao vídeo para manter as conversas claras. A abordagem de múltiplos fluxos também ajusta a largura de banda à capacidade de cada participante de enviar e receber áudio e vídeo. A camada de conferência distribuída da Zoom usa comutação baseada em assinatura, sem transcodificação ou mixagem no lado do servidor. Os serviços tradicionais frequentemente transcodificam e misturam fluxos, acrescentando sobrecarga de CPU e memória; nossa abordagem de comutação foi projetada para reduzir o uso de recursos e escalar com eficiência. Os participantes são roteados por geolocalização para o datacenter mais próximo e atribuídos ao servidor com menor carga; quando os participantes estão no mesmo local, podem ser agrupados no mesmo servidor para maior eficiência. A arquitetura oferece suporte a implantações locais e híbridas flexíveis e fornece caminhos de tráfego em cascata para grandes empresas. O Servidor de Reunião é nosso MMR (roteador multimídia), e cada MMR é agrupado em uma “Zona de Reunião”. Os controladores de zona gerenciam todos os MMRs e denunciam seu status ao controlador global da nuvem para cada Zona de Reunião. As Zonas de Reunião são duplicadas para cada datacenter com exatamente a mesma arquitetura, e podemos Adicionar facilmente mais zonas dinamicamente para ampliar a capacidade em cada região. As três camadas (o MMR, o controlador Zoom e o controlador global da nuvem) são usadas para equilibrar recursos em diferentes locais. Se apenas dois participantes estiverem em uma reunião, a Zoom poderá utilizar conexões ponto a ponto para obter excelente velocidade e confiabilidade. Tudo isso permite que a Zoom mantenha a Disponível dos serviços de reunião com 99,9% de tempo de atividade e ofereça uma experiência confiável de videoconferência. ### Zoom Phone O Zoom Phone foi desenvolvido na nuvem e para a nuvem, usando as comprovadas adaptações de qualidade de áudio já Disponível em nossos produtos Zoom Meetings e Webinars. A arquitetura da Zoom tem redundância e resiliência integradas, resultando em uma solução altamente Disponível que pode escalar para atender até mesmo às necessidades da maior Organização. O Zoom Phone utiliza mecanismos de transporte inteligentes para conectividade confiável em diversos ambientes de rede. Para mídia, ele usa SRTP sobre UDP quando disponível, com fallback contínuo para TCP/TLS, além de taxa de bits adaptativa e mitigação de perda de pacotes para preservar a qualidade do áudio em condições adversas. Para conectividade, as ligações são roteadas para a Zona SIP Disponível mais próxima a fim de minimizar a latência, com failover automático entre datacenters quando necessário.
Diagram showing a Zoom Phone device connected to a primary data center, with a secondary connection to an additional data center for failover events.

Arquitetura Ativo-ativo do Zoom Phone

A Zoom possui controladores de borda de sessão (SBCs) redundantes em cada um de seus datacenters, que protegem as comunicações de clientes e operadoras. Esses SBCs de nível de operadora facilitam o Acessar para uma ampla variedade de organizações, desde os menores clientes até empresas globais. Os balanceadores de carga redirecionam as comunicações baseadas em SIP para os comutadores de ligações da Zoom, a fim de distribuir uniformemente o volume de ligações. Essa distribuição possibilita uma experiência fluida para os usuários, mesmo durante horários de pico de inscrição e de ligações intensas. Os comutadores de ligações são o principal controle de ligações do Zoom Phone. Esses componentes escaláveis não apenas oferecem suporte à funcionalidade básica de PBX, mas também facilitam dados de telemetria para o Painel do Zoom Phone e permitem Habilitar recursos como elevar ligações do Zoom Phone a reuniões do Zoom.
A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center

Arquitetura Ativo-ativo para hardware e zonas SIP hospedadas em um datacenter

O aplicativo Zoom Workplace utiliza lógica proprietária para monitorar a largura de banda, a perda de pacotes, a latência e o jitter do aplicativo, ao mesmo tempo em que também coleta o uso de CPU, a memória e a E/S de rede do aplicativo. Essa tecnologia monitora ativamente as ligações e faz ajustes em tempo real para superar condições ruins de rede, proporcionando qualidade superior ao ligar e confiabilidade para vários ambientes de rede e diferentes dispositivos. O Painel do Zoom Phone captura dados de Qualidade do serviço em tempo real e históricos, bem como métricas de uso e adoção, registros de chamadas e métricas relacionadas a serviços de emergência nômades. O Zoom classifica automaticamente cada chamada com um Mean Opinion Score (MOS), permitindo que administradores de TI acompanhem o desempenho de todas as chamadas que atravessam a rede e identifiquem possíveis problemas relacionados à rede.
### Zoom central de contato Semelhante ao Zoom Phone, a arquitetura ativo-ativo do Zoom central de contato ajuda a fornecer resiliência e redundância em todo o seu ambiente omnicanal. Baseando-se em arquiteturas comprovadas do Zoom Meetings e dos serviços do Zoom Phone, o central de contato integra perfeitamente capacidades de comunicação em tempo real com funcionalidades da web, criando uma interface intuitiva que beneficia tanto a sua equipe de agentes quanto os seus clientes. Cada datacenter apresenta duas zonas idênticas e interligadas do Protocolo de Iniciação de Sessão (SIP). As zonas SIP têm a função de Permitir que chamadas de voz sejam feitas e recebidas pela internet, e cada zona está equipada com hardware e serviços dedicados para sustentabilidade independente. Dentro de um datacenter, um balanceador de carga distribui uniformemente as chamadas entre ambas as zonas SIP. As chamadas são distribuídas entre um cluster de comutadores de chamadas, que são responsáveis por várias funções, como roteamento de chamadas, configuração e encerramento. Dos switches de ligar, os ligar conectam-se a um SBC em cada zona, que ou se conecta à rede subjacente de fornecedores da Zoom ou a uma operadora fornecida pelo cliente para Roteamento PSTN até que o ligar chegue ao seu destino final. Os SBCs, balanceadores de carga e switches de ligar são complementados com hardware redundante em espera para resiliência. A voz no Zoom central de contato beneficia-se da mesma adaptação do cliente e do mesmo comportamento de transporte que o Zoom Phone — usando UDP quando disponível, com recurso a TCP/TLS como alternativa —, de modo que o áudio permaneça claro mesmo em redes com restrições. Para vídeo e canais digitais, o serviço aproveita a espinha dorsal de mídia em tempo real do Zoom e a resiliência na nuvem para qualidade consistente e comutação por falha. #### Cobrowse O serviço Cobrowse do Zoom central de contato é executado em uma infraestrutura separada do serviço principal do Zoom central de contato. Quando uma sessão começa, o kit de desenvolvimento de software (SDK) estabelece uma conexão WebSocket persistente com o Servidor hub de Cobrowsing (CHS) para comunicação bidirecional, com o tráfego roteado por geolocalização para o datacenter disponível mais próximo para reduzir a latência. O serviço usa uma arquitetura distribuída e sem estado, com balanceamento de carga dinâmico entre nós do CHS para suportar escalabilidade elástica em modelos de implantação em nuvem, híbridos e locais. Para ajudar a manter a continuidade da sessão, o SDK reconecta-se automaticamente a nós CHS saudáveis se a conectividade for interrompida e pode fazer failover entre centros de dados com o mínimo de interrupção. Combinada com o monitoramento contínuo de integridade e com a abordagem mais ampla de resiliência Ativo-Ativo da Zoom, esta arquitetura foi concebida para oferecer um desempenho de cobrowsing fiável e escalável para ambientes de nível empresarial.

Arquitetura Ativo-ativo para zonas do Cobrowse SDK hospedadas em um datacenter

## **Zoom Node para implantações híbridas e locais** [Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) é uma plataforma híbrida gerenciada na nuvem que liga os recursos do seu datacenter à nuvem do Zoom, permitindo que você implemente módulos de serviço do Zoom (cargas de trabalho) localmente e os gerencie no Portal web do Zoom. Dois módulos se destacam pela resiliência: Zoom Meetings Híbrido e Zoom Phone Local Survivability (ZPLS). [Zoom Meetings Híbrido](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) fornece rotas de mídia em tempo real para participantes internos através do seu Node local, enquanto o sinal, o administrador e a política permanecem na Zoom cloud, e inclui uma opção local de sobrevivência se os data centers da Zoom ficarem inacessíveis. Os utilizadores internos obtêm caminhos de baixa latência e redução da saída de internet, enquanto os participantes externos podem Entrar pela nuvem como de costume. As contas também podem Adicionar Conector de gravação para captura local quando necessário, com failover automático para a nuvem se a capacidade local não estiver Disponível.
Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud.

O Módulo Híbrido do Zoom Meetings mostra como os usuários numa rede local se conectam ao Hybrid MMR, em cascata para a nuvem.

[Sobrevivência local do Zoom Phone](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) (ZPLS) mantém as chamadas principais Disponível numa unidade se o WAN ou o caminho do fornecedor cair. Os telefones registam-se localmente, a chamada de extensão interna continua e, quando configurado, a chamada efetuada crítica pode ser mantida através de um caminho PSTN no local. Quando a conectividade regressa, o serviço retoma automaticamente a operação normal na nuvem.
Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability.

Zoom Phone Sobrevivência Local suporta vários cenários de failback para PSTN e
conectividade entre unidades em caso de um Evento com impacto no serviço.

## **Centros de dados distribuídos globalmente e redundância** A Zoom tem brokers e servidores de comunicação distribuídos entre vários datacenters interligados em todo o mundo. Avaliamos constantemente os nossos datacenters e os provedores de serviços de Internet (ISPs) para otimizar o desempenho para os nossos clientes em termos de largura de banda, latência e isolamento de recuperação de desastres. Os nossos datacenters estão situados em instalações seguras de colocation que são neutras em relação a operadoras ISP e fornecem segurança física, energia redundante e acesso simultâneo aos principais ISPs e parceiros de peering. Também temos determinadas implementações em provedores de nuvem pública quando os requisitos regionais ou de capacidade o justificam. As nossas instalações de colocation são construídas com uma arquitetura tolerante a falhas, com redundância total e capacidade de failover rápida. A Zoom distribui dinamicamente a carga pelos servidores de comunicação para mover automaticamente novas sessões para o datacenter com o melhor tempo de resposta. Estas instalações também são projetadas para resiliência na camada física. Cada instalação de colocation é construída com redundância N+1 e um conjunto completo de controlos ambientais destinados a manter a instalação operacional perante falhas de componentes e perigos físicos: * Controlos de temperatura e humidade * Sistemas de energia totalmente redundantes e dimensionados para acomodar falhas de componentes * Iluminação de emergência resiliente * Proteção contra incêndio * Proteção contra danos causados pela água Os datacenters incluem modelos de redundância da fonte de alimentação ininterrupta (UPS), como N, N+1 ou 2N, e redundância de geradores usando um design N+1, com a manutenção e os testes de energia tratados pelo fornecedor de datacenter aplicável. Onde a Zoom usa a AWS como anfitrião de partes da sua infraestrutura de nuvem, a existência e o funcionamento dos controlos da AWS são revistos anualmente pela equipa de Segurança da Zoom através de relatórios de auditores externos de serviços; quaisquer exceções identificadas são discutidas com a AWS e, quando apresentam um risco para os sistemas ou dados da Zoom, são escaladas para a gestão da Zoom.

Localizações Comerciais de datacenter da Zoom em Todo o Mundo (novembro de 2024)

## **Capacidade** A Zoom mantém 50% de capacidade excedente em todos os aspetos da nossa infraestrutura para acomodar a nossa operação Corporativa em crescimento e para satisfazer os requisitos de utilização de pico. Estamos confiantes na nossa capacidade de fornecer serviço e escalar com base nas necessidades atuais e futuras dos nossos clientes. ## **Continuidade Corporativa e Recuperação de Desastres** A fiabilidade em condições normais é apenas parte da história; igualmente importante é a forma como a plataforma se comporta quando algo corre mal. As perturbações — como desastres naturais, falhas de energia ou de instalações, incidentes cibernéticos, interrupções de rede e avarias de hardware — são uma realidade inevitável para qualquer serviço global, e a resiliência da Zoom resulta da forma como se prepara, resiste e recupera destes eventos. Essa resiliência assenta em quatro camadas distintas, mas interligadas, cada uma a operar num momento diferente antes, durante e depois de uma perturbação: * **Alta disponibilidade** — a camada arquitetural que reduz a probabilidade e o impacto de falhas antes que elas ocorram, eliminando pontos únicos de falha. * **Continuidade de negócios** — a camada operacional que mantém as funções essenciais do negócio em funcionamento quando ocorre uma interrupção. * **Recuperação de desastre** — a camada de restauração que traz de volta à operação normal os sistemas e serviços de tecnologia afetados após um evento disruptivo. * **Testes** — a camada de validação que confirma que essas práticas funcionam e evidencia lições para melhoria contínua. Essas camadas se constroem umas sobre as outras: alta disponibilidade reduz com que frequência a recuperação é necessária, a continuidade de negócios define o que permanece em funcionamento enquanto isso acontece, a recuperação de desastre restaura o que foi afetado e os testes validam o conjunto todo. A arquitetura descrita ao longo deste documento — datacenters ativos-ativos, roteamento baseado em geolocalização, failover automático e implantação N+1 — é a camada de alta disponibilidade na prática. As seções abaixo descrevem as outras três. ### Alta disponibilidade A alta disponibilidade refere-se ao design de sistemas e serviços destinado a dar suporte à operação contínua e a um tempo de inatividade mínimo, e é incorporada aos sistemas do Zoom com o objetivo de minimizar ou eliminar pontos críticos de falha. Os serviços são projetados para resistir a interrupções completas de datacenter, e processos automatizados deslocam o tráfego para longe de uma área afetada quando ocorre uma falha. As aplicações principais são implantadas segundo o padrão N+1, de modo que, se um datacenter ficar indisponível, permaneça capacidade suficiente para balancear a carga do tráfego para as unidades remanescentes. Essa filosofia de design abrange o conjunto completo de sistemas dos quais uma plataforma de comunicações depende — instalações redundantes, infraestrutura de telefonia, conectividade de internet e LAN, infraestrutura de segurança, sistemas de banco de dados relacionais, armazenamento em massa, backups, hardware e as práticas associadas de gestão de capacidade e manutenção — para que a falha de qualquer componente, sistema ou instalação isolado não resulte em perda de serviço. ### Continuidade de negócios O planejamento de continuidade de negócios do Zoom foi projetado para minimizar o impacto das interrupções nas operações, proteger ativos e manter serviços essenciais para clientes e partes interessadas. Ele identifica as funções de negócios que devem ser preservadas ou restauradas primeiro, as pessoas, a tecnologia, os fornecedores e os recursos do local de trabalho de que essas funções dependem, e o impacto potencial caso essas dependências sejam interrompidas. Isso fornece ao Zoom uma base estruturada para coordenar a resposta e a recuperação quando as operações normais são afetadas, particularmente quando várias funções ou recursos exigem atenção ao mesmo tempo. Subjacente a esse planejamento está uma Análise de Impacto nos Negócios (BIA), o processo sistemático que o Zoom usa para identificar e avaliar os possíveis efeitos de interrupções nas funções críticas do negócio. O Zoom realiza uma BIA para funções críticas pelo menos anualmente, ou quando ocorre uma alteração significativa em um processo crítico de negócio. A análise abrange quatro componentes principais: 1. **Identificação das funções críticas do negócio** — documentando os principais processos essenciais às operações do Zoom e determinando as dependências e interdependências entre eles. 2. **Avaliação de impacto** — avaliando o impacto potencial das interrupções em cada função, considerando perda financeira, tempo de inatividade operacional, implicações legais e regulatórias e danos à reputação. 3. **Requisitos de recursos** — identificando o pessoal, a tecnologia, as instalações e os serviços de terceiros necessários para apoiar a recuperação, e avaliando sua disponibilidade e adequação. 4. **Priorização dos esforços de recuperação** — sequenciando a recuperação das funções críticas com base em seu impacto e nos objetivos de recuperação estabelecidos, para que as funções mais críticas sejam restauradas primeiro. ### Recuperação de desastre O Zoom valida regularmente seus recursos de recuperação de desastre por meio de testes anuais em seus produtos. A empresa mantém um Plano de Recuperação de Desastre (DRP) formal e documentado, que define procedimentos para restaurar sistemas e serviços críticos após uma interrupção, incluindo estratégias de recuperação, funções e responsabilidades e protocolos de comunicação. O DRP do Zoom foi projetado para lidar com vários cenários de desastre que podem incluir um ou mais dos seguintes: quedas de energia, perda de conectividade de rede, falhas de hardware, desastres naturais e outros eventos disruptivos, até e incluindo a falha total da unidade. Os padrões de segurança da informação que regem a recuperação de desastre são documentados, aprovados, comunicados e revisados pelo menos anualmente. Em vez de manter uma unidade de recuperação quente dedicada para serviços em nuvem, o Zoom depende de arquitetura redundante, datacenters em múltiplas localizações e vários provedores de nuvem, incluindo AWS, OCI e GCP, para dar suporte à continuidade. No nível da plataforma, o padrão de recuperação difere por tipo de serviço: * **Cluster web e comunicações não em tempo real** usam a infraestrutura de alta disponibilidade da AWS em uma configuração ativa-ativa multirregional, dependem de registros DNS para habilitar failover entre datacenters e incluem vários componentes com recursos de replicação em cada datacenter. * **Datacenters regionais e comunicações em tempo real** operam em uma configuração ativa-ativa entre provedores geograficamente dispersos de Nível 3 ou superior, com componentes e conectividade redundantes e resilientes dentro de cada datacenter regional, operadoras diversas apoiando a conectividade e failover entre regiões exigindo reconexão. As estratégias de recuperação documentadas do Zoom incluem failover de região, que desloca o tráfego ou os serviços para fora de uma região afetada, e rollback por meio de implantação blue-green, que retorna os serviços a um ambiente ou estado de implantação previamente conhecido como bom para se recuperar de problemas de software ou relacionados à implantação. Essas estratégias são medidas em relação a objetivos de recuperação definidos. O objetivo de tempo de recuperação (RTO) — o tempo-alvo para restaurar o serviço após uma interrupção — tem como meta menos de cinco minutos. O objetivo de ponto de recuperação (RPO) — a quantidade-alvo de perda de dados tolerável — tem como meta nenhuma perda de dados, apoiado pela replicação de dados armazenados na nuvem entre várias zonas de disponibilidade. Esses objetivos orientam o design e os testes do Zoom, em vez de funcionarem como garantias de serviço. O backup e a restauração eficazes de dados são um componente central dessa abordagem, protegendo informações críticas para que possam ser restauradas em caso de interrupção a fim de manter a continuidade de negócios. O Zoom não compartilha externamente seu plano completo de recuperação de desastre nem os resultados detalhados dos testes, pois esses materiais contêm informações comerciais internas e confidenciais sensíveis. Consulte [Central de confiança da Zoom](https://www.zoom.com/en/trust/legal-compliance/) para obter mais informações sobre a documentação disponível publicamente. ### Testes O Zoom valida suas práticas de recuperação por meio de testes anuais de mesa e failover realizados por auditores terceirizados. Esses testes confirmam que os processos de resposta e recuperação funcionam conforme o esperado, identificam lacunas e apoiam a melhoria contínua por meio das lições aprendidas. Os testes abrangeram um amplo conjunto de produtos e áreas de serviço em toda a plataforma, incluindo Zoom Meetings, Zoom Phone, Zoom central de contato, Zoom Virtual Agent, Zoom Rooms, Zoom Events, quadro de compartilhamento, Reserva de local de trabalho e os gateways de RTC e de telefonia, entre outros. Combinada com a arquitetura redundante e ativa-ativa descrita ao longo deste documento, essa abordagem em camadas foi projetada para manter os serviços do Zoom disponíveis e recuperáveis em uma ampla gama de condições disruptivas. ## **Conclusão** A confiabilidade do Zoom é sustentada por uma arquitetura em camadas que combina design de serviços prioritariamente na nuvem, roteamento de mídia adaptativo, infraestrutura global redundante, planejamento de capacidade e práticas formais de continuidade de negócios e recuperação de desastre. Em Meetings, Phone, central de contato, Zoom Node, datacenters globais e serviços relacionados, a plataforma do Zoom foi projetada para dar suporte a comunicações consistentes em redes, regiões, dispositivos e modelos de implantação diversos. Os mesmos princípios de design que sustentam a qualidade do serviço no dia a dia também sustentam a resiliência em escala. Arquitetura ativa-ativa, roteamento inteligente, transporte adaptativo, instalações redundantes, planejamento de recuperação, práticas de backup e testes regulares trabalham em conjunto para ajudar a manter serviços essenciais e apoiar a recuperação quando ocorrem eventos operacionais. Para clientes e equipes de TI, essa abordagem oferece uma plataforma projetada para comunicação confiável, continuidade operacional e implantação empresarial gerenciável em ambientes UCaaS e CCaaS. *Redigido por Jakob Ganschow e Sam Azimipour* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://library.zoom.com/technical-library/pt/area-do-administrador/architecture-and-design/bcdr-whitepaper.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.