Переключение электропитания в Сан-Паулу проверяет, чего не может обещать латиноамериканская anycast-карта Cloudflare

Кратко

• Cloudflare раскрывает широкую латиноамериканскую географию городов и 500 Тбит/с глобальных внешних межсетевых соединений, но не публикует количество серверов, контрактную мощность, текущий запас портов или физически разнообразные маршруты на каждой латиноамериканской площадке.
• Публичные записи подтверждают существование коста-риканской компании, коста-риканских адресных ресурсов и развёртывания в Сан-Хосе, связанного с NIC.CR, но не подтверждают, что коста-риканская компания владеет каждой региональной стойкой, каналом и клиентским отношением под именем Cloudflare или является стороной по их договорам.
• Anycast может увести доступность от отказавшей точки, но успешное восстановление по-прежнему зависит от резервных вычислительных и сетевых мощностей, независимого питания площадки, уцелевшего городского волокна, исправных кросс-соединений и людей, уполномоченных восстанавливать затронутое оборудование.

Переключатель питания — то место, где карта заканчивается

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

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

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

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

Обычная интуиция подсказывает, что anycast решает проблему местоположения. Вобъяснении anycastCloudflare говорится, что один и тот же адрес может обслуживаться из нескольких точек и что вывод центра обработки данных из эксплуатации может заставить трафик пойти в соседний центр. Это описывает доступность. Но это не создаёт ни ваттов, ни циклов серверов, ни свободных портов на принимающей площадке. Если Сан-Паулу снимет маршруты, пользователи могут попасть в Рио-де-Жанейро, Куритибу, Порту-Алегри, Буэнос-Айрес, Сантьяго, Боготу, Майами или другую доступную точку — в зависимости от маршрутов, которые выберут их провайдеры доступа. У каждой альтернативы свои условия площадки, оператора связи и ёмкости.

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

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

Точка на карте города — это не область отказа

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

Сама Cloudflare объясняла, почему город — слишком крупная единица. В материале 2019 года омасштабировании глобальной сетикомпания сообщила, что в одном городе может быть до пяти различных развёртываний. Она также описывала планирование ёмкости по адресам, а не только по городам, и рассказывала об использовании подрядчиков и технического персонала на площадке для установки и подключения серверов. Это раскрытие было историческим и глобальным; это не текущая опись Латинской Америки. Его постоянная аналитическая ценность — в проводимом различии: одна метка мегаполиса может скрывать несколько физических адресов, а развёртывание в небольшом городе может находиться внутри интернет-провайдера, а не в крупном нейтральном кампусе.

Последний годовой отчёт компании даёт вторую половину границы. Вформе 10-K за 2025 годCloudflare сообщает, что на конец 2025 года её сеть размещалась на площадках колокации и партнёрских площадках интернет-провайдеров более чем в 330 городах и более чем в 125 странах. В ней говорится, что Cloudflare имеет электронный и, в меньшей степени, физический доступ к оборудованию, размещённому у третьих сторон, но не контролирует эксплуатацию этих площадок. В том же отчёте в числе рисков названы потеря электропитания, решения операторов связи, закрытие площадок, человеческий фактор и ограничения пропускной способности. Это не теоретические украшения вокруг точки; это граница её эксплуатации.

Охват бывает и в разных физических формах. В материале о расширении 2023 года сообщалось, что Cloudflare достигла более 300 городов, и описывалась новая площадка в Кампус-дус-Гойтаказис, Бразилия, соединённая с региональным провайдером, обслуживающим более 100 местных интернет-провайдеров. Компания сообщила, что после открытия площадки задержки существенно улучшились. Этототчёт о расширении географииподтверждает наличие партнёрской периферийной сети рядом с пользователями. Он не раскрывает мощность стоек, количество серверов, загрузку портов или маршрут, который принял бы нагрузку при отказе партнёрской площадки.

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

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

Коста-риканская компания — это граница, а не ярлык региональных активов

CloudFlare Latin America S.R.L — это реальное коста-риканское юридическое лицо, а не географический ярлык. Официальный вестник Коста-Рики зафиксировал корпоративное действие «Cloudflare Latin America S.R.L.» от января 2026 года и указал номер юридического лица 3-102-651761. Уведомление касалось официального электронного адреса и представительства резидента, а не сетевых активов, нозапись в вестнике— недавнее публичное доказательство того, что компания существует в корпоративной системе Коста-Рики.

Записи об интернет-номерах дают отдельную связь. Впубличной регистрации LACNIC для 190.93.240.0/20регистрантом названа CloudFlare Latin America S.R.L и указан адрес в районе Сан-Хосе, а операционные контакты ведут на сетевую эксплуатацию Cloudflare в Сан-Франциско. Это подтверждает связь между коста-риканской компанией и адресными ресурсами, используемыми в рамках более широкой операции Cloudflare. Но это не доказывает, что каждый адрес обслуживается только в Коста-Рике. Anycast намеренно позволяет анонсировать одни и те же сервисные адреса из нескольких мест, а регистрация адреса — это не опись стоек и не документ о праве собственности.

Клиентско-контрактная плоскость указывает в другую сторону. В стандартномсоглашении Enterprise Subscription AgreementCloudflare сказано, что публичный договор заключается между клиентом и Cloudflare, Inc., компанией из Делавэра. Оно также допускает использование аффилированными лицами и отдельные бланки заказов для аффилированных лиц. Правильный вывод ограничен: публичные стандартные условия не закрепляют обычные корпоративные подписки за коста-риканской компанией. Они не исключают другой бланк заказа, местную налоговую схему, аренду недвижимости, трудовой договор, соглашение с оператором связи или сделку аффилированного лица. Эти документы не являются публичными в рамках рассмотренных материалов.

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

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

Эта граница важна при отказе. Сторона, которая может попросить оператора проверить уровень сигнала, разрешить приезд технического персонала, одобрить аварийные расходы или обеспечить исполнение сервисных обязательств, может не совпадать со стороной, указанной в публичной записи об IP-адресах. Регуляторные требования могут относиться и к местной компании, даже если операционные решения принимаются в другом месте. Без контрактов, протоколов совета директоров или явных раскрытий об аффилированных лицах приписывание CloudFlare Latin America S.R.L регионального контроля вышло бы за пределы доказательств.

Поэтому наиболее обоснованное описание — многослойное. Cloudflare, Inc. отчитывается о консолидированной глобальной сети и её зависимости от сторонних площадок. AS13335 — глобальный маршрутный идентификатор. CloudFlare Latin America S.R.L — коста-риканская компания, связанная с ресурсами LACNIC и действующей записью в реестре Коста-Рики. Партнёром первого развёртывания в Сан-Хосе была названа NIC.CR. Эти слои очевидно относятся к одному сервису, но они не взаимозаменяемы.

Региональный сюжет, сжимающий их до утверждения «коста-риканская компания управляет Латинской Америкой», превратил бы связь в собственность, а собственность — в контроль без публичных доказательств.

Сан-Хосе доказывает присутствие, а не контроль

Cloudflare объявила о первом развёртывании в Коста-Рике в июне 2021 года. Вотчёте о расширении в Сан-Хосеговорилось, что площадка создана вместе с NIC.CR, которой управляет Academia Nacional de Ciencias. Это прямое свидетельство самой компании о развёрнутом присутствии и названном местном партнёре на тот момент. Текущая карта сети и компонент статуса указывают, что Сан-Хосе по-прежнему присутствует в действующей географии. Ни одно из раскрытий не называет здание, количество серверов, распределение мощности, список операторов связи, запас запчастей или договорного владельца оборудования.

NIC Costa Rica описывает CRIX как нейтральную точку обмена интернет-трафиком, которая позволяет местным сетям обмениваться трафиком в общей точке внутри страны, а не полагаться на международные каналы. Этоописание инфраструктуры NIC.CRобъясняет, почему площадка в Сан-Хосе может быть важна: локальный пиринг позволяет части коста-риканского трафика оставаться внутри страны, снижает зависимость от международного транзита для этого обмена и сокращает расстояние до кэшируемого или обрабатываемого контента. Оно не устанавливает текущий размер порта Cloudflare и не показывает, достигает ли каждый коста-риканский провайдер доступа Cloudflare через CRIX.

Текущая самостоятельно заполненнаязапись Cloudflare в PeeringDBопределяет AS13335 как глобальную anycast-сеть и перечисляет её публичные пиринговые связи и площадки. Запись включает действующее соединение с CRIX и на момент проверки указывала порт на бирже трафика ёмкостью 200 Гбит/с. PeeringDB — важное операционное свидетельство, потому что Cloudflare сообщает, что использует этот сервис для настройки пиринга. Однако его данные остаются самостоятельно заявленными и изменяемыми. Указанная скорость порта — это номинальная скорость интерфейса, а не фактический трафик, гарантированная пропускная способность, запас ёмкости или доказательство наличия второго физически разнообразного порта.

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

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

Таким образом, городской компонент может деградировать несколькими способами, которые бинарная точка на карте города описать не может.

Сан-Хосе также не может заменить региональную сеть. Даже если его локального трафика хватает на один порт биржи и одно развёртывание, это ничего не говорит о способности принять трафик Гватемалы, Панамы, северной части Южной Америки или Бразилии. Отсутствие опубликованных рядов данных о серверах и загрузке не позволяет сравнить установленное оборудование и аварийный резерв.

Видимый интерфейс биржи на 200 Гбит/с не следует прибавлять к глобальным показателям ёмкости, как если бы это был независимо используемый резерв: это один интерфейс в более широком наборе транзитных, частных и публичных соединений, и его фактическая нагрузка не раскрывается.

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

Сан-Паулу — это несколько залов, портов и коммерческих зависимостей

Сан-Паулу — самый наглядный публичный пример того, почему одна метка города может скрывать несколько разных операционных контуров. В записи Cloudflare в PeeringDB сеть указана на площадках Equinix SP2 и SP4 в Баруэри, Ascenty SPO02 и SPO03 в Озаску и Elea SPO1 в Сан-Паулу. Это не обязательно полная актуальная опись, а список площадок не показывает, сколько оборудования там действует. Но он показывает, что мегаполис нельзя ответственно рассматривать как единый зал.

Список точек клиентских стыковCloudflare за май 2026 года делает множественность ещё более явной. В нём названы несколько площадок в Сан-Паулу для клиентских стыков, включая Equinix SP2 и SP4, Ascenty SPO02 и SPO03, а также Elea SPO1. Документ — это список точек предоставления сервиса, а не карта внутренней периферийной или магистральной сети компании. Он показывает, где может заканчиваться клиентское соединение, но не показывает, что на каждой перечисленной площадке одинаковые вычислительные ресурсы периферии, что соединения в двух зданиях используют разные маршруты операторов или что каждая точка может заменить любую другую.

Раскрытия по площадкам добавляют физический контекст, но не закрывают разрыв, связанный именно с Cloudflare. Equinix сообщает, чтоSP4имеет резервирование ИБП и генераторов по схеме N+1, автономность генераторов не менее 30 часов при полной нагрузке, охлаждение N+1 и услуги технического персонала. Это характеристики здания, заявленные оператором. Они не показывают, какая цепь питания питает Cloudflare, какова загрузка её стоек, в каком состоянии обслуживания находится конкретный компонент, сколько топлива на площадке в конкретный день и не проходит ли канал Cloudflare через общую точку до входа на площадку.

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

Разнообразие в пределах мегаполиса помогает, только если зависимости действительно независимы. SP2 и SP4 могут быть отдельными площадками, но решающие пути включают электроснабжение, цепи генераторов и ИБП, залы meet-me, канализации, кольца операторов, коммутационную инфраструктуру бирж и магистральные выходы, соединяющие мегаполис с другими городами. Два клиентских стыка, заказанные в двух зданиях, всё равно могут сходиться на одном маршруте оператора. Два развёртывания Cloudflare могут разделять общие полномочия на изменения или региональную зависимость управления. Ни один публичный источник не отображает эти корреляции.

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

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

Пиринг локализует трафик, но может сконцентрировать его в мегаполисе

Вполитике пирингаCloudflare за декабрь 2025 года сказано, что AS13335 охватывает более 335 городов, компания просит пиров устанавливать сессии во всех общих точках и поддерживает частные стыки с шагом 100 Гбит/с для сетей, превышающих порог трафика. В ней также рекомендуется использовать все доступные адреса, если на бирже их несколько. Эти практики могут улучшить разнообразие путей и упростить перемещение трафика между портами. Они остаются условиями политики, а не доказательством того, что конкретный латиноамериканский пир заказал разнообразные кросс-соединения или сохранил достаточный незадействованный запас.

История строительства сети показывает, насколько разными могут быть локальные схемы. В Медельине Cloudflare сообщала, что запуск 2014 года опирался на Internexa и что локальный сервис передавался по наземной сети партнёра.Объявление о Медельинеописывало важное преимущество охвата, но и делало зависимость видимой: локальность трафика была связана с магистралью одного партнёра. Текущая сеть может быть шире; старый отчёт нельзя рассматривать как актуальную топологию.

В Кито компания сообщила, что площадка 2017 года стала возможна благодаря бирже NAP.EC и что дополнительные местные пиры позволили перевести трафик, который раньше обслуживался из Майами.Отчёт о Китодемонстрирует ценность местной биржи и прежнюю зависимость от зарубежного узла. И снова он не показывает сегодняшние стойки, порты или запасные точки. Он также иллюстрирует, что «локальное» относительно: развёртывание локально только для сетей, которые могут достичь его приемлемыми маршрутами.

Богота начинала с другого раскрытого физического устройства. Вотчёте Cloudflare о Боготе за 2018 годговорилось, что развёртывание располагалось в объекте уровня Tier III в зоне свободной торговли города. В текущих публичных записях Cloudflare указана на площадке Equinix BG2, но историческое описание не называет эту площадку, поэтому две записи нельзя без дополнительных доказательств соединить в непрерывную историю объекта. Можно сказать, что у Боготы было раскрытое физическое присутствие, а сейчас есть актуальная запись о площадке.

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

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

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

Anycast перенаправляет доступность, а не электричество и не резерв ёмкости

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

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

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

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

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

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

Таким образом, восстановление через anycast — это перенос спроса, а не исчезновение спроса. Если GRU обычно обрабатывает большой объём и снимает маршруты, этот объём должна обработать некоторая комбинация других площадок. Публичные данные не раскрывают штатную нагрузку GRU, долю, которую можно обслужить из кэша, состав продуктов, распределение по направлениям или загрузку принимающих площадок. Фраза «трафик может быть перенаправлен» точна, но неполна: она описывает перемещение, не измеряя точку приземления.

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

Установленная ёмкость — это не ёмкость для переключения при отказе

В апреле 2026 года Cloudflare объявила, что её внешние межсетевые соединения превысили 500 Тбит/с. Важно, что компания объяснила, что означает это число. Вматериале о 500 Тбит/ссказано, что это сумма задействованных портов, обращённых к транзитным провайдерам, частным пирам, интернет-биржам и клиентским стыкам в более чем 330 городах. Там также говорится, что это число не является пиковым трафиком и что разница поддерживает поглощение атак типа «отказ в обслуживании».

Это содержательная мера глобального масштаба. Это не таблица ёмкости Латинской Америки. Суммирование скоростей портов учитывает установленные интерфейсы, где бы они ни находились, хотя одни порты не могут заменить другие. Клиентский стык в Боготе не может автоматически принять публичный кэш-трафик, вытесненный из Сан-Паулу. Порт, подключённый к одному пиру, обслуживает трафик этого пира, а не всех пользователей. Два канала по 100 Гбит/с на одном маршрутизаторе или волоконном пути менее независимы, чем два канала на разных площадках.

Ёмкость портов также ничего напрямую не говорит о циклах серверов, хранилище, прогреве кэша или электроэнергии за маршрутизаторами.

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

Финансовое раскрытие аналогично агрегировано. Форма 10-K сообщает о 179,357 млн долларов безотзывных обязательств по пропускной способности и другим услугам колокации на конец 2025 года, распределённых по будущим периодам. Это доказывает, что компания закупает долгосрочную сетевую ёмкость и площади в значительных масштабах. Из отчёта её нельзя отнести на Латинскую Америку, и расходы — это не пропускная способность. Контракт может резервировать площадь, ещё не введённую в эксплуатацию, покрывать фиксированный срок, а не аварийный резерв, или включать продукты, ёмкость которых не взаимозаменяема.

Показатели площадок нужно держать в собственной категории. Схема питания N+1 и заявленная автономность генераторов SP4 описывают здание. Equinix сообщает, чтоBogotá BG2имеет резервирование ИБП и генераторов по схеме N+1, автономность генераторов 72 часа и круглосуточную поддержку.Спецификация Cirion для Лимы LIM1описывает питание по схеме 2N, охлаждение N+1 и более 2 200 квадратных метров колокации с приподнятым полом. Текущие публичные записи связывают Cloudflare с этими площадками или точками клиентских стыков, но рейтинги площадок — это не выделенные Cloudflare ресурсы. Они говорят, что спроектировал оператор, а не сколько мощности или площади закупила Cloudflare.

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

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

Восстановление проходит через персонал на площадке, операторов связи и полномочия на изменения

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

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

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

Для латиноамериканских периферийных площадок форма 10-K сообщает, что оборудование за рубежом могут устанавливать и обслуживать сторонние подрядчики и что Cloudflare не контролирует эксплуатацию сторонних площадок. Публичная информация о поддержке площадок помогает выявить одну человеческую зависимость. Всведениях Equinix о доступности поддержки колокациидля Bogotá BG2 указано круглосуточное присутствие операционного персонала на площадке, тогда как на других объектах оно различается. Это не раскрывает объём сервисных прав Cloudflare, целевое время реакции, наличие запчастей или то, уполномочен ли техник прикасаться к конкретному устройству. Это показывает, почему персонал должен входить в физическую оценку.

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

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

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

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

Кто первым ощущает отказ

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

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

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

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

Втекущей таблице поддержки регионовБразилия указана как управляемый регион Regional Services. В ней нет единого управляемого региона, охватывающего всю Латинскую Америку, хотя для некоторых опций могут быть доступны индивидуальные конфигурации. Поэтому обязательство локализации в Бразилии делает число и распределение исправных бразильских площадок особенно важными. Ёмкость в Майами, Боготе или Сан-Хосе может быть физически достижимой, но недопустимой для расшифровки при такой настройке. Конфигурация продукта каждого клиента имеет значение.

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

В форме 10-K Cloudflare признаёт, что клиенты могут потерять доступ к своим сетям или интернету до тех пор, пока сервис не вернётся или они не задействуют обходной путь.

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

Каких доказательств не хватает для заявления об отказоустойчивости

Публичных доказательств достаточно, чтобы подтвердить значительное латиноамериканское операционное присутствие. Cloudflare указывает широкую географию городов. Она сообщает о развёртывании в Сан-Хосе с NIC.CR и об активном компоненте статуса там. Её запись в PeeringDB показывает действующие отношения с биржами и площадками. Материалы по клиентским стыкам называют конкретные площадки от Сан-Паулу до Боготы и Лимы. Операторы площадок публикуют характеристики питания, охлаждения и поддержки. Cloudflare сообщает о 500 Тбит/с внешних межсетевых соединений и открыто описывает риски сторонних площадок, операторов и электропитания.

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

Физическая независимость тоже требует доказательств. Для каждой пары номинально разнообразных площадок полезное раскрытие должно было бы указать раздельные электроснабжение, цепи ИБП и генераторов, вводы волокна, залы meet-me, коммутационные инфраструктуры бирж, маршруты операторов и магистральные выходы. Оно должно было бы указать, где сходятся два «разнообразных» канала. Оно должно было бы отличать отдельное здание от отдельного мегаполиса, а отдельный мегаполис — от отдельного международного пути захода.

Текущая иллюстрация магистрали прямо не показывает все маршруты, а маркетинговые материалы площадок не отражают схемы каналов конкретных клиентов.

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

Доказательства восстановления включали бы путь оповещения от площадки до Cloudflare, обязательства по реагированию технического персонала, расположение запчастей, эскалацию к операторам, пороги снятия маршрутов, порядок перезапуска и подтверждение учений на уровне всей площадки. Инциденты в Орегоне показывают, почему эти детали важны, но они не устанавливают показатели Латинской Америки. Рейтинг площадки N+1 или 2N — это входной параметр, а не результат. Испытания должны включать потерю всего зала, потерю операторского пути в мегаполисе и потерю разрешённого региона локализации, а не только отдельных устройств.

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

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

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

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

Пока они не раскрыты или независимо не измерены, честное прочтение латиноамериканской периферии Cloudflare — не «карта лечит сама себя», а «карта показывает, где должна ответить тщательно поддерживаемая физическая цепочка».