CHINANET SHAANXI province Cloud Base network vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• O RDAP da APNIC listaAS134768comoCHINANET-SHAANXI-CLOUD-BASE, com o nome descritivo CHINANET SHAANXI province Cloud Base network, país CN, registro em 2015 e um contato hostmaster da Chinanet.
• A visibilidade atual da rota é forte. Avisão geral do ASdo RIPEstat relata AS134768 como anunciada, enquanto ostatus de roteamentodo RIPEstat mostra 86 prefixos IPv4, 39 prefixos IPv6 e 11 vizinhos observados na janela pública verificada.
• A topologia ainda é dependente da matriz. Osdados whoisderivados da APNIC listam importações de AS4134 e AS4809, mas as visualizações públicas atuais de vizinhos do RIPEstat,bgp.tools, apágina BGPda Hurricane Electric e oIPinfotodos fazem de AS4134, China Telecom Backbone, o upstream visível.
• A evidência de endereços públicos é mista de uma forma que importa para a capacidade hospedada. Muitos prefixos originados são recursos da Shaanxi Chinanet, mas as visualizações BGP públicas também mostram espaço roteado descrito como IDC e serviço de nuvem, linha dedicada, Baidu, Zhejiang, Guangdong e blocos de endereços Sichuan Xiaoteyun, então um cliente não pode inferir a propriedade da carga de trabalho ou a localização do rack apenas pelo número do AS.
• Os sinais de instalações públicas apontam para uma base real de computação em nuvem em Xi'an/Xixian. Um relatório de visita de 2025 da Northwest University descreve a China Telecom Cloud Computing Shaanxi Base como um grande centro de nuvem e big data no oeste da China com mais de 10.000 racks, salas com padrão T4, PUE tão baixo quanto 1,25, opções de rack de alta densidade e um papel nas operações de nuvem do governo provincial.
• A nota da evidência é Média, não Forte. A rede está visivelmente ativa e é grande, mas as fontes públicas não publicam um mapa atual e específico do produto de propriedade de rack, alimentação de energia, failover de upstream, testes de restauração, limites de portabilidade de dados ou escalonamento de suporte para clientes que compram capacidade hospedada através desta rede de base de nuvem.

Uma tabela de rotas ao vivo é apenas a primeira prova

Um provedor de capacidade hospedada pode parecer confiável de duas maneiras bem diferentes. Uma prova é a tabela de rotas: as rotas são visíveis, os prefixos são autorizados, os pacotes têm um caminho e o AS aparece sob uma operadora conhecida. A outra prova é operacional: os racks têm energia, o sistema de refrigeração tem folga, os hipervisores têm capacidade ociosa, a cópia de backup é restaurável, a central de suporte pode contatar o engenheiro certo e o cliente pode mover os dados para fora quando o relacionamento termina. A rede CHINANET SHAANXI province Cloud Base tem uma primeira prova forte e uma segunda prova pública mais fraca.

A identidade oficial é direta. O RDAP da APNIC paraAS134768nomeia o AS comoCHINANET-SHAANXI-CLOUD-BASEe o descreve como CHINANET SHAANXI province Cloud Base network. O registro o localiza na China, mostra o registro em 27 de outubro de 2015 e lista contatos hostmaster da Chinanet. Avisualização whoisdo RIPEstat repete o mesmo nome e descrição do AS e adiciona linhas de política de rota importando de AS4134 e AS4809 e exportando AS134768 para essas redes. Isso é suficiente para tratar a rede como um sujeito de roteamento real da China Telecom Shaanxi, e não um slogan vago de nuvem.

O estado atual da rota também é material. Ostatus de roteamentodo RIPEstat mostrou AS134768 visível para quase todos os peers RIS em IPv4 e IPv6 na janela verificada de julho de 2026. Contou 86 prefixos IPv4, 39 prefixos IPv6, 184.576 endereços IPv4 e 12.576 equivalentes /48 IPv6. Avisualização de prefixos anunciadosdo RIPEstat listou 125 entradas de prefixos atuais em IPv4 e IPv6. Apágina BGPda Hurricane Electric relatou uma escala semelhante, com 184.576 endereços IPv4 originados e nenhuma rota RPKI inválida originada em sua visualização atual. Esses não são sinais de um ASN dormente.

Mas uma tabela de rotas não mostra todo o serviço. Não diz se uma máquina virtual está rodando em um salão de propriedade da China Telecom, um rack de propriedade do cliente dentro do salão, um gabinete operado por parceiro, uma região da Tianyi Cloud, um pool de nuvem governamental, um ambiente de linha dedicada ou um arranjo de colocation de terceiros. Não revela se o espaço anunciado está conectado a servidores de produção, gateways de borda, roteadores de clientes, nós de hospedagem, plataformas de conteúdo ou links de negócios privados.

Não diz ao comprador quanto tempo um servidor com falha leva para ser substituído ou se uma fila de suporte sobrecarregada pode atrasar uma migração.

Essa diferença é a dependência central do artigo. O AS134768 vende a impressão de capacidade de nuvem em rede, e a evidência BGP pública apoia a existência de uma borda grande e ativa da China Telecom Shaanxi. O comprador ainda precisa testar a camada física e contratual por trás dessa borda.

Em hospedagem, a interrupção mais danosa geralmente não é "a internet desapareceu." É a falha menor e mais difícil: um rack perde uma alimentação e a alimentação restante já está carregada, uma mudança de upstream expõe um vazamento de rota, um pool de armazenamento tem backups, mas não tem caminho de restauração rápido, uma retenção de cobrança bloqueia a exportação durante uma migração ou uma janela de manutenção é tratada como fora da promessa de disponibilidade.

O que o roteamento público prova

O roteamento público prova que AS134768 é visível e importante o suficiente para ser monitorado. Avisão geral do ASdo RIPEstat identifica o titular como CHINANET-SHAANXI-CLOUD-BASE, com o mesmo nome descritivo usado pela APNIC. O status de roteamento atual do RIPEstat mostra ampla visibilidade IPv4 e IPv6, não uma rota marginal vista por alguns coletores. A mesma página de status relata atividade vista pela primeira vez em janeiro de 2017 e um último item visto em 12 de julho de 2026. O histórico de rota, portanto, apoia a continuidade: a internet pública vê este ASN há anos, e ele não foi meramente registrado e abandonado.

Agregadores de terceiros se alinham com essa imagem. Obgp.toolsclassifica a rede como ativa sob a APNIC, rotula o tipo de rede como conteúdo, mostra a China Telecom Backbone como upstream e relata 75 prefixos IPv4 e 39 IPv6 originados em sua visualização visível. Apágina AS134768da Hurricane Electric relata 127 prefixos originados no total, 88 IPv4 e 39 IPv6, mais 11 peers BGP observados. OIPinfodescreve o ASN como orientado a hospedagem, lista a China como país, mostra dezenas de milhares de domínios hospedados em endereços no ASN e nomeia AS4134 como upstream em seu resumo visível.

Há diferenças nos contadores porque os coletores BGP públicos usam diferentes pontos de observação, escolhas de filtragem e horários de atualização. O RIPEstat contou 86 prefixos IPv4 na visualização de status de roteamento, enquanto o bgp.tools mostrou 75 prefixos IPv4 originados e a Hurricane Electric mostrou 88. Essa variação não deve ser superinterpretada como uma contradição. O sinal comum é mais importante do que o número exato: AS134768 tem uma grande superfície roteada, um forte caminho de matriz China Telecom e uma grande mistura de recursos IPv4 e IPv6.

A evidência de origem de rota também parece melhor do que muitas redes de hospedagem pequenas. A validação de origem de rota do RIPEstat para blocos IPv4 representativos de Shaanxi como36.41.64.0/20,113.142.128.0/17e117.34.124.0/23retornou status válido para AS134768 nos resultados verificados. O mesmo é verdadeiro para amostras de blocos de nuvem e rede IPv6 como240e:982:4500::/40e240e:108:1140::/48. ROAs válidos não garantem qualidade de serviço, mas reduzem uma classe de risco de origem de rota.

A conclusão operacional, portanto, não é "rede fraca." É "roteamento público forte, evidência de cliente incompleta." Um cliente pode razoavelmente acreditar que AS134768 está ativa. Não deve, apenas com base nisso, acreditar que sua carga de trabalho hospedada tem proteção multi-site, dois caminhos de energia independentes, recuperação de backup testada ou portabilidade de dados fácil. O BGP responde à pergunta de alcançabilidade. A capacidade hospedada exige várias outras respostas.

A história do upstream é mais restrita do que a política de registro sugere

O registro whois derivado da APNIC do AS134768 nomeia duas importações: AS4134 e AS4809. AS4134 é a China Telecom Backbone. AS4809 é a rede CN2 da China Telecom, frequentemente associada a caminhos de backbone premium. Se ambos os caminhos estivessem carregando ativamente e independentemente as cargas de trabalho dos clientes, isso seria uma diversidade útil. As visualizações de rota públicas não provam essa leitura mais forte.

Avisualização de vizinhos ASNdo RIPEstat mostrou 11 vizinhos observados na janela verificada. O vizinho do lado esquerdo era AS4134 com alta visibilidade em IPv4 e IPv6. Os vizinhos do lado direito eram um conjunto de redes de cidades 5G da China Telecom em Shaanxi, incluindo AS138387 para Xi'an, AS138409 para Tongchuan, AS138436 para Baoji, AS138513 para Weinan, AS138514 para Xianyang e outros visíveis principalmente em IPv6. O resumo do IPinfo também contou um upstream,AS4134. O bgp.tools similarmente apresentou AS4134 como upstream. A Hurricane Electric mostrou AS4134 como o peer IPv4 e também o peer IPv6 nomeado na tabela visível.

A lacuna não é fatal. Uma grande operadora pode manter registros de política de rota que refletem engenharia interna, caminhos planejados ou interconexão privada que os coletores públicos não expõem totalmente. AS4809 ainda pode ser importante para alguns serviços, mesmo que AS4134 seja o upstream público visível nas visualizações amostradas. Mas um cliente que compra capacidade hospedada não deve tratar a linha AS4809 no whois como prova de um caminho de failover ativo e que afeta o cliente.

O teste é evidência atual e específica do produto: qual upstream transporta este serviço, o que falha para o quê, como a política de rota é filtrada, como o RPKI é aplicado e se o caminho de backup tem capacidade comprometida suficiente durante o pico de carga.

Isso é especialmente importante porque todos os caminhos visíveis estão dentro da família mais ampla da China Telecom. A resiliência da rede matriz pode ser excelente, mas não é a mesma coisa que independência comercial ou física. Uma verdadeira reivindicação de diversidade separaria pelo menos quatro camadas: diversidade de caminho BGP, diversidade de operadora ou backbone, diversidade de caminho físico e capacidade ociosa após failover.

Se ambas as rotas dependem da mesma vala de fibra metropolitana, do mesmo switch central da base de nuvem, da mesma entrada de edifício ou do mesmo plano de controle da China Telecom, a segunda linha AS pode não proteger o cliente da falha que lhe importa.

A linguagem de aquisição correta não é hostil. Um comprador pode perguntar: "Para o serviço que estamos adquirindo, quais são o AS de origem, ASNs upstream, prefixos, zonas de disponibilidade e salas de dados físicas no escopo? Qual caminho é primário? Qual caminho é testado? Qual caminho está meramente disponível para a operadora em outro lugar na rede?" Essa distinção impede que uma forte rede da China Telecom seja supervalorizada como resiliência total multi-provedor.

A mistura de prefixos mostra superfícies de hospedagem, acesso e parceiros juntas

A lista de prefixos públicos é ampla o suficiente para sugerir mais de uma superfície de negócios. Muitos prefixos visíveis são espaço de rede direto da Shaanxi Chinanet. O RDAP da APNIC para36.41.64.0/20resolve para uma alocação maior CHINANET-SN, e o rótulo de contato administrativo localiza o departamento de comunicação de dados em Xi'an. O RDAP da APNIC para113.142.128.0/17similarmente resolve para uma alocação CHINANET-SN. Esses blocos apoiam o caso de que AS134768 transporta recursos de endereço da China Telecom Shaanxi, embora algumas descrições legadas usem a grafia "Shanxi(SN)" de maneiras que podem confundir Shaanxi com Shanxi. O contexto de contato de Xi'an é a âncora prática.

Outros recursos roteados tornam o limite operacional mais complicado. O bgp.tools lista vários blocos no estilo 103.236.0.0/22 com descrições para Sichuan Xiaoteyun Technology. O RDAP da APNIC para103.236.88.0/22identifica XIAOTEYUN como o nome do recurso registrado e um contato em Chengdu, Sichuan, enquanto avisão geral do prefixodo RIPEstat mostra AS134768 como a origem atual na visualização de rota verificada. O bgp.tools também mostra alguns prefixos descritos como Baidu e não descritos como Shaanxi Chinanet na página AS134768. A presença desses recursos não é evidência de irregularidade. É evidência de que AS de origem, cliente, titular do recurso e localização da instalação podem divergir.

Essa divergência é normal em grandes redes. Uma operadora pode originar espaço PI do cliente, espaço protegido contra DDoS, endereços de nuvem, redes de linha dedicada, blocos de entrega de conteúdo, segmentos de nuvem governamental ou alocações de parceiros. O risco para o cliente é que apenas o nome do AS não pode dizer ao comprador qual arranjo operacional se aplica. Um VPS rodando na infraestrutura de nuvem da China Telecom não é o mesmo que um roteador de cliente cujo prefixo é originado por AS134768, e nenhum dos dois é o mesmo que um site hospedado em um endereço IP contado pelos dados de domínios hospedados do IPinfo.

OIPinfoilustra por que isso importa. Ele relata mais de 23.000 domínios hospedados em endereços no ASN e destaca 103.236.90.151 como um endereço com milhares de domínios. Isso é um sinal de mercado útil: o ASN parece hospedar tráfego web denso em domínios. Não pode provar o proprietário contratual desses sites, a localização dos racks, a política de backup ou se o endereço pertence a um revendedor, uma plataforma de hospedagem compartilhada, uma camada CDN ou um ambiente gerenciado pelo cliente.

Para os clientes, o mapa de endereços deve fazer parte da integração. Qual prefixo será atribuído ao serviço? É espaço da China Telecom Shaanxi, espaço do cliente, espaço de parceiro ou espaço compartilhado da Tianyi Cloud? Quem controla o DNS reverso, o tratamento de abusos, a criação de ROA, a política de firewall e o null-routing de emergência? Se o serviço for migrado, o IP se move com a carga de trabalho ou o cliente recebe novos endereços? Essas perguntas transformam uma grande tabela de rotas em um mapa de dependência real.

O rótulo de base de nuvem aponta para capacidade física

Os sinais de instalações públicas tornam o nome "Cloud Base" mais do que decorativo. Um relatório de visita de 2025 da Northwest University School of Economics and Management descreve aChina Telecom Cloud Computing Shaanxi Basecomo tendo iniciado a construção em 2013 e entrado em operação formal em 2015. O mesmo relatório a descreve como um grande centro de computação em nuvem e big data no oeste da China, com salas de computadores padrão T4, PUE tão baixo quanto 1,25, mais de 10.000 racks, opções de gabinete de 5 kW, 8 kW, 12 kW e de maior potência com refrigeração líquida, uma reivindicação de exibição de largura de banda de exportação de 22T e um papel como um dos nós centrais de backbone IDC da China Telecom. Também diz que os alunos viram refrigeração, distribuição de energia, capacidades de segurança e a arquitetura de nuvem do governo provincial.

Isso é mais forte do que uma página de produto vaga porque descreve atributos físicos: racks, densidade de energia, design de refrigeração, proteção contra incêndio, largura de banda e um papel no campus. Também se alinha historicamente com um relatório de 2015 do Data Center Dynamics sobre abase de computação em nuvem de Xi'anda China Telecom, que descreveu a abertura de uma base de nuvem na região oeste e observou a estratégia mais ampla de nós de nuvem regionais da China Telecom. Páginas secundárias e de parceiros, incluindo adescrição do nó da Fenghuoyune umartigo do Shaanxi Phoenixde 2018 sobre serviços de nuvem de empreendedorismo Tianyi, também localizam a base de nuvem de Shaanxi na Fengxi New City da Xixian New Area e discutem capacidade no estilo IDC, nuvem e colocation.

Essas descrições de instalações públicas ajudam, mas ainda devem ser lidas como contexto de nível de instalação, e não como prova específica do cliente. A página da Northwest University é um relatório de visita ao local, não um contrato de serviço. As páginas da Fenghuoyun e do Phoenix são descrições de parceiros ou estilo mídia, não auditorias neutras. A capacidade projetada não é a mesma que a capacidade utilizável.

Uma contagem de racks não é uma declaração sobre disponibilidade de racks vazios, folga de energia, switches sobressalentes, inventário de hardware, janelas de migração de clientes ou a divisão atual entre nuvem, cargas de trabalho governamentais, acesso à internet, linha dedicada e serviços de parceiros.

A conclusão mais útil é especificidade física com uma ressalva. Os clientes devem assumir que há um campus significativo de nuvem e IDC da China Telecom associado à história da base de nuvem de Shaanxi. Eles não devem assumir que qualquer serviço roteado através do AS134768 está fisicamente em um salão nomeado, apoiado por todo o campus ou protegido por todos os recursos de redundância descritos em um tour público. Uma base de nuvem pode hospedar vários ambientes logicamente separados. Alguns podem ter recuperação de desastres em dois sites. Alguns podem ser de zona única. Alguns podem ser racks de parceiros.

Alguns podem ser zonas de nuvem pública. Alguns podem ser colocation de clientes.

O comprador deve, portanto, solicitar a declaração de colocação real: campus, edifício, classe de sala, mapeamento de rack ou zona de disponibilidade, design de alimentação de energia, classe de refrigeração, caminho de cross-connect, escopo da política de manutenção e se o serviço está em uma plataforma compartilhada ou em um rack dedicado. A resposta importa mais do que a escala total da base.

Capacidade instalada não é capacidade utilizável

O material público da base de nuvem enfatiza a escala, e a escala é útil. Um campus com milhares de racks, opções de gabinete de alta densidade e um grande relacionamento de backbone da China Telecom pode absorver mais demanda do que um provedor hospedado em um pequeno escritório. Também tem mais camadas onde o serviço do cliente pode depender das escolhas de alocação interna da operadora.

Capacidade instalada é o que foi construído ou pode ser mostrado em um plano público. Capacidade utilizável é o que a carga de trabalho do cliente pode consumir sem violar restrições de energia, refrigeração, armazenamento, rede ou suporte. Capacidade recuperável é o que permanece disponível após uma falha. Uma contagem de racks diz pouco sobre a segunda e terceira categorias. Se toda a capacidade de alta densidade sobressalente estiver reservada para cargas de trabalho de nuvem do governo, um servidor hospedado comercial pode não se beneficiar.

Se o pool de armazenamento de backup for grande, mas a largura de banda de restauração for estreita, um cliente pode ter um backup sem um caminho de recuperação. Se a base de nuvem tem 22T de largura de banda de exportação exibida, mas o nível de produto do cliente é limitado por taxa ou single-homed dentro de um segmento de serviço, a largura de banda principal não define o modo de falha do cliente.

A documentação pública da própria Tianyi Cloud reforça essa visão em camadas. Apágina inicial da Tianyi Cloudapresenta a marca em torno de integração nuvem-rede, segurança, personalização dedicada e múltiplas formas de nuvem, incluindo serviços de nuvem pública, privada, dedicada, híbrida, de borda e full-stack. Sua documentação ECS pararegiões e zonas de disponibilidadeexplica uma zona de disponibilidade como um ou mais data centers físicos dentro de uma região, com energia e rede independentes, e diz que o objetivo é o isolamento de falhas, exceto para grandes desastres ou falhas de energia importantes. Essa é uma declaração de arquitetura sensata. Também significa que o cliente precisa saber se a carga de trabalho adquirida realmente abrange zonas ou se está simplesmente em um pool de recursos local.

O mesmo vale para capacidade bare-metal, VPS, colocation e serviços gerenciados. Um cliente que compra um gabinete quer energia sobressalente, mãos remotas, tempo de espera para cross-connect, hardware de substituição e janelas de manutenção. Um cliente que compra máquinas virtuais quer tamanho do cluster de hipervisor, replicação de armazenamento, isolamento de snapshot, exportação de imagem e colocação em domínio de falha. Um cliente que compra nuvem do setor público quer conformidade com políticas, localização de backup, controles de identidade e recuperação de desastres testada.

O AS134768 pode transportar tráfego para todas essas superfícies, mas cada uma tem uma definição diferente de capacidade utilizável.

O teste prático é solicitar uma declaração de capacidade sob falha. Quanto de computação, armazenamento, largura de banda e suporte permanece se um rack, host, switch, prateleira de armazenamento, alimentação de energia ou rota upstream falhar? O pool restante pode transportar a carga normal do cliente ou apenas manter clientes prioritários online? O cliente precisa comprar uma segunda zona de disponibilidade ou um produto separado de recuperação de desastres para receber essa proteção? Sem essa resposta, "base de nuvem" permanece um rótulo de instalação, não uma garantia de resiliência.

Energia, refrigeração e janelas de reparo decidem a interrupção

As páginas de data centers frequentemente apresentam energia e refrigeração como orgulho da engenharia. Os clientes devem lê-las como determinantes de interrupção. O relatório de visita da Northwest University diz que a base de Shaanxi tem salas padrão T4, baixo PUE, opções de rack de alta densidade e capacidades avançadas de refrigeração e segurança. A página da Fenghuoyun descreve sistemas de energia de backup, serviços estilo colocation, comutação central e reivindicações de certificação de segurança.

Um artigo do Shaanxi Phoenix de 2018 diz que a base tinha grande capacidade planejada de racks e promovia níveis de serviço de continuidade de rede e energia. Esses são sinais públicos positivos, mas não substituem os termos de serviço específicos do cliente.

A redundância de energia tem várias camadas. As alimentações da concessionária podem ser diversas, mas o painel de distribuição ainda pode ser comum. Os sistemas UPS podem ser redundantes, mas a duração da bateria pode ser curta. Os geradores podem estar disponíveis, mas a logística de combustível, a confiabilidade de partida do gerador e o estado de manutenção decidem a resistência real. Os PDUs de rack podem ter alimentações A e B, mas um cliente pode acidentalmente conectar ambos os suprimentos em um lado.

Um rack refrigerado a líquido de alta densidade pode ser poderoso, mas adiciona dependências de refrigerante e suporte de instalação que não existem para servidores comuns de baixa densidade.

A redundância de refrigeração também tem camadas. Um PUE baixo é valioso, mas não é uma métrica de tempo de atividade. Diz algo sobre eficiência e design. Não diz se uma determinada fileira tem folga de refrigeração suficiente após a falha de um chiller, bomba ou unidade de tratamento de ar. Não diz se gabinetes refrigerados a líquido de alta densidade podem continuar operando durante a manutenção. Não diz ao cliente se um evento temporário de redução de capacidade forçará a movimentação das cargas de trabalho.

As janelas de reparo são onde o cliente vê a verdade. Uma falha de rack pode exigir mãos remotas. Uma falha de servidor pode exigir peças de reposição. Uma falha de roteamento pode precisar de um engenheiro autorizado a alterar o BGP. Uma falha de armazenamento pode exigir escalonamento do fornecedor. Uma falha de hipervisor pode exigir espaço de evacuação. Uma falha de backup pode exigir que alguém tome uma decisão de restauração enquanto o serviço principal está fora do ar. O tamanho da China Telecom não elimina essas etapas; dá à operadora mais recursos para gerenciá-las se o processo estiver preparado.

O cliente deve solicitar o caminho do incidente em termos claros. Quem abre o ticket interno? Quem pode entrar na sala? Quais peças estão estocadas no local? Quais alterações exigem uma janela de manutenção? Como os clientes são notificados se a manutenção planejada afetar uma borda de nuvem, alimentação de energia, plano de armazenamento ou rota IP? O SLA exclui manutenção programada? Quais serviços são creditados e quais são meramente suportados no melhor esforço? Esses detalhes são menos glamorosos do que uma contagem de racks, mas determinam se uma falha se torna um evento curto ou uma longa migração.

Os sinais de domínios hospedados precisam de manuseio cuidadoso

As contagens de domínios hospedados do IPinfo fazem o AS134768 parecer uma rede de hospedagem, e isso é evidência de mercado útil. Ele relata mais de 23.000 domínios hospedados no ASN, com concentrações em um pequeno conjunto de IPs. O bgp.tools também rotula o tipo de rede como conteúdo. O portfólio de produtos públicos da Tianyi Cloud inclui hosts de nuvem elástica, hosts de nuvem de aplicativos, serviços de máquina física, armazenamento, backup, recuperação de desastres e outras ofertas de infraestrutura.

Juntos, esses sinais apoiam a premissa central: a rede de base de nuvem faz parte de uma superfície de capacidade hospedada voltada para o cliente.

Eles não provam o serviço exato por trás de qualquer domínio hospedado. Um domínio pode apontar para hospedagem compartilhada, uma plataforma de revendedor, um firewall de aplicativo, um proxy reverso, equipamento do cliente em colocation, um servidor legado, um aplicativo governamental interno ou um cliente empresarial usando serviço de IP estático. A concentração de endereços IP não é o mesmo que a concentração de contas de nuvem.

Um grande número de domínios em 103.236.90.151, por exemplo, pode indicar hospedagem compartilhada ou um endereço de plataforma, mas o RDAP da APNIC para a alocação subjacente 103.236.88.0/22 identifica XIAOTEYUN como o nome do recurso registrado. Isso torna a cadeia operacional mais complicada do que "China Telecom Shaanxi é dona de todos os sites no IP."

Essa distinção importa durante uma falha. Se um cliente está em um IP de hospedagem compartilhada, um evento de abuso por outro inquilino pode afetar a reputação, a entregabilidade de e-mail ou a filtragem. Se um cliente está em espaço de endereço de parceiro roteado, os contatos de origem de rota e abuso podem não mapear perfeitamente para o contrato. Se um cliente está em uma nuvem privada virtual com um IP elástico, a migração pode exigir alterações de DNS e cutover de endpoint.

Se um cliente está em colocation com um roteador de sua propriedade, o provedor pode ser responsável por energia e cross-connects, mas não pelo sistema operacional ou aplicativo do cliente.

O artigo, portanto, trata as contagens de domínios hospedados como um sinal de mercado não oficial, não como uma prova final de capacidade. Elas sugerem que o AS134768 é usado para tráfego web e de infraestrutura voltado para o cliente. Elas não podem estabelecer quem é o dono dos servidores, se as cargas de trabalho são copiadas, se a locação é isolada, se existe um caminho de restauração testado ou se o cliente pode exportar uma imagem de VM, um dump de banco de dados, um arquivo de caixa de correio ou uma conta completa estilo cPanel durante o estresse.

A evidência conclusiva seria a documentação do produto vinculada ao serviço real: alocação de endereços, design de isolamento de inquilinos, escopo de backup e snapshot, formatos de exportação, tratamento de abusos, controles de DDoS, controle de DNS reverso, política de reputação de e-mail e suporte à migração. Sem esses detalhes, a escala de domínios hospedados é uma razão para fazer perguntas melhores, não uma razão para relaxar.

A localização dos dados é um ponto de venda e uma restrição

O campo de região para este perfil é CN, e a evidência pública apoia uma superfície operacional baseada na China. A APNIC lista o AS na China. Os relatórios da base de nuvem de Shaanxi situam o campus físico na área de Xi'an/Xixian. As páginas de produtos e documentos de serviço da Tianyi Cloud são voltados para a China. Essa presença local pode ser valiosa para cargas de trabalho do setor público chinês, regulamentadas e sensíveis à latência. Também pode limitar como um cliente projeta backups, acesso de suporte e caminhos de saída.

O ambiente jurídico da China torna a colocação de dados mais do que uma preferência de aquisição. A tradução da Lei de Cibersegurança hospedada pelaDigiChinadescreve um requisito de localização para informações pessoais e dados importantes coletados ou produzidos por operadores de infraestrutura de informação crítica na China continental. ALei de Segurança de Dadosestabelece uma estrutura nacional de segurança de dados. A Lei de Proteção de Informações Pessoais, resumida peloPCPDde Hong Kong e traduzida por fontes comoChina Law Translate, adiciona obrigações de processamento de informações pessoais e transferência transfronteiriça. Os deveres exatos dependem do cliente, tipo de dados e arranjo de serviço, mas a direção é clara: localização, regras de acesso e transferência importam.

Para clientes do AS134768, a localidade tem três dimensões práticas. A primeira é a localidade de produção: onde os endpoints de computação, armazenamento e rede realmente estão. A segunda é a localidade de backup: onde snapshots, arquivos, réplicas de recuperação de desastres e logs são armazenados. A terceira é a localidade administrativa: quem pode acessar os sistemas, de onde, sob qual entidade legal e processo de suporte. Um serviço pode ser hospedado localmente, mas usar gerenciamento remoto, ferramentas de segurança externas ou backup entre regiões.

Um serviço pode anunciar uma base de nuvem de Shaanxi, mas fornecer recuperação de desastres em outra província. Isso pode ser boa arquitetura, mas deve ser explícito.

A localização dos dados também afeta a migração. Se um cliente precisar sair, ele pode exportar dados para outro provedor baseado na China, outra região da China Telecom, um sistema local ou uma plataforma no exterior? Existem limites legais, técnicos ou contratuais para transferir logs, informações pessoais, dados governamentais, chaves de criptografia ou backups? O provedor suporta exportação em massa sem limitação de velocidade? Por quanto tempo após o término o cliente mantém o acesso? O que acontece se a conta for suspensa por cobrança enquanto o cliente ainda precisa de recuperação de dados?

A leitura mais segura é que a infraestrutura local da China é um recurso quando as necessidades de conformidade e latência do cliente correspondem à plataforma, e uma restrição quando o cliente precisa de redundância transfronteiriça ou saída rápida. A tabela de rotas do AS134768 não pode responder a essas perguntas. Apenas os termos de serviço e o arranjo de processamento de dados podem.

O contrato de serviço decide o que a nuvem não cobre

Os clientes de nuvem frequentemente confundem a linguagem de disponibilidade com responsabilidade operacional total. Oíndice de SLAda Tianyi Cloud lista acordos de nível de serviço para produtos de computação, armazenamento, backup e recuperação de desastres. Suapágina de SLA ECSdireciona os usuários para os termos de nível de serviço do host de nuvem elástica. Os documentos de produto da Tianyi Cloud também distinguem zonas de disponibilidade, tipos de instância, serviços de GPU, discos de nuvem, produtos de backup e produtos de recuperação de desastres. Essa estrutura diz aos clientes algo importante: a resiliência é montada a partir de serviços específicos, não herdada automaticamente da marca matriz.

Na prática, um comprador deve esperar exclusões. A maioria dos SLAs de nuvem exclui manutenção programada, falhas de configuração do lado do cliente, problemas de conta e pagamento, eventos de força maior e falhas fora do limite de serviço definido pelo provedor. Alguns produtos têm créditos em vez de garantias de restauração. Algumas instâncias de alto desempenho ou especializadas podem seguir um SLA diferente. Alguns produtos de recuperação de desastres protegem apenas os dados ou a configuração selecionados pelo cliente. Nada disso é incomum. É por isso que ler o contrato específico do serviço é importante.

Para o AS134768, o limite do contrato deve ser testado contra os principais caminhos de falha. Se a rota upstream falhar, isso é coberto pela disponibilidade de rede ou excluído como manutenção de backbone? Se um rack perder energia, o cliente recebe crédito de serviço, suporte de restauração ou ambos? Se uma VM gerenciada pelo cliente for mal configurada após o failover, onde termina a responsabilidade do provedor? Se uma ação de mitigação de DDoS fizer null-route de um IP do cliente, qual é o caminho de escalonamento?

Se uma carga de trabalho de nuvem governamental tiver controles de segurança diferentes da nuvem comercial, qual equipe de suporte atua?

O estado de cobrança e conta merece atenção. A capacidade hospedada pode falhar administrativamente. Uma fatura não paga, atraso na renovação do contrato, problema de verificação de nome real, problema de registro de domínio, reclamação de abuso ou incompatibilidade de identidade do cliente pode suspender o serviço ou bloquear a migração tão efetivamente quanto um roteador quebrado. Clientes que compram capacidade crítica devem perguntar se uma disputa de cobrança pode afetar a exportação de dados, por quanto tempo os dados são retidos após a suspensão e quem pode autorizar o acesso de emergência.

O melhor contrato de nuvem torna as dependências invisíveis visíveis. Ele declara o limite do serviço, a métrica de disponibilidade, o aviso de manutenção, a retenção de dados, a responsabilidade de backup, o método de exportação, a gravidade do suporte, o alvo de resposta e as obrigações do cliente. Se o AS134768 é a superfície de rota e a Tianyi Cloud ou uma unidade da China Telecom Shaanxi é o provedor de serviços, o cliente precisa tanto dos fatos de rota quanto dos fatos contratuais no mesmo arquivo.

Principais caminhos de falha a testar

O primeiro caminho de falha é falha de rack ou instalação. Isso inclui energia do rack, refrigeração da fileira, erros de PDU, switches de topo de rack, cross-connects, painéis de fibra, acesso físico e erros de manutenção. Os relatórios públicos da base de nuvem sugerem uma instalação substancial, mas a escala da instalação não elimina a falha local. Os clientes precisam saber se seu serviço é de rack único, sala única, edifício único, multi-zona ou dois sites.

O segundo caminho é falha de upstream ou backbone. As visualizações públicas atuais mostram AS4134 como o upstream visível. A política whois menciona AS4809, mas os coletores de rota não o tornam um caminho de failover comprovado para o cliente. Os clientes precisam do mapa de upstream ativo, do teste de failover, dos filtros de rota, do estado RPKI e do comportamento esperado se AS4134 tiver um problema regional ou nacional.

O terceiro caminho é falha de estoque de hardware. Uma plataforma hospedada pode identificar um servidor com falha rapidamente e ainda esperar por uma substituição. GPU de alta densidade, computação refrigerada a líquido ou especializada adiciona mais risco de inventário. Um cliente deve perguntar quais peças estão estocadas localmente, quais exigem envio do fornecedor e se a operadora pode migrar ao vivo ou restaurar para hardware diferente enquanto as peças estão em trânsito.

O quarto caminho é falha de suporte. A rede de base de nuvem está dentro de uma grande organização de operadora, o que pode ser uma força se o escalonamento for maduro. Também pode criar risco de transferência entre operações locais, operações de backbone, operações de nuvem, suporte ao cliente, cobrança, segurança e equipes de parceiros. O cliente deve saber qual mesa é responsável por cada tipo de incidente e qual nível de gravidade aciona o escalonamento 24 horas.

O quinto caminho é falha de backup e restauração. Backups que existem, mas são lentos, incompletos ou controlados pela conta errada, não resolvem uma interrupção. Os clientes devem exigir evidência de restauração, não apenas nomes de produtos de backup. Para uma VM, isso significa inicializar uma imagem restaurada. Para um banco de dados, isso significa consistência e evidência de ponto de recuperação. Para armazenamento de objetos, isso significa versionamento, proteção contra exclusão e separação de contas. Para colocation, pode significar que o provedor não faz backup dos dados do cliente.

O sexto caminho é falha de migração. Os clientes frequentemente deixam uma plataforma durante o estresse, quando um aplicativo está instável ou o negócio perdeu a confiança. Esse é o pior momento para descobrir que os endereços IP não podem se mover, as imagens não podem ser exportadas, os snapshots são proprietários, a largura de banda é limitada ou o suporte não ajudará até que as faturas sejam liquidadas. A migração deve ser ensaiada quando o serviço está saudável.

Esses testes não exigem desconfiança. São diligências comuns para qualquer provedor de capacidade hospedada cuja evidência de rede pública é mais forte do que sua evidência de limite de serviço público.

O que elevaria a nota da evidência

O AS134768 obtém uma nota de evidência de rede Média porque tem roteamento público forte, identidade APNIC oficial e contexto plausível de nuvem física. Para alcançar Forte, a evidência pública ou contratual precisaria conectar a tabela de rotas ao serviço do cliente mais diretamente.

A primeira melhoria seria uma declaração de topologia atual. Deve nomear o AS de origem ativo, ASNs upstream, prefixos de produto, região e mapeamento de zona de disponibilidade. Deve explicar se AS4809 está ativo para o serviço ou apenas aparece na política de rota. Deve identificar se as cargas de trabalho do cliente usam espaço da China Telecom Shaanxi, espaço compartilhado da Tianyi Cloud, espaço PI do cliente ou blocos de endereços de parceiros. Deve declarar quem mantém ROAs e quem responde a eventos de abuso ou vazamento de rota.

A segunda melhoria seria evidência de limite de instalação. Os clientes não precisam de uma planta baixa pública, mas precisam saber se sua carga de trabalho está na base de nuvem Xixian/Fengxi, outro data center de Shaanxi, um pool regional da Tianyi Cloud, um rack de parceiro ou um gabinete de propriedade do cliente. A declaração deve incluir classe de energia, suposições de densidade de rack, política de janela de manutenção, plano de peças sobressalentes e se o serviço é de zona única ou multi-zona.

A terceira melhoria seria evidência de recuperação. Um provedor forte pode mostrar exercícios de restauração, não apenas produtos de backup. Pode descrever restauração recente de VM, restauração de armazenamento, restauração de banco de dados, failover de rede e testes de exportação do cliente. Pode dizer quais falhas são cobertas por failover automatizado e quais exigem um ticket manual. Também pode declarar objetivos realistas de tempo de recuperação e ponto de recuperação por produto.

A quarta melhoria seria evidência de localização de dados e saída. O provedor deve descrever a localização de produção, localização de backup, localização de logs, acesso de subcontratados, controle de chave de criptografia, formatos de exportação, retenção após o término e restrições de transferência transfronteiriça. Para cargas de trabalho governamentais ou regulamentadas, deve distinguir a conformidade legal da conveniência comercial.

A quinta melhoria seria evidência de incidentes. Uma página de status, resumo de histórico de incidentes, calendário de manutenção, matriz de gravidade de suporte e modelo de relatório pós-incidente fariam a diferença entre uma grande tabela de rotas e um serviço confiável ao cliente. Grandes operadoras às vezes mantêm essas informações atrás de portais de clientes, o que é bom para clientes sob contrato. A ausência pública ainda significa que um leitor externo não deve presumi-la.

Se esses itens forem produzidos, a história muda de "grande superfície roteada ao vivo da China Telecom Shaanxi com um respaldo plausível de instalação de base de nuvem" para "plataforma de capacidade hospedada verificada com domínios de falha conhecidos e caminhos de recuperação." Essa é a diferença entre escala de rede e confiança na infraestrutura.

A conclusão: rotas fortes, resiliência condicional

A rede CHINANET SHAANXI province Cloud Base é um sujeito de infraestrutura ativo. APNIC, RIPEstat, bgp.tools, Hurricane Electric e IPinfo todos apoiam o mesmo fato central: AS134768 é uma rede de base de nuvem da China Telecom Shaanxi ao vivo com uma pegada substancial de IPv4 e IPv6. As verificações representativas de origem de rota são válidas. A visibilidade atual é alta. A rede não é uma casca dormente.

A cautela operacional é igualmente clara. O BGP público mostra alcançabilidade, não propriedade de rack. Os registros de endereço da APNIC mostram titulares de recursos e contatos, não cargas de trabalho do cliente. As contagens de domínios hospedados sugerem uso web e de hospedagem, não qualidade de backup. Relatórios de visita à base de nuvem e páginas de parceiros apontam para um data center e campus de nuvem reais na área de Xi'an, mas não dizem ao cliente qual produto é de zona única, qual é multi-zona, qual caminho usa AS4809, qual rack tem energia sobressalente ou qual equipe de suporte restaura um servidor com falha às 2 da manhã.

Para um comprador, a postura prática é confiança disciplinada. Trate a rede como ativa. Trate o contexto da base de nuvem da China Telecom Shaanxi como significativo. Em seguida, peça a evidência que realmente decide as interrupções: prefixo do produto, zona de disponibilidade, caminho upstream, propriedade de ROA, energia do rack, folga de refrigeração, hardware sobressalente, escopo de backup, prova de restauração, escalonamento de suporte, exclusões de manutenção, regras de continuidade de cobrança e termos de exportação de dados.

A capacidade hospedada não é sem peso. Em Shaanxi, como em outros lugares, são roteadores, fibras, salas de energia, circuitos de refrigeração, portas de switch, filas de suporte e contratos. O AS134768 torna essa capacidade visível para a internet. Não elimina a necessidade de verificar a cadeia física e operacional por baixo dela.