Google Cloud宕机近13小时：香港服务器99.9% SLA该怎么看？

2026年7月15日，Google Cloud荷兰europe-west4-a可用区发生服务中断。

根据Google Cloud发布的初步事故报告，事故起因是数据中心上游公用电网出现电气故障，继而影响配电设备和制冷系统。机房温度快速上升后，Google关闭了部分主机、存储集群和网络交换机，以降低高温对设备和数据造成的风险。

此次事故影响了Google Cloud VMware Engine、Google Cloud NetApp Volumes和Bare Metal Solution。三项服务的影响时间并不相同，其中Bare Metal Solution持续约12小时57分钟，Google Cloud VMware Engine约9小时24分钟，NetApp Volumes约8小时31分钟。

这次事故说明，即使是大型云平台，也无法完全排除供电、制冷和硬件设施故障。对于准备租用香港服务器的用户来说，更值得关注的问题是：

服务商所说的99.9% SLA，具体保障什么？发生故障后又如何处理？

99.9%在线率允许停机多久？

SLA是Service Level Agreement的缩写，通常译为服务等级协议。服务器服务商常见的可用性承诺包括99.9%、99.99%和99.999%。

以30天、共43200分钟计算：

• 99.9%可用性，允许不可用约43分12秒；
• 99.99%可用性，允许不可用约4分19秒；
• 99.999%可用性，允许不可用约26秒。

因此，99.9%在线率并不代表服务器不会中断，而是指在约定的统计周期内，被SLA认定的不可用时间不能超过相应额度。

如果某个月发生一次20分钟的中断，月度可用性仍可能高于99.9%；如果累计中断超过约43分钟，则可能低于99.9%的目标。

这里的关键词是“可能”。是否违反SLA，不能只看用户记录到的中断时长，还要看协议如何定义不可用。

先确认SLA保障的是哪一部分

香港服务器的正常运行涉及多个环节，包括机房供电、制冷、网络、服务器硬件、操作系统和业务程序。不同服务商的SLA可能只覆盖其中一部分。

例如，有些SLA保障的是网络可用性。服务器硬件发生故障，但网络本身正常，未必会被计入网络停机时间。

有些云服务器SLA保障的是实例连通性，但用户自行安装的软件、错误的防火墙规则、系统配置或第三方服务故障，通常不属于服务商责任。

Google Compute Engine目前也会分别定义单实例、多可用区实例和负载均衡服务。其“停机”口径包括虚拟机失去外部网络连接或持久磁盘访问；对于多可用区部署，需要相关运行实例同时达到协议所定义的不可用状态，才会计入对应停机时间。

因此，比较香港服务器SLA时，建议先确认以下问题：

• 99.9%保障的是网络、供电、硬件还是整台服务器；
• 是按单台服务器计算，还是按整个机房或业务集群计算；
• 丢包、延迟升高和线路绕路是否属于不可用；
• 硬件故障、更换硬盘和重装系统是否有单独时限；
• 计划维护是否计入停机时间。

只有明确统计范围，在线率百分比才有实际比较价值。

SLA补偿不等于赔偿全部业务损失

SLA除了规定可用性目标，还应说明未达到目标时如何补偿。

常见条款包括：

• 按自然月还是连续30天统计；
• 故障时间以哪一方的监控记录为准；
• 用户是否需要主动申请；
• 申请期限是多长；
• 是否需要提交监控日志；
• 补偿是退款、账户余额还是续费时长；
• 补偿金额是否设有上限；
• 哪些情况属于免责范围。

Google Compute Engine当前SLA规定，符合条件的用户需要在取得补偿资格后的60天内联系技术支持，并提交能够证明停机时间的日志。补偿以抵扣未来服务费用的Financial Credit形式发放，而不是按照用户实际产生的订单损失、广告损失或其他经营损失赔付。该SLA也将Financial Credit列为未达到服务目标时的合同补救方式。

这也是为什么阅读SLA时，补偿条款往往比“99.9%”这个数字更重要。

用户需要了解的不是服务商是否写了“故障可赔”，而是：

什么情况可以申请、能够补偿多少，以及需要提供哪些材料。

机房有冗余，不代表没有单点故障

Google Cloud此次事故同时影响三项服务，原因是这些服务所在的数据中心受到同一供电和制冷故障影响。事故表明，同一可用区内的不同产品，仍可能共享部分数据中心级基础设施。

选择香港服务器时，不能只看“高可用”“多线路”或“冗余机房”等概括性描述，还要继续了解具体架构。

供电系统

可以重点询问：

• 是否有两路市电输入；
• UPS采用N+1、2N还是其他架构；
• 发电机能够覆盖哪些设备；
• 发电机油料能够维持多长时间；
• 是否定期进行带载测试；
• 供电切换是否可能造成短时中断。

即使页面写有“2N供电”，也需要确认两套系统是否真正独立，是否仍然共用开关设备、控制系统或其他关键节点。

制冷系统

服务器能否持续运行，不只取决于供电。空调、冷水机组、冷却塔和控制系统发生故障，同样可能导致服务器降频、自动关机或被人工关闭。

Google Cloud此次事故就是在供电故障后失去制冷能力。为防止设备在高温环境中继续运行，部分主机、存储和网络设备被关闭。

因此，除了确认空调数量，还应了解制冷系统是否有冗余、备用设备是否使用独立电源，以及局部故障发生后能否隔离受影响区域。

网络线路

“接入多家运营商”不等于线路完全独立。

需要进一步确认：

• 不同线路是否从不同物理路由进入机房；
• 核心路由器和交换机是否有冗余；
• 上游线路是否存在共同故障点；
• BGP、CN2或其他线路能否自动切换；
• 切换过程中是否需要人工操作；
• 是否能够提供历史延迟、丢包和可用性数据。

如果两条线路经过同一管道、同一设备间或同一台核心设备，一次故障仍可能造成同时中断。

硬件支持

租用独立服务器时，还要区分“客服响应时间”和“实际恢复时间”。

7×24小时技术支持通常表示全天可以提交问题，但不一定代表工程师随时驻场，也不代表所需硬盘、电源、内存或主板一定有现货。

签约前可以确认：

• 工单首次响应时间；
• 工程师介入时间；
• 常用硬件是否有现场备件；
• 硬件检测和更换时限；
• 更换硬盘后是否协助恢复系统；
• 数据恢复是否属于服务范围。

故障报告也能反映服务商能力

服务器发生故障并不罕见，重要的是服务商能否及时发现、准确说明并持续更新。

相对完整的事故说明通常应包括：

• 故障开始和恢复时间；
• 受到影响的服务和区域；
• 用户可能观察到的现象；
• 已确认的直接原因；
• 临时恢复措施；
• 后续调查和改进计划。

Google Cloud在此次事故中公布了三项服务各自的影响时间，并说明了上游电气故障、制冷能力丧失、机房升温和设备关闭之间的关系。目前公开的是初步事故报告，Google表示最终报告和预防措施仍会在调查完成后发布。

如果服务中断后只有“网络波动”或“正在处理”等简短回复，恢复后也没有时间线和原因说明，用户就很难判断故障是否彻底解决，也无法评估类似问题再次发生的可能性。

99.9% SLA不能代替业务容灾

服务商可以提供机房、电力、网络和硬件保障，但单台服务器仍然可能成为业务的单点故障。

Google Cloud的可靠性文档也建议，需要抵御可用区故障的业务，应把资源分布在多个可用区；需要抵御区域级故障时，则应考虑多区域部署。单可用区、多可用区和多区域架构的成本、复杂度和可用性目标并不相同。

对于企业官网、展示页面或测试环境，单台香港服务器配合异地备份，通常可以满足基本需求。

对于支付、会员系统、API、在线游戏等中断成本较高的业务，可以根据预算考虑：

• 将业务部署在两台或多台物理服务器上；
• 使用负载均衡和健康检查；
• 在不同机房保留备用节点；
• 对数据库进行复制和异地备份；
• 设置自动或人工故障切换流程；
• 定期测试备份恢复和容灾切换。

需要注意的是，多机部署并不会自动形成高可用。数据库、存储、域名解析、负载均衡和监控系统如果仍有单点，业务仍可能整体中断。

选择香港服务器时，SLA应该这样看

比较香港服务器时，CPU、内存、硬盘、带宽和价格当然重要，但还可以增加以下几项：

1. SLA保障范围；
2. 停机时间认定方法；
3. 补偿标准和申请期限；
4. 供电及制冷冗余；
5. 网络入口和上游线路；
6. 硬件备件及更换时间；
7. 故障通知和事故报告机制；
8. 是否支持跨服务器或跨机房容灾。

SellBGP的香港服务器托管提供99.9%网络可用性SLA、T3+数据中心、2N冗余基础设施和7×24小时NOC监控，低于约定标准时按照协议补偿。在购买香港服务器之前，把SLA条款、底层机房条件和自身容灾方案放在一起评估，比只比较一个在线率数字更有意义。