URnetwork
•••
故障复盘

故障记录

URnetwork 发展迅速，而增长总会触及系统的极限。每当我们遇到一次，就会在这里写下来：何时开始、何时结束、您看到了什么、哪里出了问题，以及我们做了哪些改变。

最近 3 个月

每一行是一个月，日期上下对齐。高度和颜色都表示服务受影响的程度。

2026年10月
10–131921–25现在
2026年9月
2026年8月
  • 正常
  • 性能下降
  • 部分中断
  • 严重中断
  • 完全中断

2026年10月

3 次故障

2026/10/21 – 2026/10/25

99 小时 44 分钟

Runaway connection churn filled the database disk and took the platform down

A provider-quality filter switched itself on at its default date and emptied two selection pools, and our hosted proxy service began churning through short-lived connections faster than the database could serve them. For two days connections failed or stalled for many people while database storage grew with the churn, until on Oct 23 a logging fault filled the disk and the platform was down for 16 hours, then 6 more for the storage expansion. That evening the same churn jammed payment reservations, and for about five hours apps could find providers but not send traffic.

开始于 10月21日 00:00 UTC结束于 10月25日 03:44 UTC
  • 完全中断23 小时 32 分钟
  • 严重中断14 小时 04 分钟
  • 部分中断43 小时 27 分钟
  • 性能下降17 小时 38 分钟
阅读复盘

2026年10月19日

9 小时 16 分钟

Stalled database connection pools took providers offline

The pools that connect our servers to the database stalled and could not refill. A cleanup job then mistook the stalled servers for dead ones and removed them, and 97% of providers dropped off the network for almost three hours.

开始于 10月19日 09:56 UTC结束于 10月19日 19:12 UTC
  • 完全中断2 小时 47 分钟
  • 严重中断16 分钟
  • 部分中断26 分钟
  • 性能下降4 小时 05 分钟
阅读复盘

2026/10/10 – 2026/10/13

80 小时 19 分钟

Three days of database overload, and the failures it set off

Our main database ran at its limit for three days, and every timeout added retries and more load. While it was overloaded, four separate failures hit users: a new connection check that disconnected healthy providers, a load-balancer collapse, a key rotation that broke new sign-ins, and a stalled connection pooler.

开始于 10月10日 00:22 UTC结束于 10月13日 08:41 UTC
  • 完全中断2 小时 10 分钟
  • 严重中断35 小时 35 分钟
  • 部分中断19 小时 34 分钟
  • 性能下降23 小时
阅读复盘