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 la 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 nom de réseau CU-CDC-SH et à une adresse de bâtiment de China Unicom au No. 1033 Changning Road, district de Changning, Shanghai.
• L’ASN de la branche n’est pas une preuve de routage public actuel. L’aperçu AS de RIPEstat pour l’AS63659 a montré annoncé: faux; la vue des préfixes annoncés n’a retourné aucun préfixe actuel; l’état de routage a montré 0 préfixe IPv4, 0 préfixe IPv6 et 0 voisin observé; l’historique de routage a placé l’origine visible de 103.68.128.0/22 pour l’AS63659 en 2017-2018, la dernière origine AS63659 vue en novembre 2018.
• Le bloc d’adresses compte encore parce que la vue de préfixe de RIPEstat pour 103.68.128.0/22 a montré le préfixe annoncé via l’AS138421, détenteur CU-CN-AS - China Unicom, avec 325 pairs RIS sur 325 le voyant au moment de la requête. Cela soutient un chemin routé actuel de China Unicom, pas une revendication de service client auto-exploité spécifique à la branche.
• Les rapports officiels de China Unicom montrent une activité cloud et centres de données importante: chiffre d’affaires des centres de données de 28,1 milliards de RMB en 2025, plus de 1,10 million de baies standard, sept campus AIDC de classe 100 MW, croissance du chiffre d’affaires d’Unicom Cloud, et un chiffre d’affaires d’Unicom Cloud de 37,6 milliards de RMB au premier semestre 2025. Ces chiffres établissent le contexte d’infrastructure à l’échelle de la maison mère, pas le placement exact des clients, le nombre de baies ou le chemin de restauration pour l’entité de la branche de Shanghai.
• Le niveau de preuve est Faible. Les archives publiques soutiennent une empreinte de ressources numériques réelle liée à la branche et un préfixe China Unicom actuellement routé, mais elles ne prouvent pas l’exploitation actuelle de l’AS63659, la capacité client au niveau de la branche, 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 l’enregistrement RDAP d’APNIC pourl’AS63659, le handle est AS63659, le nom est CU-CDC-SH, le pays est CN et le statut est actif. La vue whois de RIPEstat pourl’AS63659donne le même libellé 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 au « cloud » collée dans une page marketing.

Les preuves de routage sont plus restreintes. L’aperçu ASde RIPEstat a montré que l’AS63659 n’était pas annoncé au moment de la requête du 2026-07-11 à 16:00 UTC. La vue despréfixes annoncésa retourné une liste de préfixes actuels vide pour la fenêtre d’observation récente, et la vue del’état de routagea montré 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 branche transporte aujourd’hui un service hébergé actif.

Cela ne rend pas la branche inutile. L’enregistrement RDAP d’APNIC pour103.68.128.0/22identifie le nom de réseau CU-CDC-SH et donne la plage allant de 103.68.128.0 à 103.68.131.255, statut actif, pays CN. Les données whois de RIPEstat pour103.68.128.0/22répètent la description de la branche et l’adresse du bâtiment de 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 désormais visible via un AS différent. L’aperçu du préfixede RIPEstat a montré 103.68.128.0/22 annoncé par l’AS138421, détenteur CU-CN-AS - China Unicom. La vue del’état de routage pour le préfixea montré la route visible par les 325 pairs RIS IPv4 au moment de la requête, avec l’origine AS138421. Les preuves soutiennent donc un bloc d’adresses routé actuel de China Unicom associé à l’enregistrement de la branche. Elles ne soutiennent pas une simple phrase disant que l’AS63659 lui-même est actuellement la périphérie côté client.

Un AS de branche inactif modifie le test d’approvisionnement

Un AS inactif n’est pas automatiquement un service défaillant. Les grands opérateurs consolident souvent les routes clients dans un AS fédérateur plus large, retirent les petits ASN d’origine, modifient la politique de routage ou conservent les ressources numériques dans un compte régional ou produit tandis que le trafic transite par un réseau national. Mais un AS de branche inactif modifie le test. La question n’est plus « l’AS63659 annonce-t-il des préfixes clients? » La question devient « quel réseau, quelle installation et quel contrat China Unicom supportent actuellement la capacité hébergée que le nom de la branche semble représenter? »

L’historique de routage pour l’AS63659de RIPEstat a montré une visibilité historique pour 103.68.128.0/22 et des plus spécifiques associés sous l’origine AS63659, l’origine AS63659 visible se terminant fin 2018 pour l’agrégat. La vue actuelle du préfixe, en revanche, place 103.68.128.0/22 sous l’AS138421. Cet historique est utile car il évite deux erreurs courantes. La première erreur est de qualifier la branche de simple coquille vide parce que son propre AS n’est pas actuel. La seconde est de traiter une ancienne origine AS comme une preuve d’exploitation actuelle.

Le client doit imposer la distinction dans le contrat. Si un document commercial ou de support mentionne encore la branche, le client doit demander si sa charge de travail utilisera 103.68.128.0/22, un autre pool d’adresses de China Unicom Cloud, une interconnexion privée, un chemin d’échange cloud public ou un bloc attribué par le client. Si la réponse est « réseau dorsal China Unicom », le client a besoin que la périphérie de service AS138421, et non AS63659, soit incluse dans la surveillance et les preuves d’incident.

Si la réponse est « branche de Shanghai », le client doit savoir quelle installation et quelle équipe d’exploitation rendent cela réel.

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

Le chemin actuel semble être le réseau dorsal plus large de China Unicom

Les preuves de chemin actuelles reposent sur l’AS138421. L’aperçu AS pour l’AS138421de RIPEstat a identifié le détenteur comme CU-CN-AS - China Unicom et a montré l’AS comme annoncé. La vue despréfixes annoncés pour l’AS138421a retourné des centaines de préfixes IPv4 actuels dans la fenêtre récente. Pour 103.68.128.0/22 spécifiquement, lesdonnées de looking-glassde RIPEstat ont montré des chemins de collecteurs internationaux se terminant par l’AS138421 via des chemins amont qui incluent l’AS4837 dans de nombreuses observations. Cela est cohérent avec le fait que le bloc d’adresses est joignable en tant que partie d’un vaste système de routage de China Unicom.

La conséquence pratique est que la dépendance côté client de la branche peut être une relation commerciale et de support régionale dont les paquets empruntent un réseau dorsal national. Cela peut être une force. Un réseau dorsal d’opérateur national peut fournir une échelle, un levier de réparation, un transport optique, des opérations de sécurité et de multiples options régionales qu’un petit fournisseur d’hébergement indépendant ne peut égaler. Cela peut aussi masquer des détails locaux.

Un client peut connaître la marque de l’opérateur mais pas la salle de données, le rack, l’origine de la route, l’interconnexion locale, la dépendance électrique de la zone 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 usages 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 branche 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 surveillance du client doit inclure les deux identités. AS63659 est l’identité de ressource numérique liée à la branche. AS138421 est l’origine publique actuelle pour le préfixe lié à la branche. Un moniteur de route qui ne surveille que l’AS63659 manquera la route active si le service actuel reste sous l’AS138421. Un examen d’approvisionnement qui ne surveille que l’AS138421 peut manquer l’incertitude spécifique à la branche 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 mère. Lerapport annuel 2025indique que le chiffre d’affaires des centres de données a atteint 28,1 milliards de RMB, en hausse de 8,5 % en glissement annuel; les baies standard ont dépassé 1,10 million; sept campus AIDC de classe 100 MW ont été construits; le taux d’utilisation des baies 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 fibre optique dorsal « Huit verticales et huit horizontales » pour l’interconnexion des hubs de calcul. Le même rapport indique qu’Unicom Cloud a évolué vers le cloud IA et inclut les IDC cloud, les ressources cloud, la plateforme cloud, les services cloud, l’intégration cloud, l’interconnexion cloud et la sécurité cloud dans la définition du chiffre d’affaires d’Unicom Cloud.

Lerapport intermédiaire 2025ajoute une vue semestrielle: le chiffre d’affaires d’Unicom Cloud au premier semestre a atteint 37,6 milliards de RMB; le chiffre d’affaires IDC a atteint 14,4 milliards de RMB; l’utilisation des ressources IDC a dépassé 70 %; China Unicom a fourni des services de réseau intelligent à plus de 280 fournisseurs de services cloud et s’est connecté à plus de 400 centres de données; et l’entreprise a décrit des centres de calcul intelligent de 10 000 puces à Shanghai Lingang, Hohhot, Zhongwei et Sanjiangyuan. Lerapport annuel 2024a de même rapporté un chiffre d’affaires d’Unicom Cloud de 68,6 milliards de RMB, un chiffre d’affaires IDC de 25,9 milliards de 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 de la maison mère. Ils importent parce qu’ils montrent que le « cloud » dans ce cas n’est pas seulement une étiquette de revendeur attachée à un petit site web. Le groupe mère dépense et rend compte à l’échelle d’un opérateur. Pourtant, l’échelle de la maison mère ne détermine pas le placement de la branche. Les rapports ne disent pas que CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch a un nombre spécifique de baies disponibles pour les clients publics. Ils n’indiquent pas que 103.68.128.0/22 est un pool de serveurs clients.

Ils ne publient pas de temps de récupération pour ce nom de branche, et ils ne mappent pas la branche à un site nommé, une entrée opérateur, une région de sauvegarde ou un chemin de migration de charge de travail.

L’acheteur doit donc traiter les preuves d’échelle de la maison mère comme un contexte plutôt qu’une preuve. Un grand opérateur peut toujours vendre un produit local dont la réparation dépend d’un seul bâtiment, d’une seule file d’attente de téléassistance, d’un seul bureau de service, d’un seul propriétaire de changement réseau ou d’une seule procédure d’exportation de données. Inversement, une branche avec un AS inactif peut toujours ê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 des tests doivent faire ce travail.

L’adresse de Shanghai est un indice, pas une carte de salle de données

Les enregistrements publics liés à la branche pointent vers Shanghai. Les données RDAP d’APNIC et whois de RIPEstat listent le bâtiment China Unicom au No. 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 de localisation 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 commerciale adjacente à une installation.

Shanghai importe quand même. Les rapports officiels identifient Shanghai parmi les déploiements de calcul intelligent à grande échelle de China Unicom, et le rapport intermédiaire 2025 nomme spécifiquement Shanghai Lingang dans une liste de centres de calcul intelligent de 10 000 puces.

Si un client achète de la capacité hébergée en Chine parce que la localité de Shanghai, la portée réseau ou le contexte réglementaire importent, il doit 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 plusieurs régions.

La question n’est pas théorique. Un service étiqueté Shanghai peut avoir plusieurs couches physiques: une branche commerciale locale, un canal de support client à Shanghai, une allocation d’adresses enregistrée à un contact de Shanghai, une route de réseau dorsal national, un centre de données à Lingang ou dans 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 doit demander une matrice de placement. La matrice doit lister les emplacements de calcul de production, de stockage, de sauvegarde, de journaux, d’identité, d’enregistrements de facturation, de système de support client, de surveillance, d’administration à distance et d’exportation. Elle doit également indiquer lesquels de ces emplacements sont garantis, lesquels relèvent de la pratique normale d’exploitation, et lesquels peuvent changer sans l’accord du client. Sans cette matrice, l’étiquette de branche 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 de baies, d’alimentation, de refroidissement, de routeurs, de commutateurs, d’optiques, de câbles, de disques, de micrologiciels, de pièces de rechange et de personnes avec des droits d’accès. Les rapports de China Unicom montrent une base de baies énorme au niveau du groupe, mais le risque client est local: quels racks contiennent cette charge de travail, quels domaines d’alimentation alimentent ces racks, 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 rack, adresses routables, transport optique, nœuds de calcul et baies de stockage. La capacité utilisable est ce qui reste après un événement d’alimentation, une panne de routeur, un changement amont, une restriction de refroidissement, un pool de disques défaillant, une fenêtre de maintenance ou un isolement 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 en termes de profondeur de fournisseur. Mais cela rend aussi la limite de responsabilité plus compliquée. Si un client entre par un contrat de branche, utilise une plateforme Unicom Cloud nationale, reçoit des adresses publiques d’un pool et s’appuie sur un centre de données régional, le propriétaire de la réparation peut changer par couche. La branche peut gérer le compte. Un centre d’opérations national peut gérer la route.

Une équipe d’installation peut gérer l’alimentation. 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 de défaillance lorsque le client n’a qu’un seul contact de helpdesk 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 baies. C’est de savoir si le service de ce client peut survivre à la perte du rack, de la route, du pool de stockage ou de la file d’attente d’opérations 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 branche inactif. RIPEstat n’a montré aucun voisin actuel pour l’AS63659, ce qui signifie que l’AS63659 n’expose pas de carte de voisinage publique actuelle dans ces données. Le chemin de préfixe actif pointe vers l’AS138421, donc les tests de transit et de joignabilité doivent se concentrer sur la périphérie AS138421 qui transporte 103.68.128.0/22. Le client doit 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 route n’est pas idéal en tant qu’assurance autonome. Lavérification de validation RPKIde RIPEstat a retourné un statut inconnu pour l’AS138421 et 103.68.128.0/22, sans ROA validantes 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 positive d’autorisation d’origine 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 réel à clarifier.

L’hygiène de routage n’est qu’une partie de la résilience. LaRFC 6811explique la validation d’origine de route; laRFC 7454décrit les pratiques opérationnelles pour BGP;MANRSencadre les attentes de sécurité de routage pour les opérateurs de 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 malgré tout une coupure de fibre locale, un chemin de secours congestionné ou une escalade de support lente.

Le client doit demander une démonstration de défaillance de chemin. Si le chemin opérateur principal est perdu, quelle route reste? Si un segment du réseau dorsal de China Unicom est congestionné, où le trafic client bascule-t-il? Si le filtrage RPKI change en amont, quelle preuve prouve 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 accessoire 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 mère forte, et pourtant é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 distinct qui n’est pas disponible pendant l’incident.

La structure de branche rend cela particulièrement important. CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch peut être l’étiquette de contrat ou de compte visible, tandis que la restauration technique peut incomber aux équipes de plateforme Unicom Cloud, aux équipes de réseau dorsal de China Unicom, à un groupe d’exploitation de centre de données et à une équipe de service client régionale. Le client doit savoir quelle équipe est propriétaire 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 preuve de support la plus solide n’est pas une ligne SLA générique. C’est un exemple de chemin d’incident. Qui reçoit le premier ticket? Qu’est-ce qui donne droit à une escalade téléphonique? Comment le fournisseur identifie-t-il si l’incident est spécifique à la branche, au routage AS138421, à un 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 hors service?

Existe-t-il une route directe vers l’équipe qui peut modifier les routes ou restaurer le stockage, ou chaque demande doit-elle passer par le support de compte?

Les clients doivent également tester la langue et la localité. Un contact de la branche de Shanghai peut être précieux pour le support en chinois, les heures ouvrables locales et les conversations de conformité domestique. Mais si l’équipe d’urgence travaille au niveau national, le client doit savoir comment le transfert a lieu. 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 de défaillance

Les pannes cloud ne sont pas toujours mécaniques. La facturation, l’identité et l’état du compte peuvent arrêter une 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 des ressources avant que l’exportation de données ne soit terminée. Ces risques sont faciles à manquer lorsque la conversation est cadrée uniquement autour des baies et des routes.

Les preuves publiques ne divulguent pas le système de facturation ni les contrôles de compte de la branche. Cela signifie que l’acheteur doit demander directement. Quelle entité juridique facture le service? La branche de Shanghai est-elle le contact contractant, le contact de support ou les deux? Que se passe-t-il en cas d’inadéquation entre le nom du compte, la documentation liée à l’ICP, la documentation d’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 la situation 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é de compte et l’exportation d’urgence est plus sûr pour les clients qu’un fournisseur qui traite ces contrôles comme de la paperasserie 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 une défaillance gérable en une crise de migration.

Le client doit 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 un état de facturation ou de compte de bloquer cette restauration. Les deux chemins doivent être testés avant que la dépendance de production ne s’accroisse autour du service.

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

Les signaux de Chine et de Shanghai de la branche sont pertinents pour la localité des données, mais ils ne la résolvent pas. L’adresse APNIC et la description de la branche 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 de données transfrontaliers, 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ù ses données, ses sauvegardes, ses journaux ou ses enregistrements de support se trouveront.

Pour une charge de travail hébergée en Chine, le client doit 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 principales 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 fait que le préfixe lié à la branche 103.68.128.0/22 soit actuellement originé par l’AS138421 ne répond pas à ces questions. Un préfixe peut être enregistré à un contact de la branche de Shanghai et néanmoins transiter par un réseau dorsal national. Un plan de contrôle peut être domestique tandis que certains systèmes opérationnels sont centralisés. Une sauvegarde peut se trouver dans une autre province pour des raisons de résilience. Une plateforme de journaux peut être distincte de la production. La localité est une déclaration de conception et de contrat, pas une déduction à partir d’un code pays.

Le client doit 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 de support et l’exportation de données. Le calendrier doit indiquer quand les données peuvent être déplacées, si le consentement du client est requis, comment la réplication inter-régionale fonctionne, et comment un client peut prouver la suppression ou l’exportation après résiliation. Sans cette preuve, l’étiquette « Branche 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 son activité. Cela est vrai pour un petit hébergeur comme pour un cloud d’opérateur national. Un service qui fonctionne bien en exploitation normale peut rester 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 branche, les preuves publiques soulèvent une question de migration spécifique: qu’advient-il des charges de travail liées à une ressource liée à la branche 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 se déplacer 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 certificats, de listes d’autorisation, d’API partenaires et de politiques de sécurité.

Si le service utilise des adresses privées ou des liens privés, le client a besoin de preuves de basculement équivalentes.

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 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, conservez 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 de contrat. C’est le chemin de sortie pratique du client.

Qui ressent la défaillance

Le client direct de CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch peut être un locataire d’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 branche. Il peut seulement remarquer qu’une application est lente, qu’une console est injoignable, qu’une base de données ne peut pas être restaurée, qu’un portail de paiement est indisponible, ou qu’une liste d’autorisation partenaire ne correspond plus à l’adresse du service.

La défaillance peut se propager à travers plusieurs couches. Une défaillance de route peut supprimer la joignabilité publique. Une panne de stockage peut corrompre ou retarder la récupération de données. Une panne de plan de contrôle cloud peut empêcher la mise à l’échelle, la prise d’instantanés ou les modifications de pare-feu. Une défaillance 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 avec le 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 patrimoine de cloud et de centres de données. Le préfixe associé à l’enregistrement de la branche est visible sous une origine China Unicom actuelle. Ce sont des points positifs significatifs. La faiblesse n’est pas l’absence d’une plateforme mère; c’est l’absence de détails publics au niveau de la branche sur le placement actuel des clients, le basculement multi-site, l’autorisation de route, l’autorité de support et la portabilité des données.

Les clients doivent donc traiter la branche comme une dépendance à documenter, pas comme un nom à accepter ou rejeter isolément. Le bon résultat est une carte de service plus nette: contrepartie juridique, rôle de la branche, AS actif, pools d’adresses, emplacements d’installation, 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 d’indiquer si l’AS63659 est utilisé pour un service actuel orienté client. Demandez si 103.68.128.0/22 est attribué au produit, et si oui, s’il est originé par l’AS138421 en exploitation normale. Comparez la réponse avec les données RDAP d’APNIC pourl’AS63659, les données RDAP d’APNIC pour103.68.128.0/22, le statut de routage de RIPEstat pourl’AS63659et le statut de routage de RIPEstat pour103.68.128.0/22. Toute discordance peut être inoffensive, mais elle doit être expliquée 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 ayant un impact sur 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, surveillez l’origine AS, vérifiez le statut RPKI, testez la connectivité privée si elle est utilisée, et demandez un exercice de basculement de route. Testez ensuite la récupération de 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 doit inclure à la fois un scénario de maintenance planifiée et un scénario de défaillance imprévue.

Le quatrième test est la sortie. Exécutez 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’adresses IP, les certificats, les listes d’autorisation partenaires, les preuves de conformité et les journaux conservés. Un fournisseur qui peut réussir ce test n’en est pas affaibli. Il démontre que le client achète un service plutôt qu’une 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 branche. Le document le plus utile relierait le nom de la branche, l’entité contractante, l’AS63659, 103.68.128.0/22, l’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 rack sensibles ou des contrôles de sécurité. Il devrait indiquer quels faits publics sont encore opérationnellement pertinents et lesquels sont seulement historiques.

Une deuxième amélioration serait des preuves opérationnelles 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 nommant la couche affectée, et un exercice de basculement montrant ce qui se passe 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 des preuves de portabilité. Le fournisseur pourrait montrer une exportation complète, un processus documenté de restitution des données, des contacts de récupération de compte, des sauvegardes contre la suspension et une preuve de suppression après résiliation. Ces éléments ne rendraient pas la table de routage publique plus impressionnante. Ils rendraient le service hébergé moins fragile. Pour cette branche, c’est le problème central: non pas si China Unicom a une échelle d’infrastructure, mais si cette dépendance côté client est cartographiée, récupérable et suffisamment mobile pour faire confiance.

Niveau de preuve

Le niveau de preuve est Faible. Cette évaluation n’est pas une déclaration selon laquelle l’entreprise est faible, ni une déclaration selon laquelle 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 orientée branche.

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

Les rapports officiels de China Unicom établissent un vaste patrimoine national de cloud, d’IDC et de calcul intelligent, y compris le chiffre d’affaires des centres de données rapporté, l’échelle de baies, les campus AIDC, les références de calcul intelligent de Shanghai et le chiffre d’affaires d’Unicom Cloud.

Les preuves limitantes sont tout aussi importantes. L’AS63659 lui-même n’était pas actuellement annoncé dans RIPEstat, n’avait pas de préfixes actuels dans la vue des préfixes annoncés et n’avait pas de voisins observés. La route active pour le /22 lié à la branche utilisait l’AS138421, et non l’AS63659. La vérification RPKI pour 103.68.128.0/22 et l’AS138421 a retourné inconnu.

Les archives publiques examinées ici n’ont pas publié de pages de produits clients au niveau de la branche, de contrats d’installation, de nombres de baies, de redondance d’alimentation, d’escalade de support, d’objectifs de récupération testés, de placement des 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 limite 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 modifier 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: qu’advient-il des données, des journaux, des adresses, des certificats, des enregistrements de support et de l’état de facturation lorsque le client part ou lorsqu’un service est suspendu. Une grande plateforme nationale peut répondre à ces questions; les archives publiques ne le font tout simplement pas pour cette dépendance au niveau de la branche.

La conclusion est étroite: CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch est une identité de ressource numérique réelle liée à une branche à l’intérieur d’un très grand contexte de cloud et de centres de données de China Unicom, mais les preuves publiques ne prouvent pas la surface actuelle de capacité hébergée spécifique à la branche. Un client doit procéder en vérifiant l’AS actif, le pool d’adresses, le placement d’installation, 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.