Tempest Hosting, LLC продаёт хостинговые мощности, которые по-прежнему зависят от стоек, транзита и ремонтных окон

Краткое содержание

• Tempest Hosting, LLC имеет реальную публичную операционную поверхность: AS36231 анонсируется, PeeringDB указывает Tempest как глобальную контент-сеть с объёмом трафика 1–5 Тбит/с, восемью точками присутствия и набором AS, а RIPEstat на снимке 15 июля 2026 года зафиксировал 19 префиксов IPv4 и 20 префиксов IPv6.
• Более полезный вопрос с точки зрения рисков не в том, существует ли Tempest, а в том, какие клиентские нагрузки зависят от каких стоек, маршрутизаторов, местных запасов запчастей, вышестоящих операторов связи и процедур передачи поддержки, когда площадка в Амстердаме, Далласе, Лондоне, Франкфурте, Майами, Чикаго или Сиднее становится слабым звеном.
• Публичные записи о плановых работах и инцидентах здесь необычайно полезны: Tempest раскрыла миграцию ядра сети в Лондоне, модернизацию стоек и маршрутизирующего оборудования в Далласе, сбой вышестоящего оператора связи в Далласе, проблему с IP во Франкфурте и аварию в Амстердаме, связанную с отказом коммутатора ядра и задержкой поставки запасной части.
• Доказательства подтверждают высокую оценку сетевого охвата, но не безоговорочное заявление о ёмкости. Установленные префиксы, диапазоны трафика PeeringDB, тестовые файлы и списки площадок не доказывают наличие свободной ёмкости для клиентов, договорных прав на электропитание, запасённого сменного оборудования или гарантированного времени миграции.

Хостинговая компания может быть реальной и при этом непрозрачной на операционном уровне

Tempest Hosting, LLC относится к провайдерам, чей публичный след выглядит намного крупнее, чем у небольшого веб-хостинга из брошюры, но при этом самые дорогие вопросы остаются за пределами публичного поля. Публичная идентичность начинается со страницы компании всправочнике BTW, однако проверка инфраструктуры начинается с AS36231.Обзор ASв RIPEstat определяет держателя как TEMPEST-HOSTING — Tempest Hosting, LLC и отмечает, что автономная система анонсировалась в окне запроса 15 июля 2026 года. Данные WHOIS, полученные из ARIN и показанные черезпредставление WHOISв RIPEstat, содержат имя AS TEMPEST, дату регистрации в мае 2020 года и комментарий, указывающий на tempest.net. Сами по себе эти факты не описывают продукт, но они фиксируют нумерованную маршрутную границу, которую можно измерять независимо от маркетинговых формулировок.

Эта граница не пуста.Представление анонсируемых префиксовв RIPEstat на использованном здесь снимке вернуло 40 записей в хронологии префиксов.Представление статуса маршрутизацииразделило их на 19 префиксов IPv4, 4864 адреса IPv4, 20 префиксов IPv6 и 65 538 видимых единиц IPv6, эквивалентных /48, с полной видимостью от 326 из 326 пиров RIS IPv4 и 322 из 322 пиров RIS IPv6.Представление соседейв RIPEstat показало пять наблюдаемых соседей, включая четыре отношения слева и одно отношение справа. Репрезентативная проверка RPKI для 104.152.143.0/24 вернуладействительный результат происхождения маршрута. В совокупности эти записи говорят о том, что у Tempest есть активная публичная граница маршрутизации. Они не говорят, сколько клиентов находится за каждой границей, какие сервисы используют адреса, выданные провайдером, или насколько число префиксов соответствует парку серверов.

Следующий слой дают записи о взаимодействии сетей. PeeringDB указываетTempest Hosting, LLCкак AS36231 с веб-сайтомhttps://tempest.net, набором IRR AS-TEMPEST, типом Content, глобальным охватом, сбалансированным соотношением, открытой политикой пиринга и диапазоном трафика 1–5 Тбит/с.Сетевой APIPeeringDB в профиле отдал 26 префиксов IPv4 и 30 префиксов IPv6, аAPI площадокперечислил восемь площадок: Telehouse London Docklands North, NTT Frankfurt 1, Iron Mountain Amsterdam AMS-1, CoreSite Miami MI1, Equinix SY3 Sydney, ColoCrossing CHI1, IP House London и 365 Data Centers Richardson TX1. СоответствующийAPI подключений к точкам обменавернул ноль публичных записей IX LAN для этого сетевого объекта PeeringDB. Такое сочетание показательно: Tempest демонстрирует присутствие на нескольких площадках, но публично указанная поверхность взаимодействия скорее сконцентрирована на площадках, чем на портах точек обмена.

Для покупателей это различие важно. Запись о площадке может означать маршрутизатор, серверные стойки, точку передачи трафика, клиентский сервисный узел или ещё не подтверждённое присутствие. Диапазон трафика в PeeringDB сообщается самим оператором и намеренно груб. Число префиксов может включать управляющие, anycast-адреса, адреса игровых серверов, клиентские или резервные пространства. Правильный вопрос не «есть ли у Tempest глобальная инфраструктура?» — публичные данные это подтверждают.

Правильный вопрос: «какие физические и договорные части превращают оплаченный сервер в пригодную и восстанавливаемую ёмкость именно на том рынке, где её покупает клиент?»

Видимый охват глобален, но операционная поверхность локальна

Собственная страница статуса Tempest необычно конкретна.Текущая страница статуса15 июля 2026 года показывала Лондон, Франкфурт, Амстердам, Чикаго, Майами, Даллас и Сидней как работающие площадки, сгруппированные по Европе, Северной Америке и Океании. Там же были приведены показатели доступности за 30 дней: Лондон, Чикаго, Майами и Сидней — 100,0 %, Даллас — 99,4 %, Франкфурт — 97,4 % и Амстердам — 84,6 %. Это не формальные аудированные показатели доступности, и они охватывают только компоненты платформы, представленные на этой странице. Тем не менее они делают географию сервиса более осязаемой, чем у обычного хостингового бренда.

Looking glass Tempestдобавляет вторую осязаемую точку. Он показывает живую диагностику из точек присутствия и на зафиксированной странице указывал тестовую площадку в Далласе с тестовым IPv4 104.152.143.215 и дата-центром Equinix DA1. Там же были доступны тестовые файлы размером 100 МБ, 1 ГБ, 5 ГБ и 10 ГБ. Данные looking glass полезны, поскольку позволяют проводить внешние измерения, но они узки: тестовый файл доказывает, что одна диагностическая конечная точка существует и доступна оттуда, откуда пользователь её проверяет. Он не доказывает, что весь парк клиента находится в той же площадке, что у всех продуктов одинаковый маршрут через операторов связи или что сервер, заказанный в другом городе, наследует диагностический маршрут Далласа.

Список площадок PeeringDB делает географию шире, чем looking glass. Telehouse London Docklands North — это насыщенная операторами связи лондонская площадка;дата-центр NTT Frankfurt 1представлен NTT как большой кампус с 70,1 МВт критической ИТ-нагрузки и доступом к DE-CIX;Iron Mountain Amsterdam AMS-1описан как кампус в Харлеме с текущей мощностью и планируемым расширением;CoreSite Miami MI1— это специально построенная площадка в Майами, соединённая с MI2 освещённым оптоволокном; наконец, сама страница Tempest называет Сидней, Чикаго и Даллас работающими локациями. Эти факты о площадках помогают понять, где в сервис входят ограничения по электропитанию, охлаждению, зоне встречи операторов, кросс-коннектам и локальному доступу. Они не доказывают точный размер клетки Tempest, зарезервированную мощность, плотность стоек или соглашение об удалённых руках на каждой отдельной площадке.

Это и есть повторяющаяся проблема ёмкости. Установленная ёмкость — то, что сеть или площадка теоретически способны поддерживать. Полезная ёмкость — то, что можно продать, запитать, охладить, пропатчить, отслеживать, выставить в счёт и восстановить, не нарушив ограничения вышестоящего оператора, стойки, питания, поддержки или складского запаса оборудования. Глобальный охват в PeeringDB и восемь записей о площадках могут сделать провайдера более устойчивым, чем хост с одной площадкой. Но они же создают больше мест, где клиенту нужно задавать вопросы о конкретной площадке. В каком городе находится основной сервер?

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

Миграция в Лондоне показывает, чего на самом деле стоит отказоустойчивость

Самый наглядный публичный пример физической зависимости Tempest — завершённаямодернизация сети в Лондоне. Tempest сообщила, что расширяется в кампус дата-центра Telehouse London и переносит туда базовую маршрутизирующую инфраструктуру. Также было сказано, что работы потребуют отзыва BGP-анонсов с существующего граничного маршрутизатора, включения нового маршрутизатора Telehouse, анонсирования пространства IP-адресов и проверки маршрутизации у вышестоящих провайдеров и пиров. Клиентов предупреждали о возможных обрывах соединения, потере пакетов и кратковременных перебоях, пока распространяется маршрутизация и проводятся тесты.

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

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

Это же уведомление объясняет разницу между заявлениями о резервировании и доказательством резервирования. Tempest описала такие преимущества, как повышенная отказоустойчивость, более прочная связность, меньшая задержка и лучшая основа для будущего роста. Это правдоподобные преимущества присутствия в Telehouse, тем более что London Docklands — одна из главных точек межсетевого обмена в Европе. Однако уведомление о плановых работах остаётся гипотезой, пока клиент не увидит, как система ведёт себя при сбое. Есть ли в Лондоне более одного вышестоящего оператора? Проверяются ли политики маршрутизации до окна изменений?

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

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

Даллас показывает уровни стойки, шкафа и вышестоящих операторов

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

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

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

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

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

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

Амстердам — урок про запасные части

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

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

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

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

В Амстердаме собственный публичный язык инцидента Tempest говорит, что размещение запасных частей на тот момент не было завершено.

Это не делает площадку в Амстердаме непригодной. Это делает вопрос должной осмотрительности более острым. Покупатель может спросить, была ли отсутствующая запчасть разовой проблемой раннего этапа, есть ли теперь на площадке запасная замена и нет ли похожего пробела в других новых городах. Ещё покупатель может спросить, как сервисы разделены по городам: если узел в Амстердаме откажет, сможет ли клиент перейти в Лондон, Франкфурт или другой регион Tempest, не меняя архитектуру приложения? Находятся ли резервные копии уже за пределами площадки? Переносимы ли IP-адреса или только данные?

Может ли клиент восстановиться из снапшота, и если да, насколько вырастет очередь, когда откажет целый город?

Страница статуса превращает аптайм в инженерное доказательство

Запись статуса Tempest ценна тем, что превращает доступность в датированную операционную историю, а не в обещание бренда.Страница статусане просто сообщала, что у компании есть глобальные локации. Она показывала отдельные сервисные зоны для Лондона, Франкфурта, Амстердама, Чикаго, Майами, Далласа и Сиднея и отражала очень разные 30-дневные показатели на момент анализа. Лондон, Чикаго, Майами и Сидней показывались на уровне 100,0 %. Даллас — на уровне 99,4 %. Франкфурт — на уровне 97,4 %. Амстердам — на уровне 84,6 %. Эти цифры не следует рассматривать как аудированную производительность уровня обслуживания, потому что публичные страницы статуса ведутся провайдером и сами определяют отслеживаемые компоненты. Они всё же полезны, поскольку не позволяют воспринимать охват как единое гладкое облако. У каждого города своя история обслуживания, сбоев и восстановления.

Это особенно важно для покупателя, сравнивающего локации. Если у провайдера семь городов, клиент может предположить, что города взаимозаменяемы. Публичная запись Tempest говорит против этого предположения. 30-дневный показатель Амстердама снизился из-за раскрытого отказа коммутатора ядра и проблемы с поиском замены. В Далласе были и плановая модернизация шкафов и маршрутизирующего оборудования, и инцидент с вышестоящим оператором. Во Франкфурте была проблема с IP. В Лондоне — плановая миграция маршрутизатора ядра в кампус Telehouse.

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

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

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

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

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

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

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

Франкфурт и Майами показывают, почему качество площадки не доказывает качество провайдера

Франкфурт полезен тем, что в публичной записи есть два разных типа доказательств. PeeringDB указывает NTT Frankfurt 1 как площадку присутствия Tempest, а страница площадки NTT описывает большой кампус с операторско-нейтральной связностью, доступом к DE-CIX, резервированными залами встречи операторов и значительным энергетическим контуром. Отдельноинцидент во Франкфуртеот Tempest сообщал, что проблема с IP затронула франкфуртскую локацию и позже была устранена. Площадка может быть большой и хорошо подключённой, но сервис клиента по-прежнему зависит от собственного оборудования Tempest, плана адресации, выбора вышестоящих операторов и реакции поддержки внутри этой площадки или вокруг неё.

Та же логика действует в Майами. Страница CoreSite MI1 описывает специально построенный дата-центр в центре Майами, соединённый с MI2 освещённым оптоволокном и спроектированный для суровых штормовых условий. Это ценный физический контекст. Он объясняет, почему Майами может быть разумной локацией для контента, игр или трафика, ориентированного на Америку. Сам по себе он ничего не говорит о точном распределении шкафов, кросс-коннектов, энергопотреблении или пути миграции клиентов у Tempest. Сильная площадка может размещать слабое развёртывание; скромная площадка может размещать тщательно спроектированное развёртывание.

Публичные страницы площадок задают физическую оболочку, а не качество исполнения провайдера.

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

Практический шаг должной осмотрительности — разделить сервис на уровни. Уровень компании — Tempest Hosting, LLC. Уровень маршрутизации — AS36231 и наблюдаемые соседи. Уровень площадки — названные объекты в PeeringDB и на странице статуса Tempest. Уровень продукта — выделенная, бюджетная, blade, виртуальная выделенная или colocation-ёмкость. Уровень восстановления — то, что происходит, когда уровни продукта и площадки не совпадают: отказывает коммутатор ядра, у оператора происходит сбой или оборудование нужно физически переместить.

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

Разнообразие маршрутов видно, а физическое разнообразие — нет

Публичные данные о маршрутизации — одна из сильных сторон этого случая. RIPEstat на снимке видел полную видимость AS36231, а страницаAS Rankот CAIDA идентифицировала Tempest Hosting, LLC, США, небольшую клиентскую конус и ограниченную степень AS. СтраницаAS36231 на IPinfo,представление BGPHurricane Electric и BGP.tools предлагают независимые перекрёстные проверки сетевой идентичности и префиксов. Ни один из этих сервисов не видит всей договорной правды, но они снижают вероятность того, что сеть существует лишь номинально.

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

Разнообразие маршрутов — необходимый сигнал; разнообразие физических путей — отдельное доказательство.

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

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

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

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

Классы продуктов отказывают по-разному

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

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

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

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

Тем не менее она показывает, почему клиентам стоит спрашивать, может ли VDS перемещаться между хостами или городами, находятся ли резервные копии на той же площадке или на другой, и следует ли IP-адрес за нагрузкой при восстановлении.

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

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

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

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

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

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

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

Влияние на клиента зависит от нагрузки, а не только от доступности

Формулировки статуса Tempest указывают на несколько классов клиентов: корпоративные клиенты на выделенных серверах, пользователи бюджетных или blade-серверов, пользователи виртуальных выделенных серверов, клиенты colocation и игроки, подключённые к игровым нагрузкам. Эти группы по-разному переживают одно и то же событие инфраструктуры. Трёхчасовое плановое отключение питания может быть приемлемым для тестового сервера и неприемлемым для продакшн-базы данных. Короткий переход маршрута может быть безвредным для статического сайта и разрушительным для игровой сессии.

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

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

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

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

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

Какие доказательства усилили бы заявление о ёмкости

Tempest уже проходит первый барьер доказательств. AS36231 активен, набор префиксов виден, профиль PeeringDB поддерживается, страница статуса называет локации и инциденты, а looking glass показывает реальную тестовую точку. Более сильное доказательство находилось бы ближе к клиентскому договору. Оно показало бы, какие продукты доступны в каких городах, какие площадки обслуживают какие продукты, какие вышестоящие операторы присутствуют в каждом городе, является ли разнообразие маршрутов разнообразием на уровне метро и какое запасное оборудование теперь есть на новых локациях.

Провайдеру не нужно публиковать каждую операционную деталь в открытом интернете. Некоторые сведения чувствительны с точки зрения безопасности или коммерчески чувствительны. Но клиенты всё равно могут попросить закрытую архитектурную записку, матрицу эскалации поддержки, актуальный отчёт о доступности, список окон обслуживания, затрагивающих их класс сервиса, и тест восстановления. Они также могут попросить объяснить, как диапазон трафика 1–5 Тбит/с в PeeringDB соотносится с доступной клиенту свободной ёмкостью. Грубый диапазон трафика — не обещание ёмкости.

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

То же относится к электропитанию площадок. NTT Frankfurt, Iron Mountain Amsterdam, CoreSite Miami и другие операторы площадок публикуют впечатляющие характеристики мощности и связности. Клиенту Tempest всё равно нужно знать выделенную Tempest мощность, уровень резервирования, плотность стоек и процедуру удалённых рук внутри площадки. У площадки могут быть свободные мегаватты, а в конкретной клетке — ни свободного места, ни совместимого кабеля питания. У площадки может быть много операторов связи, а продукт клиента использует один маршрут по умолчанию.

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

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

Узкий вердикт

Tempest Hosting, LLC следует рассматривать как реального инфраструктурного оператора с измеримой публичной сетью, а не как чисто тонкий след. Доказательства необычно полезны для частного хостинг-провайдера: AS36231 виден; RIPEstat показывает актуальное пространство IPv4 и IPv6; PeeringDB содержит глобальный профиль, диапазон трафика 1–5 Тбит/с и восемь площадок; страница статуса называет несколько работающих городов; а записи об инцидентах раскрывают конкретные пути отказа в маршрутизаторах, вышестоящих операторах связи, шкафах и запасном оборудовании. Этого достаточно, чтобы анализировать провайдера как инфраструктуру.

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

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

Для клиентов практический тест прост в формулировке и труден в исполнении: попросить Tempest сопоставить конкретный покупаемый продукт с городом, площадкой, путём к вышестоящему оператору, очередью поддержки, запасом запчастей и планом миграции. Затем сравнить этот ответ с публичными данными о маршрутах из RIPEstat, PeeringDB, BGP.tools и страницы статуса Tempest. Если ответ согласован и процедура восстановления протестирована, охват Tempest может поддерживать серьёзные нагрузки.

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