Кратко

  • Cloudflare открыла расследование 19 августа в 06:59 UTC, сообщила об установленном исправлении в 07:06 и закрыла инцидент в 07:20. Компания предупредила о возможном росте ошибок перегрузки у нескольких клиентов в Гонконге.
  • В истории компонентов только «Durable Objects» перешёл в режим сниженной производительности. Гонконг, RealtimeKit и Realtime SFU оставались работоспособными, хотя текст предупреждал о возможном влиянии на зависимые продукты.

Зелёный индикатор Гонконга не означал, что все сервисные пути в регионе были исправны. В течение примерно 21 минуты продукт «Durable Objects» имел сниженный статус, а пользователи связанных Realtime-продуктов могли получать ошибки перегрузки.

Согласно официальной записи, расследование началось 19 августа в 06:59:19 UTC. Cloudflare заявила о проблеме, потенциально затрагивавшей нескольких клиентов в Гонконге. При обращении к «Durable Objects», RealtimeKit и Realtime SFU мог наблюдаться повышенный уровень ошибок перегрузки. В 07:06:33 исправление уже было внедрено, а в 07:20:23 инцидент получил статус «устранён».

Cloudflare оценила влияние как minor. Компания не раскрыла первопричину, содержание исправления, число клиентов, долю неуспешных запросов, конкретные пространства имён или идентификаторы объектов. Запись не подтверждает потерю данных, обрыв звонков или отказ всей гонконгской площадки.

Важная деталь находится в компонентной модели. «Durable Objects» изменил состояние с operational на degraded_performance. HKG, RealtimeKit и Realtime SFU остались operational. Одновременно текст инцидента допускал ошибки у пользователей Realtime. Широкий зелёный компонент и отказ конкретной операции поэтому не исключали друг друга.

«Durable Objects» представляет особый тип зависимости. Документация Cloudflare описывает объект как сочетание вычислений с частным, транзакционным и строго согласованным хранилищем. У него глобально уникальное имя, к которому обращаются клиенты, координирующие общее состояние.

Один объект исполняется в одном месте и одном потоке. Разные объекты можно распределять по сети в большом количестве, но конкретное состояние нельзя безусловно отправить на любую здоровую периферию, как запрос без состояния. Если координатор отвечает ошибкой перегрузки, площадка может продолжать принимать остальной трафик, а операция приложения — не завершаться.

Само слово «перегрузка» не раскрывает механизм. В руководстве по диагностике перечислены слишком длинная очередь запросов, чрезмерный объём данных в очереди, долгое ожидание и экстремальная частота обращений к одному объекту за короткий интервал. Cloudflare не указала, какой вариант возник в Гонконге, и не возложила причину на нагрузку или архитектуру клиента.

Однако документация определяет безопасную реакцию. Руководство по обработке ошибок не рекомендует немедленно повторять исключения с признаком .overloaded: дополнительные запросы усиливают нагрузку и общий уровень ошибок. Это общее правило, а не доказательство точного формата ответов в данном инциденте. Клиент должен различить сигнал и выбрать задержку, контролируемый отказ или ограниченный режим.

Упоминание Realtime также нельзя превращать в утверждение об отказе медиапотока. Cloudflare называет RealtimeKit набором SDK и API для живого аудио и видео поверх Realtime SFU, который маршрутизирует медиа. Неизвестно, затронул ли инцидент создание встречи, присутствие, сигнализацию, управление дорожками или передачу аудио и видео. Доказательств завершённых звонков нет.

Собственные измерения клиента способны уточнить масштаб. Cloudflare предоставляет метрики «Durable Objects» по пространству имён и запросу, включая фильтр по имени или ID объекта. Сопоставление ошибок, задержки и бизнес-операций с окном 06:59–07:20 покажет больше, чем статус площадки.

Инцидент следует отделять от запланированного на более позднее время обслуживания межсоединений HKG. Зафиксированные источники не связывают события. Совпадение города и даты не доказывает общую площадку, линию, устройство или изменение.

Быстрое восстановление сузило известное окно, но оставило вопрос архитектуры клиенту: что должно работать без согласованного координатора? Разделение нагрузки между большим числом объектов, ограниченные повторы, идемпотентные операции и режим только для чтения могут снизить ущерб. Каждый вариант требует заранее определить допустимую потерю функциональности или свежести.

Следующим надёжным фактом стал бы разбор Cloudflare с типом перегрузки, границей отказа и описанием ремонта. Пока его нет, вывод остаётся точным: региональный сервис состояния был деградирован около 21 минуты, хотя общий индикатор Гонконга сохранял зелёный цвет.

Источники