Отказ Cloudflare в 2022 году сделал тестирование изменений BGP тестом подотчётности

Резюме

• 21 июня 2022 года, по заявлению Cloudflare, изменение сетевой конфигурации привело к отказу в 19 дата-центрах, использующих архитектуру Multi-Colo PoP. Эти площадки составляли примерно четыре процента её сети, но обрабатывали значительную долю трафика. Cloudflare оценила, что около половины общего числа запросов в период сбоя пришлось на затронутый трафик, при этом отмечая, что влияние на пользователей различалось в зависимости от местоположения. [1]
• Предполагаемое изменение стандартизировало информационные сообщества BGP на префиксах, локальных для площадки. На магистральных маршрутизаторах MCP переупорядочивание терминов политики привело к тому, что термин для отключённых префиксов оказался перед терминами, которые должны анонсировать критические локальные для площадки маршруты. Результирующая политика маршрутизации отозвала эти префиксы. [1]
• Отзыв префиксов привёл к большему, чем потеря внешней доступности. Cloudflare сообщает, что её серверы не могли нормально взаимодействовать или достигать источников клиентов, а её уровень балансировки нагрузки Multimog не мог перемещать запросы между вычислительными кластерами внутри затронутых MCP. Меньшие кластеры затем получали трафик, сравнимый с крупными кластерами, и перегружались. [1]
• Инженеры также испытывали трудности с доступом к затронутым площадкам для отмены изменения. Потребовались резервные процедуры. Во время восстановления инженеры иногда перезаписывали откаты друг друга, что приводило к спорадическому повторению проблемы до окончательного восстановления последней площадки. [1]
• Процесс в Cloudflare уже включал наличие тикета на изменение, сухого прогона, экспертной оценки и поэтапного развёртывания. Сбой контроля был более конкретным: ни один из ранних этапов развёртывания не задействовал площадку MCP. Первый репрезентативный тест произошёл, когда финальный этап достиг всех магистральных устройств MCP. [1]
• Сообщества BGP — это метаданные, используемые политикой маршрутизации. Они не доказывают, что экспортная политика правильно упорядочена или что требуемые префиксы остаются анонсированными. Проверка происхождения RPKI решает вопрос, авторизована ли исходная AS для префикса; она не проверяет этот внутренний порядок терминов, выбор канареечного теста или процедуру отката. [10][11][12][14][15][16]
• Поэтому подотчётность должна требовать операционные доказательства: точную конфигурацию до и после изменения, машинно-проверяемый набор обязательных префиксов, симуляцию политики маршрутизации, канареечный тест, специфичный для MCP, поведение с подтверждением фиксации, независимый доступ управления, одного ответственного владельца отката, журналы изменений по каждой площадке, а также внешние наблюдения за маршрутами, сверенные с журналами маршрутизаторов.
• Публичные коллекторы маршрутов могут помочь установить видимые извне анонсы и отзывы, но они не могут показать каждый частный локальный для площадки маршрут или внутренние решения политики. Записи оператора остаются необходимыми. [17][18][19]
• Публичные данные не устанавливают злонамеренного умысла, халатности, нарушения нормативных требований, каждый затронутый префикс, потери каждого клиента или то, что все заявленные меры по исправлению остаются развёрнутыми. Эти ограничения должны оставаться явными.

Проверенное изменение всё равно может быть непротестированным изменением

Инфраструктурные организации часто используют ярлыки процессов как сокращение для контроля. Изменение было зарегистрировано в тикете. Сухой прогон завершён. Несколько инженеров провели его экспертную оценку. Развёртывание было поэтапным. Каждое утверждение может быть правдивым, в то время как операционный риск остаётся непротестированным.

Отчёт Cloudflare о её отказе 21 июня 2022 года делает это различие необычайно ясным. Изменение прошло через тикет запроса на изменение, включало сухой прогон, получило экспертную оценку и следовало пошаговой процедуре развёртывания. Ранние шаги не вызвали отказа. Отказ проявился, когда развёртывание достигло 19 площадок, использующих архитектуру, которую Cloudflare назвала Multi-Colo PoP, или MCP. Ни один из более ранних этапов не задействовал площадку MCP. Первый этап, который представлял релевантную топологию маршрутизации, был также этапом, применившим конфигурацию ко всем магистральным устройствам MCP. [1]

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

Поэтому вопрос подотчётности не в том, «Существовал ли процесс?», а в том, «Что доказывал каждый шаг процесса?» В этом инциденте раннее развёртывание доказало, что изменение не нарушает работу площадок, использующих более старую архитектуру. Оно не доказало, что политика сохранит требуемые анонсы на магистральных устройствах MCP. Зелёный результат с нерепрезентативной площадки не мог ответить на решающий вопрос.

Этот пробел важен, потому что сетевая конфигурация — это исполняемые операционные полномочия. Термин политики маршрутизации не просто описывает, куда должен направляться трафик. Его порядок определяет, какие маршруты маршрутизатор анонсирует или скрывает. Будучи применённой, конфигурация изменяет граф доступности, используемый серверами, пирами, источниками, операторами и системами восстановления. Разница между безобидным добавлением метаданных и крупным отказом может заключаться в одной ветви политики, вычисленной раньше другой.

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

Намеченное изменение было информационным; фактическое изменение затронуло доступность

Cloudflare заявила, что стандартизировала сообщества BGP, прикреплённые к подмножеству анонсируемых префиксов, а именно добавляла информационные сообщества к локальным для площадки префиксам. Сообщества BGP — это атрибуты, которые операторы используют для маркировки маршрутов и влияния на политику маршрутизации. Спецификация стандартных сообществ определяет способ группировки пунктов назначения, чтобы решения о маршрутизации могли применяться к классу маршрутов, а не к одному префиксу за раз. Large Communities расширяют формат для современных операционных нужд. [1][11][12]

Намеченные добавления не описывались как попытка отозвать сервисные маршруты. Cloudflare охарактеризовала их как безвредную информацию на обычных маршрутизаторах, показанных в её отчёте. Существенное различие проявилось на магистральных маршрутизаторах MCP. Дифф конфигурации изменил порядок терминов в агрегированной экспортной политике. Термин, связанный с отключёнными префиксами, переместился перед терминами, которые анонсировали локальные для площадки маршруты для служб и внутренних функций. Поскольку термины политики вычисляются последовательно, более раннее совпадение остановило работу логики последующего анонсирования. [1]

Это различие между семантическим намерением и фактическим поведением. Автор изменения может намереваться добавить метаданные. Рецензент может увидеть добавление сообществ. В тикете может использоваться заголовок «стандартизировать сообщества». Ни одно из этих представлений не управляет маршрутизатором. Маршрутизатор вычисляет результирующую политику по порядку. Если сгенерированная или отрисованная конфигурация меняет этот порядок, операционный эффект таков, каким его исполняет движок политики.

Сам BGP предоставляет механизм доступности. Сети анонсируют префиксы, чтобы сообщить пирам, что адреса доступны по определённому пути. Они отзывают маршруты, когда эта доступность больше не существует или её не следует анонсировать. Отозванный префикс может исчезнуть из выбранных путей, делая связанные адреса недоступными по этому маршруту. Спецификация BGP-4 определяет эти семантики анонсирования и отзыва; она не знает бизнес-намерения оператора для конкретного термина политики. [10]

Это различие создаёт требование к доказательствам. Утверждение изменения должно быть привязано к точной конфигурации-кандидату, которую будет вычислять маршрутизатор, а не только к высокоуровневому запросу или сгенерированному шаблону. Запись об экспертной оценке должна показывать:

1. Точную отрисованную политику до и после изменения.
2. Порядок вычисления каждого затронутого термина.
3. Набор маршрутов, которые ожидаются принятыми, отклонёнными, анонсированными и отозванными.
4. Источник каждого префикса в этом наборе.
5. Роли устройств и архитектуры, на которых будет выполняться политика.
6. Результат симуляции или лабораторного теста с использованием репрезентативных входных маршрутов.
7. Пути управления и отката, которые остаются доступными, если вывод политики окажется ошибочным.

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

Локальные для площадки префиксы были частью сервисного пути

Термин «локальный для площадки» может звучать как второстепенный, как будто затронутые маршруты были внутренними записями без последствий для клиентов. Отчёт Cloudflare показывает обратное. Эти префиксы обеспечивали связь между её машинами и позволяли серверам достигать источников клиентов. Их отзыв прервал эти пути. [1]

Cloudflare также связала эти префиксы с Multimog, внутренней системой балансировки нагрузки, используемой в точках MCP. Multimog больше не мог перенаправлять запросы между серверами в MCP, поскольку соответствующая доступность исчезла. Вычислительные кластеры разного размера затем получали схожие нагрузки трафика. Меньшие кластеры перегружались. [1]

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

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

• Является ли префикс обращённым в Интернет, только для управления, локальным для площадки, обращённым к источникам клиентов или межкластерным?
• Какие маршрутизаторы и политики его анонсируют?
• Какие службы от него зависят?
• Какие проверки мониторинга подтверждают его доступность?
• Какие площадки используют тот же шаблон политики?
• Что происходит, если маршрут исчезает, а входящий трафик продолжается?
• Использует ли управленческий доступ то же семейство маршрутов или политику?
• Какой альтернативный путь ожидается для обеспечения этой зависимости?

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

Эффект Multimog также показывает, почему пропускная способность нуждается в топологическом контексте. Cloudflare отметила, что затронутые площадки MCP содержали кластеры разного размера. Когда внутренняя пересылка отказала, меньшие кластеры получали трафик, сравнимый с крупными кластерами. Панель управления пропускной способностью, показывающая общую ёмкость площадки, могла бы поэтому завышать используемую ёмкость. Отказ маршрута убрал механизм балансировки, который делал совокупную ёмкость доступной.

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

Девятнадцать площадок выявили концентрацию внутри распределённой сети

Cloudflare сообщила, что 19 площадок MCP составляли около четырёх процентов её сети, однако отказ затронул примерно 50 процентов общего числа запросов. Компания также подчеркнула, что влияние различалось по местоположениям: некоторые пользователи не могли получить доступ к ресурсам, использующим Cloudflare, в то время как другие площадки продолжали работать нормально. [1]

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

Программа MCP была нацелена на повышение отказоустойчивости в самых загруженных точках. Cloudflare описала архитектуру в стиле Клоса с дополнительным уровнем маршрутизации и ячеистыми соединениями магистральных устройств. Эта архитектура позволяла включать или отключать части внутренней сети для обслуживания или обработки сбоев. Это законные цели обеспечения отказоустойчивости. Инцидент не доказывает, что архитектура была изначально ненадёжной. [1]

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

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

Для развёртывания MCP полезная карта изменений должна включать:

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

Потеря управленческой доступности изменила проблему восстановления

Cloudflare сообщила, что отзыв маршрута усложнил инженерам доступ к затронутым площадкам и откат конфигурации. Для получения контроля использовались резервные процедуры. [1]

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

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

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

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

Скриншот успешного входа в обычный день недостаточен. Тест должен убрать ту зависимость, которая отказала. Доказательства работающей системы перевешивают диаграмму, на которой один путь помечен как «внеполосный».

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

Полномочия на откат не сработали как координационный контроль

Хронология Cloudflare говорит, что окончательные откаты были задержаны, потому что сетевые инженеры перезаписывали изменения друг друга. Некоторые откаты отменяли предыдущие откаты, что приводило к спорадическому повторению проблемы. [1]

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

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

Полезные средства контроля включают:

• Назначенного командира инцидента и владельца сетевых изменений.
• Замороженный желаемый коммит состояния для восстановления.
• Блокировки на уровне устройства или домена политики во время отката.
• Единый оркестратор, записывающий каждую попытку и завершённый откат.
• Таймеры подтверждения фиксации, автоматически восстанавливающие предыдущее состояние, если управленческое подтверждение потеряно.
• Наблюдателей с доступом только для чтения, которые проверяют восстановление маршрутов и служб, не изменяя конфигурацию.
• Правило, что экстренные ручные изменения сверяются с авторитетной конфигурацией до возобновления нормальной автоматизации.
• Явную передачу владения, когда оно переходит между командами или регионами.

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

Меры Cloudflare по исправлению включали автоматический откат с подтверждением фиксации и лучшее принуждение к поэтапности. [1] Механизм подтверждения фиксации особенно актуален, когда изменение маршрута может удалить управленческий доступ. Маршрутизатор может автоматически восстановить предыдущее состояние, если оператор не подтвердит новое состояние после прохождения проверок доступности и инвариантов.

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

Процесс существовал; его доказательные обязательства были неполны

В отчёте Cloudflare явно говорится, что изменение имело тикет, сухой прогон, поэтапное развёртывание и нескольких экспертов-рецензентов. [1] Это делает инцидент полезным для организаций, у которых уже есть зрелый словарь управления изменениями.

Слабым посмертным ответом было бы добавить ещё одно утверждение. Больше подписей может замедлить доставку, не тестируя отсутствующее условие. Доказательства указывают на четыре более сильных вопроса.

Во-первых, какие входные данные использовал сухой прогон? Если он отрисовывал политику только для более старой архитектуры, он не мог выявить эффект порядка терминов MCP. Сухой прогон должен включать каждую роль политики, затронутую логикой генерации, особенно роли с другими шаблонами или наследованием.

Во-вторых, какие утверждения оценивал сухой прогон? Синтаксически корректная конфигурация всё ещё может отозвать требуемые префиксы. Валидация должна сравнивать выдачу маршрутов, а не только результаты разбора. Инструмент должен сообщать о сбое, если какой-либо обязательный локальный для площадки, управленческий, к источникам или сервисный префикс изменяется неожиданно.

В-третьих, как были определены группы развёртывания? Только географическое упорядочивание не выявило бы специфичный для архитектуры дефект, если каждая ранняя география использовала старый дизайн. Группы должны отражать аппаратное обеспечение, программное обеспечение, топологию, роль политики, версию плоскости управления, долю трафика и путь управления.

В-четвёртых, что останавливало продвижение? Поэтапное развёртывание эффективно только при наличии явных окон наблюдения и автоматических шлюзов. Системе нужны доказательства того, что канареечный тест сохранил требуемые маршруты, доступность источников, внутреннюю балансировку нагрузки, управленческий доступ и успешность служб до начала следующей группы.

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

Цель — не бюрократическое совершенство. Цель — привязать процесс к механизму отказа. Для политики BGP операционное утверждение заключается в том, что указанные префиксы остаются анонсированными указанным пирам, в то время как намеченные атрибуты изменяются. Это утверждение можно проверить машинно.

Инварианты маршрутов превращают намерение в тест

Инвариант маршрута — это утверждение, которое должно оставаться истинным до, во время и после изменения. Примеры включают:

• Каждое магистральное устройство MCP анонсирует утверждённый набор локальных для площадки префиксов.
• Управленческие префиксы остаются доступными с назначенных независимых точек доступа.
• Зонды связанности с источниками клиентов успешны из каждого вычислительного кластера.
• Внутренняя балансировка нагрузки может перемещать запросы между кластерами разного размера.
• Никакой неожиданный публичный префикс не анонсируется.
• Никакой защищённый префикс не отзывается.
• Количество и атрибуты изменённых маршрутов соответствуют утверждённому объёму изменения.

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

Перед фиксацией симуляция политики может оценить кандидата на репрезентативных маршрутах и пиринговых контекстах. После канареечной фиксации система может сравнить информационную базу маршрутов маршрутизатора и представление анонсируемых маршрутов с инвариантом. Активные зонды могут тестировать сервисные пути. Внешние коллекторы могут предоставить отдельное представление для публичных анонсов. [17][18][19]

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

Инварианты маршрутов также улучшают коммуникацию при инцидентах. Вместо «сеть восстанавливается» операторы могут сообщить, что требуемые анонсы восстановлены в определённом количестве площадок, управленческая доступность вернулась, внутренняя пересылка проходит, а успешность клиентских запросов находится в заявленном диапазоне. Каждое утверждение имеет доказательства и границы.

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

Сообщества BGP сами по себе не вызвали отказ

Было бы неточно резюмировать инцидент как «сообщества BGP сломали Cloudflare». Сообщества — это метаданные, прикрепляемые к маршрутам. Операторы используют их для политики, тегирования, инжиниринга трафика и операционной сигнализации. RFC 1997 и RFC 8092 определяют форматы сообществ; они не диктуют порядок политики Cloudflare. [11][12]

Намеченные добавления сообществ были частью контекста изменения. Механизмом отказа был эффективный порядок терминов политики на магистральных устройствах MCP и результирующий отзыв обязательных префиксов. [1] Это различие важно, потому что меры по исправлению должны устранять отказавший контроль, а не стигматизировать стандартный механизм.

Сообщества могут улучшать подотчётность, когда их значение задокументировано, уникально и последовательно применяется. Они могут идентифицировать классы маршрутов, предполагаемую обработку, состояние обслуживания, географию или отношения с клиентом. Но метки полезны только тогда, когда вычисление политики сохраняет требуемый результат. Сообщество «site local» не сохраняет маршрут анонсированным, когда более ранний термин его отклоняет.

Тот же принцип применяется к названиям изменений и комментариям. Человекочитаемые метки поддерживают экспертную оценку, но выполняющаяся политика определяет доступность. Оператор должен иметь возможность проследить от определения сообщества к набору маршрутов, ветвям политики, ожидаемым анонсам и наблюдаемым результатам. Если след заканчивается на документации, операционные доказательства неполны.

RPKI важен, но не является прямым средством исправления

RPKI предоставляет способ привязать ресурсы IP-адресов к авторизованным исходным AS. Проверка происхождения маршрута позволяет маршрутизатору классифицировать анонс на основе того, согласуется ли источник и длина префикса с Авторизацией происхождения маршрута (ROA). RFC 6480 описывает архитектуру, а RFC 6811 описывает проверку происхождения. [15][16]

Эти средства контроля решают другой вопрос, нежели отказ июня 2022 года. RPKI может помочь определить, была ли AS Cloudflare авторизована для анонса публичного префикса. Она не определяет, должен ли термин внутренней экспортной политики анонсировать локальный для площадки префикс, правильно ли упорядочены термины, является ли канареечный тест MCP репрезентативным или является ли доступ для отката независимым.

Авторизованный маршрут может быть случайно отозван. Действительный источник не доказывает доступность. С другой стороны, внутренний локальный для площадки маршрут может никогда не быть видимым в публичном RPKI или внешних коллекторах. Представлять RPKI как универсальное решение значило бы скрыть фактический отказ контроля.

RPKI всё же принадлежит модели доказательств, потому что авторизация сетевых ресурсов, политика маршрутизации и непрерывность операций взаимодействуют. Оператор должен вести точные записи номерных ресурсов и метаданные безопасности, отдельно проверяя поведение политики и доступность служб. Целостность реестра и доказательства работающего кода являются взаимодополняющими, а не заменяющими друг друга.

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

Внешнее наблюдение маршрутов ценно, но неполно

Информационная служба маршрутизации (RIS) RIPE NCC собирает данные BGP от пиров, а RIS Live предоставляет потоки обновлений. BGPStream от CAIDA предоставляет инструменты для работы с данными маршрутизации от нескольких коллекторов. Эти системы могут помочь исследователям и операторам наблюдать анонсы, отзывы, изменения путей и восстановление, видимые участвующим точкам обзора. [17][18][19]

Для инцидента с публичными префиксами внешние наблюдения могут ответить на важные вопросы:

• Когда префикс исчез из выбранных коллекторов?
• Какие пиры или регионы наблюдали отзыв?
• Когда анонсы вернулись?
• Изменились ли пути или атрибуты после восстановления?
• Совпало ли событие с публичной хронологией оператора?

Посмертный анализ июня 2022 года касается локальных для площадки префиксов и внутреннего поведения MCP, а также внешне ощутимого сервисного отказа. Публичные коллекторы могут не видеть каждый релевантный маршрут. Они не раскрывают частные термины политики, конфигурации-кандидаты маршрутизаторов, внутреннюю управленческую доступность или состояние Multimog. Отсутствие внешнего сигнала не доказывает, что частная система была исправна.

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

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

Цифры воздействия нуждаются в собственных границах

Cloudflare сообщила, что 19 площадок MCP представляли примерно четыре процента её сети, но отказ затронул 50 процентов общего числа запросов. Компания также опубликовала график объёма запросов и представление исходящей полосы пропускания. [1]

Эти цифры показывают концентрацию трафика в высокопроизводительных площадках. Они не устанавливают, что половина всех интернет-пользователей, половина клиентов Cloudflare или половина всех веб-сайтов были полностью недоступны. Трафик запросов — это не численность населения. Некоторые площадки продолжали работать нормально, и влияние на клиентов зависело от географии и сервисного пути.

Ответственный отчёт о воздействии должен разделять:

• Запросы, которые завершились неудачей.
• Запросы, которые были задержаны или повторены.
• Площадки, потерявшие обязательные маршруты.
• Кластеры, которые перегрузились.
• Источники клиентов, ставшие недоступными с затронутых площадок.
• Службы, продолжившие работу с незатронутых площадок.
• Время до первого восстановления и время до окончательного отката.
• Остаточные ошибки после восстановления маршрутов.

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

Для будущих инцидентов оператор может улучшить раскрытие, публикуя знаменатели и неопределённость. Если 50 процентов запросов были затронуты, определите интервал измерения, критерий успеха, обработку повторных попыток, географию и то, включает ли цифра трафик, перенесённый на другие площадки. Ясные метрики позволяют клиентам сравнить заявление со своими собственными журналами.

Подотчётность следует за контролем, а не за видимостью бренда

Cloudflare контролировала политику маршрутизации, процедуру развёртывания, группировку MCP, объём сухого прогона, материалы для экспертной оценки, управленческий доступ, автоматизацию и координацию отката. Её посмертный анализ признаёт, что отказ был её ошибкой, а не атакой. [1] Эти факты делают Cloudflare центральным оператором в анализе подотчётности.

Это не означает, что любое последствие юридически вменяемо или что каждый инженер нёс равную ответственность. Публичная запись не устанавливает индивидуальную вину или халатность. Управление должно отображать средства контроля на команды и системы:

• Владелец сетевой архитектуры определил роли MCP и домены отказа.
• Владелец политики определил экспортные термины и обработку сообществ.
• Владелец автоматизации отрисовал и распространил конфигурацию.
• Владелец изменения выбрал этапы и окна наблюдения.
• Рецензенты оценили предоставленные доказательства.
• Командир инцидента координировал восстановление.
• Команды устройств и платформ предоставили механизмы отката и подтверждения фиксации.
• Сервисные команды мониторили доступность источников, Multimog, нагрузку кластеров и клиентские запросы.
• Руководство установило приемлемую концентрацию трафика и риск изменений.

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

Клиенты, тем не менее, несут ответственность за свою архитектуру зависимостей. Организация, чья публичная служба зависит от одного CDN или авторитетного DNS-пути, должна понимать эту зависимость, тестировать альтернативный доступ, где это возможно, и определять порядок коммуникации, когда провайдер недоступен. Эта ответственность не передаёт контроль над маршрутизаторами Cloudflare клиенту и не делает каждую зависимость устранимой.

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

Практический пакет доказательств

Самым сильным завершением пост-инцидентного анализа является не заверение, что та же самая точная ошибка не может повториться. Это ограниченный пакет, показывающий, что изменилось и как работают новые средства контроля.

Пакет отделяет записи от операционных доказательств. Реестр префиксов полезен, потому что он сохраняет уникальность, владение, роль, ожидаемых пиров, метаданные безопасности и историю изменений. Он не является авторитетом, заставляющим пакеты передаваться. Симуляция политики полезна, потому что предсказывает поведение; канареечный тест и живое состояние маршрутов всё равно нуждаются в наблюдении. Публичный посмертный анализ полезен, потому что описывает событие; он не доказывает, что каждое последующее обязательство остаётся активным.

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

Границы сравнения имеют значение

Cloudflare пережила другие инциденты с маршрутизацией и конфигурацией. Рассматривать их как один обобщённый отказ ослабило бы анализ.

Событие июня 2019 года включало внешнюю утечку маршрутов. Это не отказ поэтапного развёртывания MCP 2022 года.

Отказ Cloudflare в июле 2020 года был отказом правила маршрутизатора. Его прямой механизм отличается от отзыва локального для площадки префикса 2022 года.

Событие марта 2025 года было связано с ошибочной ROA. Маршруты 2022 года были отозваны внутренней политикой; публичная запись не описывает ошибочную ROA как причину.

Отказ Cloudflare в 2025 году из-за файла конфигурации не был событием экспортной политики BGP.

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

Что публичная запись не доказывает

Посмертный анализ Cloudflare подробен, но это отчёт первой стороны. Он предоставляет самый сильный публичный источник о механизме и хронологии, оставляя при этом важный материал частным.

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

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

Посмертный анализ говорит, что инцидент был ошибкой Cloudflare, а не атакой. Он не устанавливает злонамеренного умысла, сокрытия, преступного поведения или индивидуальной вины. Он сам по себе не устанавливает правовой стандарт должной осмотрительности.

Раздел о мерах по исправлению фиксирует запланированные и немедленные работы. Он не доказывает, что каждый специфичный для MCP канареечный тест, переработка политики, автоматизация поэтапности или механизм подтверждения фиксации остаются развёрнутыми и эффективными сегодня. Текущая документация может объяснять архитектуру и средства контроля, но её не следует ретроспективно рассматривать как доказательство точного состояния 2022 года.

RIPE RIS и BGPStream могут предоставить независимые наблюдения маршрутизации, но доступные публичные доказательства не дают полной коллекторной реконструкции каждого локального для площадки отзыва. Внешняя видимость имеет ограничения.

Эти неизвестные не препятствуют анализу подотчётности. Они определяют вопросы, на которые должны ответить держатели доказательств, и не позволяют статье превратить технический посмертный анализ в бездоказательное обвинение.

Вопросы для операторов, советов директоров, клиентов и рецензентов

Сетевые операторы должны спросить:

• Какие политики маршрутизации различаются по архитектуре или роли маршрутизатора?
• Отрисовывает ли сухой прогон каждую затронутую роль?
• Какие префиксы должны оставаться анонсированными в процессе изменения?
• Версионированы ли списки обязательных префиксов, привязаны ли они к владельцу и сервисным зависимостям?
• Оценивает ли симулятор политики репрезентативные входные маршруты и порядок терминов?
• Является ли первый канареечный тест небольшим и репрезентативным для архитектуры?
• Какое окно наблюдения и автоматический шлюз останавливают продвижение?
• Могут ли операторы достичь устройств после того, как политика-кандидат убирает обычные управленческие маршруты?
• Восстанавливает ли подтверждение фиксации согласованное состояние множества устройств?
• Кто владеет правом на мутацию во время отката при инциденте?
• Могут ли команды с доступом только для чтения наблюдать маршруты и службы, не изменяя конфигурацию?

Советы директоров и комитеты по рискам должны спросить:

• Какая доля трафика зависит от самого загруженного общего домена контроля?
• Скрывает ли географическое распределение общую зависимость от политики или автоматизации?
• Какие зависимости управления, идентичности, DNS, электропитания и операторов связи разделяются основным и резервным путями?
• Какие доказательства демонстрируют повторяющиеся учения, а не однократное исправление?
• Как определены метрики воздействия на клиентов и как они сверены с доказательствами маршрутов и служб?

Клиенты должны спросить:

• Какие службы зависят от доступности Cloudflare, DNS, CDN, безопасности, доступа или путей к источникам?
• Может ли критическая коммуникация продолжаться, если провайдер и его путь статуса нарушены?
• Протестированы ли альтернативные провайдеры или прямые пути к источникам технически и операционно?
• Какие компромиссы безопасности возникают при обходе или переключении на резерв?
• Какие журналы устанавливают собственное воздействие на клиента, не предполагая универсального отказа?

Рецензенты и аудиторы должны спросить:

• Изучили ли они точную отрисованную политику, а не только запрос?
• Соответствовал ли канареечный тест топологии MCP и магистральной политике?
• Были ли локальные для площадки и управленческие маршруты включены в инварианты?
• Согласовывались ли независимые измерения и журналы маршрутизаторов?
• Могли ли два инженера перезаписать откаты друг друга?
• Привязано ли каждое заявление об исправлении к текущему результату теста и записи об исключениях?

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

Заключение: этап хорош ровно настолько, насколько хороша представляемая им система

Отказ Cloudflare в июне 2022 года начался с контролируемого изменения. Изменение имело тикет, сухой прогон, экспертную оценку и несколько этапов развёртывания. И всё же оно отозвало критические локальные для площадки префиксы, когда достигло архитектуры, которую ни один из ранних этапов не задействовал. Отзыв нарушил связь серверов и источников, отключил внутреннее перераспределение нагрузки, перегрузил меньшие кластеры и ухудшил путь управления, необходимый для восстановления. Параллельные откаты затем вызвали спорадическое повторение. [1]

Инцидент превратил поэтапное изменение BGP в тест на подотчётность. Этап не является доказательством только потому, что он идёт перед другим этапом. Он должен представлять релевантную топологию, роль политики, программное обеспечение, входные маршруты, концентрацию трафика и управленческую зависимость. Его критерии успеха должны включать маршруты и службы, которые должны оставаться доступными.

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

Сообщества BGP, RPKI, коллекторы маршрутов, тикеты и диаграммы — все вносят свой вклад в доказательства. Ничто из этого не заменяет операционный результат. Сообщества маркируют маршруты; порядок политики управляет решениями. RPKI проверяет авторизацию источника; он не доказывает доступность или корректность внутренней политики. Коллекторы наблюдают отдельные внешние представления; они не раскрывают каждую частную зависимость. Тикеты фиксируют намерение; они не сохраняют префикс анонсированным.

Этот уровень реальности — непреходящий урок. Распределённая сеть отказоустойчива, когда её работающие пути, политики контроля, управленческий доступ и механизмы отката сохраняют обслуживание при репрезентативном отказе. Доказательство — не название процесса. Доказательство — это маршрут, оставшийся доступным, канареечный тест, остановивший развёртывание, и восстановление, которое одна команда смогла завершить без того, чтобы другая команда его отменила.

Источники

1. Cloudflare, "Cloudflare outage on June 21, 2022":https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
2. Cloudflare, 2022 Impact Report:https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
3. Cloudflare, "Cloudflare Backbone: A Fast Lane on the Busy Internet Highway":https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
4. Cloudflare, "The backbone behind Cloudflare's Connectivity Cloud":https://blog.cloudflare.com/backbone2024/
5. Cloudflare, "Load Balancing without Load Balancers":https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
6. Cloudflare, CDN Reference Architecture:https://developers.cloudflare.com/reference-architecture/architectures/cdn/
7. Cloudflare, IP addresses and anycast network:https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
8. Cloudflare, Peering Policy:https://www.cloudflare.com/peering-policy/
9. PeeringDB, Cloudflare network record:https://www.peeringdb.com/net/4224
10. IETF / RFC Editor, RFC 4271, Border Gateway Protocol 4:https://www.rfc-editor.org/rfc/rfc4271
11. IETF / RFC Editor, RFC 1997, BGP Communities Attribute:https://www.rfc-editor.org/rfc/rfc1997
12. IETF / RFC Editor, RFC 8092, BGP Large Communities Attribute:https://www.rfc-editor.org/rfc/rfc8092
13. IETF / RFC Editor, RFC 8326, Graceful BGP Session Shutdown:https://www.rfc-editor.org/rfc/rfc8326
14. IETF / RFC Editor, RFC 7454, BGP Operations and Security:https://www.rfc-editor.org/rfc/rfc7454
15. IETF / RFC Editor, RFC 6811, BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
16. IETF / RFC Editor, RFC 6480, RPKI Architecture:https://www.rfc-editor.org/rfc/rfc6480
17. RIPE NCC, RIS Live Manual:https://ris-live.ripe.net/manual/
18. RIPE NCC, Routing Information Service:https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
19. CAIDA, BGPStream:https://bgpstream.caida.org/
20. Cloudflare, "What is BGP?":https://www.cloudflare.com/learning/security/glossary/what-is-bgp/