CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch vend une capacité hébergée qui dépend encore des baies, du transit et des fenêtres de réparation

Résumé

• APNIC identifie l'AS63659 comme CU-CDC-SH et le décrit comme CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch en Chine. Les mêmes données publiques d'APNIC lient 103.68.128.0/22 au netname CU-CDC-SH et à une adresse de bâtiment China Unicom au 1033 Changning Road, district de Changning, Shanghai.
• L'ASN de la filiale n'est pas une preuve de routage public actuelle. Le résumé AS de RIPEstat pour AS63659 indiquait announced: false; la vue announced-prefixes ne retournait aucun préfixe courant; le routing-status montrait 0 préfixes IPv4, 0 préfixes IPv6 et 0 voisins observés; l'historique de routage plaçait l'origine visible de 103.68.128.0/22 par AS63659 en 2017-2018, avec la dernière origine AS63659 vue en novembre 2018.
• Le bloc d'adresses compte toujours car la vue préfixe de RIPEstat pour 103.68.128.0/22 montrait le préfixe annoncé par AS138421, titulaire CU-CN-AS - China Unicom, avec 325 pairs sur 325 RIS le voyant au moment de la requête. Cela soutient un chemin routé China Unicom actuel, pas une revendication de service client auto-exploité spécifique à la filiale.
• Les rapports officiels de China Unicom montrent une importante activité de cloud et de centre de données: revenus des centres de données 2025 de 28,1 milliards RMB, plus de 1,10 million d'armoires standard, sept campus AIDC de 100 MW, croissance des revenus de Unicom Cloud et revenus de Unicom Cloud au premier semestre 2025 de 37,6 milliards RMB. Ces chiffres établissent le contexte d'infrastructure à l'échelle du parent, pas le placement exact du client, le nombre de baies ou le chemin de restauration pour l'entité de la filiale de Shanghai.
• Le niveau de preuve est Faible. Le dossier public soutient une empreinte réelle de ressources numériques liées à la filiale et un préfixe China Unicom actuellement routé, mais il ne prouve pas l'exploitation courante de l'AS63659, la capacité client au niveau de la filiale, la diversité de transit, le placement des données ou les performances de récupération.

Les preuves utiles commencent par une scission

Le fait principal concernant CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch est une scission entre les preuves d'enregistrement et les preuves de routage actuelles. Dans le registre RDAP d'APNIC pourAS63659, le handle est AS63659, le nom est CU-CDC-SH, le pays est CN et le statut est actif. Lavue whois de RIPEstat pour AS63659donne le même label d'exploitation et décrit la ressource comme CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch. C'est un signal d'identité significatif: ce n'est pas une référence générique à « cloud » collée sur une page marketing.

Les preuves de routage sont plus étroites. Lerésumé ASde RIPEstat montrait AS63659 comme non annoncé au moment de la requête du 2026-07-11 16:00 UTC. Lavue announced-prefixesde RIPEstat retournait une liste vide de préfixes courants pour la fenêtre d'observation récente, et lavue routing-statusmontrait zéro espace IPv4 annoncé, zéro espace IPv6 annoncé et zéro voisin observé. Un client ne peut pas convertir ces champs en une promesse que cet ASN de filiale transporte un service hébergé en direct aujourd'hui.

Cela ne rend pas la filiale non pertinente. Le registre RDAP d'APNIC pour103.68.128.0/22identifie le netname CU-CDC-SH et donne la plage comme 103.68.128.0 à 103.68.131.255, statut actif, pays CN. Lesdonnées whois de RIPEstat pour 103.68.128.0/22répètent la description de la filiale et l'adresse du bâtiment China Unicom. Ces enregistrements indiquent à un acheteur par où commencer, mais ils ne montrent pas un service cloud complet.

Le changement important est que le même bloc d'adresses est visible maintenant via un AS différent. Leaperçu du préfixede RIPEstat montrait 103.68.128.0/22 annoncé par AS138421, titulaire CU-CN-AS - China Unicom. Lavue routing-status pour le préfixemontrait la route visible pour tous les 325 pairs IPv4 RIS au moment de la requête, avec l'origine AS138421. Les preuves soutiennent donc un bloc d'adresses routé China Unicom actuel associé à l'enregistrement de la filiale. Elles ne soutiennent pas une simple phrase que l'AS63659 lui-même est actuellement la bordure orientée client.

Un AS de filiale dormant modifie le test d'approvisionnement

Un AS dormant n'est pas automatiquement un service en échec. Les grands opérateurs consolident souvent les routes clients dans un AS dorsal plus large, retirent les petits ASN d'origine, changent la politique de routage, ou maintiennent les ressources numériques dans un compte régional ou produit tandis que le trafic passe par un réseau national. Mais un AS de filiale dormant modifie le test. La question n'est plus « est-ce que l'AS63659 annonce des préfixes clients? » La question devient « quel réseau, installation et contrat de China Unicom portent maintenant la capacité hébergée que le nom de la filiale semble représenter? »

L'historique de routage pour AS63659de RIPEstat montrait une visibilité historique pour 103.68.128.0/22 et des plus spécifiques connexes sous l'origine AS63659, avec l'origine visible AS63659 se terminant fin 2018 pour l'agrégat. La vue actuelle des préfixes, en revanche, place 103.68.128.0/22 sous AS138421. Cet historique est utile car il empêche deux erreurs courantes. La première erreur est de qualifier la filiale de simple coquille parce que son propre AS n'est pas courant. La seconde est de traiter une ancienne origine AS comme une preuve d'exploitation actuelle.

Le client devrait forcer la distinction dans le contrat. Si un document commercial ou de support mentionne encore la filiale, le client devrait demander si sa charge de travail utilisera 103.68.128.0/22, un autre pool d'adresses Unicom Cloud, une interconnexion privée, un chemin d'échange de cloud public, ou un bloc attribué au client. Si la réponse est « dorsal China Unicom », le client a besoin de la bordure de service AS138421, pas d'AS63659, incluse dans la supervision et les preuves d'incident. Si la réponse est « filiale de Shanghai », le client doit savoir quelle installation et équipe d'exploitation rendent cela vrai.

L'absence d'unprofil PeeringDB pour AS63659dans la vérification de l'API publique renforce le même point. L'absence de PeeringDB n'est pas un jugement négatif; de nombreux ASN internes ou régionaux d'opérateurs ne maintiennent pas d'enregistrements publics PeeringDB. Cela signifie simplement que la surface d'interconnexion publique n'expose pas les attachments d'échange, les installations, la politique de peering ou les données de looking-glass pour cet ASN de filiale. Un acheteur doit obtenir ces informations directement plutôt que de les déduire d'un nom.

Le chemin en direct semble être le dorsal plus large de China Unicom

La preuve de chemin actuelle repose sur AS138421. Lerésumé AS pour AS138421de RIPEstat identifiait le titulaire comme CU-CN-AS - China Unicom et montrait l'AS comme annoncé. Lavue announced-prefixes pour AS138421retournait des centaines de préfixes IPv4 courants dans la fenêtre récente. Pour 103.68.128.0/22 spécifiquement, lesdonnées looking-glassde RIPEstat montraient des chemins de collecteurs internationaux se terminant par AS138421 via des chemins amont qui incluent AS4837 dans de nombreuses observations. Cela est cohérent avec le bloc d'adresses étant joignable dans le cadre d'un grand système de routage China Unicom.

La conséquence pratique est que la dépendance orientée client de la filiale peut être une relation commerciale et de support régionale dont les paquets circulent sur un dorsal national. Cela peut être une force. Un dorsal d'opérateur national peut fournir une échelle, un levier de réparation, un transport optique, des opérations de sécurité et plusieurs options régionales qu'un petit hébergeur indépendant ne peut égaler. Cela peut aussi cacher des détails locaux.

Un client peut connaître la marque de l'opérateur mais pas la salle de données, la baie, l'origine de la route, la cross-connexion locale, la dépendance d'alimentation métropolitaine ou la file d'attente de support qui affecte réellement la charge de travail.

Le routage public ne peut pas répondre si le préfixe actif est utilisé pour des serveurs cloud, des services de gestion, l'accès client, des systèmes internes ou d'autres utilisations de China Unicom. Il ne peut pas montrer quelle partie du /22 est libre, attribuée, filtrée, pare-feu ou liée à un produit particulier. Il ne peut pas dire si la filiale de Shanghai contrôle le calendrier de changement ou si un centre d'opérations réseau national contrôle la politique de routage. La route est un signal d'exploitation actuel, pas un certificat de capacité.

C'est pourquoi le plan de supervision du client devrait inclure les deux identités. AS63659 est l'identité de ressource numérique liée à la filiale. AS138421 est l'origine publique actuelle pour le préfixe lié à la filiale. Un moniteur de route qui ne surveille que AS63659 manquera la route en direct si le service actuel reste sous AS138421. Une revue d'approvisionnement qui ne surveille que AS138421 peut manquer l'incertitude spécifique à la filiale concernant l'allocation d'adresses, l'escalade de support et le placement client.

L'échelle de China Unicom est réelle, mais l'échelle n'est pas le placement

Les rapports officiels de China Unicom montrent l'échelle derrière le système parent. Lerapport annuel 2025indique que les revenus des centres de données ont atteint 28,1 milliards RMB, en hausse de 8,5 % en glissement annuel; les armoires standard ont dépassé 1,10 million; sept campus AIDC de 100 MW ont été construits; l'utilisation des armoires a dépassé 72 %; l'échelle de calcul intelligent a atteint 45 EFLOPS; et plus de 9 000 kilomètres ont été ajoutés au réseau de câbles à fibres optiques dorsaux « Huit verticales et huit horizontales » pour l'interconnexion des centres de calcul. Le même rapport indique que Unicom Cloud a évolué vers le cloud IA et inclut les centres de données cloud, les ressources cloud, la plateforme cloud, le service cloud, l'intégration cloud, l'interconnexion cloud et la sécurité cloud dans la définition des revenus de Unicom Cloud.

Lerapport semestriel 2025ajoute une vue à mi-année: les revenus de Unicom Cloud au premier semestre ont atteint 37,6 milliards RMB; les revenus des centres de données ont atteint 14,4 milliards RMB; l'utilisation des ressources des centres de données a dépassé 70 %; China Unicom a fourni des services de réseau intelligent à plus de 280 fournisseurs de services cloud et était connecté à plus de 400 centres de données; et la société a décrit des centres de calcul intelligent de 10 000 puces à Shanghai Lingang, Hohhot, Zhongwei et Sanjiangyuan. Lerapport annuel 2024a également rapporté des revenus de Unicom Cloud de 68,6 milliards RMB, des revenus de centres de données de 25,9 milliards RMB et des centres de calcul intelligent à grande échelle à Shanghai et dans d'autres régions.

Ce sont des faits d'infrastructure solides au niveau parent. Ils importent car ils montrent que « cloud » dans ce cas n'est pas seulement une étiquette de revendeur attachée à un petit site web. Le groupe parent dépense et rapporte à l'échelle d'un opérateur. Pourtant, l'échelle parent ne décide pas du placement de la filiale. Les rapports ne disent pas que CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch dispose d'un nombre spécifique de baies disponibles pour les clients publics. Ils ne précisent pas que 103.68.128.0/22 est un pool de serveurs clients.

Ils ne publient pas les temps de récupération pour ce nom de filiale, ni ne cartographient la filiale à un site nommé, une entrée d'opérateur, une région de sauvegarde ou un chemin de migration de charge de travail.

L'acheteur devrait donc traiter les preuves à l'échelle parent comme un contexte plutôt qu'une preuve. Un grand opérateur peut encore vendre un produit local dont la réparation dépend d'un seul bâtiment, d'une seule file d'attente d'intervention à distance, d'un seul service d'assistance, d'un seul propriétaire de changement réseau ou d'une seule procédure d'exportation de données. Inversement, une filiale avec un AS dormant peut encore être soutenue par une plateforme nationale robuste. La recherche publique ne peut pas choisir entre ces résultats. Le contrat, les preuves d'architecture et les résultats de test doivent faire ce travail.

L'adresse de Shanghai est un indice, pas un plan de salle de données

Les enregistrements publics liés à la filiale pointent vers Shanghai. Le RDAP d'APNIC et le whois de RIPEstat listent le bâtiment China Unicom au 1033 Changning Road, district de Changning, Shanghai dans les champs d'adresse de contact administratif et technique pour l'AS et l'allocation 103.68.128.0/22. C'est un indice d'emplacement réel. Cela ne signifie pas que les serveurs clients sont situés à cette adresse, et cela ne signifie pas que l'adresse est un centre de données.

Il peut s'agir d'un bureau, d'un point d'enregistrement, d'un contact d'exploitation, d'un site d'administration réseau ou d'une adresse professionnelle adjacente à une installation.

Shanghai compte toujours. Les rapports officiels identifient Shanghai parmi les déploiements de calcul intelligent à grande échelle de China Unicom, et le rapport semestriel 2025 nomme spécifiquement Shanghai Lingang dans une liste de centres de calcul intelligent de 10 000 puces. Si un client achète une capacité hébergée en Chine parce que la localité de Shanghai, la portée réseau ou le contexte réglementaire importe, il devrait demander si la charge de travail de production est à Shanghai, dans un hub de calcul national, dans une autre province, ou dans un pool cloud partagé dont le plan de contrôle et les sauvegardes couvrent les régions.

La question n'est pas académique. Un service étiqueté Shanghai peut avoir plusieurs couches physiques: une filiale commerciale locale, un canal de support client à Shanghai, une allocation d'adresse enregistrée à un contact à Shanghai, une route dorsale nationale, un centre de données à Lingang ou un autre district, une sauvegarde dans une autre province, et une plateforme de gestion ou de journalisation ailleurs. Chaque couche modifie la latence, la juridiction, la responsabilité opérationnelle et la récupération.

L'acheteur devrait demander une matrice de placement. La matrice devrait lister la production de calcul, le stockage, la sauvegarde, les journaux, l'identité, les enregistrements de facturation, le système de support client, la supervision, l'administration à distance et les lieux d'exportation. Elle devrait également indiquer lesquels de ces emplacements sont garantis, lesquels sont une pratique opérationnelle normale, et lesquels peuvent changer sans approbation du client. Sans cette matrice, l'étiquette de la filiale de Shanghai est utile pour la découverte mais insuffisante pour l'assurance de souveraineté ou de continuité.

Les baies transforment un service cloud en un problème de réparation

L'expression « capacité hébergée » cache la file d'attente physique derrière le service. Une machine virtuelle ou une plateforme gérée a besoin d'armoires, d'électricité, de refroidissement, de routeurs, de commutateurs, d'optiques, de câbles, de disques, de firmware, de pièces de rechange et de personnes disposant de droits d'accès. Les rapports de China Unicom montrent une base d'armoires énorme au niveau du groupe, mais le risque client est local: quelles baies contiennent cette charge de travail, quels domaines d'alimentation alimentent ces baies, et à quelle vitesse une personne qualifiée peut-elle agir en cas de panne matérielle?

La capacité installée n'est pas la même que la capacité utilisable. La capacité installée est ce qui existe avant une panne: espace en baie, adresses routables, transport optique, nœuds de calcul et baies de stockage. La capacité utilisable est ce qui reste après un événement électrique, une panne de routeur, un changement amont, une restriction de refroidissement, un pool de disques défaillant, une fenêtre de maintenance ou une isolation de sécurité. La capacité récupérable est ce que le fournisseur peut restaurer avant l'échéance commerciale du client. Le BGP public peut montrer un préfixe; il ne peut montrer aucun de ces trois chiffres.

Pour CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch, les preuves publiques pointent vers un environnement d'opérateur national plutôt qu'un hébergeur boutique isolé. Cela aide avec la profondeur du fournisseur. Mais cela rend également la frontière de responsabilité plus complexe. Si un client entre par un contrat de filiale, utilise une plateforme nationale Unicom Cloud, reçoit des adresses publiques d'un pool et dépend d'un centre de données régional, le propriétaire de la réparation peut changer par couche. La filiale peut gérer le compte. Un centre d'opérations national peut gérer la route.

Une équipe d'installation peut gérer l'électricité. Une équipe de plateforme cloud peut gérer le stockage. Une équipe de terrain peut gérer le remplacement matériel.

Cette division n'est pas un défaut si elle est visible. Elle devient un chemin d'échec lorsque le client n'a qu'un seul contact d'assistance et aucune preuve du fonctionnement de l'arbre d'escalade. La question utile n'est pas de savoir si China Unicom possède de nombreuses armoires. C'est de savoir si le service de ce client peut survivre à la perte de la baie, de la route, du pool de stockage ou de la file d'attente d'exploitation spécifique dont il dépend.

La diversité de transit doit être prouvée sous l'origine actuelle

La diversité de transit ne peut pas être déduite d'un AS de filiale dormant. RIPEstat n'a montré aucun voisin actuel pour AS63659, ce qui signifie que AS63659 n'expose pas de carte de voisin public actuelle dans ces données. Le chemin de préfixe actif pointe vers AS138421, donc les tests de transit et d'accessibilité devraient se concentrer sur la bordure AS138421 qui transporte 103.68.128.0/22. Le client devrait demander la politique d'origine actuelle, l'arrangement amont et de peering, les contrôles de filtrage de route, l'état d'autorisation d'origine de route et le chemin de basculement testé.

L'état d'origine de la route n'est pas idéal en tant qu'assurance autonome. Lavérification de validation RPKIde RIPEstat retournait le statut inconnu pour AS138421 et 103.68.128.0/22, sans ROA de validation dans cette requête. Inconnu n'est pas invalide, et cela ne signifie pas que la route est détournée. Cela signifie que le signal RPKI public n'a pas fourni de preuve d'autorisation d'origine positive pour cette origine et ce préfixe au moment de la vérification. Pour les clients qui dépendent d'un filtrage strict des routes par les amonts ou les pairs, un statut d'origine inconnu est un point à clarifier.

L'hygiène de routage n'est qu'une partie de la résilience. LeRFC 6811explique la validation d'origine de route; leRFC 7454décrit les pratiques opérationnelles pour BGP;MANRSencadre les attentes de sécurité de routage pour les opérateurs réseau. Ces documents sont utiles car ils définissent les questions, pas parce qu'ils certifient un opérateur particulier. Un fournisseur peut suivre de bonnes pratiques de filtrage de route et avoir quand même une coupure de fibre locale, un chemin de sauvegarde congestionné ou une escalade de support lente.

Le client devrait demander une démonstration de panne de chemin. Si le chemin de l'opérateur principal est perdu, quelle route reste-t-il? Si un segment du dorsal China Unicom est congestionné, où le trafic client est-il redirigé? Si le filtrage RPKI change en amont, quelle preuve garantit que le préfixe sera toujours accepté? Si le client utilise une connectivité privée, le chemin privé partage-t-il une installation, un routeur ou un domaine d'alimentation avec le chemin Internet public? La diversité est un résultat de test, pas un diagramme de topologie.

La main-d'œuvre de support fait partie de l'infrastructure

Le support n'est pas un service logiciel superposé à l'infrastructure. C'est le mécanisme par lequel l'infrastructure devient réparable. Un service hébergé peut avoir une route valide et une marque parente forte, mais encore échouer opérationnellement si le client ne peut pas joindre la bonne équipe, si l'équipe de support ne peut pas voir la couche pertinente, ou si une escalade nécessite un propriétaire de compte séparé qui n'est pas disponible pendant l'incident.

La structure de filiale rend cela particulièrement important. CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch peut être le contrat ou l'étiquette de compte visible, tandis que la restauration technique peut relever des équipes de plateforme Unicom Cloud, des équipes dorsales China Unicom, d'un groupe d'exploitation de centre de données et d'une équipe régionale de service client. Le client doit savoir quelle équipe possède chaque symptôme.

Un retrait de route publique, une perte de paquets, une défaillance de console, un échec d'instantané de stockage, un verrouillage d'identité, une suspension de facturation et un retard d'exportation peuvent tous nécessiter des propriétaires différents.

La meilleure preuve de support n'est pas une ligne SLA générique. C'est un chemin d'incident échantillon. Qui reçoit le premier ticket? Qu'est-ce qui qualifie pour une escalade téléphonique? Comment le fournisseur identifie-t-il si l'incident est spécifique à la filiale, au routage AS138421, au plan de contrôle cloud, au stockage, à l'alimentation, au filtrage de sécurité ou à la configuration client? La page de statut peut-elle fonctionner si la console de gestion principale est en panne?

Existe-t-il un chemin direct vers l'équipe qui peut changer les routes ou restaurer le stockage, ou chaque demande doit-elle passer par le support de compte?

Les clients devraient également tester la langue et la localité. Un contact de la filiale de Shanghai peut être précieux pour le support en langue chinoise, les heures d'ouverture locales et les conversations de conformité nationale. Mais si l'équipe d'urgence travaille au niveau national, le client doit savoir comment la transmission se produit. La promesse de support pertinente n'est pas « nous avons du support ». C'est « la chaîne de support peut atteindre le propriétaire physique ou du plan de contrôle assez rapidement pour protéger la charge de travail. »

La facturation, la suspension et l'état du compte sont des chemins d'échec

Les pannes cloud ne sont pas toujours mécaniques. La facturation, l'identité et l'état du compte peuvent arrêter la capacité hébergée aussi sûrement qu'une fibre endommagée. Un client peut perdre l'accès parce qu'une facture est contestée, qu'un chemin de paiement échoue, qu'un administrateur part, qu'un domaine expire, qu'un examen de sécurité verrouille le compte, ou qu'un processus de résiliation supprime les ressources avant que l'exportation des données ne soit terminée. Ces risques sont faciles à manquer lorsque la conversation est uniquement cadrée autour des baies et des routes.

Les preuves publiques ne divulguent pas le système de facturation de la filiale ni les contrôles de compte. Cela signifie que l'acheteur devrait demander directement. Quelle entité légale facture le service? La filiale de Shanghai est-elle le contact contractuel, le contact de support, ou les deux? Que se passe-t-il en cas de décalage entre le nom du compte, la documentation liée à l'ICP, la documentation de l'examen de sécurité et le locataire technique? Une suspension pour non-paiement peut-elle affecter les sauvegardes ou les exportations de données?

Combien de temps le client a-t-il pour rétablir l'état du compte avant que les ressources ne soient supprimées?

Ces questions ne sont pas hostiles. Elles rendent le service plus utilisable. Un fournisseur hébergé qui peut expliquer les règles de suspension, la récupération administrative, le transfert de propriété du compte et l'exportation d'urgence est plus sûr pour les clients que celui qui traite ces contrôles comme de la paperasse de bureau. Dans l'infrastructure, l'état administratif est l'état opérationnel. Une console verrouillée pendant un incident réseau ou de stockage peut transformer un échec gérable en une crise de migration.

Le client devrait demander deux chemins écrits: un chemin d'opérations d'urgence et un chemin commercial d'urgence. Le chemin d'opérations indique qui peut restaurer ou déplacer le service. Le chemin commercial indique qui peut empêcher qu'un état de facturation ou de compte bloque cette restauration. Les deux chemins devraient être testés avant que la dépendance de production ne se développe autour du service.

La localité des données n'est pas résolue par une adresse chinoise

Les signaux de la filiale en Chine et à Shanghai sont pertinents pour la localité des données, mais ils ne la résolvent pas. L'adresse APNIC et la description de la filiale montrent un enregistrement de ressource numérique lié à la Chine. Les rapports de China Unicom montrent une échelle nationale de cloud et de centres de données. Les sources réglementaires chinoises, y compris lesdispositions de la CAC de 2024 sur les flux transfrontaliers de données, lesmesures d'évaluation de sécurité des exportations de données de la CAC, et la publication officielle en anglais de laloi sur la protection des informations personnelles, montrent pourquoi le placement, l'accès et les chemins d'exportation importent. Mais aucune de ces sources ne dit à un client spécifique où se trouveront ses données, ses sauvegardes, ses journaux ou ses enregistrements de support.

Pour une charge de travail hébergée en Chine, le client devrait séparer la résidence des données, l'accès opérationnel et le chemin réseau. La résidence des données demande où les copies primaires et de sauvegarde sont stockées. L'accès opérationnel demande quelles équipes et fournisseurs peuvent atteindre le système, depuis quelles juridictions et sous quels contrôles. Le chemin réseau demande comment le trafic atteint le service et si la route publique, la ligne privée ou l'interconnexion cloud expose l'application à des dépendances que le client n'avait pas l'intention d'accepter.

Le préfixe lié à la filiale 103.68.128.0/22 étant actuellement originaire d'AS138421 ne répond pas à ces questions. Un préfixe peut être enregistré à un contact de filiale à Shanghai et toujours routé via un dorsal national. Un plan de contrôle peut être national tandis que certains systèmes opérationnels sont centralisés. Une sauvegarde peut être dans une autre province pour la résilience. Une plateforme de journaux peut être séparée de la production. La localité est une déclaration de conception et de contrat, pas une déduction d'un code pays.

Le client devrait exiger un calendrier de localité qui couvre la production, la sauvegarde, les journaux, la télémétrie, les tickets clients, les enregistrements de facturation, l'accès au support et l'exportation de données. Le calendrier devrait indiquer quand les données peuvent être déplacées, si le consentement du client est requis, comment la réplication inter-régions fonctionne, et comment un client peut prouver la suppression ou l'exportation après la résiliation. Sans cette preuve, l'étiquette « filiale de Shanghai » reste utile mais incomplète.

La migration est le dernier test honnête de résilience

Le test final de la capacité hébergée est de savoir si le client peut partir sans perdre l'activité. Cela est vrai pour un petit hébergeur et pour un cloud d'opérateur national. Un service qui fonctionne bien en fonctionnement normal peut encore être une mauvaise dépendance si le client ne peut pas exporter les données, reconstruire la configuration, déplacer le DNS, récupérer les adresses, récupérer les journaux ou transférer les preuves de support lorsque la relation avec le fournisseur change.

Pour cette filiale, les preuves publiques soulèvent une question de migration spécifique: qu'arrive-t-il aux charges de travail liées à une ressource de filiale qui est actuellement routée via un AS China Unicom plus large? Si le client reçoit des IP publiques de 103.68.128.0/22, ces adresses peuvent-elles être déplacées avec la charge de travail? Habituellement, les adresses attribuées par le fournisseur ne se déplacent pas en dehors du fournisseur, donc le client a besoin d'un plan pour les changements de DNS, de certificat, de liste blanche, d'API partenaire et de politique de sécurité.

Si le service utilise des adresses privées ou des liaisons privées, le client a besoin d'une preuve de basculement équivalente.

L'exportation de données nécessite la même précision. Le client peut-il exporter toutes les données sans services professionnels? L'exportation inclut-elle les métadonnées, les paramètres d'identité, les règles de sécurité, les journaux, les instantanés et les versions d'objets? Les exportations peuvent-elles être exécutées pendant que le service est dégradé? Combien de temps les exportations sont-elles conservées après la résiliation? La bande passante d'exportation est-elle plafonnée? Qui approuve une exportation d'urgence si l'administrateur de compte habituel n'est pas disponible?

Le meilleur test de migration est petit mais complet. Déplacez une charge de travail représentative hors du service, restaurez-la ailleurs, validez l'intégrité des données, mettez à jour les contrôles d'accès, préservez les journaux d'audit et mesurez le temps écoulé. Si le fournisseur ne peut pas soutenir cet exercice avant une crise, il est peu probable que ce soit plus facile pendant une crise. La portabilité n'est pas une annexe contractuelle. C'est le chemin d'évacuation pratique du client.

Qui ressent la panne

Le client direct de CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch peut être un locataire entreprise, une charge de travail du secteur public, un opérateur d'application, un revendeur, un intégrateur de systèmes, une entreprise locale ou une autre équipe réseau. L'utilisateur final peut ne jamais connaître le nom de la filiale. Il peut seulement remarquer qu'une application est lente, qu'une console est inaccessible, qu'une base de données ne peut pas être restaurée, qu'un portail de paiement est indisponible, ou qu'une liste blanche partenaire ne correspond plus à l'adresse du service.

La panne peut se propager à travers plusieurs couches. Une panne de route peut supprimer l'accessibilité publique. Un défaut de stockage peut corrompre ou retarder la récupération des données. Un défaut du plan de contrôle cloud peut empêcher la mise à l'échelle, la création d'instantanés ou les modifications de pare-feu. Un défaut d'escalade de support peut allonger l'incident même lorsque la réparation technique est connue. Un verrouillage de facturation peut bloquer l'exportation. Un décalage de localité peut créer des problèmes juridiques ou de communication client après la restauration du service technique.

Les preuves ici soutiennent une posture opérationnelle prudente. Elles ne soutiennent pas la panique. China Unicom est un opérateur majeur avec un vaste parc de cloud et de centres de données. Le préfixe associé à l'enregistrement de la filiale est visible sous une origine China Unicom actuelle. Ce sont des points positifs significatifs. La faiblesse n'est pas l'absence de plateforme parente; c'est l'absence de détails publics au niveau de la filiale sur le placement actuel des clients, le basculement multi-sites, l'autorisation de route, l'autorité de support et la portabilité des données.

Les clients devraient donc traiter la filiale comme une dépendance à documenter, pas comme un nom à accepter ou rejeter isolément. Le bon résultat est une carte de service plus précise: contrepartie légale, rôle de la filiale, AS actif, pools d'adresses, emplacements des installations, emplacements de sauvegarde, propriétaires de support, contrôles de route, statut RPKI, chemin de sortie et résultats de récupération testés. Une fois ceux-ci visibles, le client peut décider si la capacité hébergée vaut la dépendance.

Comment tester le service avant de s'y fier

Le premier test est la cartographie de l'identité et des adresses. Demandez au fournisseur de préciser si AS63659 est utilisé pour un service orienté client actuel. Demandez si 103.68.128.0/22 est attribué au produit, et si oui, s'il est originaire d'AS138421 en fonctionnement normal. Comparez la réponse avec le RDAP d'APNIC pourAS63659, le RDAP d'APNIC pour103.68.128.0/22, lestatut de routage AS63659 de RIPEstatet lestatut de routage 103.68.128.0/22 de RIPEstat. Tout décalage peut être inoffensif, mais il devrait être expliqué avant la production.

Le deuxième test est le placement. Demandez le site de production, le site de récupération, l'emplacement de sauvegarde, l'emplacement du plan de contrôle et l'emplacement du support. Si la localité de Shanghai fait partie de l'achat, demandez quelle partie du service est réellement à Shanghai et si Shanghai Lingang ou un autre site est impliqué. Le fournisseur n'a pas besoin de divulguer des plans d'étage sensibles pour répondre à la question opérationnelle. Il peut indiquer la région, le type d'installation, la conception de redondance, le domaine d'alimentation et le processus de changement impactant le client à un niveau approprié.

Le troisième test est la route et la récupération. Surveillez le préfixe depuis plusieurs points de vue, observez l'origine AS, vérifiez le statut RPKI, testez la connectivité privée si utilisée, et demandez un exercice de basculement de route. Testez ensuite la récupération de la charge de travail: restaurez à partir d'une sauvegarde, déplacez le trafic, confirmez les journaux, reconstruisez les contrôles d'accès et mesurez le temps. L'exercice devrait inclure à la fois un scénario de maintenance planifiée et un scénario de panne non planifiée.

Le quatrième test est la sortie. Effectuez une exportation complète, déplacez une petite charge de travail ailleurs et confirmez que le client peut fonctionner sans assistance cachée du fournisseur. Incluez le DNS, les changements d'adresse IP, les certificats, les listes blanches partenaires, les preuves de conformité et les journaux conservés. Un fournisseur qui peut réussir ce test n'est pas affaibli par celui-ci. Cela démontre que le client achète un service plutôt que de la captivité.

Ce qui améliorerait les preuves

Les preuves deviendraient matériellement plus solides si le fournisseur publiait ou partageait une carte de service actuelle pour les ressources liées à la filiale. Le document le plus utile relierait le nom de la filiale, l'entité contractante, AS63659, 103.68.128.0/22, AS138421, la région de production, la région de récupération, le propriétaire du support et le produit client en un seul endroit. Il n'aurait pas besoin d'exposer des coordonnées de baie sensibles ou des contrôles de sécurité. Il aurait besoin de dire quels faits publics sont toujours pertinents opérationnellement et lesquels ne sont qu'historiques.

Une deuxième amélioration serait une preuve opérationnelle en direct. Cela pourrait inclure des échantillons récents de surveillance de route pour le pool d'adresses client, un plan RPKI actuel ou une explication de l'état d'origine inconnu, des avis de maintenance qui nomment la couche affectée, et un exercice de basculement montrant ce qui se produit lorsque le chemin, le site ou le canal de support normal est supprimé. La confiance interne d'un fournisseur est utile, mais un client a besoin de preuves qu'il peut conserver et interpréter pendant un incident.

Une troisième amélioration serait une preuve de portabilité. Le fournisseur pourrait montrer une exportation complète, un processus documenté de retour des données, des contacts de récupération de compte, des garanties de suspension et une preuve de suppression après la résiliation. Ces éléments ne rendraient pas la table de route publique plus impressionnante. Ils rendraient le service hébergé moins fragile. Pour cette filiale, c'est le problème central: non pas si China Unicom a une échelle d'infrastructure, mais si cette dépendance orientée client est suffisamment cartographiée, récupérable et mobile pour être digne de confiance.

Niveau de preuve

Le niveau de preuve est Faible. Ce niveau n'est pas une déclaration que l'entreprise est faible, et ce n'est pas une déclaration que China Unicom manque d'échelle de cloud ou de centres de données. C'est une déclaration sur ce que les preuves publiques peuvent soutenir pour cette dépendance d'infrastructure exacte liée à la filiale.

Les preuves positives sont concrètes. APNIC et RIPEstat lient AS63659 et 103.68.128.0/22 à CU-CDC-SH et CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch. Le bloc IPv4 lié à la filiale est actif dans les données du registre. RIPEstat montre 103.68.128.0/22 actuellement annoncé par AS138421, China Unicom, avec une visibilité RIS complète au moment de la requête.

Les rapports officiels de China Unicom établissent un vaste parc national de cloud, de centres de données et de calcul intelligent, y compris les revenus déclarés des centres de données, l'échelle des armoires, les campus AIDC, les références de calcul intelligent à Shanghai et les revenus de Unicom Cloud.

Les preuves limitantes sont tout aussi importantes. AS63659 lui-même n'était pas actuellement annoncé dans RIPEstat, n'avait pas de préfixes courants dans la vue announced-prefixes et n'avait pas de voisins observés. La route active pour le /22 lié à la filiale utilisait AS138421, pas AS63659. La vérification RPKI pour 103.68.128.0/22 et AS138421 retournait inconnu.

Les enregistrements publics examinés ici n'ont pas publié de pages de produits clients au niveau de la filiale, de contrats d'installation, de nombre de baies, de redondance d'alimentation, d'escalade de support, d'objectifs de récupération testés, de placement de données clients ou de conditions d'exportation.

Cette faiblesse devrait façonner la vérification de l'acheteur plutôt que de mettre fin à l'évaluation. La première frontière est juridique: quelle entité China Unicom signe, facture et peut approuver une action d'urgence. La deuxième est technique: quel AS, préfixe, région cloud, plateforme de stockage et plan de contrôle transportent la charge de travail aujourd'hui. La troisième est opérationnelle: quelle équipe peut changer les routes, restaurer le stockage, entrer sur un site, outrepasser un verrouillage de console ou autoriser l'exportation lorsque le chemin de compte normal n'est pas disponible.

La quatrième est contractuelle: ce qui arrive aux données, journaux, adresses, certificats, enregistrements de support et statut de facturation lorsque le client part ou lorsqu'un service est suspendu. Une grande plateforme nationale peut répondre à ces questions; le dossier public ne les répond tout simplement pas pour cette dépendance au niveau de la filiale.

La conclusion est étroite: CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch est une identité réelle de ressource numérique liée à une filiale dans un très grand contexte de cloud et de centre de données China Unicom, mais les preuves publiques ne prouvent pas la surface de capacité hébergée actuelle spécifique à la filiale. Un client devrait procéder en vérifiant l'AS en direct, le pool d'adresses, le placement des installations, les contrôles de route, le propriétaire du support, l'exercice de récupération et le chemin de sortie avant de traiter le service comme résilient.