> 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/sv/adminhornan/architecture-and-design/bcdr-whitepaper.md). # Whitepaper om Businesskontinuitet och katastrofåterställning ## **Introduktion** Zoom levererar AI-först enhetlig kommunikation som en tjänst (UCaaS) och kontaktcenter som en tjänst (CCaaS) via en enda integrerad plattform. Detta dokument beskriver innovationerna och arkitekturen bakom Zooms tjänster och produkter i toppklass och förklarar hur vi levererar en konsekvent, säker och hanterbar upplevelse för slutanvändare och IT över UCaaS och CCaaS. ## **Byggt på erfarenhet** Zooms moln-först-vision hjälper organisationer att gå bortom kostnaderna och komplexiteten i äldre system på plats. I stället för att lägga till funktioner ovanpå åldrande stackar har vi investerat i fullstackteknik över klienter, medietjänster och rumssystem för att optimera kvalitet, motståndskraft och användbarhet från början till slut som en sammanhängande plattform — förankrad i en strategi med en enda klient och en gemensam kodbas över plattformar som utnyttjar varje operativsystems inbyggda UX. Det moln-först-tillvägagångssättet syns i appen Zoom Workplace: en enda modern applikation som ger användarna centraliserad åtkomst till Meetings, chatt, telefon, kontaktcenter, evenemang, webbinarier, rum, whiteboard, Canvas och mer. Access styrs av licensiering, så IT kan aktivera eller stänga av produkter och funktioner utan att distribuera ett lapptäcke av separata installationsprogram eller hantera motstridiga klientversioner. För IT minskar modellen overheaden — färre servrar att köpa, montera i rack och patcha; färre skräddarsydda integrationer att underhålla; och inget behov av hela team som ägnas åt att hålla den på plats-baserade infrastrukturen igång. Kapacitet, uppdateringar och säkerhetsförbättringar levereras från molnet, så administratörer kan fokusera på policy, införande och resultat i stället för underhåll. ## Arkitektur för realtidsmedier och motståndskraft Följande avsnitt diskuterar Zooms designansats för att aktivera en medieupplevelse i realtid i toppklass. ### Zoom Meetings, webbinarier och evenemang Grunden för vår arkitektur är ett intelligent transportlager som väljer den bästa vägen baserat på faktiska nätverksförhållanden och policyer. UDP används när det är tillgänglig, med sömlös återgång till TCP/TLS (inklusive HTTPS/443) i mer restriktiva miljöer. Skärmdelning använder Reliable UDP för jämna rörelser när det är möjligt, med automatisk återgång vid behov. När du ansluter till ett möte, ett webbinarium eller ett evenemang styrs appen Zoom Workplace av geolokalisering till de närmaste tillgängliga resurserna för att minimera latens. När organisatoriska policyer eller prestanda kräver det kan trafiken färdas genom Zooms globala stomnät via dedikerade länkar till olika datacenter.
Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers.

En översikt över Zooms mötes-, webbinarie- och evenemangsarkitektur med aktiv-aktiv-design.

Nästa lager är ett reaktivt QoS-lager som anpassar sig efter realtidsförhållanden i nätverket och på enheten. Det övervakar bandbredd, paketförlust, latens och jitter, och samlar även in lokal CPU-användning, minne och nätverks-I/O. Dessa signaler informerar de övre lagren att vidta lämpliga adaptiva åtgärder för att upprätthålla kvalitet och tillförlitlighet. Zooms anpassade, adaptiva codec på sessionlagret är optimerad för prestanda i realtid. Omgivande algoritmer optimerar kontinuerligt bildfrekvens och upplösning för att matcha förhållanden för enhet och nätverk. För att ge bästa möjliga upplevelse när förhållandena tillåter använder Zoom flera samtidiga strömmar, och Zoom Workplace appen väljer dynamiskt det mest lämpliga lagret. Tack vare effektiv komprimering förblir sessioner användbara vid paketförlust på upp till cirka 45 %; i dessa fall prioriteras ljud framför video för att hålla samtalen tydliga. Strategin med flera strömmar justerar också bandbredden efter varje deltagares förmåga att skicka och ta emot ljud och video. Zooms distribuerade konferenslager använder prenumerationsbaserad växling utan transkodning eller mixning på serversidan. Traditionella tjänster transkoderar och mixar ofta strömmar, vilket ökar CPU- och minnesbelastningen; vår växlingsmetod är utformad för att minska resursanvändningen och skala effektivt. Deltagare dirigeras via geolokalisering till närmaste datacentral och tilldelas den minst belastade servern; när deltagare är samlokaliserade kan de grupperas på samma server för effektivitet. Arkitekturen stöder flexibla lokala och hybrida driftsättningar och tillhandahåller kaskaderade trafikvägar för stora företag. Mötesservern är vår MMR (multimediarouter), och varje MMR är grupperad i en ”möteszon.” Zon Controller-enheterna hanterar alla MMR:er och rapporterar deras status till Global Moln Controller för varje möteszon. Möteszonerna dupliceras för varje datacentral med exakt samma arkitektur, och vi kan enkelt lägga till fler zoner i farten för ökad kapacitet i varje region. De tre lagren (MMR, Zoom Controller och Global Moln Controller) används för att balansera resurser på olika platser. Om bara två deltagare är i ett möte kan Zoom använda peer-to-peer-anslutningar för utmärkt hastighet och tillförlitlighet. Allt detta gör att Zoom kan upprätthålla tillgängligheten för mötestjänster med 99,9 % drifttid och erbjuda en pålitlig videokonferensupplevelse. ### Zoom Phone Zoom Phone byggdes i molnet och för molnet, med hjälp av de beprövade anpassningarna för ljudkvalitet som redan finns i våra produkter Zoom Meetings och Webbinarier. Zooms arkitektur har redundans och resiliens inbyggt, vilket resulterar i en mycket tillgänglig lösning som kan skalas för att möta behoven hos även den största organisationen. Zoom Phone använder intelligenta transportmekanismer för tillförlitlig anslutning över olika nätverksmiljöer. För media använder det SRTP över UDP när tillgänglig, med sömlös reservväxling till TCP/TLS, tillsammans med adaptiv bithastighet och paketförlustreducering för att bevara ljudkvaliteten under dåliga förhållanden. För anslutning dirigeras samtal till närmaste tillgänglig SIP-zon för att minimera latens, med automatisk failover över datacenter när det behövs.
Diagram showing a Zoom Phone device connected to a primary data center, with a secondary connection to an additional data center for failover events.

Zoom Phones aktiv-aktiv-arkitektur

Zoom har redundanta Session Border Controllers (SBC:er) i var och en av sina datacenter som säkrar klient- och operatörskommunikation. Dessa SBC:er i operatörsklass underlättar enkel Access för ett brett spektrum av organisationer, från de minsta Kunderna till globala företag. Lastbalanserare omdirigerar SIP-baserad kommunikation till Zooms samtalsväxlar för att jämnt fördela samtalsvolymen. Denna fördelning möjliggör en smidig upplevelse för användare, även under hög registrering och upptagna samtalstimmar. Samtalsväxlar utgör den centrala samtalskontrollen i Zoom Phone. Dessa skalbara komponenter stöder inte bara grundläggande PBX-funktionalitet, utan underlättar även telemetridata till Zoom Phone-kontrollpanel och kan aktivera funktioner som att lyfta Zoom Phone-samtal till Zoom-möten.
A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center

aktiv-aktiv-arkitektur för hårdvara- och SIP-zoner som finns i en datacentral

Zoom Workplace-appen använder egenutvecklad logik för att övervaka appens bandbredd, paketförlust, latens och jitter, samtidigt som den även samlar in appens CPU-användning, minne och nätverks-I/O. Den här tekniken övervakar aktivt samtal och gör justeringar i realtid för att övervinna dåliga nätverksförhållanden och ge överlägsen samtalskvalitet och tillförlitlighet för olika nätverksmiljöer och olika enheter. Zoom Phone-kontrollpanelen samlar in data om tjänstekvalitet i realtid och historik, samt användnings- och införandemått, samtalsloggar och mått relaterade till nomadiska nödtjänster. Zoom betygsätter automatiskt varje samtal med en genomsnittlig åsiktspoäng (MOS), vilket gör det möjligt för IT-administratörer att följa prestandan för alla samtal som passerar nätverket och isolera potentiella nätverksrelaterade problem.
### Zoom kontaktcenter I likhet med Zoom Phone hjälper Zoom kontaktcenters aktiv-aktiv-arkitektur till att ge motståndskraft och redundans i hela dess omnikanalmiljö. Genom att bygga vidare på beprövade arkitekturer från Zoom Meetings och telefontjänster integrerar kontaktcenter sömlöst funktioner för realtidskommunikation med webbfunktionalitet och skapar ett intuitivt gränssnitt som gynnar både ditt team av agenter och Kunder. Varje datacentral har två identiska, sammankopplade Session Initiation Protocol (SIP)-zoner. SIP-zoner tillåter att röstsamtal kan göras och tas emot över internet, och varje zon är utrustad med dedikerad hårdvara och tjänster för oberoende hållbarhet. Inom en datacentral fördelar en lastbalanserare samtal jämnt mellan båda SIP-zonerna. Samtal fördelas mellan ett kluster av samtalsväxlar, som ansvarar för olika funktioner såsom samtalsdirigering, uppsättning och nedkoppling. Från samtalsväxlarna ansluts samtal till en SBC inom varje zon, som antingen ansluter till Zooms underliggande nätverk av leverantörer eller till en operatör som tillhandahålls av kunden för PSTN-dirigering tills samtalet når sin slutdestination. SBC:er, lastbalanserare och samtalsväxlar kompletteras med redundant hårdvara i beredskap för robusthet. Röst i Zoom kontaktcenter drar nytta av samma klientanpassning och transportbeteende som Zoom Phone—genom att använda UDP när det är tillgänglig med fallback till TCP/TLS—så att ljudet förblir klart även i nätverk med begränsningar. För video- och digitala kanaler utnyttjar tjänsten Zooms realtidsmediebackbone och molnresiliens för konsekvent kvalitet och failover. #### Cobrowse Zoom kontaktcenters Cobrowse-tjänst körs på infrastruktur som är separat från den centrala Zoom kontaktcenter-tjänsten. När en session börjar upprättar programvaruutvecklingskitet (SDK) en beständig WebSocket-anslutning till Cobrowsing Hubbservern (CHS) för tvåvägskommunikation, med trafik som dirigeras efter geolokalisering till den närmaste tillgängliga datacentralen för att minska latensen. Tjänsten använder en tillståndslös, distribuerad arkitektur med dynamisk lastbalansering mellan CHS-noder för att stödja elastisk skalning över moln-, hybrid- och lokala implementeringsmodeller. För att hjälpa till att upprätthålla sessionens kontinuitet återansluter SDK:n automatiskt till friska CHS-noder om anslutningen avbryts och kan växla över mellan datacenter med minimal störning. Tillsammans med kontinuerlig hälsoövervakning och Zooms bredare strategi för aktiv-aktiv motståndskraft är denna arkitektur utformad för att ge tillförlitlig och skalbar cobrowsing-prestanda för Enterprise-miljöer.

aktiv-aktiv arkitektur för Cobrowse SDK-zoner som finns i en datacentral

## **Zoom Node för hybrid- och lokala distributioner** [Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) är en molnhanterad, hybrid plattform som kopplar ihop dina datacentralresurser med Zooms moln, vilket gör att du kan distribuera Zoom Service Modules (arbetslaster) lokalt och hantera dem via Zoom-webbportal. Två moduler utmärker sig när det gäller motståndskraft: Zoom Meetings Hybrid och Zoom Phone Local Survivability (ZPLS). [Zoom Meetings Hybrid](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) dirigerar realtidsmedia för interna deltagare via din lokala nod medan signalering, admin och policy förblir i Zoom-molnet, och det inkluderar ett lokalt överlevnadsalternativ om Zooms datacenter blir otillgängliga. Interna användare får lågfördröjningsvägar och minskad utgående internettrafik, medan externa deltagare kan gå med via molnet som vanligt. Konton kan också lägga till Recording anslutningsprogram för lokal inspelning när så krävs, med automatisk molnövertagning om lokal kapacitet inte är tillgänglig.
Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud.

Zoom Meetings Hybridmodulen visar hur användare i ett lokalt
nätverk ansluter till Hybrid MMR och sedan kaskaderar till moln.

[Zoom Phone lokal överlevnadsförmåga](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) (ZPLS) håller kärnsamtal tillgängliga på en plats om WAN- eller leverantörsvägen går ned. Telefonerna registreras lokalt, samtal mellan anknytningar fortsätter och, när det är konfigurerat, kan kritiska utgående samtal upprätthållas via en lokal PSTN-väg. När anslutningen återkommer återupptar tjänsten automatiskt normal drift i molnet.
Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability.

Zoom Phone Local Surviability stöder flera återgångsscenarier för PSTN och
anslutning mellan platser vid ett tjänstepåverkande evenemang.

## **Globala distribuerade datacenter och redundans** Zoom har mäklare och kommunikationsservrar distribuerade mellan flera sammankopplade datacentraler över hela världen. Vi utvärderar kontinuerligt våra datacentraler och internetleverantörer (ISP:er) för att optimera prestandan för våra kunder vad gäller bandbredd, latens och isolering för katastrofåterställning. Våra datacentraler är belägna i säkra samlokaliseringsanläggningar som är operatörsneutrala för ISP:er och erbjuder fysisk säkerhet, redundant strömförsörjning och samtidig åtkomst till förstklassiga ISP:er och peeringpartner. Vi har även vissa driftsättningar hos offentliga molnleverantörer där regionala krav eller kapacitetskrav motiverar det. Våra samlokaliseringsanläggningar är byggda med feltolerant arkitektur med full redundans och kapacitet för snabb redundansomkoppling. Zoom lastbalanserar dynamiskt kommunikationsservrarna för att automatiskt flytta nya sessioner till den datacentral som har bäst svarstid. Dessa anläggningar är konstruerade för robusthet även på det fysiska lagret. Varje colocation-anläggning är byggd med N+1-redudans och ett komplett set miljökontroller som är avsedda att hålla anläggningen i drift vid komponentfel och fysiska risker: * Temperatur- och luftfuktighetskontroller * Strömförsörjningssystem som är helt redundanta och dimensionerade för att hantera komponentfel * Robust nödbelysning * Brandskydd * Skydd mot vattenskador I datacentraler ingår redundansmodeller för avbrottsfri kraftförsörjning (UPS) såsom N, N+1 eller 2N, samt generatorredundans med en N+1-design, där underhåll och testning av kraftförsörjningen hanteras av den tillämpliga datacentralleverantören. När Zoom använder AWS som värd för delar av sin molninfrastruktur granskas förekomsten och driften av AWS-kontroller årligen av Zooms säkerhetsteam genom rapporter från externa tjänstegranskare; eventuella avvikelser som identifieras diskuteras med AWS och, när de kan presentera en risk för Zooms system eller data, eskaleras till Zooms ledning.

Zooms kommersiella datacentraler runt om i världen (november 2024)

## **kapacitet** Zoom upprätthåller 50 % överskottskapacitet i alla delar av vår infrastruktur för att möta vår växande affärsverksamhet och kraven vid topplaster. Vi är säkra på vår förmåga att leverera tjänster och skala utifrån våra nuvarande och framtida kundbehov. ## **Businesskontinuitet och katastrofåterställning** Tillförlitlighet under normala förhållanden är bara en del av helheten; lika viktigt är hur plattformen beter sig när något går fel. Störningar — såsom naturkatastrofer, ström- eller anläggningsfel, cyberincidenter, nätverksavbrott och hårdvarufel — är en oundviklig verklighet för alla globala tjänster, och Zooms motståndskraft bygger på hur den förbereder sig för, står emot och återhämtar sig från dessa händelser. Den motståndskraften vilar på fyra distinkta men sammanlänkade lager, som vart och ett verkar vid olika tidpunkter före, under och efter en störning: * **Hög tillgänglighet** — det arkitektoniska lagret som minskar sannolikheten för och konsekvensen av fel innan de inträffar genom att eliminera enstaka felpunkter. * **Business kontinuitet** — det operativa lagret som håller viktiga affärsfunktioner igång när en störning faktiskt inträffar. * **Katastrofåterställning** — återställningslagret som för berörda tekniksystem och tjänster tillbaka till normal drift efter en störande händelse. * **Testning** — valideringslagret som bekräftar att dessa metoder fungerar och lyfter fram lärdomar för kontinuerlig förbättring. Dessa lager bygger på varandra: hög tillgänglighet minskar hur ofta återställning behövs, Business kontinuitet styr vad som fortsätter att vara igång medan det sker, katastrofåterställning återställer det som påverkades och testning validerar helheten. Den arkitektur som beskrivs genom hela detta dokument — aktiva datacentraler på flera platser, geolokaliseringsbaserad dirigering, automatisk failover och N+1-implementering — är den hög tillgänglighet-lagret i praktiken. Avsnitten nedan beskriver de återstående tre. ### Hög tillgänglighet Hög tillgänglighet avser system- och tjänstedesign som är avsedd att stödja kontinuerlig drift och minimal nedtid, och den är utformad in i Zooms system med målet att minimera eller eliminera kritiska felpunkter. Tjänster är utformade för att tåla fullständiga datacentralavbrott, och automatiserade processer flyttar trafik bort från ett påverkat område när ett fel inträffar. Kärnapplikationer distribueras enligt en N+1-standard, så att om en datacentral blir otillgänglig finns tillräcklig kapacitet kvar för att lastbalansera trafiken till de överlevande platserna. Denna designfilosofi omfattar hela uppsättningen system som en kommunikationsplattform är beroende av — redundanta anläggningar, telefoniinfrastruktur, internet- och LAN-anslutning, säkerhetsinfrastruktur, relationsdatabassystem, masslagring, säkerhetskopior, hårdvara samt tillhörande kapacitets- och underhållspraxis — så att fel i en enskild komponent, ett enskilt system eller en enskild anläggning inte leder till tjänstebortfall. ### Business kontinuitet Zooms planering för affärskontinuitet är utformad för att minimera påverkan av störningar på verksamheten, skydda tillgångar och upprätthålla nödvändiga tjänster för Kunder och intressenter. Den identifierar de affärsfunktioner som måste bevaras eller återställas först, de människor, den teknik, de leverantörer och de arbetsplatsresurser som dessa funktioner är beroende av, och den potentiella påverkan om dessa beroenden störs. Detta ger Zoom en strukturerad grund för att samordna respons och återhämtning när den normala driften påverkas, särskilt när flera funktioner eller resurser kräver uppmärksamhet samtidigt. Grunden för denna planering är en Businesskonsekvensanalys (BIA), den systematiska process som Zoom använder för att identifiera och utvärdera de potentiella effekterna av störningar på kritiska affärsfunktioner. Zoom genomför en BIA för kritiska funktioner minst årligen, eller när en kritisk affärsprocess genomgår en betydande förändring. Analysen omfattar fyra nyckelkomponenter: 1. **Identifiering av kritiska affärsfunktioner** — dokumentera de nyckelprocesser som är nödvändiga för Zooms verksamhet och fastställa beroenden och inbördes beroenden mellan dem. 2. **Påverkansbedömning** — utvärdera den potentiella påverkan av störningar på varje funktion, med hänsyn till ekonomisk förlust, operativ nedtid, juridiska och regulatoriska konsekvenser samt skada på anseendet. 3. **Resursbehov** — identifiera den personal, teknik, de anläggningar och tredjepartstjänster som behövs för att stödja återställning, och bedöma deras tillgänglighet och lämplighet. 4. **Prioritering av återställningsinsatser** — sekvensera återställningen av kritiska funktioner utifrån deras påverkan och de fastställda återställningsmålen, så att de mest kritiska funktionerna återställs först. ### Katastrofåterställning Zoom validerar regelbundet sina katastrofåterställningsförmågor genom årliga tester över sina produkter. Företaget upprätthåller en formell, dokumenterad Disaster Recovery Plan (DRP) som definierar rutiner för att återställa kritiska system och tjänster efter en störning, inklusive återställningsstrategier, roller och ansvar samt kommunikationsprotokoll. Zooms DRP är utformad för att hantera olika katastrofscenarier som kan omfatta ett eller flera av följande: strömavbrott, förlust av nätverksanslutning, hårdvarufel, naturkatastrofer och andra störande händelser, upp till och inklusive total anläggningskollaps. Informationssäkerhetsstandarder som styr katastrofåterställning är dokumenterade, godkända, kommunicerade och granskas minst årligen. I stället för att upprätthålla en dedikerad varm återställningsplats för molntjänster förlitar sig Zoom på redundant arkitektur, datacentraler på flera platser och flera molnleverantörer inklusive AWS, OCI och GCP för att stödja kontinuitet. På plattformsnivå skiljer sig återställningsmönstret beroende på tjänstetyp: * **Webbkluster och icke-realtidskommunikation** använder AWS infrastruktur för hög tillgänglighet i en aktiv-aktiv konfiguration över flera regioner, förlitar sig på DNS-poster för att möjliggöra failover mellan datacentraler och omfattar flera komponenter med replikeringsförmåga inom varje datacentral. * **Regionala datacentraler och realtidskommunikation** drivs i en aktiv-aktiv konfiguration över geografiskt utspridda leverantörer på Tier 3-nivå och högre, med redundanta och motståndskraftiga komponenter och anslutning inom varje regional datacentral, olika operatörer som stöder anslutning och failover mellan regioner som kräver återanslutning. Zooms dokumenterade återställningsstrategier inkluderar regionfailover, som flyttar trafik eller tjänster bort från en påverkad region, och rollback via blue-green-driftsättning, som återför tjänster till en tidigare känd fungerande miljö eller distributionsstatus för att återhämta sig från programvaru- eller distributionsrelaterade problem. Dessa strategier mäts mot definierade återställningsmål. Återställningstidmålet (RTO) — den målsatta tiden för att återställa tjänsten efter en störning — har målet under fem minuter. Återställningspunktsmålet (RPO) — den målsatta mängden tolererbar dataförlust — har målet ingen dataförlust, stödd av replikering av molnlagrad data över flera tillgänglighetszoner. Dessa mål vägleder Zooms design och testning snarare än att fungera som tjänstegarantier. Effektiv säkerhetskopiering och återställning av data är en kärnkomponent i detta tillvägagångssätt, som skyddar kritisk information så att den kan återställas vid en störning för att upprätthålla affärskontinuitet. Zoom delar inte externt sin fullständiga katastrofåterställningsplan eller detaljerade testresultat, eftersom dessa material innehåller intern och känslig konfidentiell affärsinformation. Se [Zooms tillitscenter](https://www.zoom.com/en/trust/legal-compliance/) för mer information om offentligt tillgänglig dokumentation. ### Testning Zoom validerar sina återställningsrutiner genom årliga skrivbords- och failover-tester som utförs av tredjepartsrevisorer. Denna testning bekräftar att respons- och återställningsprocesser fungerar som avsett, identifierar brister och stöder kontinuerlig förbättring genom lärdomar. Testning har omfattat ett brett spektrum av produkter och tjänsteområden över plattformen, inklusive Zoom Meetings, Zoom Phone, Zoom kontaktcenter, Zoom Virtual Agent, Zoom Rooms, Zoom Events, whiteboard, reservering av arbetsplats och RTC- och telefoni-gateways, bland annat. Tillsammans med den redundanta aktiv-aktiv-arkitektur som beskrivs genom hela detta dokument är denna lagerindelade metod utformad för att hålla Zooms tjänster tillgängliga och återställningsbara över ett brett spektrum av störande förhållanden. ## **Slutsats** Zooms tillförlitlighet stöds av en lagerindelad arkitektur som kombinerar molnförst tjänstedesign, adaptiv mediarouting, redundant global infrastruktur, kapacitetsplanering och formella rutiner för affärskontinuitet och katastrofåterställning. Över Meetings, Phone, kontaktcenter, Zoom Node, globala datacentraler och relaterade tjänster är Zooms plattform utformad för att stödja konsekvent kommunikation över olika nätverk, regioner, enheter och distributionsmodeller. Samma designprinciper som stödjer daglig tjänstekvalitet stödjer också motståndskraft i stor skala. Aktiv-aktiv-arkitektur, intelligent dirigering, adaptiv transport, redundanta anläggningar, återställningsplanering, säkerhetskopieringsrutiner och regelbunden testning arbetar tillsammans för att hjälpa till att upprätthålla nödvändiga tjänster och stödja återställning när operativa händelser inträffar. För Kunder och IT-team ger detta tillvägagångssätt en plattform utformad för tillförlitlig kommunikation, operativ kontinuitet och hanterbar företagsdriftsättning över UCaaS- och CCaaS-miljöer. *Författad av Jakob Ganschow och 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/sv/adminhornan/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.