TI-20250709-0001：Techaro 服务的 IPv4 流量故障

Techaro 的服务于 2025 年 7 月 9 日因 IPv4 流量中断。这篇博文将报告事件经过、已采取的解决措施以及近期为防止此类问题将采取的措施。敬请欣赏这篇事件报告！

在其他公司，这类文件会保留在内部。但在 Techaro，我们相信您值得拥有彻底的坦诚和真相。因此，我们正以行动践行我们的崇高承诺，公开发布问题细节。

此后的一切均遵循我的标准事件根本原因会议模板。

该事件报告将重点关注受影响的服务、事件发生的时间线、我们幸运的地方、根本原因分析以及正在计划或采取哪些行动来防止将来再次发生此类事件。

时间线

所有活动将于 2025 年 7 月 9 日举行。

时间（UTC）	描述
12:32	Uptime Kuma 报告称同一集群上的另一个不相关的网站超时。
12:33	Uptime Kuma 报告称 Thoth 的生产端点未通过 gRPC 健康检查。
12:35	开始调查，由于影响，包括他们的个人博客，在Xe的Bluesky上发布公告。
12:39	生产集群上的`nginx-ingress`日志显示 IPv6 流量正常，但 IPv4 流量在 UTC 时间 12:32 左右突然中断。已向主机提供商提交工单。
12:41	IPv4 流量恢复的时间足够长，以便 Uptime Kuma 报告正常运行时间，但随后立即再次失败。
12:46	IPv4 流量恢复的时间足够长，以便 Uptime Kuma 报告正常运行时间，但随后立即再次失败。（重复出现这种情况的情况已被清除，但大约每 5-10 分钟就会发生一次）
12:48	来自托管服务提供商的第一个回复。
12:57	回复托管服务提供商，要求重新启动负载均衡器。
13:00	事件响应人员由于要开会而非常忙碌，他们认为停机时间超出了他们的控制范围，并且正常运行时间监控软件会在停机恢复时通知他们。
13:20	事故响应人员结束会议并回去监控停机时间并准备此文件。
13:34	IPv4 流量开始出现在`ingress-nginx`日志中。
13:35	所有服务开始报告健康。事件状态更改为监控。
13:48	事件已结束。
14:07	事件已重新开启。问题似乎表现为上游提供商的 BGP 问题。
14:10	IPv4 流量恢复然后停止。
14:18	IPv4 流量恢复。事件状态转为监控。
14:40	事件已结束。

受影响的服务

服务名称	用户影响
Anubis 文档(IPv4)	连接超时
Anubis 文档(IPv6)	没有任何
托特(IPv4)	连接超时
托特（IPv6）	没有任何
位于同一集群 (IPv4) 上的其他网站	连接超时
位于同一集群的其他网站（IPv6）	没有任何

根本原因分析

为了简化服务器管理，Techaro 在Vultr VKE （Vultr Kubernetes Engine）上运行Kubernetes集群。执行此操作时，Vultr 需要配置一个负载均衡器来弥合外部世界与 Kubernetes 世界之间的差距，如下所示：

 --- title : Overall architecture ---         flowchart LR UT (User Traffic) subgraph Provider Infrastructure LB [Load Balancer] end subgraph Kubernetes IN (ingress-nginx) TH (Thoth) AN (Anubis Docs) OS (Other sites)          IN --> TH IN --> AN IN --> OS end          UT --> LB --> IN Techaro 控制着图中 Kubernetes 部分的一切。其他部分我们无法控制。该负载均衡器通过以下方式路由到公共互联网： --- title : Overall architecture ---         flowchart LR UT (User Traffic) subgraph Provider Infrastructure LB [Load Balancer] end subgraph Kubernetes IN (ingress-nginx) TH (Thoth) AN (Anubis Docs) OS (Other sites)          IN --> TH IN --> AN IN --> OS end          UT --> LB --> IN

边界网关协议（BGP）。

如果上游提供商的 BGP 会话中断，则可能导致网络无法正常工作或工作不稳定。由于 IPv4 和 IPv6 互联网在技术上是独立的网络，因此这种情况更加难以解决。因此，IPv4 流量中断，而 IPv6 流量正常的情况很可能出现。

根本原因是我们用于生产服务的主机提供商在其多伦多地区出现了 IPv4 BGP 会话不稳定的情况。当这种情况发生时，我们能做的就是提交工单，等待它恢复正常。

我们的幸运之处

捕获此事件的 Uptime Kuma 实例运行在纯 IPv4 网络环境中。如果是双栈网络，捕获此事件的速度可能慢得多。

ingress-nginx日志会将远程客户端的 IP 地址打印到日志源中。如果不是这样，查找此错误会困难得多。

行动项目

像这样的单次宕机事件不足以成为更换供应商的理由。因此，更换供应商不属于本条款的范畴。
Techaro 需要一个状态页面，该页面托管在与生产集群使用的云提供商不同的云提供商上（ TecharoHQ/TODO#6 ）。
需要创建针对 IPv4 和 IPv6 流量的健康检查（ TecharoHQ/TODO#7 ）。
如果启用了 Thoth，则无需 Anubis 在启动前通过 Thoth 健康检查。

原文： https://anubis.techaro.lol/blog/incident/TI-20250709-0001