CHINANET SHAANXI province Cloud Base network vend une capacité hébergée qui dépend encore des baies, du transit et des fenêtres de réparation

Résumé

• Le RDAP d’APNIC répertorieAS134768en tant queCHINANET-SHAANXI-CLOUD-BASE, avec le nom descriptif CHINANET SHAANXI province Cloud Base network, pays CN, enregistrement en 2015 et un contact hostmaster Chinanet.
• La visibilité actuelle des routes est forte. L’aperçu ASde RIPEstat indique qu’AS134768 est annoncé, tandis que lestatut de routagede RIPEstat montre 86 préfixes IPv4, 39 préfixes IPv6 et 11 voisins observés dans la fenêtre publique vérifiée.
• La topologie reste dépendante du réseau parent. Lesdonnées whoisdérivées d’APNIC répertorient des imports depuis AS4134 et AS4809, mais les vues actuelles des voisins publics de RIPEstat,bgp.tools, lapage BGPde Hurricane Electric etIPinfodésignent toutes AS4134, le backbone de China Telecom, comme l’amont visible.
• Les preuves sur les adresses publiques sont mitigées d’une manière qui importe pour la capacité hébergée. De nombreux préfixes annoncés sont des ressources Shaanxi Chinanet, mais les vues BGP publiques montrent également de l’espace routé décrit comme service IDC et cloud, ligne louée, blocs d’adresses Baidu, Zhejiang, Guangdong et Sichuan Xiaoteyun, de sorte qu’un client ne peut pas déduire la propriété de la charge de travail ou l’emplacement des baies à partir du seul numéro d’AS.
• Les signaux publics sur les installations pointent vers une véritable base de cloud computing à Xi’an/Xixian. Un rapport de visite de l’Université du Nord-Ouest de 2025 décrit la base de cloud computing de China Telecom au Shaanxi comme un grand centre cloud et big data de l’ouest de la Chine avec plus de 10 000 baies, des salles de norme T4, un PUE aussi bas que 1,25, des options de baies haute densité et un rôle dans les opérations cloud du gouvernement provincial.
• Le niveau de preuve est moyen, pas fort. Le réseau est visiblement actif et étendu, mais les sources publiques ne publient pas de carte actuelle et spécifique au produit de la propriété des baies, des alimentations électriques, du basculement amont, des tests de restauration, des limites de portabilité des données ou de l’escalade de support pour les clients achetant de la capacité hébergée via ce réseau de base cloud.

Une table de routage active n'est que la première preuve

Un fournisseur de capacité hébergée peut paraître fiable de deux manières très différentes. Une preuve est la table de routage: les routes sont visibles, les préfixes sont autorisés, les paquets ont un chemin, et l’AS apparaît sous un opérateur connu. L’autre preuve est opérationnelle: les baies sont alimentées, le système de refroidissement a de la marge, les hyperviseurs ont de la capacité de réserve, la copie de sauvegarde est restaurable, le support technique peut joindre le bon ingénieur, et le client peut sortir ses données à la fin de la relation.

Le réseau CHINANET SHAANXI province Cloud Base a une première preuve solide et une deuxième preuve publique plus mince.

L’identité officielle est simple. Le RDAP d’APNIC pourAS134768nomme l’ASCHINANET-SHAANXI-CLOUD-BASEet le décrit comme CHINANET SHAANXI province Cloud Base network. L’enregistrement le situe en Chine, montre un enregistrement le 27 octobre 2015 et répertorie des contacts hostmaster Chinanet. Lavue whoisde RIPEstat reprend le même nom et la même description d’AS, et ajoute des lignes de politique de routage important depuis AS4134 et AS4809 et exportant AS134768 vers ces réseaux. Cela suffit pour considérer le réseau comme un véritable sujet de routage China Telecom Shaanxi, et non comme un vague slogan cloud.

L’état actuel des routes est également significatif. Lestatut de routagede RIPEstat a montré AS134768 visible par presque tous les pairs RIS en IPv4 et en IPv6 dans la fenêtre de juillet 2026 vérifiée. Il a compté 86 préfixes IPv4, 39 préfixes IPv6, 184 576 adresses IPv4 et 12 576 équivalents IPv6 /48. Lavue des préfixes annoncésde RIPEstat a répertorié 125 entrées de préfixes actuelles en IPv4 et IPv6. Lapage BGPde Hurricane Electric a rapporté une échelle similaire, avec 184 576 adresses IPv4 annoncées et aucune route RPKI invalide annoncée dans sa vue actuelle. Ce ne sont pas les signes d’un ASN dormant.

Mais une table de routage ne montre pas l’intégralité du service. Elle ne dit pas si une machine virtuelle s’exécute dans une salle appartenant à China Telecom, une baie client dans la salle, une armoire exploitée par un partenaire, une région Tianyi Cloud, un pool de cloud gouvernemental, un environnement de ligne louée ou un arrangement de colocation tiers. Elle ne révèle pas si l’espace annoncé est attaché à des serveurs de production, des passerelles de périphérie, des routeurs clients, des nœuds d’hébergement, des plateformes de contenu ou des liaisons professionnelles privées.

Elle ne dit pas à l’acheteur combien de temps il faut pour remplacer un serveur défaillant ou si une file de support surchargée peut retarder une migration.

Cette différence est la dépendance centrale de l’article. AS134768 vend l’impression d’une capacité cloud en réseau, et les preuves BGP publiques soutiennent l’existence d’une périphérie China Telecom Shaanxi étendue et active. L’acheteur doit encore tester la couche physique et contractuelle derrière cette périphérie. Dans l’hébergement, la panne la plus dommageable n’est souvent pas « Internet a disparu ».

C’est la défaillance plus petite et plus dure: une baie perd une alimentation et l’alimentation restante est déjà chargée, un changement en amont expose une fuite de route, un pool de stockage a des sauvegardes mais pas de chemin de restauration rapide, un blocage de facturation empêche l’export pendant une migration, ou une fenêtre de maintenance est traitée comme hors de la promesse de disponibilité.

Ce que prouve le routage public

Le routage public prouve qu’AS134768 est visible et suffisamment important pour être surveillé. L’aperçu ASde RIPEstat identifie le détenteur comme CHINANET-SHAANXI-CLOUD-BASE, avec le même nom descriptif utilisé par APNIC. Le statut de routage actuel de RIPEstat montre une large visibilité IPv4 et IPv6, pas une route marginale vue par quelques collecteurs. La même page de statut rapporte une première activité vue en janvier 2017 et un dernier élément le 12 juillet 2026. L’historique des routes soutient donc la continuité: l’internet public voit cet ASN depuis des années, et il n’a pas simplement été enregistré puis abandonné.

Les agrégateurs tiers s’alignent sur cette image.bgp.toolsclasse le réseau comme actif sous APNIC, qualifie le type de réseau de contenu, montre China Telecom Backbone comme l’amont et rapporte 75 préfixes IPv4 et 39 IPv6 annoncés dans sa vue visible. Lapage AS134768de Hurricane Electric rapporte 127 préfixes annoncés au total, 88 IPv4 et 39 IPv6, plus 11 pairs BGP observés.IPinfodécrit l’ASN comme orienté hébergement, indique la Chine comme pays, montre des dizaines de milliers de domaines hébergés sur des adresses de l’ASN, et nomme AS4134 comme l’amont dans son résumé visible.

Il y a des différences dans les compteurs parce que les collecteurs BGP publics utilisent différents points de vue, choix de filtrage et temps de mise à jour. RIPEstat a compté 86 préfixes IPv4 dans la vue du statut de routage, tandis que bgp.tools en a montré 75 annoncés et Hurricane Electric 88. Cette variation ne doit pas être interprétée comme une contradiction. Le signal commun est plus important que le nombre exact: AS134768 a une large surface routée, un chemin parent China Telecom fort et un large mélange de ressources IPv4 et IPv6.

Les preuves d’origine de route semblent également meilleures que de nombreux petits réseaux d’hébergement. La validation d’origine de route de RIPEstat pour des blocs IPv4 représentatifs du Shaanxi tels que36.41.64.0/20,113.142.128.0/17et117.34.124.0/23a retourné un statut valide pour AS134768 dans les résultats vérifiés. Il en va de même pour des échantillons de blocs cloud et réseau IPv6 tels que240e:982:4500::/40et240e:108:1140::/48. Des ROA valides ne garantissent pas la qualité de service, mais ils réduisent une classe de risque d’origine de route.

La conclusion opérationnelle n’est donc pas « réseau faible ». C’est « routage public fort, preuves client incomplètes ». Un client peut raisonnablement croire qu’AS134768 est actif. Il ne devrait pas, sur cette seule base, croire que sa charge de travail hébergée bénéficie d’une protection multi-site, de deux chemins d’alimentation indépendants, d’une récupération de sauvegarde testée ou d’une portabilité facile des données. BGP répond à la question d’atteignabilité. La capacité hébergée exige plusieurs autres réponses.

L’histoire de l’amont est plus étroite que ce que suggère la politique du registre

L’enregistrement whois d’AS134768 dérivé d’APNIC nomme deux imports: AS4134 et AS4809. AS4134 est le backbone de China Telecom. AS4809 est le réseau CN2 de China Telecom, souvent associé à des chemins backbone premium. Si les deux chemins transportaient activement et indépendamment les charges de travail des clients, cela constituerait une diversité utile. Les vues de routes publiques ne prouvent pas cette interprétation plus forte.

Lavue des voisins ASNde RIPEstat a montré 11 voisins observés dans la fenêtre vérifiée. Le voisin de gauche était AS4134 avec une haute visibilité en IPv4 et IPv6. Les voisins de droite étaient un ensemble de réseaux urbains 5G de China Telecom au Shaanxi, notamment AS138387 pour Xi’an, AS138409 pour Tongchuan, AS138436 pour Baoji, AS138513 pour Weinan, AS138514 pour Xianyang et d’autres visibles principalement en IPv6. Le résumé d’IPinfo comptait également un amont,AS4134. bgp.tools présentait de même AS4134 comme l’amont. Hurricane Electric montrait AS4134 comme le pair IPv4 et aussi le pair IPv6 nommé dans la table visible.

L’écart n’est pas fatal. Un grand opérateur peut conserver des enregistrements de politique de routage qui reflètent l’ingénierie interne, des chemins planifiés ou une interconnexion privée que les collecteurs publics n’exposent pas complètement. AS4809 peut encore compter pour certains services même si AS4134 est l’amont public visible dans les vues échantillonnées. Mais un client achetant de la capacité hébergée ne devrait pas considérer la ligne AS4809 dans le whois comme une preuve d’un chemin de basculement actif affectant les clients.

Le test est une preuve actuelle et spécifique au produit: quel amont transporte ce service, vers quoi bascule-t-il, comment la politique de routage est-elle filtrée, comment RPKI est-il appliqué, et si le chemin de secours a suffisamment de capacité engagée pendant la charge de pointe.

C’est particulièrement important car tous les chemins visibles se situent à l’intérieur de la famille élargie de China Telecom. La résilience du réseau parent peut être excellente, mais ce n’est pas la même chose que l’indépendance commerciale ou physique. Une véritable revendication de diversité séparerait au moins quatre couches: la diversité des chemins BGP, la diversité des opérateurs ou des backbones, la diversité des chemins physiques et la capacité de réserve après un basculement.

Si les deux routes dépendent de la même tranchée de fibre métropolitaine, du même commutateur central de la base cloud, de la même entrée de bâtiment ou du même plan de contrôle de China Telecom, la deuxième ligne AS peut ne pas protéger le client contre la panne qui l’inquiète.

Le bon langage d’approvisionnement n’est pas hostile. Un acheteur peut demander: « Pour le service que nous achetons, quels sont l’AS d’origine, les ASN amont, les préfixes, les zones de disponibilité et les salles de données physiques concernés? Quel chemin est primaire? Quel chemin est testé? Quel chemin est simplement disponible pour l’opérateur ailleurs dans le réseau? » Cette distinction empêche qu’un réseau China Telecom solide soit survendu comme une résilience multi-fournisseur complète.

Le mélange de préfixes montre les surfaces d’hébergement, d’accès et de partenariat ensemble

La liste des préfixes publics est suffisamment large pour suggérer plus d’une surface commerciale. De nombreux préfixes visibles sont simplement de l’espace réseau Shaanxi Chinanet. Le RDAP d’APNIC pour36.41.64.0/20renvoie à une allocation plus large CHINANET-SN, et le libellé du contact administratif place le bureau de communication de données à Xi’an. Le RDAP d’APNIC pour113.142.128.0/17renvoie de la même manière à une allocation CHINANET-SN. Ces blocs soutiennent l’idée qu’AS134768 transporte des ressources d’adresses China Telecom Shaanxi, même si certaines descriptions héritées utilisent l’orthographe « Shanxi(SN) » d’une manière qui peut prêter à confusion entre Shaanxi et Shanxi. Le contexte du contact à Xi’an est l’ancrage pratique.

D’autres ressources routées rendent la frontière opérationnelle plus compliquée. bgp.tools répertorie plusieurs blocs de style 103.236.0.0/22 avec des descriptions pour Sichuan Xiaoteyun Technology. Le RDAP d’APNIC pour103.236.88.0/22identifie XIAOTEYUN comme le nom de ressource enregistré et un contact à Chengdu, Sichuan, tandis que l’aperçu du préfixede RIPEstat montre AS134768 comme l’origine actuelle dans la vue de route vérifiée. bgp.tools montre également certains préfixes décrits Baidu et non décrits comme Shaanxi Chinanet sur la page AS134768. La présence de ces ressources n’est pas une preuve de méfait. C’est la preuve que l’AS d’origine, le client, le détenteur de la ressource et l’emplacement de l’installation peuvent diverger.

Cette divergence est normale dans les grands réseaux. Un opérateur peut annoncer de l’espace PI client, de l’espace protégé contre les DDoS, des adresses cloud, des réseaux de ligne louée, des blocs de diffusion de contenu, des segments de cloud gouvernemental ou des allocations partenaires. Le risque pour le client est que le nom de l’AS seul ne peut pas dire à l’acheteur quel arrangement opérationnel s’applique.

Un VPS fonctionnant sur l’infrastructure cloud de China Telecom n’est pas la même chose qu’un routeur client dont le préfixe est annoncé par AS134768, et aucun des deux n’est la même chose qu’un site web hébergé sur une adresse IP comptée dans les données de domaines hébergés d’IPinfo.

IPinfoillustre pourquoi cela importe. Il rapporte plus de 23 000 domaines hébergés sur des adresses de l’ASN et met en évidence 103.236.90.151 comme une adresse avec des milliers de domaines. C’est un signal de marché utile: l’ASN semble héberger un trafic web dense en domaines. Il ne peut pas prouver le propriétaire contractuel de ces sites, l’emplacement des baies, la politique de sauvegarde, ni si l’adresse appartient à un revendeur, une plateforme d’hébergement partagé, une couche CDN ou un environnement géré par le client.

Pour les clients, la carte des adresses devrait faire partie de l’intégration. Quel préfixe sera attribué au service? S’agit-il d’espace China Telecom Shaanxi, d’espace client, d’espace partenaire ou d’espace partagé Tianyi Cloud? Qui contrôle le DNS inverse, la gestion des abus, la création de ROA, la politique de pare-feu et le null-routage d’urgence? Si le service est migré, l’IP suit-elle la charge de travail ou le client reçoit-il de nouvelles adresses? Ces questions transforment une grande table de routage en une véritable carte de dépendance.

Le label de base cloud indique une capacité physique

Les signaux publics sur les installations font que le nom « Cloud Base » est plus que décoratif. Un rapport de visite de l’École d’économie et de gestion de l’Université du Nord-Ouest en 2025 décrit labase de cloud computing de China Telecom au Shaanxicomme ayant commencé sa construction en 2013 et étant entrée en exploitation officielle en 2015. Le même rapport la décrit comme un grand centre de cloud computing et de big data de l’ouest de la Chine, avec des salles informatiques de norme T4, un PUE aussi bas que 1,25, plus de 10 000 baies, des options d’armoires de 5 kW, 8 kW, 12 kW et de plus haute puissance refroidies par liquide, une affirmation d’affichage de 22T de bande passante d’exportation et un rôle comme l’un des nœuds IDC centraux de China Telecom. Il indique également que l’on a montré aux étudiants le refroidissement, la distribution électrique, les capacités de sécurité et l’architecture du cloud gouvernemental provincial.

C’est plus solide qu’une vague page produit car cela décrit des attributs physiques: baies, densité de puissance, conception du refroidissement, protection incendie, bande passante et un rôle de campus. Cela s’aligne également historiquement avec un rapport de 2015 de centres de données Dynamics sur labase de cloud computing de Xi’ande China Telecom, qui décrivait l’ouverture d’une base cloud dans la région ouest et notait la stratégie plus large de nœuds cloud régionaux de China Telecom. Des pages secondaires et partenaires, y compris ladescription de nœud de Fenghuoyunet unarticle de 2018 de Shaanxi Phoenixsur les services cloud d’entrepreneuriat Tianyi, situent également la base cloud du Shaanxi dans la nouvelle ville de Fengxi de la nouvelle zone de Xixian et discutent de capacité de type IDC, cloud et colocation.

Ces descriptions publiques des installations aident, mais elles doivent encore être lues comme un contexte au niveau de l’installation plutôt que comme une preuve spécifique au client. La page de l’Université du Nord-Ouest est un rapport de visite, pas un contrat de service. Les pages Fenghuoyun et Phoenix sont des descriptions de style partenaire ou média, pas des audits neutres. La capacité de conception n’est pas la même que la capacité utilisable.

Un nombre de baies n’est pas une déclaration sur la disponibilité de baies vides, la marge de puissance, les commutateurs de rechange, l’inventaire matériel, les fenêtres de migration des clients ou la répartition actuelle entre le cloud, les charges gouvernementales, l’accès internet, les lignes louées et les services partenaires.

La conclusion la plus utile est une spécificité physique avec une mise en garde. Les clients devraient supposer qu’il existe un campus cloud et IDC important de China Telecom associé à l’histoire de la base cloud du Shaanxi. Ils ne devraient pas supposer que tout service routé via AS134768 se trouve physiquement dans une salle nommée, soutenu par l’ensemble du campus, ou protégé par chaque fonction de redondance décrite dans une visite publique. Une base cloud peut héberger plusieurs environnements logiquement séparés. Certains peuvent avoir une reprise après sinistre sur deux sites. Certains peuvent être à zone unique.

Certains peuvent être des baies partenaires. Certains peuvent être des zones de cloud public. Certains peuvent être de la colocation client.

L’acheteur devrait donc demander la déclaration de placement réel: campus, bâtiment, classe de salle, baie ou mappage de zone de disponibilité, conception de l’alimentation électrique, classe de refroidissement, chemin d’interconnexion, portée de la politique de maintenance et si le service est dans une plateforme partagée ou une baie dédiée. La réponse importe plus que l’échelle totale de la base.

La capacité installée n’est pas la capacité utilisable

Le matériel public sur la base cloud met l’accent sur l’échelle, et l’échelle est utile. Un campus avec des milliers de baies, des options d’armoires haute densité et une grande relation avec le backbone de China Telecom peut absorber plus de demande qu’un petit fournisseur hébergé dans un bureau. Il a également plus de couches où le service du client peut dépendre des choix d’allocation internes de l’opérateur.

La capacité installée est ce qui a été construit ou peut être montré dans un plan public. La capacité utilisable est ce que la charge de travail du client peut consommer sans violer les contraintes d’alimentation, de refroidissement, de stockage, de réseau ou de support. La capacité récupérable est ce qui reste disponible après une panne. Un nombre de baies en dit peu sur les deuxième et troisième catégories. Si toute la capacité haute densité de réserve est réservée aux charges de travail du cloud gouvernemental, un serveur hébergé commercial peut ne pas en bénéficier.

Si le pool de stockage de sauvegarde est grand mais que la bande passante de restauration est étroite, un client peut avoir une sauvegarde sans chemin de récupération. Si la base cloud a 22T de bande passante d’exportation affichée mais que le niveau de produit du client est limité en débit ou mono-hébergé dans un segment de service, la bande passante affichée ne définit pas le mode de défaillance du client.

La propre documentation publique de Tianyi Cloud renforce cette vue en couches. Lapage d’accueil de Tianyi Cloudprésente la marque autour de l’intégration cloud-réseau, de la sécurité, de la personnalisation dédiée et de multiples formes de cloud, y compris les services cloud publics, privés, dédiés, hybrides, de périphérie et full-stack. Sa documentation ECS pour lesrégions et zones de disponibilitéexplique une zone de disponibilité comme un ou plusieurs centres de données physiques au sein d’une région, avec une alimentation et un réseau indépendants, et indique que l’objectif est l’isolation des pannes sauf en cas de catastrophes majeures ou de pannes de courant importantes. C’est une déclaration d’architecture sensée. Cela signifie également que le client doit savoir si la charge de travail achetée s’étend réellement sur plusieurs zones, ou si elle se trouve simplement dans un pool de ressources local.

Il en va de même pour la capacité bare-metal, VPS, colocation et services gérés. Un client achetant une armoire veut de la puissance de réserve, des interventions à distance, un délai de mise en place d’interconnexion, du matériel de remplacement et des fenêtres de maintenance. Un client achetant des machines virtuelles veut une taille de cluster d’hyperviseur, une réplication de stockage, une isolation des snapshots, une exportation d’image et un placement dans un domaine de panne.

Un client achetant du cloud pour le secteur public veut la conformité aux politiques, l’emplacement de sauvegarde, des contrôles d’identité et une reprise après sinistre testée. AS134768 peut transporter du trafic pour toutes ces surfaces, mais chacune a une définition différente de la capacité utilisable.

Le test pratique consiste à demander une déclaration de capacité en cas de panne. Quelle quantité de calcul, de stockage, de bande passante et de support reste-t-il si une baie, un hôte, un commutateur, une étagère de stockage, une alimentation électrique ou une route amont tombe en panne? Le pool restant peut-il supporter la charge normale des clients, ou seulement maintenir les clients prioritaires en ligne? Le client doit-il acheter une deuxième zone de disponibilité ou un produit de reprise après sinistre distinct pour bénéficier de cette protection?

Sans cette réponse, « base cloud » reste une étiquette d’installation, pas une garantie de résilience.

L’alimentation, le refroidissement et les fenêtres de réparation déterminent la panne

Les pages des centres de données présentent souvent l’alimentation et le refroidissement comme une fierté d’ingénierie. Les clients devraient les lire comme des déterminants de panne. Le rapport de visite de l’Université du Nord-Ouest indique que la base du Shaanxi a des salles de norme T4, un PUE bas, des options de baies haute densité et des capacités avancées de refroidissement et de sécurité. La page de Fenghuoyun décrit des systèmes d’alimentation de secours, des services de type colocation, des commutateurs centraux et des revendications de certification de sécurité.

Un article de 2018 de Shaanxi Phoenix indique que la base avait une grande capacité de baies planifiée et promouvait des niveaux de service de continuité de réseau et d’alimentation. Ce sont des signaux publics positifs, mais pas un substitut aux conditions de service spécifiques au client.

La redondance électrique a plusieurs couches. Les arrivées du réseau électrique peuvent être diverses, mais l’appareillage de commutation peut encore être commun. Les systèmes UPS peuvent être redondants, mais la durée des batteries peut être courte. Les générateurs peuvent être disponibles, mais la logistique du carburant, la fiabilité de démarrage du générateur et l’état de la maintenance déterminent l’endurance réelle. Les PDU de baie peuvent avoir des arrivées A et B, mais un client peut accidentellement brancher les deux alimentations d’un seul côté.

Une baie haute densité refroidie par liquide peut être puissante, mais elle ajoute des dépendances au liquide de refroidissement et au soutien de l’installation qui n’existent pas pour les serveurs ordinaires à faible densité.

La redondance du refroidissement a également des couches. Un PUE bas est précieux, mais ce n’est pas une métrique de disponibilité. Il dit quelque chose sur l’efficacité et la conception. Il ne dit pas si une rangée donnée a suffisamment de marge de refroidissement après la défaillance d’un refroidisseur, d’une pompe ou d’une unité de traitement d’air. Il ne dit pas si les armoires haute densité refroidies par liquide peuvent continuer à fonctionner pendant la maintenance. Il ne dit pas au client si un événement temporaire de déclassement forcera les charges de travail à se déplacer.

Les fenêtres de réparation sont là où le client voit la vérité. Une panne de baie peut nécessiter des interventions à distance. Une panne de serveur peut nécessiter des pièces de rechange. Une panne de routage peut nécessiter un ingénieur autorisé à changer BGP. Une panne de stockage peut nécessiter une escalade vers le fournisseur. Une panne d’hyperviseur peut nécessiter un espace d’évacuation. Une panne de sauvegarde peut nécessiter que quelqu’un prenne une décision de restauration pendant que le service principal est en panne.

La taille de China Telecom ne supprime pas ces étapes; elle donne à l’opérateur plus de ressources pour les gérer si le processus est préparé.

Le client devrait demander le cheminement de l’incident en termes simples. Qui ouvre le ticket interne? Qui peut entrer dans la salle? Quelles pièces sont stockées sur place? Quels changements nécessitent une fenêtre de maintenance? Comment les clients sont-ils informés si une maintenance planifiée affecte une périphérie cloud, une alimentation électrique, un plan de stockage ou une route IP? Le SLA exclut-il la maintenance programmée? Quels services sont crédités et lesquels sont simplement soutenus au mieux?

Ces détails sont moins glamour qu’un nombre de baies, mais ils déterminent si une panne devient un événement court ou une longue migration.

Les signaux des domaines hébergés nécessitent une manipulation prudente

Les comptes de domaines hébergés d’IPinfo font paraître AS134768 comme un réseau d’hébergement, et c’est une preuve de marché utile. Il rapporte plus de 23 000 domaines hébergés dans l’ASN, avec des concentrations sur un petit ensemble d’IP. bgp.tools qualifie également le type de réseau de contenu. Le portefeuille de produits publics de Tianyi Cloud inclut des hôtes cloud élastiques, des hôtes cloud d’application, des services de machine physique, du stockage, de la sauvegarde, de la reprise après sinistre et d’autres offres d’infrastructure.

Ensemble, ces signaux soutiennent le postulat central: le réseau de base cloud fait partie d’une surface de capacité hébergée orientée client.

Ils ne prouvent pas le service exact derrière un domaine hébergé donné. Un domaine peut pointer vers un hébergement partagé, une plateforme de revendeur, un pare-feu applicatif, un proxy inverse, un équipement client en colocation, un serveur hérité, une application gouvernementale interne, ou un client professionnel utilisant un service IP statique. La concentration d’adresses IP n’est pas la même chose que la concentration de comptes cloud.

Un grand nombre de domaines sur 103.236.90.151, par exemple, peut indiquer un hébergement partagé ou une adresse de plateforme, mais le RDAP d’APNIC pour l’allocation sous-jacente 103.236.88.0/22 identifie XIAOTEYUN comme le nom de ressource enregistré. Cela rend la chaîne opérationnelle plus compliquée que « China Telecom Shaanxi possède chaque site sur l’IP ».

Cette distinction importe pendant une panne. Si un client est sur une IP d’hébergement partagé, un événement d’abus par un autre locataire peut affecter la réputation, la délivrabilité des courriels ou le filtrage. Si un client est sur de l’espace d’adresse partenaire routé, les contacts d’origine de route et d’abus peuvent ne pas correspondre nettement au contrat. Si un client est sur un cloud privé virtuel avec une IP élastique, la migration peut nécessiter des changements DNS et un basculement de point de terminaison.

Si un client est en colocation avec un routeur appartenant au client, le fournisseur peut être responsable de l’alimentation et des interconnexions mais pas du système d’exploitation ou de l’application du client.

L’article traite donc les comptes de domaines hébergés comme un signal de marché non officiel, pas comme une preuve finale de capacité. Ils suggèrent qu’AS134768 est utilisé pour le trafic web et d’infrastructure orienté client. Ils ne peuvent pas établir qui possède les serveurs, si les charges de travail sont sauvegardées, si la location est isolée, s’il existe un chemin de restauration testé, ou si le client peut exporter une image de VM, un vidage de base de données, une archive de boîte aux lettres ou un compte complet de type cPanel en période de stress.

La preuve déterminante serait une documentation produit liée au service réel: allocation d’adresses, conception de l’isolation des locataires, portée des sauvegardes et des snapshots, formats d’exportation, gestion des abus, contrôles DDoS, contrôle du DNS inverse, politique de réputation de courrier et support à la migration. Sans ces détails, l’échelle des domaines hébergés est une raison de poser de meilleures questions, pas une raison de se détendre.

La localisation des données est un argument de vente et une contrainte

Le champ région pour ce profil est CN, et les preuves publiques soutiennent une surface opérationnelle basée en Chine. APNIC répertorie l’AS en Chine. Les rapports sur la base cloud du Shaanxi situent le campus physique dans la région de Xi’an/Xixian. Les pages produits et les documents de service de Tianyi Cloud sont orientés vers la Chine. Cette présence locale peut être précieuse pour les charges de travail du secteur public chinois, réglementées et sensibles à la latence. Elle peut également limiter la façon dont un client conçoit les sauvegardes, l’accès au support et les chemins de sortie.

L’environnement juridique chinois fait du placement des données plus qu’une préférence d’approvisionnement. La traduction de la Loi sur la cybersécurité hébergée parDigiChinadécrit une exigence de localisation pour les informations personnelles et les données importantes collectées ou produites par les opérateurs d’infrastructures d’information critiques en Chine continentale. LaLoi sur la sécurité des donnéesétablit un cadre national de sécurité des données. La Loi sur la protection des informations personnelles, résumée par lePCPDde Hong Kong et traduite par des sources telles queChina Law Translate, ajoute des obligations de traitement des informations personnelles et de transfert transfrontalier. Les devoirs exacts dépendent du client, du type de données et de l’arrangement de service, mais la direction est claire: les règles de localisation, d’accès et de transfert importent.

Pour les clients d’AS134768, la localité a trois dimensions pratiques. La première est la localité de production: où se trouvent réellement les points de terminaison de calcul, de stockage et de réseau. La deuxième est la localité de sauvegarde: où sont stockés les snapshots, les archives, les réplicas de reprise après sinistre et les journaux. La troisième est la localité administrative: qui peut accéder aux systèmes, d’où, sous quelle entité juridique et quel processus de support. Un service peut être hébergé localement mais utiliser une gestion à distance, des outils de sécurité externes ou une sauvegarde inter-région.

Un service peut annoncer une base cloud du Shaanxi mais fournir une reprise après sinistre dans une autre province. Cela peut être une bonne architecture, mais cela doit être explicite.

La localisation des données affecte également la migration. Si un client doit partir, peut-il exporter des données vers un autre fournisseur basé en Chine, une autre région de China Telecom, un système sur site ou une plateforme à l’étranger? Y a-t-il des limites juridiques, techniques ou contractuelles au transfert de journaux, d’informations personnelles, de données gouvernementales, de clés de chiffrement ou de sauvegardes? Le fournisseur prend-il en charge l’exportation en masse sans limitation de débit? Combien de temps après la résiliation le client conserve-t-il l’accès?

Que se passe-t-il si le compte est suspendu pour facturation alors que le client a encore besoin de récupération de données?

La lecture la plus sûre est que l’infrastructure locale en Chine est un avantage lorsque les besoins de conformité et de latence du client correspondent à la plateforme, et une contrainte lorsque le client a besoin de redondance transfrontalière ou de sortie rapide. La table de routage d’AS134768 ne peut pas répondre à ces questions. Seuls les conditions de service et l’arrangement de traitement des données le peuvent.

Le contrat de service décide de ce que le cloud ne couvre pas

Les clients du cloud confondent souvent le langage de disponibilité avec la pleine responsabilité opérationnelle. L’index SLAde Tianyi Cloud répertorie les accords de niveau de service pour les produits de calcul, de stockage, de sauvegarde et de reprise après sinistre. Sapage SLA ECSrenvoie les utilisateurs aux conditions de niveau de service de l’hôte cloud élastique. Les documents produit de Tianyi Cloud distinguent également les zones de disponibilité, les types d’instance, les services GPU, les disques cloud, les produits de sauvegarde et les produits de reprise après sinistre. Cette structure indique aux clients quelque chose d’important: la résilience est assemblée à partir de services spécifiques, pas automatiquement héritée de la marque mère.

En pratique, un acheteur devrait s’attendre à des exclusions. La plupart des SLA cloud excluent la maintenance programmée, les échecs de configuration côté client, les problèmes de compte et de paiement, les événements de force majeure et les pannes en dehors de la limite de service définie par le fournisseur. Certains produits offrent des crédits plutôt que des garanties de restauration. Certaines instances hautes performances ou spécialisées peuvent suivre un SLA différent. Certains produits de reprise après sinistre ne protègent que les données ou la configuration sélectionnées par le client. Rien de tout cela n’est inhabituel.

C’est pourquoi la lecture de l’accord spécifique au service importe.

Pour AS134768, la limite contractuelle devrait être testée par rapport aux principaux chemins de défaillance. Si la route amont tombe en panne, est-ce couvert par la disponibilité du réseau ou exclu comme maintenance backbone? Si une baie perd l’alimentation, le client reçoit-il un crédit de service, un support de restauration, ou les deux? Si une VM gérée par le client est mal configurée après un basculement, où s’arrête la responsabilité du fournisseur? Si une action d’atténuation DDoS null-route une IP client, quel est le chemin d’escalade?

Si une charge de travail cloud gouvernemental a des contrôles de sécurité différents du cloud commercial, quelle équipe de support agit?

La facturation et l’état du compte méritent attention. La capacité hébergée peut échouer administrativement. Une facture impayée, un retard de renouvellement de contrat, un problème de vérification de nom réel, un problème de dépôt de domaine, une plainte pour abus ou une non-concordance de l’identité du client peuvent suspendre le service ou bloquer la migration aussi efficacement qu’un routeur cassé. Les clients achetant une capacité critique devraient demander si un litige de facturation peut affecter l’exportation de données, combien de temps les données sont conservées après suspension, et qui peut autoriser un accès d’urgence.

Le meilleur contrat cloud rend visibles les dépendances invisibles. Il énonce la limite de service, la métrique de disponibilité, l’avis de maintenance, la conservation des données, la responsabilité de sauvegarde, la méthode d’exportation, la sévérité du support, l’objectif de réponse et les obligations du client. Si AS134768 est la surface de routage et Tianyi Cloud ou une unité de China Telecom Shaanxi est le fournisseur de service, le client a besoin à la fois des faits de routage et des faits contractuels dans le même dossier.

Principaux chemins de défaillance à tester

Le premier chemin de défaillance est la panne de baie ou d’installation. Cela inclut l’alimentation des baies, le refroidissement de la rangée, les erreurs de PDU, les commutateurs de haut de baie, les interconnexions, les panneaux de fibres, l’accès physique et les erreurs de maintenance. Les rapports publics sur la base cloud suggèrent une installation substantielle, mais l’échelle de l’installation ne supprime pas la défaillance locale. Les clients doivent savoir si leur service est à baie unique, salle unique, bâtiment unique, multi-zone ou sur deux sites.

Le deuxième chemin est la défaillance de l’amont ou du backbone. Les vues publiques actuelles montrent AS4134 comme l’amont visible. La politique whois mentionne AS4809, mais les collecteurs de routes n’en font pas un chemin de basculement client prouvé. Les clients ont besoin de la carte active de l’amont, du test de basculement, des filtres de route, de l’état RPKI et du comportement attendu si AS4134 a un problème régional ou national.

Le troisième chemin est la défaillance du stock de matériel. Une plateforme hébergée peut identifier rapidement un serveur défaillant et attendre néanmoins un remplacement. Le calcul haute densité GPU, refroidi par liquide ou spécialisé ajoute un risque d’inventaire supplémentaire. Un client devrait demander quelles pièces sont stockées localement, lesquelles nécessitent l’envoi d’un fournisseur, et si l’opérateur peut effectuer une migration en direct ou une restauration vers un autre matériel pendant que les pièces sont en transit.

Le quatrième chemin est la défaillance du support. Le réseau de base cloud se trouve à l’intérieur d’une grande organisation opératrice, ce qui peut être une force si l’escalade est mature. Cela peut également créer un risque de transfert entre les opérations locales, les opérations backbone, les opérations cloud, le support client, la facturation, la sécurité et les équipes partenaires. Le client devrait savoir quel guichet est propriétaire de chaque type d’incident et quel niveau de sévérité déclenche une escalade de 24 heures.

Le cinquième chemin est la défaillance de la sauvegarde et de la restauration. Les sauvegardes qui existent mais sont lentes, incomplètes ou contrôlées par le mauvais compte ne résolvent pas une panne. Les clients devraient exiger des preuves de restauration, pas seulement des noms de produits de sauvegarde. Pour une VM, cela signifie démarrer une image restaurée. Pour une base de données, cela signifie des preuves de cohérence et de point de récupération. Pour le stockage d’objets, cela signifie le versionnage, la protection contre la suppression et la séparation des comptes.

Pour la colocation, cela peut signifier que le fournisseur ne sauvegarde pas du tout les données du client.

Le sixième chemin est l’échec de la migration. Les clients quittent souvent une plateforme en période de stress, lorsqu’une application est instable ou que l’entreprise a perdu confiance. C’est le pire moment pour découvrir que les adresses IP ne peuvent pas être déplacées, que les images ne peuvent pas être exportées, que les snapshots sont propriétaires, que la bande passante est limitée ou que le support n’aidera pas tant que les factures ne sont pas réglées. La migration devrait être répétée lorsque le service est sain.

Ces tests ne nécessitent pas de méfiance. Ils constituent une diligence raisonnable ordinaire pour tout fournisseur de capacité hébergée dont les preuves de réseau public sont plus solides que ses preuves de limite de service public.

Ce qui élèverait le niveau de preuve

AS134768 obtient un niveau de preuve réseau moyen parce qu’il a un routage public solide, une identité APNIC officielle et un contexte de cloud physique plausible. Pour atteindre le niveau fort, les preuves publiques ou contractuelles devraient relier la table de routage au service client plus directement.

La première amélioration serait une déclaration de topologie actuelle. Elle devrait nommer l’AS d’origine actif, les ASN amont, les préfixes de produit, la région et le mappage des zones de disponibilité. Elle devrait expliquer si AS4809 est actif pour le service ou s’il apparaît seulement dans la politique de routage. Elle devrait identifier si les charges de travail des clients utilisent l’espace China Telecom Shaanxi, l’espace partagé Tianyi Cloud, l’espace PI client ou des blocs d’adresses partenaires. Elle devrait indiquer qui maintient les ROA et qui répond aux événements d’abus ou de fuite de route.

La deuxième amélioration serait des preuves de limite d’installation. Les clients n’ont pas besoin d’un plan d’étage public, mais ils ont besoin de savoir si leur charge de travail se trouve dans la base cloud de Xixian/Fengxi, un autre centre de données du Shaanxi, un pool régional Tianyi Cloud, une baie partenaire ou une armoire appartenant au client. La déclaration devrait inclure la classe de puissance, les hypothèses de densité de baie, la politique de fenêtre de maintenance, le plan de pièces de rechange et si le service est à zone unique ou multi-zone.

La troisième amélioration serait des preuves de récupération. Un fournisseur solide peut montrer des exercices de restauration, pas seulement des produits de sauvegarde. Il peut décrire les récentes restaurations de VM, de stockage, de base de données, les tests de basculement réseau et d’exportation client. Il peut dire quelles pannes sont couvertes par un basculement automatisé et lesquelles nécessitent un ticket manuel. Il peut également énoncer des objectifs réalistes de temps de récupération et de point de récupération par produit.

La quatrième amélioration serait des preuves de localisation des données et de sortie. Le fournisseur devrait décrire l’emplacement de production, l’emplacement de sauvegarde, l’emplacement des journaux, l’accès des sous-traitants, le contrôle des clés de chiffrement, les formats d’exportation, la conservation après résiliation et les contraintes de transfert transfrontalier. Pour les charges de travail gouvernementales ou réglementées, il devrait distinguer la conformité légale de la commodité commerciale.

La cinquième amélioration serait des preuves d’incident. Une page de statut, un résumé de l’historique des incidents, un calendrier de maintenance, une matrice de sévérité du support et un modèle de rapport post-incident feraient la différence entre une grande table de routage et un service client fiable. Les grands opérateurs gardent parfois ces informations derrière des portails clients, ce qui est bien pour les clients sous contrat. L’absence publique signifie toujours qu’un lecteur extérieur ne devrait pas les supposer.

Si ces éléments sont produits, l’histoire passe de « grande surface routée China Telecom Shaanxi active avec un soutien plausible d’installation de base cloud » à « plateforme de capacité hébergée vérifiée avec des domaines de panne et des chemins de récupération connus ». C’est la différence entre l’échelle du réseau et la confiance dans l’infrastructure.

La conclusion: des routes solides, une résilience conditionnelle

Le réseau CHINANET SHAANXI province Cloud Base est un sujet d’infrastructure actif. APNIC, RIPEstat, bgp.tools, Hurricane Electric et IPinfo soutiennent tous le même fait central: AS134768 est un réseau de base cloud China Telecom Shaanxi actif avec une empreinte IPv4 et IPv6 substantielle. Les vérifications représentatives d’origine de route sont valides. La visibilité actuelle est élevée. Le réseau n’est pas une coquille dormante.

La prudence opérationnelle est tout aussi claire. Le BGP public montre l’atteignabilité, pas la propriété des baies. Les enregistrements d’adresses APNIC montrent les détenteurs de ressources et les contacts, pas les charges de travail des clients. Les comptes de domaines hébergés suggèrent une utilisation web et d’hébergement, pas la qualité des sauvegardes.

Les rapports de visite de la base cloud et les pages partenaires indiquent un véritable centre de données et campus cloud dans la région de Xi’an, mais ils ne disent pas à un client quel produit est à zone unique, lequel est multi-zone, quel chemin utilise AS4809, quelle baie a de la puissance de réserve, ou quelle équipe de support restaure un serveur défaillant à 2 heures du matin.

Pour un acheteur, la position pratique est une confiance disciplinée. Traitez le réseau comme actif. Traitez le contexte de la base cloud China Telecom Shaanxi comme significatif. Demandez ensuite les preuves qui décident réellement des pannes: préfixe de produit, zone de disponibilité, chemin amont, propriété des ROA, puissance des baies, marge de refroidissement, matériel de rechange, portée des sauvegardes, preuve de restauration, escalade de support, exclusions de maintenance, règles de continuité de facturation et conditions d’exportation des données.

La capacité hébergée n’est pas sans poids. Dans le Shaanxi, comme ailleurs, ce sont des routeurs, des fibres, des salles électriques, des boucles de refroidissement, des ports de commutateur, des files de support et des contrats. AS134768 rend cette capacité visible sur internet. Il ne supprime pas la nécessité de vérifier la chaîne physique et opérationnelle qui se trouve en dessous.