Краткое изложение

  • Cloudflare сообщает, что 2 ноября 2023 года её плоскость управления и аналитические сервисы были нарушены, тогда как основной трафик периферийной сети продолжал передаваться [1].
  • Заявленным триггером стала последовательность сбоев электропитания на площадке PDX-04 — дата-центре в Орегоне, где размещались критически важные зависимости плоскости управления [1][3].
  • Инцидент обнажил скрытые зависимости в Kafka, ClickHouse, аутентификации, внутренних инструментах и других системах, необходимых для восстановления или наблюдения за частями сервиса [1].
  • Второй сбой электропитания на той же площадке в 2024 году стал практической проверкой подготовки Cloudflare по процедуре Code Orange и снизил влияние на плоскость управления [2].
  • Достоверное закрытие инцидента должно доказать, что конфигурация, аналитика, идентификация, внутренние инструменты и видимые клиентам функции управления могут пережить полную потерю площадки, а не только то, что периферийная сеть продолжает обслуживать кэшированный или уже настроенный трафик.

Что произошло

В ноябрьском разборе инцидента 2023 года Cloudflare сообщает, что сбой начался 2 ноября в 11:43 UTC. Компания охарактеризовала пострадавший уровень как плоскость управления и аналитические сервисы. Это означает, что клиенты и операторы могли испытывать трудности с изменением настроек, просмотром аналитики или использованием административных функций, даже когда распределённая периферийная сеть продолжала обрабатывать трафик, не требующий нового решения плоскости управления [1].

Физической отправной точкой стала площадка PDX-04 в Орегоне. Cloudflare сообщает, что у Portland General Electric произошло внеплановое техническое обслуживание, затронувшее один независимый ввод электропитания в здание. Затем компания описала последовательность, включавшую вводы от коммунальной сети, батареи, генераторы, доступ в здание, замену автоматических выключателей и поэтапное восстановление серверов [1]. В публичном отчёте Baxtel сбой также связывается с отказом электропитания в дата-центре Flexential в Хилсборо, штат Орегон, и приводится то же объяснение Cloudflare о событии с вводом от коммунальной сети [3].

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

Скрытая зависимость не сводилась к одной машине

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

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

Разбор инцидента также разделяет то, что продолжало работать, и то, что вышло из строя. Cloudflare сообщает, что её сеть продолжала обслуживать большую часть клиентского трафика. Это не следует сводить к выводу «сбой был незначительным». Такая картина показывает проблему расщеплённой подотчётности: плоскость данных может выглядеть устойчивой, тогда как плоскость управления остаётся хрупкой. Зрелая проверка после инцидента должна рассматривать оба уровня по отдельности.

Аварийное восстановление — это проверка работающим кодом

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

У восстановления была и проблема нагрузки. Когда сервисы начали возвращаться, пользователи и внутренние системы могли создать лавинообразную нагрузку: множество клиентов одновременно переподключались, обновляли страницы или повторяли запросы. Это вопрос ёмкости плоскости управления. Недостаточно, чтобы резервная система просто запустилась. Она должна поглотить накопившийся объём, сохранить корректность и не превратить восстановление во второй сбой [1].

Продолжение 2024 года полезно тем, что даёт публичное сравнение. Cloudflare сообщает, что на той же площадке через четыре месяца произошёл ещё один крупный сбой электропитания. На этот раз компания задействовала процедуру Code Orange — подготовленный внутренний режим реагирования на инциденты — и сообщила, что ранее внесённые изменения снизили влияние на клиентов [2]. Это не доказывает, что все зависимости устранены. Но это показывает правильную модель доказательства: произошёл похожий сбой, оператор внёс изменения, и второй результат оказался существенно иным.

Физическая инфраструктура по-прежнему важна для облачного сервиса

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

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

Отчёт Baxtel важен здесь потому, что помещает инцидент в контекст оператора дата-центра и включает публичный ответ Flexential о сценариях с электросетью и договорённостях о поддержке энергосистемы [3]. Не следует преувеличивать этот ответ до полноценного установления первопричины. Однако он показывает, что цепочка восстановления Cloudflare пересекала организационные границы, а именно в таких местах записи о подотчётности часто становятся неполными.

Доктринальный уровень — операционная непрерывность

Поверхность Heng.lu — это непрерывность работы оператора и идентичность хостинга и сети. Справочник или публичная страница статуса может указать Cloudflare как оператора, а PDX-04 — как зависимость от площадки. Такие записи не доказывают, что состояние плоскости управления, учётные данные, аналитические данные и внутренние инструменты способны пережить полную потерю площадки. Реальный слой — это доказательства фактического восстановления.

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

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

Что должна включать достоверная проверка на повторение инцидента

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

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

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

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

Наконец, сравнивайте следующий инцидент с предыдущим. Отчёт о Code Orange 2024 года — полезная модель, поскольку он связывает похожее физическое событие с изменённым реагированием и сниженным влиянием [2]. Каждый последующий повторный случай следует оценивать так же: какой прежний урок был проверен, какой механизм контроля устоял, какая новая зависимость проявилась и что клиенты по-прежнему могли делать.

За чем следить дальше

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

Также следите за тем, станет ли Code Orange повторяемой публичной моделью доказательства. Событие марта 2024 года указывает на то, что после ноября 2023 года компания улучшила подготовку [2]. Более сильным сигналом была бы устойчивая серия учений и инцидентов, показывающая, что конфигурация, аналитика, внутренние инструменты и клиентские функции управления переключаются на резерв независимо от PDX-04 или любой отдельной площадки.

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

Источники

  1. https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/
  2. https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested/
  3. https://baxtel.com/news/cloudflare-blames-flexential-dc-outage-for-its-service-disruption