Кратко

  • Задача очистки отправила параметр pending_delete без значения. Addressing API восприняла запрос как выборку всех префиксов BYOIP, после чего задача удалила префиксы и связанные с ними привязки сервисов.
  • Было отозвано около 1 100 префиксов. Примерно 800 вернули повторным объявлением; около 300 лишились также конфигурации сервиса на пограничных узлах и потребовали последующего глобального восстановления. Возврат маршрута был лишь одним этапом ремонта.

Вторая шкала восстановления

Инцидент Cloudflare 20 февраля 2026 года можно описать как сбой BGP. Но важнейшая деталь появилась, когда маршруты начали возвращаться: у части клиентских префиксов объявление уже восстановили, а в системах на границе сети Cloudflare больше не было привязки, указывающей, какой продукт должен обрабатывать трафик на эти адреса. Маршрут вернулся раньше сервиса.

Публичный IP-адрес сам по себе не является приложением. Префикс может быть зарегистрирован за клиентом, разрешён к объявлению провайдером, внесён в адресную базу провайдера, объявляться по BGP, привязываться к продукту и распространяться как конфигурация на пограничные узлы. Это связанные, но разные состояния. Видимый извне маршрут не доказывает, что пакет достиг нужного клиентского сервиса.

Согласно разбору Cloudflare, регулярная задача очистки должна была автоматизировать удаление префиксов, которые клиенты просили вывести из BYOIP. В запросе к API параметр pending_delete передавался без значения. В серверной реализации, описанной в отчёте, фильтр выбирал ожидающие удаления объекты только при непустой текстовой величине параметра. Пустое значение привело к тому, что API вернула все префиксы BYOIP. Задача посчитала каждый результат кандидатом на удаление и убрала зависимые объекты, в том числе привязки сервисов.

Cloudflare заявила, что причиной не были атака или злонамеренные действия. Релиз Addressing API завершился в 17:46 UTC, а через десять минут задача начала работу. Инженеры выявили процесс и остановили его в 18:46. За это время были отозваны примерно 1 100 префиксов. По данным компании, это 25% от 4 306 префиксов BYOIP, объявлявшихся по всему миру. В отчёте также указано 6 500 префиксов, видимых одному пиру. Это другой знаменатель, его нельзя подменять глобальным количеством BYOIP.

Изменение применялось поэтапно, поэтому его остановили до охвата всех клиентов. Это ограничило масштаб последствий, но само по себе не стало планом восстановления.

Объявление маршрута ещё не означает работу сервиса

Документация Cloudflare различает объявление BGP и привязку сервиса. Объявление привлекает трафик к сети Cloudflare, а привязка направляет его в CDN, Spectrum или Magic Transit. Для некоторых сценариев CDN добавляется карта адресов. Если автоматика удаляет и префикс, и его привязки, повторное объявление может вернуть трафик в сеть провайдера, но не восстановить путь к продукту на пограничном узле.

Поэтому рекомендация в панели помогала не всем. В 19:19 UTC Cloudflare предложила клиентам повторно объявить свои префиксы. К 20:20 были восстановлены примерно 800. Около 300 нельзя было починить простым переключением объявления: их конфигурации сервиса тоже исчезли с пограничных систем. Клиенты не могли создать привязку, которой больше не было в доступной их аккаунту конфигурации. Инженерам пришлось вернуть это состояние и развернуть глобальное обновление; оно завершилось в 23:03 UTC. Компания сообщила, что инцидент длился шесть часов и семь минут.

В открытом отчёте нет числа затронутых клиентов, географии, упущенной выручки или суммы компенсаций по SLA. Зато описаны разные пути восстановления: у одних исчезло только объявление маршрута, у других — часть привязок, у третьих — все привязки сервиса. Одна «авария BYOIP» включала разные сроки и зоны ответственности.

Сайт one.one.one.one также выдавал HTTP 403. Cloudflare отдельно подчеркнула, что DNS-разрешение через публичный резолвер 1.1.1.1, включая DNS over HTTPS, не пострадало. Ошибка на сайте свидетельствовала о проблеме веб-поверхности, работавшей через BYOIP, а не о том, что сам резолвер перестал отвечать. Смешение этих случаев направило бы поиск неисправности не туда.

Конфигурация — часть сетевой инфраструктуры

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

Пробел в тестировании был конкретным. Данных тестовой среды и макетов оказалось недостаточно. Команда проверила путь самообслуживания, по которому шёл бы клиент, но не отдельный планировщик задач, самостоятельно меняющий пользовательские данные. API-сценарий, запущенный человеком, может быть безопасным, а расписанный по времени процесс с той же API — разрушительным. Проверка только интерфейса не учитывает идентичность и полномочия автоматизации.

Объявленные меры Cloudflare выходили за рамки исправления параметра: стандартизация схемы API; разделение настроенного и фактического операционного состояния; поэтапное применение снимков конфигурации под контролем метрик здоровья; автоматическая остановка или откат при проблемном распространении; предохранитель от слишком быстрых или масштабных отзывов префиксов. Компания также упоминала здоровье клиентских сервисов как сигнал для остановки. Февральский разбор фиксирует планы и текущую работу, но не подтверждает, что их завершили позже.

BYOIP позволяет клиенту сохранить привычную адресную идентичность и при этом пользоваться сетью и продуктами провайдера. Операционная договорённость сложнее: клиент может владеть блоком и разрешить его объявление, а провайдер управляет плоскостью контроля, которая снимает маршрут, назначает продукт и распространяет конфигурацию на пограничные узлы. Переносимый актив может зависеть от состояния, которое его владелец не способен восстановить самостоятельно.

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

Что должно подтверждать обещание непрерывности

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

Проверку приёмки можно построить на сценарии, где маршрут уже вернулся, но привязка сервиса отсутствует. Умеет ли провайдер это обнаружить? Может ли он восстановить конфигурацию одного клиента без рискованного отката всей базы? Остановит ли развёртывание плохая метрика здоровья сервиса, а не только число маршрутов? Какие изменения клиент может делать во время блокировки записей и как долго она действует?

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

Вывод проверяем: адрес обозначает ресурс; маршрут заявляет достижимость; привязка определяет обработку трафика; работающий сервис — конечный результат. Отчёт о непрерывности не должен сводить эти уровни к одной зелёной лампе. Возврат префикса был прогрессом, но не завершением восстановления.

Источники