> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# BYOC FAQ

> 有关 ClickHouse 自备 Cloud (BYOC) 的常见问题

<div id="faq">
  ## FAQ
</div>

<div id="onboarding-and-provisioning">
  ### 引导与预配
</div>

<Accordion title="如何开始使用 BYOC？">
  请通过[联系表单](https://clickhouse.com/cloud/bring-your-own-cloud)联系 ClickHouse，我们的团队将为您的组织启用 BYOC。随后，准备一个专用云账户 (AWS 账户、GCP 项目或 Azure 订阅) ，并按照[标准引导指南](/zh/products/bring-your-own-cloud/onboarding/standard)操作。我们强烈建议使用仅用于 BYOC 的专用账户、项目或订阅。
</Accordion>

<Accordion title="基础设施预配需要多长时间？常见的卡住原因有哪些？">
  整个过程预计约需 45–90 分钟。时间跨度较大，是因为大部分时间都用于等待云提供商预配资源 (Kubernetes 集群、负载均衡器和网络组件) ；每次执行所需时间并不固定，且不受 ClickHouse 控制。预配停滞时，最常见的原因通常与账户有关：

  * 在应用 CloudFormation 模板或 Terraform 模块前对其进行了修改——例如添加 `PermissionsBoundary`，或为符合命名规范而重命名 IAM 角色 (在 AWS 上，请保留默认的 `ClickHouseManagementRole` 名称，除非 ClickHouse 已明确批准使用其他名称) 。请按原样应用这些文件——支持的自定义项会以参数形式提供，其他任何更改均需先获得 ClickHouse 批准。
  * 组织级策略 (AWS SCP、GCP 组织策略，例如 `iam.allowedPolicyMemberDomains`，或限制角色分配的 Azure 策略) 阻止角色承担或 IAM 绑定。
  * 引导角色的外部 ID 不匹配 (请参阅下方关于外部 ID 的问题) 。
  * 账户配额限制 (例如 AWS 上的 Elastic IP 或 VPC) 。

  预配会自动重试，并会在解决根本问题后自动恢复。如果基础设施卡住超过数小时，请联系支持团队。
</Accordion>

<Accordion title="引导模板中的外部 ID 应使用什么值？">
  开始引导时，ClickHouse Cloud 控制台会为您的 AWS 账户生成外部 ID，并在 CloudFormation 链接中预填该值 (`ExternalID` 参数) ；如果使用 Terraform，请将相同的值作为 `external_id` 传入。同一 AWS 账户中的所有 BYOC 基础设施共享相同的外部 ID。请勿自行指定值：它必须与 ClickHouse 自动化流程预期的值相匹配，否则无法承担跨账户角色，预配将失败。有关详细信息，请参阅 [AWS 外部 ID](/zh/products/bring-your-own-cloud/onboarding/standard#aws-external-id)。
</Accordion>

<Accordion title="为什么我的外部 ID 是 emptyid？">
  在引入外部 ID 之前完成引导的 BYOC 基础设施，会使用占位符值 `emptyid` 以保持向后兼容性。当您在已有旧版部署的 AWS 账户中添加新基础设施时，控制台会重复使用此占位符，以确保该账户中的所有基础设施保持一致的信任配置。如果您想切换为唯一的外部 ID，请联系 ClickHouse 支持团队。
</Accordion>

<Accordion title="BYOC 可以使用现有 VPC 吗？共享 VPC 呢？">
  在 AWS 和 GCP 上，您可以部署到与 BYOC 基础设施位于**同一**账户或项目中的现有 VPC。请参阅 [AWS](/zh/products/bring-your-own-cloud/onboarding/customization-aws) 和 [GCP](/zh/products/bring-your-own-cloud/onboarding/customization-gcp) 自定义指南。在 GCP 上，还支持来自独立宿主项目的**共享 VPC**：[引导模块](https://github.com/ClickHouse/terraform-byoc-onboarding/tree/main/modules/gcp)可直接接受宿主项目和子网——有关设置和前置条件，请参阅其“共享 VPC”部分。Azure 的自带 VNet 支持即将推出。

  在 AWS 上，不支持来自其他账户的共享子网 (AWS RAM) ——请改用通过 VPC peering 或 PrivateLink 连接到现有网络的专用账户。请注意，使用客户管理的 VPC 时，默认仅启用私网负载均衡器 (请参阅[配置](/zh/products/bring-your-own-cloud/configuration/configurations)) 。
</Accordion>

<Accordion title="可以将 BYOC 安装到现有 Kubernetes 集群中吗？">
  不可以。Kubernetes 集群 (EKS、GKE 或 AKS) 由 ClickHouse 创建并完全管理。这是确保 ClickHouse 能够可靠运营平台并持续保持其更新所必需的。
</Accordion>

<Accordion title="我们能否在 BYOC 集群或云账户中运行自己的工作负载？">
  在云账户中：可以，但共置资源始终会在一定程度上受到 ClickHouse 权限的影响——在 AWS 上，大多数写入权限都按标签和前缀限定 (由 ClickHouse 预配的资源带有 `clickhouse-byoc=true`) ，但少量 EC2 操作无法按标签限定；在 GCP 和 Azure 上，引导配置身份拥有项目级或订阅级权限。请将您的资源与 ClickHouse 预配的资源隔离，并优先在每个云平台使用专用账户、项目或订阅——这仍是我们的强烈建议。

  在 Kubernetes 集群中：可以，但有一定限制——请使用自己的节点组，并配置污点和容忍；避开由 ClickHouse 管理的命名空间；也不要安装集群级准入控制器或策略引擎，因为它们可能会阻碍 ClickHouse 组件的协调。请先向支持团队说明您的计划，以便我们确认不会产生冲突。
</Accordion>

<div id="compute">
  ### 计算资源与扩缩容
</div>

<Accordion title="我可以在同一 BYOC 基础设施中创建多个服务吗？">
  可以。对于每个云账户/项目/订阅与区域的组合，基础设施 (包括 Kubernetes 集群) 只需预配一次，您在该区域创建的所有服务都会共享该基础设施。
</Accordion>

<Accordion title="BYOC 支持哪些区域？">
  [支持的区域](/zh/products/cloud/reference/supported-regions)文档中列出的所有**公共区域**均可用于 BYOC 部署。BYOC 会跨三个可用区进行预配，因此可用区少于三个的区域以及 AWS Local Zones 均不受支持。如果您需要的区域未列出，请联系您的 ClickHouse 代表了解可用性。
</Accordion>

<Accordion title="是否存在资源开销？运行 ClickHouse 实例以外的服务需要哪些资源？">
  除 ClickHouse 实例本身 (ClickHouse 服务器和 ClickHouse Keeper) 外，我们还会运行 `clickhouse-operator`、集群自动扩缩器、Istio 和监控栈等支持服务。

  这些共享组件的资源消耗相对稳定，不会随 ClickHouse 服务的数量或规模线性增长。作为粗略参考，运行这些工作负载的专用系统节点组总计约需 48 个 vCPU 和 192 GB 内存；例如在 AWS 上，大致相当于六个 `2xlarge` 实例。此外，每个仓库都会运行一个专用的三节点 ClickHouse Keeper ensemble，由该仓库中的所有服务共享。有关详细信息，请参阅[成本模型](/zh/products/bring-your-own-cloud/reference/cost-model-aws)。
</Accordion>

<Accordion title="BYOC 支持自动扩缩容吗？">
  服务级别的 (纵向) 自动扩缩容已列入路线图。目前可用的功能包括：通过控制台手动进行纵向和横向扩缩容、针对可预测负载模式的定时扩缩容、针对间歇性工作负载的自动闲置和唤醒，以及基础设施级别的自动节点组扩缩容——您无需自行管理节点。ClickHouse Keeper 由 ClickHouse 监控并进行扩缩容。
</Accordion>

<Accordion title="BYOC 使用哪些实例类型？我们可以更改实例系列吗？">
  BYOC 使用一组经过筛选的节点组，而非任意实例类型。工作负载节点组 (ClickHouse 服务器和 Keeper) 默认使用基于 ARM 的内存优化型实例 (AWS 上为 Graviton) ，而系统节点组通常使用 x86 实例。可通过支持请求预配不同的实例系列、CPU 与内存配比或架构；不支持竞价实例。请参阅[配置](/zh/products/bring-your-own-cloud/configuration/configurations)。
</Accordion>

<Accordion title="我们能否运行非常小的副本以降低成本？">
  每个副本均以一个 pod 的形式运行在独立节点上——节点大小与副本大小相匹配，节点按需预配，且绝不会将多个副本部署到同一节点上。因此，非常小的副本效率较低：更大比例的硬件资源会用于开销，网络和磁盘带宽也会随实例大小而变化。低于控制台所提供规格的大小需通过支持提交定制请求。
</Accordion>

<Accordion title="我们可以将摄取和查询工作负载分开吗？">
  可以。BYOC 支持仓库 (计算资源分离) ：多个服务共享相同的数据，因此您可以将部分服务专用于摄取，其他服务专用于查询。
</Accordion>

<div id="network-and-security">
  ### 网络与安全
</div>

<Accordion title="我们能否限制或撤销安装期间授予的权限？">
  在 AWS 和 GCP 上，您可以从一开始就缩减授权范围：引导制品支持参数配置，因此在使用自有 VPC 时，您可以不授予管理 VPC 网络拓扑的权限 (CloudFormation 中的 `IncludeVPCWritePermissions`、Terraform 模块中的 `include_vpc_write_permissions`) 。在 GCP 上，这仅会缩小拓扑管理的权限范围——ClickHouse 仍保留对其在 VPC 内拥有的网络资源的写入权限，例如 Private Service Connect NAT 子网、服务附件和入口地址。在 AWS 上，您还可以——目前处于私有预览阶段，需通过支持团队启用——自行管理 IAM 角色 (`IncludeIAMWritePermissions=false`，请参阅[客户管理的 IAM 角色](/zh/products/bring-your-own-cloud/onboarding/customization-aws)) ；跨账户角色则通过外部 ID 防范混淆代理访问。在 Azure 上，引导模块目前授予固定的订阅范围角色，且不提供范围限定参数。对于所有云平台，某些权限仅为特定功能所需；如果您永远不会使用这些功能，则可移除这些权限——如需将权限范围缩小至制品提供的范围以外，请联系支持团队。

  完成预配后，请勿单方面从管理身份中移除权限：ClickHouse 会持续协调基础设施，缺少权限会导致预配、升级和支持工作受阻。若要更改已授予的权限或完全退役，请与支持团队协调 (请参阅下方有关退役的问题) 。
</Accordion>

<Accordion title="ClickHouse 在我们的云账户中究竟能做什么？我们的安全团队能否审核这些权限？">
  [权限参考](/zh/products/bring-your-own-cloud/reference/privilege)概述了 AWS、GCP 和 Azure 中每个角色和身份及其用途。对于引导 (bootstrap) 身份，确切的策略范围由已发布的制品定义——[CloudFormation 模板](https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/cf-templates/byoc_v2.yaml)和[Terraform 模块](https://github.com/ClickHouse/terraform-byoc-onboarding)——您的安全团队可直接审核。ClickHouse 在引导后创建的其他身份 (控制器角色、服务账户和托管身份) 均在权限参考中按云服务商说明；由于它们位于您的账户中，您可以在云控制台中检查其实际策略，并在 CloudTrail 或 GCP/Azure 的对应服务中查看其创建和使用情况。在 AWS 上，管理角色的大多数写入权限都通过资源标签和名称前缀 (如 `clickhouse-cloud-*`) 限定范围，因此通常无法修改并非由其创建的资源 (少量 EC2 操作无法按标签限定范围) ；并且它**没有对您的数据存储桶的对象级访问权限**——对象访问仅限于权限范围限定为 ClickHouse 工作负载的集群内身份。在 GCP 和 Azure 上，引导身份则拥有项目或订阅范围的权限——这也是强烈建议使用专用项目或订阅的原因之一。读取权限范围更广，因为持续协调需要这些权限。
</Accordion>

<Accordion title="ClickHouse 员工可以访问我们的环境和数据吗？">
  默认情况下，无法访问您的数据。为进行故障排查，工程师必须经过内部即时处理流程；访问具有时限、基于证书、仅限于 `system.*` 表 (不包括客户数据表) 、会被记录并由我们的安全团队审计。ClickHouse 工程师运行的任何查询都会显示在您自己的 `system.query_log` 中。对于基础设施诊断，同样需经审批的处理流程还可授予通过 Tailscale 访问 Kubernetes API server 和集群内监控栈的限时权限。有关数据访问模型，请参阅 [ClickHouse data access](/zh/products/bring-your-own-cloud/reference/clickhouse-data-access)；有关连接模型，请参阅[网络安全](/zh/products/bring-your-own-cloud/reference/network-security)。
</Accordion>

<Accordion title="您是否考虑过未来让 ClickHouse 工程师为故障排查访问客户基础设施时采用的安全控制措施？">
  是的。我们的路线图中计划实现一种由客户控制的机制，使客户能够批准工程师访问集群。目前，工程师必须经过内部处理流程，才能获得对集群的即时访问权限。此过程会被记录并由我们的安全团队审计。
</Accordion>

<Accordion title="哪些数据会离开我们的账户？">
  仅有运营元数据：服务和备份状态事件、用于计费的使用指标以及告警通知。您的数据、备份、日志和监控数据均保留在您的账户中。有关完整的出站流量列表，请参阅[网络安全](/zh/products/bring-your-own-cloud/reference/network-security)。
</Accordion>

<Accordion title="ClickHouse 控制平面如何访问我们账户中的 Kubernetes API？是否必须使用 Tailscale？">
  默认情况下，Kubernetes API 端点为公网端点，但仅允许来自 ClickHouse NAT IP 地址的访问。使用此默认设置时，请勿移除 ClickHouse 允许列表条目，因为控制平面需要这些条目来管理集群。也可在与 ClickHouse 团队协调后，将端点切换为仅私网访问：通过 Tailscale (仅出站，也用于故障排查访问) ，或者在 AWS 上通过 VPC Lattice (私有预览) ——请参阅[配置](/zh/products/bring-your-own-cloud/configuration/configurations)。请注意，这仅适用于 Kubernetes API：云提供商 API 调用 (例如 AWS 上的 EKS 和 EC2) 通过跨账户角色承担从 ClickHouse Cloud 网络发起，绝不能经由 Tailscale 路由——请参阅[云提供商 API 与 Kubernetes API](/zh/products/bring-your-own-cloud/reference/network-security#cloud-api-vs-kubernetes-api)。
</Accordion>

<Accordion title="BYOC 网络与对象存储之间如何通信？">
  在 AWS 上，您的 Customer BYOC VPC 与 S3 之间的流量通过 AWS S3 API 使用 HTTPS (端口 443) 传输表数据、备份和日志。该流量经由 S3 网关 VPC 端点，因此始终位于 AWS 网络内，不经过公网，也不会产生 NAT 网关费用。在 GCP 上，访问 Google API 同样使用 Private Google Access。在 Azure 上，数据存储在您的订阅中的 Azure Blob 存储账户内。
</Accordion>

<Accordion title="数据位于我们自己的存储桶中，能否直接读取或修改？">
  不能。表数据 blob 采用共享布局存储，不存在按表划分的路径，因此无法将对象归属到特定表，任何直接修改都可能导致服务损坏。切勿直接修改存储桶内容；如怀疑存在问题，请提交支持工单。
</Accordion>

<Accordion title="客户端和集群通信使用哪些端口？">
  客户端连接终止于负载均衡器的 TLS 端口：**8443** (HTTPS 接口) 和 **9440** (通过 TLS 的原生协议) ；端口 443 也会路由至 HTTPS 接口。MySQL 接口 (端口 3306) 目前未在 BYOC 中暴露，已列入路线图 (请参阅[概述](/zh/products/cloud/guides/infrastructure/deployment-options/byoc/overview)) 。

  在网络内部，集群内部通信使用端口 9000 上的原生协议、端口 8123 上的 HTTP，以及用于复制和分布式查询的端口 9009 上的服务器间通信。这些内部端口和 ClickHouse Keeper 端口绝不会暴露在任何负载均衡器上。
</Accordion>

<Accordion title="我们的服务端点是否暴露在公网？能否改为仅私网访问？">
  对于 ClickHouse 管理的 VPC，默认情况下，每个服务都配备一个受 IP 访问列表保护的公网负载均衡器；此外，还可在 ClickHouse Cloud 控制台中启用私网负载均衡器，供您的网络及其对等网络访问 (请参阅[负载均衡器](/zh/products/bring-your-own-cloud/configuration/configurations#load-balancers)) 。对于客户管理的 VPC，默认设置则相反，仅启用私网负载均衡器。IP 过滤在入口代理层实施，因此负载均衡器端口在扫描中可能显示为开放，但来自未列出来源的连接会被拒绝。待不再有任何依赖项后，可完全禁用公网端点。控制台的[连接方式选择器](/zh/products/bring-your-own-cloud/configuration/connect#connection-via)会显示服务已启用的每条连接路径对应的端点。请参阅[连接性](/zh/products/bring-your-own-cloud/configuration/connect)。
</Accordion>

<Accordion title="我们可以使用自己的 DNS 域名或自带 TLS 证书吗？">
  目前还不支持。服务端点在 `clickhouse-byoc.com` 域名下预配，并使用由 ClickHouse 管理的证书。
</Accordion>

<Accordion title="如何设置 AWS PrivateLink、GCP Private Service Connect 或 Azure Private Link？">
  请遵循 [AWS](/zh/products/bring-your-own-cloud/onboarding/network-aws)、[GCP](/zh/products/bring-your-own-cloud/onboarding/network-gcp) 和 [Azure](/zh/products/bring-your-own-cloud/onboarding/network-azure) 的网络设置指南。以下两点经常被忽略：端点允许列表是**按服务**设置的，因此每个新服务都必须再次注册端点；如果您运行自己的 DNS，则必须自行配置私有端点名称的 DNS 解析。设置完成后，使用控制台的[连接方式选择器](/zh/products/bring-your-own-cloud/configuration/connect#connection-via)复制正确的私有端点主机名。
</Accordion>

<Accordion title="能否通过 PrivateLink 从其他 AWS 区域连接？">
  可以，但控制台中的 **Enable private link** 开关仅适用于同区域消费者——AWS 默认禁用端点服务的跨区域访问，且 ClickHouse 控制台不管理此设置。由于端点服务位于您的 BYOC 账户中，需由您自行启用：在 AWS 控制台中，将消费者区域添加到端点服务的 **Supported regions** 列表，然后在消费者端使用跨区域选项创建端点。ClickHouse 不会更改或重置这些配置值。具体步骤请参阅 [PrivateLink 设置指南](/zh/products/bring-your-own-cloud/onboarding/network-aws#setup-privatelink)；需适用 AWS 跨区域数据传输费率。
</Accordion>

<Accordion title="是否有需要在防火墙或出站规则中允许的端点列表？">
  没有统一发布的端点列表。除通过私网访问云提供商 API 外，集群还需要可用的出站互联网访问 (直接访问或通过 NAT) ——请参阅[网络连接要求](/zh/products/bring-your-own-cloud/onboarding/customization-aws#ensure-network-connectivity)。如果您的网络策略要求提供明确清单，请联系支持团队审核您的配置。
</Accordion>

<Accordion title="我们的安全工具在 BYOC 集群中标记了特权容器或主机挂载——这是预期行为吗？">
  某些平台组件确实需要提升的权限或访问主机文件系统，例如 EBS CSI 驱动程序、节点配置作业和 Prometheus 节点 exporter (会读取 `/proc` 和 `/sys`) 。如果扫描器发现问题，请与支持团队分享——我们将确认每项发现是设计如此，还是需要采取措施。
</Accordion>

<Accordion title="是否支持客户管理的加密密钥 (CMEK)？">
  BYOC 目前尚不支持。静态数据使用云提供商管理的密钥加密。有关当前计划功能的列表，请参阅[概述](/zh/products/cloud/guides/infrastructure/deployment-options/byoc/overview)。
</Accordion>

<div id="upgrades-and-maintenance">
  ### 升级与维护
</div>

<Accordion title="ClickHouse 版本如何升级？我可以决定维护频率吗？">
  升级方式与 ClickHouse Cloud 相同：服务会加入发布渠道 (快速、常规、慢速) ，并遵循预定的维护窗口——请联系支持团队进行配置。更新频率至少为每周一次。升级采用滚动方式，逐个副本进行 (先创建后删除) ，因此不会导致整个服务停机。请参阅[操作](/zh/products/bring-your-own-cloud/configuration/operations)。
</Accordion>

<Accordion title="谁负责 Kubernetes 升级？预期会有什么影响？">
  ClickHouse 会在提供商终止支持日期之前主动执行 Kubernetes 升级，并通过支持团队与您协调维护窗口。控制平面升级对您无感；节点组升级会以先创建后删除的方式逐个滚动升级节点，因此 pod (容器组) 重启时，可能会出现短暂的连接重置，但不会丢失数据。请参阅[操作](/zh/products/bring-your-own-cloud/configuration/operations)。
</Accordion>

<div id="backups-and-disaster-recovery">
  ### 备份和灾难恢复
</div>

<Accordion title="备份存储在哪里？">
  备份存储在您自己的云账户中的对象存储内，绝不会离开您的环境。您可以配置备份计划和保留期限；如需调整，请联系支持团队。
</Accordion>

<Accordion title="备份包含哪些内容？系统表会被备份吗？">
  所有用户创建的数据库、表和对象，以及访问实体 (用户、角色、profile、行策略、配额) 和用户自定义函数。`system.query_log` 等系统日志表不包含在内。
</Accordion>

<Accordion title="为什么需要为超过保留窗口的备份付费？">
  备份会形成链：一个全量备份及其后依赖该备份的增量备份。恢复该链中的任何增量备份都需要基础全量备份，因此在所有依赖它的增量备份均超出保留期之前，该全量备份都会被保留并存储。
</Accordion>

<Accordion title="如何自行监控备份状态？">
  有两种方式：使用 ClickHouse Cloud API 的备份端点，或使用集群内监控栈公开的备份指标 (启动、完成和失败计数器) 。建议在您自己的监控系统中针对失败设置告警。请参阅[可观测性](/zh/products/bring-your-own-cloud/reference/observability-aws)。
</Accordion>

<Accordion title="如何满足灾难恢复要求（RPO/RTO）？">
  BYOC 跨三个可用区部署，且只有在对象存储确认写入后，写入操作才会得到确认。目前不支持跨区域复制，因此区域级灾难恢复依赖备份，可实现的 RPO 受备份频率限制。您可以配置备份频率和目标端以满足自身目标，包括备份到其他区域的 bucket；如需设置，请联系支持团队。
</Accordion>

<div id="observability">
  ### 可观测性
</div>

<Accordion title="如何将 BYOC 与自有监控和告警系统集成？">
  监控栈 (Prometheus、Grafana、AlertManager) 在您的账户内运行，您可以通过私有连接直接使用：通过 PromQL API 查询、将其联邦到您自己的 Prometheus，或抓取每个服务的 ClickHouse `/metrics_all` 端点。目前尚未提供与 Datadog 等第三方平台的开箱即用集成，可通过其兼容 Prometheus 的摄取方式进行集成。有关端点和设置，请参阅[可观测性](/zh/products/bring-your-own-cloud/reference/observability-aws)。
</Accordion>

<div id="cost">
  ### 成本
</div>

<Accordion title="BYOC 的费用包括哪些？">
  账单分为两部分：ClickHouse Cloud 按分配给您的服务的内存计费；云提供商则直接向您收取底层基础设施的成本，不加价。目前，详细成本参考页面涵盖 AWS：请参阅[成本模型](/zh/products/bring-your-own-cloud/reference/cost-model-aws)、[计费 AWS 服务](/zh/products/bring-your-own-cloud/reference/billable-aws-services)和 [AWS 服务限制](/zh/products/bring-your-own-cloud/reference/aws-service-limits)。
</Accordion>

<div id="availability-and-lifecycle">
  ### 可用性和生命周期
</div>

<Accordion title="BYOC 可在哪些云提供商上使用？">
  AWS、GCP 和 Azure 均已正式发布。有关各云平台支持的功能和区域，请参阅[概览](/zh/products/cloud/guides/infrastructure/deployment-options/byoc/overview)。
</Accordion>

<Accordion title="如何停用 BYOC 环境？">
  请在 ClickHouse 控制台中终止服务和 BYOC 基础设施——不要先在云提供商控制台中删除资源或撤销权限，否则会在操作过程中中断与控制平面的连接，并导致需要手动清理。通过控制台完成终止后，请移除引导技术栈 (CloudFormation stack 或 Terraform 模块) 及所有剩余资源。在 AWS 上，所有由 ClickHouse 创建的资源均带有 `clickhouse-byoc=true` 标签，因此您可以随后枚举这些资源，确认没有遗漏；在 GCP 和 Azure 上，您引导的专用项目或订阅界定了需要检查的范围。
</Accordion>

<div id="uptime-sla">
  ### 运行时间 SLA
</div>

<Accordion title="ClickHouse 是否为 BYOC 提供运行时间 SLA？">
  不提供。由于数据平面托管在客户自己的云环境中，服务可用性取决于 ClickHouse 无法控制的资源。因此，ClickHouse 不为 BYOC 部署提供正式的运行时间 SLA。请注意，正在运行的服务独立于 ClickHouse 控制平面运行：控制平面发生故障不会导致您账户中运行的服务停止。如有其他问题，请联系 [support@clickhouse.com](mailto:support@clickhouse.com)。
</Accordion>