Résumé
- Tempest Hosting, LLC dispose d'une surface opérationnelle publique réelle: AS36231 est annoncé, PeeringDB liste Tempest comme un réseau de contenu mondial avec 1 à 5 Tbps de trafic, huit présences dans des installations et un ensemble AS, tandis que RIPEstat a observé 19 préfixes IPv4 et 20 préfixes IPv6 dans l'instantané du 2026-07-15.
- La question de risque la plus utile n'est pas de savoir si Tempest existe, mais quelles charges de travail client dépendent de quelles baies, routeurs, pools de pièces de rechange locaux, fournisseurs en amont et transferts de support lorsqu'un site comme Amsterdam, Dallas, Londres, Francfort, Miami, Chicago ou Sydney devient le point faible.
- Les enregistrements publics de maintenance et d'incident sont particulièrement utiles ici: Tempest a divulgué une migration de routeur central à Londres, une mise à niveau d'armoire et d'équipement de routage à Dallas, un défaut de fournisseur en amont à Dallas, un problème IP à Francfort et une panne à Amsterdam liée à une défaillance du commutateur central et à un approvisionnement retardé de pièces de rechange.
- Les preuves soutiennent une note élevée d'empreinte réseau, mais pas une revendication de capacité illimitée. Les préfixes installés, les bandes de trafic PeeringDB, les fichiers de test et les listes d'installations ne prouvent pas la marge de manœuvre disponible pour le client, les droits de puissance contractuels, le matériel de remplacement en stock ou le temps de migration garanti.
Une entreprise d'hébergement peut être réelle et pourtant opaque au niveau opérationnel
Tempest Hosting, LLC est le type de fournisseur dont l'empreinte publique semble bien plus grande qu'une petite brochure d'hébergement web, mais qui laisse néanmoins les questions les plus coûteuses hors de la vue du public. L'identité publique commence par la page de l'entreprise dans l'annuaire BTW, mais le test d'infrastructure commence avec AS36231. Lavue ASde RIPEstat identifie le titulaire comme TEMPEST-HOSTING - Tempest Hosting, LLC et marque le système autonome comme annoncé dans la fenêtre de requête du 2026-07-15. Les données WHOIS dérivées d'ARIN rendues via lavue WHOISde RIPEstat donnent le nom AS TEMPEST, une date d'enregistrement en mai 2020 et un commentaire pointant vers tempest.net. Ces faits ne décrivent pas un produit en eux-mêmes, mais ils établissent une frontière de routage numérotée qui peut être mesurée indépendamment du langage commercial.
Cette frontière n'est pas vide. Lavue des préfixes annoncésde RIPEstat a renvoyé 40 entrées de chronologie de préfixes dans l'instantané utilisé ici. Savue de statut de routagea séparé cela en 19 préfixes IPv4, 4 864 adresses IPv4, 20 préfixes IPv6 et 65 538 unités IPv6 visibles équivalent /48, avec une visibilité complète de 326 des 326 pairs RIS IPv4 et 322 des 322 pairs RIS IPv6. Lavue voisinsde RIPEstat a montré cinq voisins observés, dont quatre relations de gauche et une relation de droite. Une vérification RPKI représentative pour 104.152.143.0/24 a renvoyé unrésultat d'origine de route valide. Pris ensemble, ces enregistrements disent que Tempest a une bordure de routage publique active. Ils ne disent pas combien de clients se trouvent derrière chaque bordure, quels services utilisent des adresses attribuées par le fournisseur, ou si le nombre de préfixes correspond proprement à l'inventaire des serveurs.
L'enregistrement d'interconnexion donne la couche suivante. PeeringDB listeTempest Hosting, LLCcomme AS36231, avec le site webhttps://tempest.net, l'ensemble IRR AS-TEMPEST, le type Content, la portée mondiale, le ratio équilibré, la politique d'échange ouverte et une bande de trafic de 1 à 5 Tbps. L'API réseaude PeeringDB a donné 26 préfixes IPv4 et 30 préfixes IPv6 dans le profil, tandis que l'API installationa listé huit installations: Telehouse London Docklands North, NTT Frankfurt 1, Iron Mountain Amsterdam AMS-1, CoreSite Miami MI1, Equinix SY3 Sydney, ColoCrossing CHI1, IP House London et 365 Data Centers Richardson TX1. L'API d'attachement d'échangecorrespondante a renvoyé zéro entrée LAN d'échange public pour cet objet réseau PeeringDB. Cette combinaison est révélatrice: Tempest présente une empreinte multi-installations, mais la surface d'interconnexion listée publiquement est riche en installations plutôt qu'en ports d'échange.
Pour les acheteurs, cette distinction compte. Une entrée d'installation peut signifier un routeur, des armoires de serveurs, un transfert de transport, un nœud de service client ou une présence en attente. Une bande de trafic PeeringDB est auto-déclarée et volontairement grossière. Un nombre de préfixes peut inclure l'espace de gestion, anycast, serveur de jeu, client ou de réserve. La bonne question n'est pas "Tempest a-t-il une infrastructure mondiale?" Les preuves publiques le soutiennent.
La bonne question est "quelles parties physiques et contractuelles transforment un serveur payé en capacité utilisable et restaurable dans le marché exact où le client achète?"
L'empreinte visible est mondiale, mais la surface opérationnelle est locale
La propre page de statut de Tempest est inhabituellement concrète. Lapage de statut actuellemontrait Londres, Francfort, Amsterdam, Chicago, Miami, Dallas et Sydney comme opérationnels le 2026-07-15, regroupés en Europe, Amérique du Nord et Océanie. Elle affichait également des chiffres de disponibilité sur 30 jours: Londres, Chicago, Miami et Sydney à 100,0 %, Dallas à 99,4 %, Francfort à 97,4 % et Amsterdam à 84,6 %. Ce ne sont pas des chiffres de disponibilité audités formels, et ils ne couvrent que les composants de la plateforme représentés sur cette page. Néanmoins, ils rendent la géographie de service plus tangible qu'une marque d'hébergement générique ne le ferait.
Lelooking glass de Tempestajoute un deuxième point tangible. Il expose des diagnostics en direct depuis les points de présence et, sur la page capturée, listait un emplacement de test à Dallas avec l'IPv4 de test 104.152.143.215 et le centre de données Equinix DA1. Il exposait également des fichiers de test de 100 Mo, 1 Go, 5 Go et 10 Go. La preuve du looking glass est utile car elle invite à une mesure externe, mais elle est étroite: un fichier de test prouve qu'un point de terminaison de diagnostic existe et peut être atteint depuis l'endroit où l'utilisateur le teste. Elle ne prouve pas que l'ensemble du parc client se trouve dans la même installation, que tous les produits ont le même chemin de transport, ou qu'un serveur commandé dans une autre ville hérite de la route de diagnostic de Dallas.
La liste des installations PeeringDB rend la géographie plus large que le looking glass. Telehouse London Docklands North est un site londonien dense en transporteurs; lecentre de données Francfort 1de NTT est présenté par NTT comme un grand campus avec 70,1 MW de charge informatique critique et un accès à DE-CIX; l'Amsterdam AMS-1d'Iron Mountain est décrit comme un campus à Haarlem avec une puissance actuelle et une expansion prévue; leMiami MI1de CoreSite est une installation dédiée à Miami reliée à MI2 par fibre allumée; et la page Tempest elle-même liste Sydney, Chicago et Dallas comme emplacements opérationnels. Ces faits d'installation aident à expliquer où les contraintes d'alimentation, de refroidissement, de salle de rencontre, de cross-connect et d'accès local entrent en jeu dans le service. Ils ne prouvent pas la taille exacte de la cage de Tempest, la puissance réservée, la densité des armoires ou l'accord de main distante dans un site donné.
C'est le problème de capacité récurrent. La capacité installée est ce que le réseau ou l'installation peut théoriquement supporter. La capacité utilisable est ce qui peut être vendu, alimenté, refroidi, câblé, surveillé, facturé et récupéré sans violer une contrainte de fournisseur en amont, de baie, d'alimentation, de support ou de stock de matériel. Une portée mondiale sur PeeringDB et huit entrées d'installation peuvent rendre un fournisseur plus résilient qu'un hébergeur monosite. Elles créent également plus d'endroits où un client doit poser des questions spécifiques au site. Quelle ville détient le serveur principal?
Quelle ville détient les sauvegardes? La migration est-elle à froid, tiède ou automatique? Les IP publiques sont-elles portables entre les emplacements de Tempest? Si un transporteur en amont à Dallas tombe en panne, le trafic se déplace-t-il vers un autre chemin à Dallas, une autre ville nord-américaine, ou une reroutage temporaire avec impact sur la session?
La migration à Londres montre ce que coûte réellement la résilience
L'exemple public le plus clair de la dépendance physique de Tempest est lamise à niveau réseau à Londresterminée. Tempest a déclaré qu'il s'étendait dans le campus du centre de données Telehouse London et y migrait l'infrastructure de routage central. Il a également indiqué que les travaux nécessiteraient le retrait des annonces BGP du routeur de bord existant, la mise en service d'un nouveau routeur Telehouse, l'annonce de l'espace d'adresses IP et la validation du routage entre les fournisseurs en amont et les pairs. Les clients ont été prévenus de pertes de connectivité, de pertes de paquets et de brèves interruptions pendant la propagation du routage et l'exécution des tests.
Cet avis de maintenance est plus important qu'un message de disponibilité ordinaire car il montre le graphe de dépendance caché. Le produit visible peut être un serveur dédié, un serveur virtuel dédié, un serveur de jeu ou un service de colocation. Le changement qui compte, cependant, est un déplacement de routeur dans un campus neutre.
Le mode de défaillance n'est pas seulement "un serveur tombe en panne." C'est "le chemin par lequel le reste d'Internet atteint le serveur est délibérément retiré, réannoncé et validé." Un acheteur qui ne demande que CPU, RAM et bande passante mensuelle manque le chemin qui rend en fait la charge de travail accessible.
Le même avis explique également la différence entre les revendications de redondance et la preuve de redondance. Tempest a décrit des avantages tels qu'une résilience améliorée, une connectivité plus forte, une latence réduite et une meilleure base pour la croissance future. Ce sont des avantages plausibles d'une présence à Telehouse, surtout que London Docklands est l'une des principales zones d'interconnexion en Europe. Mais un avis de maintenance reste une hypothèse jusqu'à ce que le client puisse voir comment il se comporte en condition de panne. Le site de Londres a-t-il plus d'un fournisseur en amont?
Les politiques de route sont-elles testées avant la fenêtre de changement? Quelle quantité de trafic est déplacée par validation manuelle plutôt que par basculement automatique? Le support client sait-il quels préfixes ou produits sont affectés? Quel est l'objectif de récupération si le nouveau routeur tombe en panne après le retrait de l'ancien bord?
La réponse peut être excellente, mais le registre public ne la divulgue pas entièrement. Le registre public place cependant les clients dans une meilleure position qu'un marketing vague. Un client peut suivre AS36231 viaBGP.tools, comparer les changements de route publics avec lestatut de routagede RIPEstat, et observer si l'ensemble de préfixes ou de voisins change autour des fenêtres de maintenance importantes. Ces tests ne remplacent pas un contrat, mais ils créent des preuves indépendantes lorsqu'un fournisseur dit qu'une migration améliore la résilience.
Dallas expose les couches de baie, d'armoire et de fournisseur en amont
Lamise à niveau réseau programmée à Dallasterminée est un deuxième enregistrement utile car elle ne concerne pas seulement BGP. Tempest a déclaré qu'il ajouterait de nouveaux équipements de routage et réduirait l'espace d'armoire pour que de nouveaux équipements puissent être montés en baie. Il s'attendait à ce que certaines machines de clients soient mises hors tension et déplacées vers d'autres emplacements de baie, avec au moins trois heures d'interruption pour les clients dédiés entreprise et au moins cinq heures pour les serveurs économiques ou blade. Pendant la fenêtre, les clients pouvaient également subir des pertes réseau périodiques pendant que les équipes travaillaient dans ou autour des armoires.
C'est le rappel public le plus concret que la capacité hébergée n'est pas un logiciel flottant au-dessus du bâtiment. Elle est boulonnée dans des armoires, câblée à des équipements de tête de baie ou d'agrégation, alimentée par des arrivées du site, refroidie par la conception de la salle, et gérée par des personnes ayant un accès physique. Condenser l'espace est un acte d'infrastructure. Cela signifie qu'un fournisseur modifie la disposition des armoires qui fait de la place pour la croissance, le remplacement du matériel ou les mises à niveau réseau.
Cela peut améliorer la capacité future, mais cela crée un chemin de défaillance à court terme dans lequel le service dépend des déplacements de machines, de la discipline de câblage, du séquencement de l'alimentation, de l'étiquetage et de la validation post-déplacement.
L'incident de routage à Dallasajoute la couche transporteur. Tempest a déclaré avoir identifié un problème de routage avec le réseau de Dallas, avoir engagé le transporteur en amont car la panne se trouvait dans son réseau, avoir temporairement rerouté le trafic pour remettre les services en ligne, puis avoir ramené le trafic sur le chemin de connectivité normal. La mise à jour notait également que certains joueurs avaient peut-être subi une brève déconnexion pendant la transition. Ce langage pointe vers un groupe de clients susceptible de se soucier de la latence et de la continuité de session: les utilisateurs de serveurs de jeu ou d'autres charges de travail en temps réel. Pour eux, "le serveur est resté alimenté" ne suffit pas si la route réinitialise une session ou déplace la latence vers un chemin qui modifie l'expérience utilisateur.
Dallas montre donc deux risques différents. Le risque planifié est un changement d'armoire et d'équipement où les clients connaissent la fenêtre de maintenance et peuvent planifier autour du temps d'arrêt. Le risque non planifié est une panne de fournisseur en amont où le fournisseur doit diagnostiquer la propriété, engager le transporteur, rerouter le trafic et plus tard restaurer le routage normal sans aggraver l'impact client. Les deux sont récupérables; aucun n'est invisible pour les clients.
Un acheteur sérieux devrait demander le chemin d'escalade correspondant aux deux: qui peut autoriser un reroutage d'urgence, qui peut entrer dans l'installation, qui gère le déplacement des machines, et à quelle vitesse le fournisseur peut communiquer un impact spécifique au produit plutôt qu'un statut général au niveau de la ville.
Amsterdam est la leçon sur les pièces de rechange
Lapanne à Amsterdamde Tempest est la preuve publique la plus difficile dans le dossier car elle nomme une contrainte très spécifique. L'incident a affecté Amsterdam, a commencé comme une enquête de panne, et a ensuite été identifié comme une défaillance du commutateur central. Tempest a déclaré qu'Amsterdam était un site où il n'avait pas encore eu la chance d'expédier une pièce de rechange, il engageait donc des fournisseurs locaux pour trouver un remplacement. La connectivité a ensuite été restaurée et surveillée.
Cette divulgation est opérationnellement précieuse. Elle transforme la phrase vague "panne matérielle" en une dépendance actionnable: un commutateur central, une pièce de rechange non encore présente sur le site, et un approvisionnement local. Pour un client décidant de placer sa production à Amsterdam, la leçon n'est pas simplement qu'un fournisseur a eu une panne. Les pannes arrivent. La leçon est qu'une empreinte multi-sites contient encore des différences de maturité site par site. Un site peut être listé, annoncé et opérationnel alors que son stock de pièces de rechange est moins complet qu'un emplacement plus établi.
Un fournisseur peut restaurer le service, mais le chemin de restauration peut dépendre d'un approvisionnement local plutôt que d'un remplacement prêt à l'emploi.
C'est là où la capacité installée par rapport à la capacité utilisable devient une question de résilience. Une armoire peut avoir de l'espace. Une installation peut avoir de l'alimentation. Un préfixe peut être annoncé. Aucun de ces faits ne garantit que la pièce de remplacement nécessaire après une défaillance de commutateur est déjà dans la bonne ville. La capacité utilisable inclut l'inventaire banal qui permet à un service de survivre aux pannes: commutateurs de rechange, optiques, alimentations, disques, câbles et cartes routeurs compatibles.
Elle inclut les droits de main distante, les délais de livraison des fournisseurs et la capacité d'expédier rapidement à travers les frontières. À Amsterdam, le propre langage d'incident public de Tempest dit que le placement des pièces de rechange n'était pas complet à ce moment-là.
Cela ne rend pas le site d'Amsterdam inutilisable. Cela rend la question de diligence plus pointue. Un acheteur peut demander si la pièce de rechange manquante était un problème ponctuel de début de vie, si le site dispose maintenant d'un remplacement en stock, et si d'autres nouvelles villes ont un écart similaire. Un acheteur peut également demander comment les services sont répartis par ville: si un nœud Amsterdam tombe en panne, le client peut-il se déplacer vers Londres, Francfort ou une autre région de Tempest sans modifier l'architecture de l'application? Les sauvegardes sont-elles déjà en dehors du site?
Les adresses IP sont-elles portables ou seulement les données? Le client peut-il restaurer à partir d'un instantané, et si oui, combien de temps la file d'attente devient-elle lorsqu'une ville entière a une panne?
La page de statut transforme la disponibilité en preuve technique
L'enregistrement de statut de Tempest est précieux car il transforme la disponibilité en un historique d'exploitation daté plutôt qu'en une promesse de marque. Lapage de statutne disait pas simplement que l'entreprise avait des emplacements mondiaux. Elle affichait des zones de service séparées pour Londres, Francfort, Amsterdam, Chicago, Miami, Dallas et Sydney, et elle montrait des chiffres sur 30 jours très différents entre eux au moment examiné ici. Londres, Chicago, Miami et Sydney étaient affichés à 100,0 %. Dallas était affiché à 99,4 %. Francfort était affiché à 97,4 %. Amsterdam était affiché à 84,6 %. Ces chiffres ne doivent pas être traités comme des performances de service auditées, car les pages de statut publiques sont maintenues par le fournisseur et définissent leurs propres composants surveillés. Ils sont néanmoins utiles car ils empêchent de lire l'empreinte comme un seul cloud lisse. Chaque ville a son propre historique de maintenance, historique de panne et comportement de récupération.
C'est particulièrement important pour un acheteur comparant des emplacements. Si un fournisseur a sept villes, un client peut supposer que les villes sont interchangeables. Le registre public de Tempest plaide contre cette hypothèse. Le chiffre sur 30 jours d'Amsterdam a été abaissé par une panne de commutateur central divulguée et un problème d'approvisionnement de remplacement. Dallas a eu à la fois une mise à niveau planifiée d'armoire/équipement de routage et un incident de fournisseur en amont. Francfort a eu un problème IP. Londres a eu une migration planifiée de routeur central vers le campus Telehouse.
Sydney, Miami et Chicago semblaient calmes dans la même fenêtre de statut, mais le calme public n'est pas la preuve d'un stock de pièces identique, d'une topologie amont identique ou d'une disponibilité de produit identique. Cela signifie que l'enregistrement de statut public examiné n'a pas montré les mêmes perturbations pour ces emplacements.
L'historique de statut sépare également le risque planifié du risque non planifié. La maintenance planifiée n'est pas simplement un temps d'arrêt avec préavis. C'est un indicateur de la quantité de changement physique qui se produit derrière le service. L'avis de Londres montre un retrait de route, une mise en service de routeur et une validation amont. La mise à niveau programmée de Dallas montre un déplacement de machines, une condensation d'armoires et de nouveaux équipements de routage. Ce sont des signes d'investissement, mais aussi des signes que la capacité utilisable nécessite parfois une interruption de service.
Un fournisseur ne peut augmenter sa capacité qu'en touchant des routeurs, des câbles, des armoires et des machines. Les clients devraient donc demander si les travaux d'expansion sont programmés par ville, si la maintenance affecte tous les produits ou des familles de produits spécifiques, et si l'avis identifie des plages IP ou des groupes de clients avec suffisamment de précision pour planifier autour.
Les incidents non planifiés testent une partie différente du système. La panne de transporteur à Dallas a nécessité que Tempest engage un fournisseur en amont et reroute le trafic. La panne à Amsterdam a nécessité un approvisionnement local de remplacement. Dans les deux cas, l'expérience du client dépendait de la rapidité avec laquelle Tempest pouvait identifier la couche responsable et passer au bon chemin de récupération. Une panne d'alimentation de baie, un commutateur central défaillant et une panne de routage amont peuvent tous ressembler à "le serveur est inaccessible" pour un client.
Ils nécessitent des intervenants différents. Le fournisseur doit savoir s'il doit envoyer des mains distantes, ouvrir un ticket transporteur, modifier la politique BGP, remplacer du matériel ou dire au client de restaurer ailleurs.
Cela fait de la formulation du statut un objet de diligence utile. Les clients devraient rechercher si les futurs incidents identifient l'emplacement, la famille de produits, la couche, la solution de contournement et la restauration finale. Une marque "opérationnel" au niveau de la ville est une bonne nouvelle, mais un bon rapport d'incident est souvent plus informatif qu'un badge vert. Il révèle si le fournisseur comprend sa propre pile de dépendances et si les clients reçoivent un langage qui peut être utilisé pour la communication aval.
Les avis publics de Tempest nomment des couches concrètes dans plusieurs cas, ce qui renforce l'analyse. L'écart restant est spécifique au client: une page de statut publique indique rarement à un acheteur individuel si son serveur exact, son bloc d'adresses, sa sauvegarde et son niveau de support sont couverts par le composant affiché.
Francfort et Miami montrent pourquoi la qualité de l'installation n'est pas une preuve du fournisseur
Francfort est utile car le registre public contient deux types de preuves différents. PeeringDB liste NTT Frankfurt 1 comme une présence d'installation de Tempest, et la page d'installation de NTT décrit un grand campus avec une connectivité neutre, un accès à DE-CIX, des salles de rencontre redondantes et une grande enveloppe de puissance. Par ailleurs, l'incident de Francfortde Tempest a indiqué qu'un problème IP avait affecté l'emplacement de Francfort et avait ensuite été résolu. L'installation peut être grande et bien connectée, mais le service d'un client dépend toujours de l'équipement propre de Tempest, de son plan d'adressage, de ses choix de fournisseurs en amont et de sa réponse de support à l'intérieur ou autour de cette installation.
La même logique s'applique à Miami. La page MI1 de CoreSite décrit un centre de données dédié au centre-ville de Miami, connecté à MI2 par fibre allumée et conçu pour des conditions de tempête sévères. C'est un contexte physique précieux. Il nous dit pourquoi Miami pourrait être un emplacement sensé pour le contenu, le jeu ou le trafic orienté Amériques. Il ne nous dit rien en soi sur l'allocation exacte de Tempest en armoires, cross-connects, consommation électrique ou chemin de migration client. Une installation solide peut héberger un déploiement faible; une installation modeste peut héberger un déploiement soigneusement conçu.
Les pages d'installation publiques définissent l'enveloppe physique, pas l'exécution du fournisseur.
Cette distinction est particulièrement importante car les clients achètent souvent la marque, pas le bâtiment. Si un client de Tempest commande un serveur à Dallas, il peut penser avoir acheté un produit Tempest. Opérationnellement, il a acheté un composite: le matériel de Tempest, la politique de routeur de Tempest, le régime d'alimentation et d'accès d'un opérateur d'installation, un ou plusieurs transporteurs, des mains distantes ou du personnel local, des files d'attente de support, des systèmes de facturation et une règle de migration. Quand quelque chose se casse, le client expérimente la pièce responsable la plus lente.
Le registre d'incident public est utile car il nous dit que ces pièces ont fait surface dans des événements réels.
L'étape de diligence pratique consiste à diviser le service en couches. La couche entreprise est Tempest Hosting, LLC. La couche de routage est AS36231 et ses voisins observés. La couche installation est les sites nommés dans PeeringDB et la page de statut de Tempest. La couche produit est la capacité dédiée, économique, blade, virtuelle dédiée ou de colocation. La couche de récupération est ce qui se passe lorsque les couches produit et installation ne correspondent pas: un commutateur central tombe en panne, un transporteur a une panne, ou l'équipement doit être physiquement déplacé.
Les clients ont besoin de réponses à chaque couche, car une panne respecte rarement les limites nettes d'un devis.
La diversité de routage est visible, mais la diversité physique ne l'est pas
Les preuves de routage public sont l'une des meilleures parties de ce dossier. RIPEstat a vu une visibilité complète pour AS36231 dans l'instantané, et lapage de classement ASde CAIDA a identifié Tempest Hosting, LLC, les États-Unis, un petit cône client et un degré AS limité. Lapage AS36231d'IPinfo, lavue BGPd'Hurricane Electric et BGP.tools fournissent tous des vérifications croisées indépendantes pour l'identité réseau et les préfixes. Aucun de ces services ne voit toute la vérité contractuelle, mais ils réduisent la probabilité que le réseau soit simplement nominal.
Les limites sont tout aussi importantes. Les données de voisins RIPEstat ont montré cinq voisins observés. Cela est utile, mais l'adjacence BGP publique ne révèle pas si deux sessions partagent la même fibre métropolitaine, la même salle de rencontre du bâtiment, le même conduit de transporteur ou la même équipe de maintenance amont. Elle ne révèle pas si une route apprise d'un voisin est préférée pour tout le trafic, si un chemin de secours a suffisamment de capacité pour la charge de pointe, ou si une charge de travail de serveur de jeu peut tolérer un changement de latence même lorsque la livraison de paquets revient.
La diversité de routage est un indice nécessaire; la diversité de chemin physique est une preuve distincte.
Le fait que PeeringDB ait zéro attachement d'échange public pour l'objet réseau Tempest nécessite également une manipulation prudente. Cela ne signifie pas que Tempest manque d'interconnexion, et cela ne contredit pas un réseau multi-installations. La participation à PeeringDB est volontaire, et les enregistrements réseau peuvent omettre les interconnexions privées, le transit, les sessions de routeur de serveur ou les arrangements spécifiques aux clients. Ce que cela dit, c'est que le profil public ne donne actuellement pas une liste riche de ports d'échange comme le font certains réseaux européens.
Les clients devraient donc poser des questions directes sur les fournisseurs de transit, les pairs privés, les ports de secours, et si chaque ville a des chemins indépendants capables par défaut.
Les enregistrements de Londres et Dallas montrent pourquoi cela importe. Pendant la migration à Londres, Tempest prévoyait de retirer et de réannoncer les routes BGP tout en validant les amonts et les pairs. Pendant l'incident à Dallas, une panne dans le réseau d'un transporteur en amont a forcé un reroutage temporaire. Dans les deux cas, l'effet côté client dépendait non seulement de la visibilité d'AS36231 quelque part, mais aussi du chemin qui gérait le service affecté à ce moment-là.
Une revue sérieuse de la résilience devrait inclure des traceroutes depuis les marchés clients, une revue de l'autorisation d'origine de route, la surveillance des préfixes et une explication du fournisseur sur ce qui change pendant une panne de transporteur.
Les classes de produits échouent de différentes manières
Les avis publics de Tempest sont également utiles car ils identifient différentes classes de clients. La mise à niveau programmée de Dallas faisait référence aux clients dédiés entreprise, aux serveurs économiques ou blade, et aux pertes réseau périodiques pendant que les équipes travaillaient autour des armoires. L'incident de routage à Dallas mentionnait des joueurs qui auraient pu subir une brève déconnexion. La page de statut elle-même pointe vers les serveurs virtuels dédiés, les serveurs dédiés, les serveurs de jeu et la colocation comme catégories de produits.
Ces étiquettes comptent car le même événement d'installation peut créer différentes tâches de récupération pour chaque type de produit.
Les clients de serveurs dédiés se soucient de la machine en tant qu'actif individuel. Si une armoire est condensée, ils doivent savoir si leur serveur sera mis hors tension, physiquement déplacé, recâblé ou laissé en place. Si un disque, une alimentation ou une carte mère tombe en panne, ils doivent savoir si une pièce de rechange compatible est dans la même ville, si les données peuvent être préservées, et qui autorise le travail pratique. L'avis de mise à niveau de Dallas est concret car il dit aux clients que certaines machines peuvent être mises hors tension et déplacées.
Il implique également que le plan de croissance du fournisseur avait une composante de disposition physique, pas seulement une composante de provisionnement logiciel.
Les clients de serveurs virtuels dédiés ont une dépendance différente. Ils peuvent ne pas se soucier du châssis individuel qui héberge la machine virtuelle jusqu'à ce qu'un hôte, un pool de stockage ou un élément d'agrégation réseau tombe en panne. Leur récupération dépend de la santé de l'hyperviseur, de la réplication de stockage, de la capacité d'accueil disponible, de la fraîcheur des sauvegardes et des outils de migration. Le registre public de Tempest ne divulgue pas l'architecture de virtualisation ou de stockage derrière ces produits.
Il montre cependant pourquoi les clients devraient demander si un VDS peut se déplacer entre hôtes ou villes, si les sauvegardes sont sur site ou intersites, et si une adresse IP suit la charge de travail pendant une restauration.
Les clients de serveurs de jeu se soucient du timing autant que de l'accessibilité. Un reroutage temporaire qui restaure la connectivité peut encore changer la latence, la gigue ou la continuité de session. Le langage de l'incident de Dallas concernant d'éventuelles déconnexions de joueurs est donc important. Il reconnaît qu'une solution de contournement réseau peut avoir un effet visible pour l'utilisateur même après que le service est techniquement revenu en ligne.
Pour les jeux et autres charges de travail en temps réel, un client devrait demander où se trouve la base de joueurs, quelle ville Tempest est utilisée, quel est le chemin de latence normal, quel est le chemin de basculement DDoS et amont, et si les changements de route sont testés depuis les marchés des joueurs plutôt que seulement depuis les propres points de surveillance du fournisseur.
Les clients de colocation sont encore un autre cas. Un appareil colocalisé peut dépendre de Tempest pour l'espace, l'alimentation, le réseau, les mains distantes et la coordination des cross-connects, tandis que le client possède le logiciel serveur et parfois le matériel. Si une route amont change, Tempest agit. Si un appareil client tombe en panne, la politique de mains distantes et d'accès compte. Si un événement d'installation se produit, les deux parties peuvent devoir se coordonner.
La liste d'installations de PeeringDB est utile car elle nomme les lieux physiques probables, mais le nom du lieu seul ne définit pas qui peut toucher quoi, à quelle vitesse et sous quel processus d'autorisation. Cette limite devrait être écrite avant une panne.
Cette distinction de produit est au cœur de l'économie de la capacité hébergée. La même baie, le même routeur et la même équipe de support peuvent servir de nombreuses gammes de produits, ce qui crée de l'efficacité. Cela crée également une contention lors d'un incident partagé. Une défaillance de commutateur central, une panne de transporteur ou un déplacement d'armoire peut envoyer de nombreux clients dans la même file d'attente de support et de réparation. Les preuves publiques prouvent que les couches existent; elles ne prouvent pas la capacité de la file d'attente.
La posture la plus sûre pour le client est de demander à Tempest un langage de récupération spécifique au produit plutôt que de se fier à des descriptions générales d'infrastructure.
La même distinction devrait façonner la surveillance. Un client de serveur dédié peut surveiller les événements d'alimentation, les compteurs d'interface, la santé des disques et l'accès hors bande. Un client VDS peut surveiller l'âge des instantanés, les avis de maintenance de l'hôte et la latence de stockage. Un client de serveur de jeu peut surveiller la latence et la gigue de la région des joueurs, car l'incident de routage de Dallas montre qu'une route récupérée peut encore interrompre une session.
Un client de colocation peut surveiller le statut des cross-connects, l'alimentation de l'armoire, la réponse des mains distantes et les changements de route amont. Les outils publics autour d'AS36231 aident seulement pour une partie de ce travail. Ils montrent le bord faisant face à Internet; ils ne montrent pas si les propres hypothèses de récupération du client correspondent à la classe de produit réellement achetée.
L'impact client dépend de la charge de travail, pas seulement de la disponibilité
Le langage de statut de Tempest suggère plusieurs classes de clients: clients dédiés entreprise, utilisateurs de serveurs économiques ou blade, utilisateurs de serveurs virtuels dédiés, clients de colocation et joueurs connectés à des charges de travail de jeu. Ces groupes vivent le même événement d'infrastructure différemment. Une mise hors tension planifiée de trois heures peut être acceptable pour un serveur de test et inacceptable pour une base de données de production. Une brève transition de route peut être inoffensive pour un site web statique et perturbatrice pour une session de jeu.
Une défaillance de commutateur central peut être une panne temporaire pour un locataire et un événement de réputation pour un revendeur avec des clients en aval.
C'est pourquoi la partie affectée n'est pas seulement "les clients de Tempest." Elle peut inclure des communautés de jeu, des petites entreprises utilisant des machines dédiées comme serveur principal, des revendeurs dont les clients ne savent pas que Tempest est en dessous, des développeurs qui ont choisi une ville pour la latence, et des entreprises qui ont supposé qu'un fournisseur mondial pourrait les déplacer rapidement entre sites. Elle peut également inclure des pairs et des amonts lorsque les changements de route déplacent le trafic vers des chemins alternatifs.
Le client qui voit une panne est souvent à plusieurs couches de la partie physique qui a échoué.
La localisation des données ajoute une autre conséquence. Une zone de service mondiale ne dit pas à un client quelle juridiction détient les données, quel processus judiciaire s'applique, ou si le support peut agir localement. Si une charge de travail est à Amsterdam, les données et le matériel peuvent se trouver aux Pays-Bas même si le compte est géré via une interface commerciale américaine ou dubaiote. Si un client restaure à Londres ou Dallas, le profil juridique et de latence change.
Les registres publics peuvent identifier les sites probables, mais seule la documentation du fournisseur et la configuration du compte client peuvent prouver où se trouve une charge de travail spécifique.
La migration doit donc être testée avant d'être nécessaire. Les clients devraient demander si les instantanés sont portables entre les emplacements de Tempest, si les adresses publiques peuvent être préservées, si les sauvegardes interrégions sont incluses ou optionnelles, et si le fournisseur a un processus documenté pour la relocalisation d'urgence.
Le registre de statut public montre que Tempest peut effectuer des déplacements réseau planifiés et des reroutages d'urgence, mais il ne montre pas le temps de récupération au niveau client pour les données, le calcul, la continuité d'adresse IP ou la capacité de la file d'attente de support lors d'un événement régional.
Quelles preuves renforceraient la revendication de capacité
Tempest franchit déjà le premier obstacle de preuve. AS36231 est actif, l'ensemble de préfixes est visible, le profil PeeringDB est maintenu, une page de statut nomme les emplacements et incidents, et le looking glass expose un véritable point de terminaison de test. La preuve plus forte se situerait plus près du contrat client. Elle montrerait quels produits sont disponibles dans quelles villes, quelles installations hébergent quels produits, quels amonts sont présents dans chaque ville, si la diversité de routage est diverse au niveau métropolitain, et quel matériel de rechange est maintenant stocké dans les nouveaux emplacements.
Le fournisseur n'a pas besoin de publier chaque détail opérationnel sur l'internet ouvert. Certains détails sont sensibles à la sécurité ou commercialement sensibles. Mais les clients peuvent encore demander une note d'architecture privée, une matrice d'escalade de support, un rapport de disponibilité actuel, une liste des fenêtres de maintenance affectant leur classe de service, et un test de récupération. Ils peuvent également demander une explication de la façon dont la bande de trafic PeeringDB de 1 à 5 Tbps correspond à la marge de manœuvre disponible pour le client. Une bande de trafic grossière n'est pas une promesse de capacité.
Elle peut décrire l'échelle réseau agrégée de pointe ou moyenne, pas la quantité de bande passante qu'un client peut réellement utiliser lors d'une panne.
La même chose s'applique à l'alimentation de l'installation. NTT Frankfurt, Iron Mountain Amsterdam, CoreSite Miami et d'autres opérateurs d'installation publient des caractéristiques impressionnantes de puissance et de connectivité. Un client de Tempest a encore besoin de connaître la puissance engagée de Tempest, le niveau de redondance, la densité des baies et la procédure de main distante à l'intérieur du site. Une installation peut avoir des mégawatts de réserve tandis qu'une cage spécifique n'a pas d'espace immédiat ou de fouet d'alimentation compatible.
Une installation peut avoir de nombreux transporteurs tandis que le produit du client utilise une route par défaut. Une salle de données peut être sécurisée tandis qu'une restauration client échoue parce que la sauvegarde n'a jamais été en dehors de la ville affectée.
C'est l'échelle de preuve de l'acheteur. D'abord, prouver que l'entreprise est liée à un réseau actif. Deuxièmement, prouver que le produit utilise réellement ce réseau. Troisièmement, prouver les dépendances de ville, baie, alimentation, amont et support du produit. Quatrièmement, prouver le chemin de récupération en l'exerçant. Le registre public de Tempest est solide sur la première étape et significatif sur la troisième en raison des divulgations d'incidents. Il est encore incomplet sur la deuxième et la quatrième pour tout client individuel jusqu'à ce que le client obtienne une confirmation spécifique au produit.
Le verdict étroit
Tempest Hosting, LLC doit être traité comme un opérateur d'infrastructure réel avec un réseau public mesurable, pas comme une empreinte purement mince. Les preuves sont inhabituellement utiles pour un fournisseur d'hébergement privé: AS36231 est visible; RIPEstat montre un espace IPv4 et IPv6 actuel; PeeringDB liste un profil mondial, une bande de trafic de 1 à 5 Tbps et huit installations; la page de statut nomme plusieurs villes opérationnelles; et les enregistrements d'incidents exposent des chemins de défaillance concrets dans les routeurs, les transporteurs amont, les armoires et le matériel de rechange.
C'est suffisant pour analyser le fournisseur en tant qu'infrastructure.
Ce n'est pas suffisant pour traiter chaque unité de capacité annoncée ou implicite comme déjà utilisable en cas de panne. Le matériel public ne divulgue pas les nombres exacts de baies, les réservations de puissance, la distribution des clients par ville, l'inventaire des pièces de rechange après la panne d'Amsterdam, ou les termes contractuels qui décident si un client peut déplacer des données et des adresses entre emplacements. La leçon la plus importante est que le registre public de Tempest montre à la fois la portée et la friction. La portée vient de l'empreinte mondiale de préfixes et d'installations.
La friction vient de la façon dont les fenêtres de maintenance et les incidents révèlent les mains, les pièces, les transporteurs et les décisions locales derrière le service.
Pour les clients, le test pratique est simple à énoncer et difficile à satisfaire: demander à Tempest de mapper le produit exact acheté à une ville, une installation, un chemin amont, une file d'attente de support, un stock de pièces et un plan de migration. Ensuite, comparer cette réponse avec les preuves de route publiques de RIPEstat, PeeringDB, BGP.tools et la page de statut de Tempest. Si la réponse est cohérente et que la procédure de récupération a été testée, l'empreinte de Tempest peut supporter des charges de travail sérieuses.
Si la réponse reste générique, l'acheteur devrait supposer qu'un compte serveur dépend encore de baies spécifiques au site, de changements de routage, de livraisons de fournisseurs et de fenêtres de réparation qui peuvent ne devenir visibles que lorsque quelque chose échoue.