> 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/guan-li-yuan-zhuan-qu/architecture-and-design/bcdr-whitepaper.md).

# 商业版连续性和灾难恢复白皮书

## **简介**

Zoom 通过单一集成平台提供 AI 优先的统一通信即服务 (UCaaS) 和呼叫中心即服务 (CCaaS)。本文档详细介绍了 Zoom 一流服务和产品背后的创新与架构，并说明我们如何在 UCaaS 和 CCaaS 中为最终用户和 IT 提供一致、安全且易于管理的体验。

## **源于经验构建**

Zoom 的云优先愿景帮助组织超越传统企业部署系统的成本与复杂性。我们并未将功能简单叠加到老旧技术栈上，而是在客户端、媒体服务和会议室系统方面投资于全栈工程，以一个统一的平台优化端到端质量、弹性和易用性——以单一客户端战略为基础，使用跨平台的通用代码库，并充分利用每个操作系统的原生用户体验。

这种云优先方法体现在 Zoom Workplace 应用中：这是一个单一、现代化的应用程序，让用户能够集中访问会议、聊天、电话、呼叫中心、事件 & 活动 &直播、网络研讨会、Zoom Rooms、白板、Canvas 等功能。访问权限由许可证控制，因此 IT 可以启用或关闭产品和功能，而无需部署由不同安装程序拼凑而成的方案，或管理相互冲突的客户端版本。

对于 IT 而言，该模式可降低开销——需要购买、上架和修补的服务器更少；需要维护的定制集成更少；也无需专门的整个团队来维持企业部署基础设施运行。容量、更新和安全改进均由云端提供，因此管理员可以专注于策略、采用情况和成果，而非维护工作。

## 实时媒体架构和弹性

以下章节讨论 Zoom 为实现一流实时媒体体验所采用的设计方法。

### Zoom Meetings、网络研讨会和事件 & 活动 &直播

我们架构的基础是一个智能传输层，可根据实际网络状况和策略选择最佳路径。在可用时使用 UDP，在限制更严格的环境中可无缝回退至 TCP/TLS（包括 HTTPS/443）。屏幕共享尽可能使用可靠 UDP 以实现流畅动态效果，并会在必要时自动回退。正在连接会议、网络研讨会或事件 & 活动 &直播时，Zoom Workplace 应用会通过地理位置定位至最近的在线资源，以最大限度地减少延迟。当组织策略或性能要求如此时，流量可通过连接至不同数据中心的专用链路，经由 Zoom 的全球骨干网传输。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FnFxtmNHVYydGwOrYTGFv%2F226B9D5D-5C3B-422D-91F5-A157C60A67BD.png?alt=media&amp;token=ee2ef06d-f83a-490c-9fba-e52f4dbe29b3" alt="Diagram detailing how the Zoom App maintains active-active connectivity to failover data centers, zone controllers, and multi-media routers." width="563"><figcaption><p>Zoom 的会议、网络研讨会和事件 &#x26; 活动 &#x26;直播主动-主动架构及设计概述。</p></figcaption></figure></div>

下一层是响应式服务质量层，可适应实时网络和设备状况。它会监控带宽、数据包丢失、延迟和抖动，还会收集本地 CPU 使用率、内存和网络 I/O。这些信号会为上层提供依据，以采取适当的自适应措施来保持质量和可靠性。

Zoom 在会议层采用定制的自适应编解码器，并针对实时性能进行了调优。周边算法会持续优化帧率和分辨率，以匹配设备和网络状况。为在条件允许时提供尽可能出色的体验，Zoom 使用多个同时流，而 Zoom Workplace 应用会动态选择最合适的层。得益于高效压缩，即使数据包丢失率高达约 45%，会议仍可正常使用；在这种情况下，音频会优先于视频，以保持对话清晰。多流方式还会根据每位参会者发送和接收音视频的能力调整带宽。

Zoom 的分布式会议层采用基于订阅的交换机制，无需服务器端转码或混流。传统服务通常会对流进行转码和混流，从而增加 CPU 和内存开销；我们的交换方法旨在减少资源使用并实现高效扩展。参会者会根据地理位置被路由至最近的数据中心，并分配到负载最低的服务器；当与会者位于同一地点时，可将其归组到同一服务器以提高效率。该架构支持灵活的企业部署和混合部署，并为大型企业提供级联流量路径。

会议服务器是我们的 MMR（多媒体路由器），每个 MMR 都归属在一个“会议区域”中。区域控制器管理所有 MMR，并将每个会议区域的状态报告给全球云控制器。每个数据中心的会议区域均采用完全相同的架构进行复制，我们可以随时轻松添加更多区域，以增加各区域的容量。这三个层级（MMR、Zoom 控制器和全球云控制器）用于平衡不同位置的资源。如果会议中只有两位参会者，Zoom 可以利用点对点连接，提供出色的速度和可靠性。所有这些使 Zoom 能够保持 99.9% 正常运行时间的会议服务可用性，并提供可靠的视频会议体验。

### Zoom Phone

Zoom Phone 在云中构建并专为云而设计，采用了我们 Zoom Meetings 和网络研讨会产品中已有的经验证音频质量自适应技术。Zoom 的架构内置冗余和弹性，从而形成了一个高可用性解决方案，即使是最大的组织需求也能扩展满足。

Zoom Phone 利用智能传输机制，在多样化的网络环境中实现可靠连接。对于媒体，它会在可用时通过 UDP 使用 SRTP，并无缝回退至 TCP/TLS，同时采用自适应比特率和数据包丢失缓解机制，以在恶劣条件下保持音频质量。对于连接，呼叫会路由至最近的在线 SIP 区域以减少延迟，并在需要时自动跨数据中心故障转移。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fc7qphWNnzClbmFTFUBJt%2F39E3A87C-8C89-457C-BDA5-305F26CDFA27.png?alt=media&amp;token=44860c84-cd37-450d-a10e-846c73b8ca48" alt="Diagram showing a Zoom Phone device connected to a primary data center, with a secondary connection to an additional data center for failover events." width="563"><figcaption><p>Zoom Phone 的主动-主动架构</p></figcaption></figure></div>

Zoom 在其每个数据中心都配备了冗余会话边界控制器 (SBC)，以保护客户端和运营商通信。这些运营商级 SBC 可为广泛的组织提供便捷访问，从最小规模的客户到全球企业均涵盖在内。负载均衡器会将基于 SIP 的通信重定向至 Zoom 的呼叫交换机，以均匀分配呼叫量。即使在注册高峰期和呼叫繁忙时段，这种分配也能为用户提供流畅体验。

呼叫交换机是 Zoom Phone 的核心呼叫控制组件。这些可扩展组件不仅支持基本 PBX 功能，还可将遥测数据传送至 Zoom Phone 仪表板，并启用将 Zoom Phone 呼叫升级为 Zoom 会议等功能。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FzpgEaRrGK5oT6NQfmFRp%2FB9547F0B-E921-4EFD-B16D-B03FD320F31B.png?alt=media&amp;token=e10984d8-d5e4-4ee2-a9e2-82e612353d5f" alt="A diagram showing the active-active architecture for hardware and SIP zones hosted within a data center" width="563"><figcaption><p>数据中心内托管的硬件和 SIP 区域的主动-主动架构</p></figcaption></figure></div>

Zoom Workplace 应用利用专有逻辑监控应用的带宽、数据包丢失、延迟和抖动，同时还会收集应用的 CPU 使用率、内存和网络 I/O。该技术会主动监控呼叫并进行实时调整，以克服不良网络状况，从而为各种网络环境和不同设备提供卓越的呼叫质量和可靠性。

Zoom Phone 仪表板可采集实时和历史服务质量数据，以及使用情况和采用指标、呼叫日志，以及与游牧紧急服务相关的指标。Zoom 会使用平均意见得分 (MOS) 自动为每个呼叫评分，使 IT 管理员能够跟踪所有穿越网络的呼叫性能，并识别潜在的网络相关问题。<br>

### Zoom 呼叫中心

与 Zoom Phone 类似，Zoom 呼叫中心的主动-主动架构有助于在其全渠道环境中提供弹性和冗余。呼叫中心以 Zoom Meetings 和 Phone 服务中经过验证的架构为基础，无缝集成实时通信功能与 Web 功能，创建直观的界面，使您的客服人员团队和客户都能受益。

每个数据中心均设有两个相同且互连的会话发起协议 (SIP) 区域。SIP 区域支持通过互联网拨打和接听语音呼叫，每个区域均配备专用硬件和服务，以实现独立持续运行。在一个数据中心内，负载均衡器会在两个 SIP 区域之间均匀分配呼叫。呼叫会分配给由呼叫交换机组成的集群，这些交换机负责呼叫路由、建立和拆除等各种功能。

呼叫从呼叫交换机连接至每个区域内的 SBC，SBC 随后连接至 Zoom 的底层供应商网络或客户提供的运营商，以进行 PSTN 路由，直至呼叫到达最终目的地。SBC、负载均衡器和呼叫交换机均配有处于待命状态的冗余硬件，以提供弹性。

Zoom 呼叫中心中的语音与 Zoom Phone 一样，受益于相同的客户端自适应和传输行为——在可用时使用 UDP，并回退至 TCP/TLS——因此即使在受限网络中，音频仍能保持清晰。对于视频和数字频道，该服务利用 Zoom 的实时媒体骨干网和云弹性来实现一致的质量和故障转移。

#### Cobrowse

Zoom 呼叫中心的 Cobrowse 服务运行在独立于核心 Zoom 呼叫中心服务的基础设施上。会议开始时，软件开发工具包 (SDK) 会建立与协同浏览中心服务器 (CHS) 的持久 WebSocket 连接，以进行双向通信；流量会按地理位置路由至最近的在线数据中心，以降低延迟。该服务采用无状态分布式架构，并在 CHS 节点之间进行动态负载均衡，以支持跨云、混合和企业部署模型的弹性扩展。

为帮助保持会议连续性，如果连接中断，SDK 会自动重新连接至正常的 CHS 节点，并可跨数据中心进行故障转移，从而将中断降至最低。结合持续健康监控和 Zoom 更广泛的主动-主动弹性方法，该架构旨在为企业环境提供可靠、可扩展的协同浏览性能。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FqgrjZ7zNepHGpbyeVtdB%2F2bbf10_uubksQ_iRI6klG25EenQ5w_260403-Cobrowse-SDK-Diagram-1-v2.png?alt=media&amp;token=a734884a-1888-47f3-a03f-f7d896eda153" alt="" width="563"><figcaption><p>数据中心内托管的 Cobrowse SDK 区域的主动-主动架构</p></figcaption></figure></div>

## **用于混合及企业部署的 Zoom Node**

[Zoom Node](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer) 是一个由云管理的混合平台，可将您的数据中心资源与 Zoom 云相连，使您能够在企业部署环境中部署 Zoom 服务模块（工作负载），并通过 Zoom Web门户进行管理。两个模块在弹性方面尤为突出：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 数据中心无法访问，它还提供本地持续运行选项。内部用户可获得低延迟路径并减少互联网出口流量，而外部参会者仍可像往常一样通过云加入。账户还可以在需要时添加录制连接器进行本地录制；如果本地容量不可用，则会自动故障转移至云端。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FC0GcdeoEhnCKSkpoLPeD%2FC5C3B116-A2C7-46B9-963B-5BDA9FCAFB8B.png?alt=media&amp;token=751a33a1-7c01-4ed3-b6f0-81a036a0887c" alt="Zoom Meetings Hybrid Module shows how users in a local network connect to the Hybrid MMR, cascading to the cloud." width="563"><figcaption><p>Zoom Meetings Hybrid 模块展示了本地<br>网络中的用户如何连接至 Hybrid MMR，并级联至云端。</p></figcaption></figure></div>

[Zoom Phone 本地生存能力](https://library.zoom.com/advanced-enterprise-services/zoom-node/zoom-node-explainer/zoom-phone-local-survivability) (ZPLS) 可在 WAN 或供应商路径中断时，保持站点的核心呼叫功能在线。电话会在本地注册，内部扩展呼叫将继续进行；在完成配置后，关键外拨通话可通过企业部署 PSTN 路径维持。当连接恢复后，服务会自动恢复正常云端运行。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FUsoAHP6CgWryBUz2JjOz%2FC3998DFD-40AC-4CD0-A76D-32AC5898BE41.png?alt=media&amp;token=7e0b4233-6ab2-4409-801f-961728bb6814" alt="Diagram showing how the ZPLS module supports PSTN, intra-site, and cross-site survivability." width="563"><figcaption><p>发生影响服务的事件时，Zoom Phone Local Survivability 支持针对 PSTN 和<br>跨站点连接的多种故障恢复方案。</p></figcaption></figure></div>

## **全球分布式数据中心和冗余**

Zoom 的代理服务器和通信服务器分布在全球多个互连的数据中心中。我们持续评估数据中心和互联网服务提供商 (ISP)，以针对带宽、延迟和灾难恢复隔离性优化客户体验。我们的数据中心位于安全的托管设施中，这些设施对 ISP 运营商保持中立，并提供物理安全、冗余供电以及对顶级 ISP 和对等合作伙伴的同时访问。我们还会在区域或容量要求需要时，在公共云提供商上进行特定部署。我们的托管设施采用具备完全冗余和快速故障转移能力的容错架构构建。Zoom 会动态地对通信服务器进行负载均衡，自动将新会议移至响应时间最佳的数据中心。

这些设施在物理层面也经过弹性工程设计。每个托管设施均采用 N+1 冗余模式构建，并具备一整套环境控制措施，旨在确保设施在组件故障和物理风险发生期间保持运行：

* 温度和湿度控制
* 完全冗余且能够适应组件故障的电力系统
* 具备弹性的应急照明
* 消防保护
* 防水损保护

数据中心包括不间断电源 (UPS) 冗余模式，例如 N、N+1 或 2N，以及采用 N+1 设计的发电机冗余；电力维护和测试由相应的数据中心提供商负责。在 Zoom 使用 AWS 托管部分云基础设施的情况下，Zoom 安全团队会通过外部服务审计师报告，每年审查 AWS 控制措施的存在性和运行情况；发现的任何例外情况都会与 AWS 讨论，若其对 Zoom 的系统或数据构成风险，则会升级至 Zoom 管理层。

<div data-with-frame="true"><figure><img src="https://2325962437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FI74U4hZkRltHhURZmGZz%2FDB57E664-C00F-4E57-B8CD-A2A98C9FBBFD.png?alt=media&amp;token=4f3a6c81-c583-4f68-9d65-3e0443d2d9eb" alt="" width="563"><figcaption><p>Zoom 全球商业数据中心位置（2024 年 11 月）</p></figcaption></figure></div>

## **容量**

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 记录实现数据中心之间的故障转移，并在每个数据中心内包含具有复制能力的多个组件。
* **区域数据中心和实时通信** 在地理上分散的三级及以上提供商之间采用主动-主动配置，每个区域数据中心内部都具有冗余且具备弹性的组件和连接，由多样化运营商支持连接；区域之间的故障转移需要重新连接。

Zoom 已记录的恢复策略包括区域故障转移，即将流量或服务从受影响区域转移出去；以及通过蓝绿部署进行回滚，即将服务恢复至先前已知正常的环境或部署状态，以从软件或部署相关问题中恢复。

这些策略根据既定恢复目标进行衡量。恢复时间目标 (RTO)——中断后恢复服务的目标时间——设定为少于五分钟。恢复点目标 (RPO)——可容忍的数据丢失目标量——设定为零数据丢失，并通过在多个可用区之间复制云存储数据来支持。这些目标用于指导 Zoom 的设计和测试，而非作为服务保证。

有效的数据备份和恢复是此方法的核心组成部分，可保护关键信息，以便在发生中断时恢复，从而维持业务连续性。Zoom 不会对外共享其完整的灾难恢复计划或详细测试结果，因为这些材料包含内部及敏感的机密商业信息。请参阅 [Zoom 的信任中心](https://www.zoom.com/en/trust/legal-compliance/) 以了解有关公开文档的更多信息。&#x20;

### 测试

Zoom 通过由第三方审计师执行的年度桌面演练和故障转移测试，验证其恢复实践。这些测试确认响应和恢复流程按预期运行，发现缺口，并通过经验教训支持持续改进。测试涵盖了整个平台中的广泛产品和服务领域，包括 Zoom Meetings、Zoom Phone、Zoom 呼叫中心、Zoom Virtual Agent、Zoom Rooms、Zoom Events、白板、工作区预约以及 RTC 和电话通讯网关等。结合本文档中所述的冗余主动-主动架构，这种分层方法旨在使 Zoom 的服务在各种广泛的破坏性条件下保持可用和可恢复。

## **结论**

Zoom 的可靠性由分层架构支持，该架构结合了云优先服务设计、自适应媒体路由、冗余全球基础设施、容量规划以及正式的业务连续性和灾难恢复实践。Zoom 的平台涵盖会议、电话、呼叫中心、Zoom Node、全球数据中心和相关服务，旨在支持跨不同网络、区域、设备和部署模型的一致通信。

支持日常服务质量的相同设计原则，也支持大规模弹性。主动-主动架构、智能路由、自适应传输、冗余设施、恢复规划、备份实践和定期测试共同协作，以帮助维持关键服务，并在发生运营事件时支持恢复。

对于客户和 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/guan-li-yuan-zhuan-qu/architecture-and-design/bcdr-whitepaper.md?ask=<question>&goal=<user_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.