> 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/zh-tw/guan-li-yuan-zhuan-qu/architecture-and-design/bcdr-whitepaper.md). # 營運持續與災難復原白皮書 ## **簡介** Zoom 透過單一整合平台，提供以 AI 為先的統一通訊即服務（UCaaS）與聯絡中心即服務（CCaaS）。本文詳細說明支撐 Zoom 一流服務與產品的創新與架構，並解釋我們如何在 UCaaS 與 CCaaS 中，為終端使用者與 IT 提供一致、安全且易於管理的體驗。 ## **從經驗中打造** Zoom 以雲端優先的願景，協助組織擺脫傳統地端系統的成本與複雜性。我們並非在老舊技術堆疊上勉強加掛功能，而是投資於涵蓋用戶端、媒體服務與會議室系統的全堆疊工程，以單一整合平台優化端到端品質、韌性與可用性——並以單一用戶端策略為基礎，在跨平台共用程式碼庫的同時，充分利用各作業系統原生的使用者體驗。這種雲端優先的方法體現在 Zoom Workplace 應用程式中：一個現代化的單一應用程式，讓使用者可集中存取會議、聊天、電話、聯絡中心、活動、網路研討會、會議室、白板、Canvas 等功能。存取權由授權控管，因此 IT 可以開啟或關閉產品與功能，而不必部署零散的獨立安裝程式或管理互相衝突的用戶端版本。對 IT 而言，這種模式可降低負擔——需要購買、上架與修補的伺服器更少；需要維護的客製整合更少；也不再需要整個團隊專職維持地端基礎架構運作。容量、更新與安全性改善都由雲端提供，因此管理員能專注於政策、採用與成果，而非維護工作。 ## 即時媒體架構與韌性以下各節將說明 Zoom 的設計方法，以實現一流的即時媒體體驗。 ### Zoom Meetings、Webinars 與 Events 我們架構的基礎是一個智慧型傳輸層，會根據實際網路狀況與政策選擇最佳路徑。在可用時使用 UDP；在限制較嚴格的環境中，則可無縫回退到 TCP/TLS（包含 HTTPS/443）。螢幕分享會在可行時使用 Reliable UDP，以提供順暢的動作體驗，並在需要時自動回退。當連線至會議、網路研討會或活動時，Zoom Workplace 應用程式會根據地理位置導向最近可用的資源，以將延遲降到最低。在組織政策或效能需求下，流量也可透過專線連結穿越 Zoom 的全球骨幹網路，傳送至不同資料中心。

Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers. — Zoom 會議、網路研討會與 Events 的主動-主動架構與設計概覽。

下一層是反應式服務品質層，會根據即時網路與裝置狀況自我調整。它會監控頻寬、封包遺失、延遲與抖動，同時也會收集本機 CPU 使用率、記憶體與網路 I/O。這些訊號會通知上層採取適當的自適應動作，以維持品質與可靠性。 Zoom 在工作階段層的自訂自適應編解碼器，針對即時效能進行調校。周邊的演算法會持續最佳化畫面更新率與解析度，以符合裝置與網路狀況。為了在條件允許下提供最佳體驗，Zoom 使用多條同時串流，而 Zoom Workplace 應用程式會動態選擇最適合的層級。由於壓縮效率高，即使封包遺失高達約 45% 的情況，工作階段仍可使用；在此情況下，音訊會優先於視訊，以維持對話清晰。多串流方法也會根據每位參與者傳送與接收音訊及視訊的能力來調整頻寬。 Zoom 的分散式會議層採用基於訂閱的切換機制，且不需伺服器端轉碼或混流。傳統服務往往會轉碼並混合串流，增加 CPU 與記憶體負擔；我們的切換方法旨在降低資源使用並有效擴充。參與者會依地理位置導向最近的資料中心，並指派到負載最低的伺服器；當與會者位於同一地點時，則可為了效率而分組至同一伺服器。此架構支援彈性的地端與混合式部署，並為大型企業提供級聯式流量路徑。 Meeting Server 是我們的 MMR（多媒體路由器），每個 MMR 都會分組在一個「Meeting Zone」中。Zone Controller 負責管理所有 MMR，並將其狀態回報給每個 Meeting Zone 的 Global Cloud Controller。每個資料中心都複製相同的 Meeting Zone 架構，我們也能在每個區域中隨時輕鬆新增更多 Zone 以增加容量。這三層（MMR、Zoom Controller 與 Global Cloud Controller）用來平衡不同地點的資源。若會議中只有兩位參與者，Zoom 可使用點對點連線，以獲得極佳的速度與可靠性。所有這些讓 Zoom 能維持會議服務 99.9% 的正常運作時間，並提供可靠的視訊會議體驗。 ### Zoom Phone Zoom Phone 是為雲端而生、並在雲端中打造的，採用我們在 Zoom Meetings 與 Webinars 產品中已證實可行的音訊品質自適應技術。Zoom 的架構內建備援與韌性，因此是一個高可用性的解決方案，能擴充以滿足即使是最大型組織的需求。 Zoom Phone 採用智慧型傳輸機制，以便在各種網路環境中維持可靠連線。在媒體傳輸上，可用時使用 UDP 上的 SRTP，並可無縫回退到 TCP/TLS，搭配自適應位元率與封包遺失緩解機制，即使在不佳條件下也能維持音訊品質。在連線方面，通話會路由到最近可用的 SIP Zone，以將延遲降到最低，且在需要時可跨資料中心自動故障轉移。

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 Phone 的主動-主動架構

Zoom 在其每個資料中心都設有備援的 Session Border Controller（SBC），以保護用戶端與電信商通訊。這些電信等級的 SBC 讓各種規模的組織都能輕鬆存取，從最小型客戶到全球企業皆可。Load Balancer 會將基於 SIP 的通訊重新導向至 Zoom 的 Call Switch，以平均分配通話量。這種分配讓使用者即使在註冊高峰與繁忙通話時段，也能獲得流暢體驗。 Call Switch 是 Zoom Phone 的核心通話控制元件。這些可擴充元件不僅支援基本 PBX 功能，也可將遙測資料提供給 Zoom Phone Dashboard，並啟用將 Zoom Phone 通話升級至 Zoom 會議等功能。

A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center — 部署於資料中心內、具有硬體與 SIP Zone 的主動-主動架構

Zoom Workplace 應用程式運用專有邏輯監控應用程式的頻寬、封包遺失、延遲與抖動，同時也收集應用程式的 CPU 使用率、記憶體與網路 I/O。此技術會主動監控通話，並根據即時調整來克服不良網路條件，為各種網路環境與不同裝置提供更優異的通話品質與可靠性。 Zoom Phone Dashboard 會擷取即時與歷史的服務品質資料，以及使用與採用指標、通話記錄，和與移動式緊急服務相關的指標。Zoom 會自動為每通電話評定 Mean Opinion Score（MOS），讓 IT 管理員能追蹤所有穿越網路之通話的效能，並找出潛在的網路相關問題。
### Zoom Contact Center 與 Zoom Phone 類似，Zoom Contact Center 的主動-主動架構有助於在其全通路環境中提供韌性與備援。建立在 Zoom Meetings 與 Phone 服務的成熟架構之上，Contact Center 可將即時通訊功能與網頁功能無縫整合，打造直覺式介面，使您的客服團隊與客戶皆受益。每個資料中心都有兩個相同且互連的 Session Initiation Protocol（SIP）Zone。SIP Zone 讓語音通話可透過網際網路進行撥打與接聽，而每個 Zone 都配備專用硬體與服務，以維持獨立運作能力。在資料中心內，Load Balancer 會平均分配兩個 SIP Zone 之間的通話。通話會分配到一組 Call Switch，這些元件負責通話路由、建立與拆除等各種功能。通話會從 Call Switch 連接至每個 Zone 內的 SBC，接著 SBC 會連至 Zoom 底層的供應商網路，或由客戶提供的電信業者，以進行 PSTN 路由，直到通話抵達最終目的地。為了提升韌性，SBC、Load Balancer 與 Call Switch 都配有待命中的備援硬體。 Zoom Contact Center 的語音功能受惠於與 Zoom Phone 相同的用戶端自適應與傳輸行為——可用時使用 UDP，並可回退到 TCP/TLS——因此即使在受限網路上，音訊也能保持清晰。對於視訊與數位通道，此服務則運用 Zoom 的即時媒體骨幹與雲端韌性，以維持一致的品質與故障轉移能力。 #### 協同瀏覽 Zoom Contact Center 的協同瀏覽服務運行在與核心 Zoom Contact Center 服務分離的基礎架構上。當工作階段開始時，軟體開發套件（SDK）會與 Cobrowsing Hub Server（CHS）建立持久的 WebSocket 連線，以進行雙向通訊；流量則依地理位置路由到最近可用的資料中心，以降低延遲。此服務採用無狀態的分散式架構，並在 CHS 節點之間進行動態負載平衡，以支援雲端、混合式與地端部署模型中的彈性擴充。為了協助維持工作階段連續性，當連線中斷時，SDK 會自動重新連線到健康的 CHS 節點，並可在跨資料中心故障轉移時將中斷降到最低。結合持續的健康監控與 Zoom 更廣泛的主動-主動韌性方法，此架構旨在為企業環境提供可靠且可擴充的協同瀏覽效能。

## **用於混合式與地端部署的 Zoom Node** [Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) 是一個由雲端管理的混合式平台，可將您的資料中心資源與 Zoom 雲端連結，使您能在地端部署 Zoom Service Modules（工作負載），並透過 Zoom 網頁入口網站進行管理。其中有兩個模組在韌性方面特別突出：Zoom Meetings Hybrid 與 Zoom Phone Local Survivability（ZPLS）。 [Zoom Meetings 混合式](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-meetings-hybrid) 會透過您的本地 Node 將內部參與者的即時媒體進行路由，而信號、管理與政策則保留在 Zoom 雲端中；如果 Zoom 資料中心無法連線，還包含本地持續服務選項。內部使用者可獲得低延遲路徑與較少的網際網路外流流量，而外部參與者則可如常透過雲端加入。若需要，本帳戶也可新增 Recording Connector 進行本地擷取；若本地容量不足，則可自動故障轉移至雲端。

Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud. — Zoom Meetings Hybrid 模組示範本地
網路中的使用者如何連線至 Hybrid MMR，並級聯至雲端。

[Zoom Phone 本地生存能力](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) （ZPLS）可在 WAN 或供應商路徑中斷時，讓站點持續提供核心通話服務。電話會在本地註冊，內部分機通話持續進行，且在設定完成時，重要的外撥通話可透過地端 PSTN 路徑維持。當連線恢復時，服務會自動恢復正常的雲端運作。

Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability. — Zoom Phone Local Surviability 支援多種 PSTN 與
跨站點連線的回復情境，以因應會影響服務的事件。

## **全球分散式資料中心與備援** Zoom 在全球多個互連的資料中心之間分散部署代理程式與通訊伺服器。我們持續評估資料中心與網際網路服務提供者（ISP），以針對頻寬、延遲與災難復原隔離，為客戶最佳化效能。我們的資料中心設置於安全的共置機房，採 ISP 供應商中立設計，並提供實體安全、備援電力，以及同時連接頂級 ISP 與對等互連夥伴的能力。我們也在某些符合區域或容量需求的情況下，使用公有雲供應商進行部署。我們的共置機房採用具故障容忍能力的架構，具備完整備援與快速故障轉移能力。Zoom 會動態平衡通訊伺服器的負載，自動將新工作階段移至回應時間最佳的資料中心。這些設施在實體層面同樣以韌性為目標進行工程設計。每個共置機房都採用 N+1 備援與完整的環境控制系統，旨在讓設施即使在元件故障與實體危害下仍能維持運作： * 溫度與濕度控制 * 完全備援且可因應元件故障的電力系統 * 韌性的緊急照明 * 消防防護 * 防水損保護資料中心包含不斷電系統（UPS）備援模型，例如 N、N+1 或 2N，並採用 N+1 設計的發電機備援，電力維護與測試則由適用的資料中心供應商負責。當 Zoom 使用 AWS 托管其部分雲端基礎架構時，AWS 控制項的存在與運作會由 Zoom 資安團隊每年透過外部服務稽核報告進行審查；若發現任何例外，會與 AWS 討論，且若其對 Zoom 的系統或資料構成風險，則會升級通報 Zoom 管理層。

## **容量** Zoom 在基礎架構的各個面向都維持 50% 的超額容量，以因應業務成長並滿足高峰使用需求。我們有信心依據目前與未來客戶需求提供服務與擴充。 ## **營運持續與災難復原** 在正常條件下的可靠性只是故事的一部分；同樣重要的是，當事情出錯時平台會如何運作。對任何全球性服務而言，自然災害、電力或設施故障、網路攻擊、網路中斷與硬體故障等中斷都不可避免，而 Zoom 的韌性來自於其如何為這些事件做準備、承受並從中恢復。這種韌性建立在四個彼此獨立但相互連結的層次之上，每一層都在中斷之前、期間與之後的不同時間點發揮作用： * **高可用性** — 架構層級，透過消除單點故障，在故障發生前降低其發生機率與影響。 * **營運持續** — 當中斷真的發生時，維持核心業務功能持續運作的作業層。 * **災難復原** — 在破壞性事件後，將受影響的技術系統與服務恢復至正常運作的復原層。 * **測試** — 驗證層，用以確認這些作法是否有效，並找出可持續改善的經驗。這些層次彼此相互建構：高可用性降低需要復原的頻率，營運持續決定中斷發生時哪些服務仍維持運作，災難復原負責還原受影響的部分，而測試則驗證整體機制。本文所描述的架構——主動-主動資料中心、基於地理位置的路由、自動故障轉移與 N+1 部署——在實務上就是高可用性層。以下各節將說明其餘三層。 ### 高可用性高可用性指的是旨在支援持續運作與最短停機時間的系統與服務設計，而 Zoom 已將其工程化地融入系統中，目標是將關鍵故障點降至最低或完全消除。服務的設計可承受完整資料中心停機，而當故障發生時，自動化程序會將流量移離受影響區域。核心應用程式採 N+1 標準部署，因此若某個資料中心無法使用，仍保留足夠容量將流量負載平衡至倖存站點。這種設計理念涵蓋通訊平台所依賴的完整系統集合——備援設施、電話基礎架構、網際網路與 LAN 連線、資安基礎架構、關聯式資料庫系統、大容量儲存、備份、硬體，以及相關的容量管理與維護作法——以確保任何單一元件、系統或設施的故障都不會導致服務中斷。 ### 營運持續 Zoom 的營運持續規劃旨在將中斷對營運的影響降至最低、保護資產，並維持對客戶與利害關係人的核心服務。它會辨識哪些業務功能必須最先保留或恢復、這些功能所依賴的人員、技術、供應商與工作場所資源，以及這些依賴關係若被中斷可能造成的潛在影響。這使 Zoom 在正常營運受影響時，特別是當多項功能或資源同時需要處理時，能有結構化的基礎來協調應變與復原。支撐此規劃的是業務衝擊分析（BIA），這是 Zoom 用來系統性辨識與評估中斷對關鍵業務功能潛在影響的流程。Zoom 至少每年一次，或在關鍵業務流程發生重大變更時，會對關鍵功能執行 BIA。該分析涵蓋四個關鍵構面： 1. **辨識關鍵業務功能** — 文件化 Zoom 營運所需的主要流程，並判定它們之間的依賴與相互依賴關係。 2. **影響評估** — 評估中斷對每項功能的潛在影響，考量財務損失、營運停機、法律與法規影響，以及商譽損害。 3. **資源需求** — 辨識支援復原所需的人員、技術、設施與第三方服務，並評估其可用性與充足性。 4. **復原工作的優先順序** — 根據影響程度與既定復原目標，依序復原關鍵功能，以便最關鍵的功能優先恢復。 ### 災難復原 Zoom 透過跨產品的年度測試，定期驗證其災難復原能力。公司維持正式且有文件記錄的災難復原計畫（DRP），其中定義了在中斷後恢復關鍵系統與服務的程序，包括復原策略、角色與責任，以及通訊協定。Zoom 的 DRP 旨在處理各種災難情境，可能包含以下一項或多項：停電、網路連線中斷、硬體故障、自然災害，以及其他破壞性事件，甚至包括整個設施完全失效。管理災難復原的資訊安全標準均有文件記錄、核准、溝通，並至少每年審查一次。 Zoom 並未為雲端服務維護專用的熱復原站點，而是依賴備援架構、多地點資料中心，以及包含 AWS、OCI 與 GCP 在內的多家雲端供應商來支援營運持續。在平台層級，復原模式會因服務類型而異： * **Web 叢集與非即時通訊** 使用 AWS 的高可用性基礎架構，採多區域主動-主動配置，依賴 DNS 記錄實現資料中心之間的故障轉移，且在每個資料中心內包含多個具備複寫能力的元件。 * **區域資料中心與即時通訊** 在地理分散的 Tier 3 以上供應商之間，以主動-主動配置運作，於每個區域資料中心內具備備援且具韌性的元件與連線，由多元電信業者支援連線，而跨區域故障轉移則需要重新連線。 Zoom 文件化的復原策略包括區域故障轉移，會將流量或服務移離受影響的區域；以及透過藍綠部署進行回復，將服務還原至先前已知良好的環境或部署狀態，以從軟體或部署相關問題中復原。這些策略會依既定復原目標來衡量。復原時間目標（RTO）——即在中斷後恢復服務的目標時間——目標是少於五分鐘。復原點目標（RPO）——即可容忍的資料遺失量目標——目標是零資料遺失，並由儲存在雲端的資料跨多個可用區進行複寫所支援。這些目標用於指引 Zoom 的設計與測試，而非作為服務保證。有效的資料備份與還原是此方法的核心組成部分，可保護關鍵資訊，使其在中斷時能被還原，以維持營運持續。Zoom 不對外分享完整的災難復原計畫或詳細測試結果，因為這些資料包含內部且敏感的機密商業資訊。請參閱 [Zoom 的信任中心](https://www.zoom.com/en/trust/legal-compliance/) 以取得更多公開可取得文件的資訊。 ### 測試 Zoom 透過由第三方稽核員執行的年度桌面演練與故障轉移測試來驗證其復原作法。這些測試確認應變與復原流程能如預期運作、找出缺口，並透過經驗回饋支持持續改善。測試涵蓋平台上廣泛的產品與服務範圍，包括 Zoom Meetings、Zoom Phone、Zoom Contact Center、Zoom Virtual Agent、Zoom Rooms、Zoom Events、Whiteboard、Workspace Reservation，以及 RTC 和 Telephony Gateway 等。結合本文各處所描述的備援主動-主動架構，這種分層方法旨在讓 Zoom 的服務在各種破壞性條件下保持可用並可復原。 ## **結論** Zoom 的可靠性建立在分層架構之上，結合雲端優先的服務設計、自適應媒體路由、備援的全球基礎架構、容量規劃，以及正式的營運持續與災難復原實務。從 Meetings、Phone、Contact Center、Zoom Node、全球資料中心到相關服務，Zoom 平台都被設計成能在多樣的網路、地區、裝置與部署模型中支援一致的通訊體驗。支援日常服務品質的相同設計原則，也支援大規模的韌性。主動-主動架構、智慧型路由、自適應傳輸、備援設施、復原規劃、備份作法與定期測試共同運作，以協助在營運事件發生時維持核心服務並支持復原。對客戶與 IT 團隊而言，這種方法提供了一個為可靠通訊、營運持續性，以及在 UCaaS 與 CCaaS 環境中可管理的企業部署而設計的平台。 *由 Jakob Ganschow 與 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/zh-tw/guan-li-yuan-zhuan-qu/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.