Постмортем от Cloudflare подъехал. Исходники тут - https://blog.cloudflare.com/18-november-2025-outage/. А ниже я сделаю вольный перевод, чисто чтобы понять идею произошедшего. Итак. Каждый запрос, идущий через Cloudflare, проходит примерно такой путь: 1. HTTP/TLS Layer - обработка запроса на внешнем уровне - сюда подключаются клиенты - браузеры, мобилки и так далее. 2. Core Proxy (FL/FL2) - это ключевой компонент, который Cloudflare называет FL (Frontline), или его новая версия FL2. Здесь отрабатывают все настройки, которые вы добавляете в дашбоард Cloudflare: WAF, DDoS-защита, маршрутизация и, что важно для этого сбоя - Bot Management. 3. Pingora - прокси сервис, который обслуживает кеш и забирает данные с вашего origin. FL/FL2 - это две версии Frontline сервиса. И в момент инцидента они вели себя по-разному: - FL2 (Rust) - Вторая версия. Принял на себя основной удар и начал возвращать пятисотые из-за паники (panic!) - FL (Старая версия) - сбой проявился мягче — он не выдавал 5xx, а просто часть функционала не работала. При этом трафик продолжал ходить. Здесь конечно кажется, что второй вариант с частичным отказом является более логичным решением. Но, возможно, есть какая-то бизнес-логика, которая требует останавливать трафик в случае проблем. В любом случае - тут решать только CF. Кстати, хочется отдельно отметить, что FL2 написан на Rust. И Pingora написана на Rust. Что-то похожее я видел только у Linkerd - https://linkerd.io/ - у них прокси sidecar написан на Rust. Собственно что происходило дальше. Внутри Core Proxy есть система Bot Management, которая проставляет оценку каждому запросу - бот он или нет. Для принятия решения используется модель машинного обучения. Моделька на вход требует файл конфигурации - feature file, который содержит список признаков, используемых для предсказания. Этот файл обновляется раз в 5 минут. С ним-то и возникли проблемы. В модуле Bot Management (внутри FL) был установлен жесткий лимит в 200 фич, которые могли содержиться в этом файле. Этот лимит нужен был для предварительной аллокации памяти - короче ради оптимизаций производительности. И вот вдруг этот файл удваивается в размере и FL2 начинает падать с паникой, потому что превышен лимит в 200 строк. Так почему же этот файл вырос в размере в два раза? Данные для этого файла берутся из Clickhouse базки. Структура базки верхнеуровнево достаточно простая. В базе default лежат distributed таблички, которые смотрят на таблицы в базе r0. Кто не знаком с CH сейчас кратко поясню. В CH есть разные типы движков для таблиц (считайте что разные типы таблиц). Одни - это условно обычные таблички, которые хранят данные. Вторые - это мета-таблицы, которые смотрят на первые таблицы. Они имеют тип - distributed. Это нужно для шардирования. Вы можете сделать один запрос к мета-таблице (distributed), а кликхаус раскидает его на все таблицы с реальными данными во всех шардах. Ну это если очень упрощенно. Главное здесь понимать, что мета-таблица (distributed) и реальная таблица (с данными) имеет одну и ту же структуру - колонки, типы и тд. А теперь посмотрите вот на такой запрос. Его выполнял bot management раз в 5 минут для формирования файла с фичами (ну не прямо весь запрос - главная его часть): SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name; Этот запрос вытаскивает информацию об именах и типах колонок для конкретной таблицы. И все было хорошо, пока пользователь имел права только на default базу, а соответственно только к distributed таблице. Таким образом данный запрос возвращал name и type только для одной таблички - http_requests_features в базе default. Ну а дальше ребята из CloudFlare меняли права доступа и у пользователя, под которым выполняется этот запрос появился доступ к реальным таблицам в базе r0. И он тут же начал возвращать name и type для двух идентичных таблиц - мета-таблицы и реальной таблички. Это привело к удвоению данных в feature файле, а потом и к панике, как вы