Tempest Hosting, LLC vende capacidade hospedada que ainda depende de racks, trânsito e janelas de manutenção

Resumo

• A Tempest Hosting, LLC possui uma superfície operacional pública real: o AS36231 é anunciado, o PeeringDB lista a Tempest como uma rede de conteúdo global com 1 a 5 Tbps de tráfego, oito presenças em instalações e um conjunto AS, enquanto o RIPEstat observou 19 prefixos IPv4 e 20 prefixos IPv6 no instantâneo de 2026-07-15.
• A pergunta de risco mais útil não é saber se a Tempest existe, mas quais cargas de trabalho do cliente dependem de quais racks, roteadores, pools locais de peças de reposição, provedores upstream e transferências de suporte quando um site como Amsterdã, Dallas, Londres, Frankfurt, Miami, Chicago ou Sydney se torna o ponto fraco.
• Os registros públicos de manutenção e incidentes são particularmente úteis aqui: a Tempest divulgou uma migração de roteador central em Londres, uma atualização de gabinete e equipamento de roteamento em Dallas, uma falha de provedor upstream em Dallas, um problema de IP em Frankfurt e uma parada em Amsterdã relacionada a uma falha do switch central e a um atraso no fornecimento de peças de reposição.
• As evidências apoiam uma alta classificação de pegada de rede, mas não uma alegação de capacidade ilimitada. Os prefixos instalados, as faixas de tráfego do PeeringDB, os arquivos de teste e as listas de instalações não comprovam a margem de manobra disponível para o cliente, os direitos contratuais de energia, o hardware de reposição em estoque ou o tempo de migração garantido.

Uma empresa de hospedagem pode ser real e ainda assim opaca no nível operacional

A Tempest Hosting, LLC é o tipo de provedor cuja pegada pública parece muito maior do que um pequeno prospecto de hospedagem web, mas que ainda assim deixa as perguntas mais caras fora da vista do público. A identidade pública começa com a página da empresa nodiretório BTW, mas o teste de infraestrutura começa com o AS36231. Avisão ASdo RIPEstat identifica o titular como TEMPEST-HOSTING - Tempest Hosting, LLC e marca o sistema autônomo como anunciado na janela de consulta de 2026-07-15. Os dados WHOIS derivados da ARIN disponibilizados viavisão WHOISdo RIPEstat fornecem o nome AS TEMPEST, uma data de registro em maio de 2020 e um comentário apontando para tempest.net. Esses fatos não descrevem um produto por si só, mas estabelecem uma fronteira de roteamento numerada que pode ser medida independentemente da linguagem comercial.

Essa fronteira não está vazia. Avisão de prefixos anunciadosdo RIPEstat retornou 40 entradas de linha do tempo de prefixos no instantâneo utilizado aqui. Suavisão de status de roteamentoseparou isso em 19 prefixos IPv4, 4.864 endereços IPv4, 20 prefixos IPv6 e 65.538 unidades IPv6 visíveis equivalentes a /48, com visibilidade completa de 326 dos 326 pares RIS IPv4 e 322 dos 322 pares RIS IPv6. Avisão de vizinhosdo RIPEstat mostrou cinco vizinhos observados, incluindo quatro relações esquerda e uma relação direita. Uma verificação RPKI representativa para 104.152.143.0/24 retornou umresultado de origem de rota válida. Juntos, esses registros indicam que a Tempest possui uma borda de roteamento pública ativa. Eles não dizem quantos clientes estão por trás de cada borda, quais serviços usam endereços atribuídos pelo provedor, ou se o número de prefixos corresponde corretamente ao inventário de servidores.

O registro de interconexão fornece a próxima camada. O PeeringDB lista aTempest Hosting, LLCcomo AS36231, com o sitehttps://tempest.net, conjunto IRR AS-TEMPEST, tipo Conteúdo, escopo global, proporção equilibrada, política de troca aberta e uma faixa de tráfego de 1 a 5 Tbps. AAPI de rededo PeeringDB forneceu 26 prefixos IPv4 e 30 prefixos IPv6 no perfil, enquanto aAPI de instalaçãolistou oito instalações: Telehouse London Docklands North, NTT Frankfurt 1, Iron Mountain Amsterdam AMS-1, CoreSite Miami MI1, Equinix SY3 Sydney, ColoCrossing CHI1, IP House London e 365 Data Centers Richardson TX1. AAPI de anexo de trocacorrespondente retornou zero entradas de LAN de troca pública para este objeto de rede do PeeringDB. Essa combinação é reveladora: a Tempest apresenta uma pegada de múltiplas instalações, mas a superfície de interconexão listada publicamente é rica em instalações em vez de portas de troca.

Para os compradores, essa distinção importa. Uma entrada de instalação pode significar um roteador, racks de servidores, um handoff de transporte, um nó de serviço ao cliente ou uma presença em espera. Uma faixa de tráfego do PeeringDB é autodeclarada e voluntariamente aproximada. Um número de prefixos pode incluir espaço de gerenciamento, anycast, servidor de jogos, cliente ou reserva. A pergunta certa não é "A Tempest tem infraestrutura global?" As evidências públicas apoiam isso.

A pergunta certa é "quais partes físicas e contratuais transformam um servidor pago em capacidade utilizável e restaurável no mercado exato onde o cliente compra?"

A pegada visível é global, mas a superfície operacional é local

A própria página de status da Tempest é incomumente concreta. Apágina de status atualmostrava Londres, Frankfurt, Amsterdã, Chicago, Miami, Dallas e Sydney como operacionais em 2026-07-15, agrupados em Europa, América do Norte e Oceania. Ela também exibia números de disponibilidade de 30 dias: Londres, Chicago, Miami e Sydney em 100,0%, Dallas em 99,4%, Frankfurt em 97,4% e Amsterdã em 84,6%. Esses não são números de disponibilidade auditados formalmente, e cobrem apenas os componentes da plataforma representados nessa página. No entanto, eles tornam a geografia do serviço mais tangível do que uma marca de hospedagem genérica faria.

Olooking glass da Tempestadiciona um segundo ponto tangível. Ele expõe diagnósticos ao vivo dos pontos de presença e, na página capturada, listava uma localização de teste em Dallas com o IPv4 de teste 104.152.143.215 e o data center Equinix DA1. Ele também expunha arquivos de teste de 100 MB, 1 GB, 5 GB e 10 GB. A evidência do looking glass é útil porque convida à medição externa, mas é estreita: um arquivo de teste prova que um endpoint de diagnóstico existe e pode ser alcançado de onde o usuário o testa. Não prova que todo o parque de clientes está na mesma instalação, que todos os produtos têm o mesmo caminho de transporte, ou que um servidor encomendado em outra cidade herda a rota de diagnóstico de Dallas.

A lista de instalações do PeeringDB torna a geografia mais ampla do que o looking glass. Telehouse London Docklands North é um site londrino denso em transportadoras; odata center Frankfurt 1da NTT é apresentado pela NTT como um grande campus com 70,1 MW de carga de TI crítica e acesso à DE-CIX; oAmsterdam AMS-1da Iron Mountain é descrito como um campus em Haarlem com energia atual e expansão planejada; oMiami MI1da CoreSite é uma instalação dedicada em Miami conectada ao MI2 por fibra escura; e a própria página da Tempest lista Sydney, Chicago e Dallas como localizações operacionais. Esses fatos de instalação ajudam a explicar onde as restrições de energia, resfriamento, sala de encontro, cross-connect e acesso local entram em jogo no serviço. Eles não provam o tamanho exato da gaiola da Tempest, a energia reservada, a densidade dos racks ou o acordo de mão remota em um determinado site.

Esse é o problema recorrente de capacidade. A capacidade instalada é o que a rede ou instalação pode teoricamente suportar. A capacidade utilizável é o que pode ser vendido, alimentado, resfriado, cabeado, monitorado, faturado e recuperado sem violar uma restrição de provedor upstream, rack, energia, suporte ou estoque de hardware. Um alcance global no PeeringDB e oito entradas de instalação podem tornar um provedor mais resiliente do que um hospedeiro de site único. Eles também criam mais lugares onde um cliente precisa fazer perguntas específicas do site. Qual cidade detém o servidor primário? Qual cidade detém os backups?

A migração é a frio, morna ou automática? Os IPs públicos são portáteis entre as localizações da Tempest? Se uma transportadora upstream em Dallas falha, o tráfego se move para outro caminho em Dallas, outra cidade norte-americana, ou um reroteamento temporário com impacto na sessão?

A migração em Londres mostra o custo real da resiliência

O exemplo público mais claro da dependência física da Tempest é aatualização de rede em Londresconcluída. A Tempest afirmou que estava se expandindo para o campus do data center Telehouse London e migrando a infraestrutura de roteamento central para lá. Ela também indicou que o trabalho exigiria a retirada dos anúncios BGP do roteador de borda existente, a ativação de um novo roteador Telehouse, o anúncio do espaço de endereços IP e a validação do roteamento entre provedores upstream e pares. Os clientes foram avisados sobre perdas de conectividade, perda de pacotes e breves interrupções durante a propagação do roteamento e execução dos testes.

Este aviso de manutenção é mais significativo do que uma mensagem de disponibilidade comum porque mostra o grafo de dependência oculto. O produto visível pode ser um servidor dedicado, um servidor virtual dedicado, um servidor de jogos ou um serviço de colocação. A mudança que importa, no entanto, é uma realocação de roteador em um campus neutro. O modo de falha não é apenas "um servidor cai". É "o caminho pelo qual o resto da Internet alcança o servidor é deliberadamente retirado, reanunciado e validado." Um comprador que só pergunta sobre CPU, RAM e largura de banda mensal perde o caminho que de fato torna a carga de trabalho acessível.

O mesmo aviso também explica a diferença entre alegações de redundância e prova de redundância. A Tempest descreveu benefícios como resiliência melhorada, conectividade mais forte, latência reduzida e uma base melhor para crescimento futuro. Esses são benefícios plausíveis de uma presença na Telehouse, especialmente porque London Docklands é uma das principais zonas de interconexão na Europa. Mas um aviso de manutenção continua sendo uma hipótese até que o cliente possa ver como ele se comporta em condição de falha. O site de Londres tem mais de um provedor upstream? As políticas de rota são testadas antes da janela de mudança?

Quanto tráfego é movido por validação manual em vez de failover automático? O suporte ao cliente sabe quais prefixos ou produtos são afetados? Qual é o objetivo de recuperação se o novo roteador falhar após a remoção da borda antiga?

A resposta pode ser excelente, mas o registro público não a divulga completamente. O registro público, no entanto, coloca os clientes em uma posição melhor do que o marketing vago. Um cliente pode seguir o AS36231 viaBGP.tools, comparar mudanças de rota públicas com ostatus de roteamentodo RIPEstat e observar se o conjunto de prefixos ou vizinhos muda em torno das janelas de manutenção importantes. Esses testes não substituem um contrato, mas criam evidências independentes quando um provedor diz que uma migração melhora a resiliência.

Dallas expõe as camadas de rack, gabinete e provedor upstream

Aatualização de rede programada em Dallasconcluída é um segundo registro útil porque não se trata apenas de BGP. A Tempest afirmou que adicionaria novos equipamentos de roteamento e reduziria o espaço do gabinete para que novos equipamentos pudessem ser montados em rack. Ela esperava que algumas máquinas de clientes fossem desligadas e movidas para outros locais de rack, com pelo menos três horas de interrupção para clientes dedicados empresariais e pelo menos cinco horas para servidores econômicos ou blade. Durante a janela, os clientes também poderiam sofrer perdas de rede periódicas enquanto as equipes trabalhavam dentro ou ao redor dos gabinetes.

Este é o lembrete público mais concreto de que a capacidade hospedada não é um software flutuando sobre o prédio. Ela é parafusada em racks, cabeada em equipamentos de cabeceira de rack ou agregação, alimentada por chegadas do site, resfriada pelo design da sala e gerenciada por pessoas com acesso físico. Consolidar o espaço é um ato de infraestrutura. Isso significa que um provedor está alterando o layout dos gabinetes que abre espaço para crescimento, substituição de hardware ou atualizações de rede.

Isso pode melhorar a capacidade futura, mas cria um caminho de falha de curto prazo no qual o serviço depende de movimentação de máquinas, disciplina de cabeamento, sequenciamento de energia, etiquetagem e validação pós-movimentação.

Oincidente de roteamento em Dallasadiciona a camada da transportadora. A Tempest afirmou ter identificado um problema de roteamento com a rede de Dallas, acionado a transportadora upstream porque a falha estava em sua rede, temporariamente reroteado o tráfego para restaurar os serviços e depois trazido o tráfego de volta ao caminho de conectividade normal. A atualização também observava que alguns jogadores podem ter sofrido uma breve desconexão durante a transição. Essa linguagem aponta para um grupo de clientes que provavelmente se preocupa com latência e continuidade de sessão: usuários de servidores de jogos ou outras cargas de trabalho em tempo real. Para eles, "o servidor permaneceu ligado" não é suficiente se a rota redefinir uma sessão ou mover a latência para um caminho que altera a experiência do usuário.

Dallas mostra, portanto, dois riscos diferentes. O risco planejado é uma mudança de gabinete e equipamento onde os clientes conhecem a janela de manutenção e podem se planejar para o tempo de inatividade. O risco não planejado é uma falha de provedor upstream onde o provedor precisa diagnosticar a propriedade, acionar a transportadora, rerotear o tráfego e depois restaurar o roteamento normal sem agravar o impacto no cliente. Ambos são recuperáveis; nenhum é invisível para os clientes.

Um comprador sério deve perguntar pelo caminho de escalada correspondente a ambos: quem pode autorizar um reroteamento de emergência, quem pode entrar na instalação, quem gerencia a movimentação das máquinas e com que rapidez o provedor pode comunicar um impacto específico do produto em vez de um status geral no nível da cidade.

Amsterdã é a lição sobre peças de reposição

Aparada em Amsterdãda Tempest é a evidência pública mais difícil no dossiê porque nomeia uma restrição muito específica. O incidente afetou Amsterdã, começou como uma investigação de parada e depois foi identificado como uma falha do switch central. A Tempest afirmou que Amsterdã era um site onde ainda não tinha tido a oportunidade de enviar uma peça de reposição, então estava acionando provedores locais para encontrar um substituto. A conectividade foi então restaurada e monitorada.

Essa divulgação é operacionalmente valiosa. Ela transforma a frase vaga "falha de hardware" em uma dependência acionável: um switch central, uma peça de reposição ainda não presente no site e um fornecimento local. Para um cliente decidindo colocar sua produção em Amsterdã, a lição não é apenas que um provedor teve uma falha. Falhas acontecem. A lição é que uma pegada de múltiplos sites ainda contém diferenças de maturidade site a site. Um site pode estar listado, anunciado e operacional enquanto seu estoque de peças de reposição é menos completo do que uma localização mais estabelecida.

Um provedor pode restaurar o serviço, mas o caminho de restauração pode depender de fornecimento local em vez de uma reposição pronta para uso.

É aqui que a capacidade instalada versus capacidade utilizável se torna uma questão de resiliência. Um rack pode ter espaço. Uma instalação pode ter energia. Um prefixo pode ser anunciado. Nenhum desses fatos garante que a peça de reposição necessária após uma falha de switch já esteja na cidade certa. A capacidade utilizável inclui o inventário prosaico que permite que um serviço sobreviva a falhas: switches de reposição, ópticas, fontes de alimentação, discos, cabos e placas de roteador compatíveis. Ela inclui direitos de mão remota, prazos de entrega de fornecedores e a capacidade de enviar rapidamente através das fronteiras.

Em Amsterdã, a própria linguagem do incidente público da Tempest diz que o posicionamento de peças de reposição não estava completo naquele momento.

Isso não torna o site de Amsterdã inutilizável. Isso torna a pergunta de diligência mais contundente. Um comprador pode perguntar se a peça de reposição faltante foi um problema pontual de início de vida, se o site agora tem uma reposição em estoque e se outras novas cidades têm uma lacuna semelhante. Um comprador também pode perguntar como os serviços são distribuídos por cidade: se um nó de Amsterdã falha, o cliente pode se mover para Londres, Frankfurt ou outra região da Tempest sem modificar a arquitetura da aplicação? Os backups já estão fora do site? Os endereços IP são portáteis ou apenas os dados?

O cliente pode restaurar a partir de um snapshot e, em caso afirmativo, quanto tempo a fila se torna quando uma cidade inteira tem uma falha?

A página de status transforma a disponibilidade em evidência técnica

O registro de status da Tempest é valioso porque transforma a disponibilidade em um histórico operacional datado em vez de uma promessa de marca. Apágina de statusnão dizia apenas que a empresa tinha localizações globais. Ela exibia zonas de serviço separadas para Londres, Frankfurt, Amsterdã, Chicago, Miami, Dallas e Sydney, e mostrava números de 30 dias muito diferentes entre eles no momento examinado aqui. Londres, Chicago, Miami e Sydney eram exibidos como 100,0%. Dallas era exibido como 99,4%. Frankfurt era exibido como 97,4%. Amsterdã era exibido como 84,6%. Esses números não devem ser tratados como desempenho de serviço auditado, porque páginas de status públicas são mantidas pelo provedor e definem seus próprios componentes monitorados. Eles são, no entanto, úteis porque impedem a leitura da pegada como uma única nuvem lisa. Cada cidade tem seu próprio histórico de manutenção, histórico de falhas e comportamento de recuperação.

Isso é particularmente importante para um comprador comparando localizações. Se um provedor tem sete cidades, um cliente pode supor que as cidades são intercambiáveis. O registro público da Tempest argumenta contra essa suposição. O número de 30 dias de Amsterdã foi reduzido por uma falha de switch central divulgada e um problema de fornecimento de reposição. Dallas teve tanto uma atualização planejada de gabinete/equipamento de roteamento quanto um incidente de provedor upstream. Frankfurt teve um problema de IP. Londres teve uma migração planejada de roteador central para o campus Telehouse.

Sydney, Miami e Chicago pareciam calmas na mesma janela de status, mas a calma pública não é prova de estoque de peças idêntico, topologia upstream idêntica ou disponibilidade de produto idêntica. Isso significa que o registro de status público examinado não mostrou as mesmas perturbações para essas localizações.

O histórico de status também separa o risco planejado do risco não planejado. A manutenção planejada não é apenas tempo de inatividade com aviso prévio. É um indicador de quanto mudança física está ocorrendo por trás do serviço. O aviso de Londres mostra uma retirada de rota, ativação de roteador e validação upstream. A atualização programada de Dallas mostra movimentação de máquinas, consolidação de gabinetes e novos equipamentos de roteamento. Esses são sinais de investimento, mas também sinais de que a capacidade utilizável às vezes requer interrupção de serviço.

Um provedor só pode aumentar sua capacidade tocando em roteadores, cabos, gabinetes e máquinas. Os clientes devem, portanto, perguntar se os trabalhos de expansão são programados por cidade, se a manutenção afeta todos os produtos ou famílias de produtos específicas e se o aviso identifica faixas de IP ou grupos de clientes com precisão suficiente para planejamento.

Os incidentes não planejados testam uma parte diferente do sistema. A falha de transportadora em Dallas exigiu que a Tempest acionasse um provedor upstream e reroteasse o tráfego. A parada em Amsterdã exigiu fornecimento local de reposição. Em ambos os casos, a experiência do cliente dependia da rapidez com que a Tempest podia identificar a camada responsável e mudar para o caminho de recuperação correto. Uma falha de energia de rack, um switch central com defeito e uma falha de roteamento upstream podem parecer "o servidor está inacessível" para um cliente. Eles exigem diferentes respondedores.

O provedor precisa saber se deve enviar mão remota, abrir um ticket de transportadora, modificar a política BGP, substituir hardware ou dizer ao cliente para restaurar em outro lugar.

Isso torna a formulação do status um objeto de diligência útil. Os clientes devem procurar se incidentes futuros identificam a localização, a família de produtos, a camada, a solução alternativa e a restauração final. Uma marca "operacional" no nível da cidade é uma boa notícia, mas um bom relatório de incidente é frequentemente mais informativo do que um selo verde. Ele revela se o provedor entende sua própria pilha de dependências e se os clientes recebem uma linguagem que pode ser usada para comunicação downstream. Os avisos públicos da Tempest nomeiam camadas concretas em vários casos, o que fortalece a análise.

A lacuna restante é específica do cliente: uma página de status pública raramente indica a um comprador individual se seu servidor exato, bloco de endereços, backup e nível de suporte são cobertos pelo componente exibido.

Frankfurt e Miami mostram por que a qualidade da instalação não é prova do provedor

Frankfurt é útil porque o registro público contém dois tipos diferentes de evidência. O PeeringDB lista NTT Frankfurt 1 como uma presença de instalação da Tempest, e a página de instalação da NTT descreve um grande campus com conectividade neutra, acesso à DE-CIX, salas de encontro redundantes e uma grande envelope de energia. Por outro lado, oincidente de Frankfurtda Tempest indicou que um problema de IP afetou a localização de Frankfurt e depois foi resolvido. A instalação pode ser grande e bem conectada, mas o serviço de um cliente ainda depende do equipamento próprio da Tempest, do seu plano de endereçamento, das suas escolhas de provedores upstream e da sua resposta de suporte dentro ou ao redor dessa instalação.

A mesma lógica se aplica a Miami. A página MI1 da CoreSite descreve um data center dedicado no centro de Miami, conectado ao MI2 por fibra escura e projetado para condições severas de tempestade. Esse é um contexto físico valioso. Ele nos diz por que Miami pode ser uma localização sensata para conteúdo, jogos ou tráfego voltado para as Américas. Ele não nos diz nada por si só sobre a alocação exata da Tempest em racks, cross-connects, consumo de energia ou caminho de migração do cliente. Uma instalação sólida pode hospedar uma implantação fraca; uma instalação modesta pode hospedar uma implantação cuidadosamente projetada.

As páginas de instalação públicas definem o envelope físico, não a execução do provedor.

Essa distinção é particularmente importante porque os clientes muitas vezes compram a marca, não o prédio. Se um cliente da Tempest encomenda um servidor em Dallas, ele pode pensar que comprou um produto Tempest. Operacionalmente, ele comprou um compósito: o hardware da Tempest, a política de roteador da Tempest, o regime de energia e acesso de um operador de instalação, uma ou mais transportadoras, mão remota ou pessoal local, filas de suporte, sistemas de faturamento e uma regra de migração. Quando algo quebra, o cliente experimenta a peça responsável mais lenta.

O registro de incidente público é útil porque nos diz que essas peças vieram à tona em eventos reais.

A etapa de diligência prática é dividir o serviço em camadas. A camada empresa é Tempest Hosting, LLC. A camada de roteamento é AS36231 e seus vizinhos observados. A camada de instalação são os sites nomeados no PeeringDB e na página de status da Tempest. A camada de produto é a capacidade dedicada, econômica, blade, virtual dedicada ou de colocação. A camada de recuperação é o que acontece quando as camadas de produto e instalação não correspondem: um switch central falha, uma transportadora tem uma falha, ou o equipamento precisa ser fisicamente movido.

Os clientes precisam de respostas em cada camada, porque uma falha raramente respeita os limites nítidos de um orçamento.

A diversidade de roteamento é visível, mas a diversidade física não

As evidências de roteamento público são uma das melhores partes deste dossiê. O RIPEstat viu visibilidade completa para AS36231 no instantâneo, e apágina de classificação ASda CAIDA identificou Tempest Hosting, LLC, Estados Unidos, um pequeno cone de cliente e um grau AS limitado. Apágina AS36231do IPinfo, avisão BGPda Hurricane Electric e o BGP.tools fornecem todas verificações cruzadas independentes para a identidade da rede e prefixos. Nenhum desses serviços vê toda a verdade contratual, mas eles reduzem a probabilidade de que a rede seja apenas nominal.

Os limites são igualmente importantes. Os dados de vizinhos do RIPEstat mostraram cinco vizinhos observados. Isso é útil, mas a adjacência BGP pública não revela se duas sessões compartilham a mesma fibra metropolitana, a mesma sala de encontro do prédio, o mesmo duto de transportadora ou a mesma equipe de manutenção upstream. Ela não revela se uma rota aprendida de um vizinho é preferida para todo o tráfego, se um caminho de backup tem capacidade suficiente para a carga de pico, ou se uma carga de trabalho de servidor de jogos pode tolerar uma mudança de latência mesmo quando a entrega de pacotes retorna.

A diversidade de roteamento é uma pista necessária; a diversidade de caminho físico é uma evidência distinta.

O fato de o PeeringDB ter zero anexos de troca pública para o objeto de rede Tempest também requer manuseio cuidadoso. Isso não significa que a Tempest carece de interconexão, e não contradiz uma rede de múltiplas instalações. A participação no PeeringDB é voluntária, e os registros de rede podem omitir interconexões privadas, trânsito, sessões de roteador de servidor ou arranjos específicos do cliente. O que isso diz é que o perfil público atualmente não fornece uma lista rica de portas de troca como algumas redes europeias fazem.

Os clientes devem, portanto, fazer perguntas diretas sobre provedores de trânsito, pares privados, portas de backup e se cada cidade tem caminhos independentes capazes por padrão.

Os registros de Londres e Dallas mostram por que isso importa. Durante a migração em Londres, a Tempest planejava retirar e reanunciar rotas BGP enquanto validava upstreams e pares. Durante o incidente em Dallas, uma falha na rede de um provedor upstream forçou um reroteamento temporário. Em ambos os casos, o efeito do lado do cliente dependia não apenas da visibilidade do AS36231 em algum lugar, mas também do caminho que geria o serviço afetado naquele momento.

Uma revisão séria da resiliência deve incluir traceroutes a partir dos mercados dos clientes, uma revisão da autorização de origem de rota, monitoramento de prefixos e uma explicação do provedor sobre o que muda durante uma falha de transportadora.

As classes de produtos falham de maneiras diferentes

Os avisos públicos da Tempest também são úteis porque identificam diferentes classes de clientes. A atualização programada de Dallas referia-se a clientes dedicados empresariais, servidores econômicos ou blade, e perdas de rede periódicas enquanto as equipes trabalhavam ao redor dos gabinetes. O incidente de roteamento em Dallas mencionava jogadores que podem ter sofrido uma breve desconexão. A página de status em si aponta para servidores virtuais dedicados, servidores dedicados, servidores de jogos e colocação como categorias de produto.

Esses rótulos importam porque o mesmo evento de instalação pode criar diferentes tarefas de recuperação para cada tipo de produto.

Os clientes de servidores dedicados se preocupam com a máquina como um ativo individual. Se um gabinete é consolidado, eles precisam saber se seu servidor será desligado, fisicamente movido, recabeado ou deixado no lugar. Se um disco, fonte de alimentação ou placa-mãe falha, eles precisam saber se uma peça de reposição compatível está na mesma cidade, se os dados podem ser preservados e quem autoriza o trabalho prático. O aviso de atualização de Dallas é concreto porque diz aos clientes que algumas máquinas podem ser desligadas e movidas.

Também implica que o plano de crescimento do provedor tinha um componente de layout físico, não apenas um componente de provisionamento de software.

Os clientes de servidores virtuais dedicados têm uma dependência diferente. Eles podem não se importar com o chassi individual que hospeda a máquina virtual até que um host, pool de armazenamento ou elemento de agregação de rede falhe. Sua recuperação depende da saúde do hipervisor, da replicação de armazenamento, da capacidade de acolhimento disponível, da atualidade dos backups e das ferramentas de migração. O registro público da Tempest não divulga a arquitetura de virtualização ou armazenamento por trás desses produtos.

Mostra, no entanto, por que os clientes devem perguntar se um VDS pode se mover entre hosts ou cidades, se os backups estão no local ou entre sites, e se um endereço IP segue a carga de trabalho durante uma restauração.

Os clientes de servidores de jogos se preocupam com o timing tanto quanto com a acessibilidade. Um reroteamento temporário que restaura a conectividade ainda pode mudar a latência, a oscilação ou a continuidade da sessão. A linguagem do incidente de Dallas sobre possíveis desconexões de jogadores é, portanto, importante. Ela reconhece que uma solução alternativa de rede pode ter um efeito visível para o usuário mesmo após o serviço ter tecnicamente voltado ao ar.

Para jogos e outras cargas de trabalho em tempo real, um cliente deve perguntar onde está a base de jogadores, qual cidade da Tempest é usada, qual é o caminho de latência normal, qual é o caminho de failover de DDoS e upstream, e se as mudanças de rota são testadas a partir dos mercados dos jogadores em vez de apenas dos próprios pontos de monitoramento do provedor.

Os clientes de colocação são ainda outro caso. Um equipamento colocado pode depender da Tempest para espaço, energia, rede, mão remota e coordenação de cross-connects, enquanto o cliente possui o software do servidor e às vezes o hardware. Se uma rota upstream muda, a Tempest age. Se um equipamento do cliente falha, a política de mão remota e acesso importa. Se um evento de instalação ocorre, ambas as partes podem precisar se coordenar. A lista de instalações do PeeringDB é útil porque nomeia os locais físicos prováveis, mas o nome do local por si só não define quem pode tocar no quê, com que rapidez e sob qual processo de autorização.

Esse limite deve ser escrito antes de uma falha.

Essa distinção de produto está no centro da economia da capacidade hospedada. O mesmo rack, o mesmo roteador e a mesma equipe de suporte podem servir muitas linhas de produto, o que cria eficiência. Também cria contenção durante um incidente compartilhado. Uma falha de switch central, uma falha de transportadora ou uma movimentação de gabinete pode enviar muitos clientes para a mesma fila de suporte e reparo. As evidências públicas provam que as camadas existem; não provam a capacidade da fila.

A postura mais segura para o cliente é pedir à Tempest uma linguagem de recuperação específica do produto em vez de confiar em descrições gerais de infraestrutura.

A mesma distinção deve moldar o monitoramento. Um cliente de servidor dedicado pode monitorar eventos de energia, contadores de interface, saúde do disco e acesso fora de banda. Um cliente VDS pode monitorar a idade dos snapshots, avisos de manutenção do host e latência de armazenamento. Um cliente de servidor de jogos pode monitorar a latência e oscilação da região dos jogadores, porque o incidente de roteamento de Dallas mostra que uma rota recuperada ainda pode interromper uma sessão. Um cliente de colocação pode monitorar o status dos cross-connects, energia do rack, resposta de mão remota e mudanças de rota upstream.

As ferramentas públicas em torno do AS36231 ajudam apenas para uma parte desse trabalho. Elas mostram a borda voltada para a Internet; não mostram se as próprias suposições de recuperação do cliente correspondem à classe de produto realmente comprada.

O impacto no cliente depende da carga de trabalho, não apenas da disponibilidade

A linguagem de status da Tempest sugere várias classes de clientes: clientes dedicados empresariais, usuários de servidores econômicos ou blade, usuários de servidores virtuais dedicados, clientes de colocação e jogadores conectados a cargas de trabalho de jogos. Esses grupos vivenciam o mesmo evento de infraestrutura de forma diferente. Um desligamento programado de três horas pode ser aceitável para um servidor de teste e inaceitável para um banco de dados de produção. Uma breve transição de rota pode ser inofensiva para um site estático e perturbadora para uma sessão de jogo.

Uma falha de switch central pode ser uma parada temporária para um locatário e um evento de reputação para um revendedor com clientes downstream.

É por isso que a parte afetada não é apenas "os clientes da Tempest." Ela pode incluir comunidades de jogos, pequenas empresas usando máquinas dedicadas como servidor principal, revendedores cujos clientes não sabem que a Tempest está por baixo, desenvolvedores que escolheram uma cidade pela latência, e empresas que assumiram que um provedor global poderia movê-las rapidamente entre sites. Ela também pode incluir pares e upstreams quando mudanças de rota movem o tráfego para caminhos alternativos. O cliente que vê uma falha está frequentemente a várias camadas da parte física que falhou.

A localização dos dados adiciona outra consequência. Uma zona de serviço global não diz a um cliente qual jurisdição detém os dados, qual processo judicial se aplica, ou se o suporte pode agir localmente. Se uma carga de trabalho está em Amsterdã, os dados e o hardware podem estar na Holanda mesmo que a conta seja gerenciada através de uma interface comercial americana ou dubaiota. Se um cliente restaura em Londres ou Dallas, o perfil jurídico e de latência muda.

Os registros públicos podem identificar os sites prováveis, mas apenas a documentação do provedor e a configuração da conta do cliente podem provar onde uma carga de trabalho específica está localizada.

A migração deve, portanto, ser testada antes de ser necessária. Os clientes devem perguntar se os snapshots são portáteis entre as localizações da Tempest, se os endereços públicos podem ser preservados, se os backups entre regiões estão incluídos ou são opcionais, e se o provedor tem um processo documentado para realocação de emergência. O registro de status público mostra que a Tempest pode realizar movimentações de rede planejadas e reroteamentos de emergência, mas não mostra o tempo de recuperação no nível do cliente para dados, computação, continuidade de endereço IP ou capacidade da fila de suporte durante um evento regional.

Quais evidências reforçariam a alegação de capacidade

A Tempest já supera o primeiro obstáculo de evidência. O AS36231 está ativo, o conjunto de prefixos é visível, o perfil do PeeringDB é mantido, uma página de status nomeia as localizações e incidentes, e o looking glass expõe um endpoint de teste real. A evidência mais forte estaria mais perto do contrato do cliente. Ela mostraria quais produtos estão disponíveis em quais cidades, quais instalações hospedam quais produtos, quais upstreams estão presentes em cada cidade, se a diversidade de roteamento é diversa no nível metropolitano e qual hardware de reposição está agora estocado nas novas localizações.

O provedor não precisa publicar cada detalhe operacional na internet aberta. Alguns detalhes são sensíveis à segurança ou comercialmente sensíveis. Mas os clientes ainda podem pedir uma nota de arquitetura privada, uma matriz de escalada de suporte, um relatório de disponibilidade atual, uma lista das janelas de manutenção que afetam sua classe de serviço e um teste de recuperação. Eles também podem pedir uma explicação de como a faixa de tráfego do PeeringDB de 1 a 5 Tbps corresponde à margem de manobra disponível para o cliente. Uma faixa de tráfego aproximada não é uma promessa de capacidade.

Ela pode descrever o pico ou a média agregada da escala da rede, não a quantidade de largura de banda que um cliente pode realmente usar durante uma falha.

A mesma coisa se aplica à energia da instalação. NTT Frankfurt, Iron Mountain Amsterdam, CoreSite Miami e outros operadores de instalação publicam características impressionantes de energia e conectividade. Um cliente da Tempest ainda precisa saber a energia contratada da Tempest, o nível de redundância, a densidade dos racks e o procedimento de mão remota dentro do site. Uma instalação pode ter megawatts de reserva enquanto uma gaiola específica não tem espaço imediato ou tomada de energia compatível. Uma instalação pode ter muitas transportadoras enquanto o produto do cliente usa uma rota padrão.

Uma sala de dados pode ser segura enquanto uma restauração do cliente falha porque o backup nunca esteve fora da cidade afetada.

Essa é a escala de evidência do comprador. Primeiro, provar que a empresa está ligada a uma rede ativa. Segundo, provar que o produto realmente usa essa rede. Terceiro, provar as dependências de cidade, rack, energia, upstream e suporte do produto. Quarto, provar o caminho de recuperação exercitando-o. O registro público da Tempest é sólido na primeira etapa e significativo na terceira devido às divulgações de incidentes. Ainda está incompleto na segunda e quarta para qualquer cliente individual até que o cliente obtenha confirmação específica do produto.

O veredito estreito

A Tempest Hosting, LLC deve ser tratada como um operador de infraestrutura real com uma rede pública mensurável, não como uma pegada puramente fina. As evidências são incomumente úteis para um provedor de hospedagem privada: AS36231 é visível; RIPEstat mostra espaço IPv4 e IPv6 atual; PeeringDB lista um perfil global, faixa de tráfego de 1 a 5 Tbps e oito instalações; a página de status nomeia várias cidades operacionais; e os registros de incidentes expõem caminhos de falha concretos em roteadores, transportadoras upstream, gabinetes e hardware de reposição. Isso é suficiente para analisar o provedor como infraestrutura.

Não é suficiente para tratar cada unidade de capacidade anunciada ou implícita como já utilizável em caso de falha. O material público não divulga os números exatos de racks, reservas de energia, distribuição de clientes por cidade, inventário de peças de reposição após a parada de Amsterdã, ou os termos contratuais que decidem se um cliente pode mover dados e endereços entre localizações. A lição mais importante é que o registro público da Tempest mostra tanto o alcance quanto o atrito. O alcance vem da pegada global de prefixos e instalações.

O atrito vem de como as janelas de manutenção e incidentes revelam as mãos, as peças, as transportadoras e as decisões locais por trás do serviço.

Para os clientes, o teste prático é simples de enunciar e difícil de satisfazer: pedir à Tempest que mapeie o produto exato comprado para uma cidade, instalação, caminho upstream, fila de suporte, estoque de peças e plano de migração. Em seguida, comparar essa resposta com as evidências de rota públicas do RIPEstat, PeeringDB, BGP.tools e da página de status da Tempest. Se a resposta for consistente e o procedimento de recuperação tiver sido testado, a pegada da Tempest pode suportar cargas de trabalho sérias.

Se a resposta permanecer genérica, o comprador deve assumir que uma conta de servidor ainda depende de racks específicos do site, mudanças de roteamento, entregas de fornecedores e janelas de reparo que podem só se tornar visíveis quando algo falha.