A rede CHINANET SHAANXI province Cloud Base vende capacidade hospedada que ainda depende de racks, trânsito e janelas de manutenção

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 Chinanet.
• A visibilidade de roteamento atual é forte. Avisão geral ASdo RIPEstat sinaliza AS134768 como anunciado, 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 do pai. Osdados whoisderivados da APNIC listam importações de AS4134 e AS4809, mas as visualizações públicas atuais dos vizinhos do RIPEstat,bgp.tools, apágina BGPda Hurricane Electric e oIPinfoindicam todas AS4134, o backbone da China Telecom, como upstream visível.
• As evidências de endereços públicos são mistas de uma forma que importa para a capacidade hospedada. Muitos prefixos de origem são recursos Chinanet de Shaanxi, mas as visualizações BGP públicas também mostram espaço roteado descrito como IDC e serviço de nuvem, linha alugada, Baidu, Zhejiang, Guangdong e blocos de endereços Sichuan Xiaoteyun, portanto, um cliente não pode deduzir a propriedade das cargas de trabalho ou a localização dos racks apenas pelo número AS.
• Os sinais públicos de instalações apontam para uma verdadeira base de computação em nuvem em Xi'an/Xixian. Um relatório de visita da Universidade do Noroeste de 2025 descreve a base de computação em nuvem Shaanxi da China Telecom como um grande centro de nuvem e big data do oeste da China com mais de 10.000 racks, salas de padrão T4, PUE tão baixo quanto 1,25, opções de racks de alta densidade e um papel nas operações de nuvem governamental provincial.
• O nível de evidência é Médio, não Alto. A rede está visivelmente viva e vasta, mas as fontes públicas não publicam um mapa atual e específico do produto da propriedade dos racks, fontes de alimentação, failover upstream, testes de restauração, limites de portabilidade de dados ou escalação de suporte para clientes comprando capacidade hospedada através desta rede cloud base.

Uma tabela de roteamento ao vivo é apenas a primeira evidência

Um provedor de capacidade hospedada pode parecer confiável de duas maneiras muito diferentes. Uma evidência é a tabela de roteamento: as rotas estão visíveis, os prefixos são permitidos, os pacotes têm um caminho, e o AS aparece sob um operador conhecido. A outra evidência é operacional: os racks têm eletricidade, o sistema de refrigeração tem margem, os hipervisores têm capacidade de reserva, a cópia de backup é restaurável, o suporte pode contatar o engenheiro certo, e o cliente pode mover os dados ao final do relacionamento.

A rede CHINANET SHAANXI province Cloud Base tem uma primeira evidência sólida e uma segunda evidência pública mais enxuta.

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

O estado de roteamento atual também é material. Ostatus de roteamentodo RIPEstat mostrava AS134768 visível para quase todos os pares RIS em IPv4 e IPv6 na janela verificada de julho de 2026. Ele contava 86 prefixos IPv4, 39 prefixos IPv6, 184.576 endereços IPv4 e 12.576 equivalentes /48 IPv6. Avisão de prefixos anunciadosdo RIPEstat listava 125 entradas de prefixos atuais em IPv4 e IPv6. Apágina BGPda Hurricane Electric reportava uma escala similar, com 184.576 endereços IPv4 de origem e nenhuma rota RPKI inválida originada em sua visão atual. Esses não são sinais de um ASN adormecido.

Mas uma tabela de roteamento não mostra todo o serviço. Ela não diz se uma máquina virtual está funcionando em uma sala pertencente à China Telecom, um rack pertencente ao cliente na sala, um armário operado por um parceiro, uma região Tianyi Cloud, um pool de nuvem governamental, um ambiente de linha alugada ou um acordo de colocation de terceiros. Ela não revela se o espaço anunciado está anexado a servidores de produção, gateways de borda, roteadores de clientes, nós de hospedagem, plataformas de conteúdo ou links privados corporativos.

Ela não diz ao comprador quanto tempo leva para substituir um servidor com falha ou se uma fila de suporte sobrecarregada pode atrasar uma migração.

Essa diferença é a dependência central do artigo. AS134768 vende a impressão de uma capacidade em nuvem em rede, e as evidências BGP públicas apoiam a existência de um grande edge ativo China Telecom Shaanxi. O comprador ainda precisa testar a camada física e contratual por trás desse edge. Na hospedagem, a falha mais prejudicial muitas vezes não é "a internet desapareceu".

É a falha menor e mais difícil: um rack perde uma fonte de alimentação e a alimentação restante já está carregada, uma mudança upstream expõe um vazamento de rota, um pool de armazenamento tem backups mas não um caminho de restauração rápido, um bloqueio de faturamento impede a exportação durante uma migração, ou uma janela de manutenção é tratada como externa à promessa de disponibilidade.

O que o roteamento público prova

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

Os agregadores de terceiros se alinham com essa imagem.bgp.toolsclassifica a rede como ativa sob a APNIC, rotula o tipo de rede como conteúdo, mostra o backbone China Telecom como upstream e reporta 75 prefixos IPv4 e 39 IPv6 de origem em sua visão visível. Apágina AS134768da Hurricane Electric reporta 127 prefixos de origem no total, 88 IPv4 e 39 IPv6, mais 11 pares BGP observados.IPinfodescreve 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 vista, escolhas de filtragem e tempos de atualização. RIPEstat contava 86 prefixos IPv4 na visão do status de roteamento, enquanto bgp.tools mostrava 75 prefixos IPv4 de origem e Hurricane Electric 88. Essa variação não deve ser superinterpretada como uma contradição. O sinal comum é mais importante que o número exato: AS134768 tem uma grande superfície roteada, um forte caminho pai China Telecom e uma ampla mistura de recursos IPv4 e IPv6.

A evidência de origem de rota também parece melhor que a de muitas pequenas redes de hospedagem. 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/23retornava um status válido para AS134768 nos resultados verificados. O mesmo vale para amostras de blocos de nuvem e rede IPv6 como240e:982:4500::/40e240e:108:1140::/48. ROAs válidas 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ências de cliente incompletas". Um cliente pode razoavelmente acreditar que AS134768 está ativo. Ele não deve, a partir disso apenas, acreditar que sua carga de trabalho hospedada tem proteção multissite, dois caminhos de alimentação independentes, recuperação de backup testada ou portabilidade de dados fácil. BGP responde à pergunta de acessibilidade. A capacidade hospedada requer várias outras respostas.

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

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

Avisão de vizinhos ASNdo RIPEstat mostrava 11 vizinhos observados na janela verificada. O vizinho esquerdo era AS4134 com alta visibilidade em IPv4 e IPv6. Os vizinhos direitos eram um conjunto de redes 5G China Telecom Shaanxi das cidades, 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 contava um upstream,AS4134. bgp.tools também apresentava AS4134 como o upstream. Hurricane Electric mostrava AS4134 como o par IPv4 e também o par IPv6 nomeado na tabela visível.

A lacuna não é fatal. Um grande operador pode manter registros de política de roteamento que refletem engenharia interna, caminhos planejados ou interconexão privada que os coletores públicos não expõem completamente. 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 comprando capacidade hospedada não deve tratar a linha AS4809 no whois como evidência de um caminho de failover vivo e que afeta o cliente.

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

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

Se ambas as rotas dependem da mesma vala de fibra metropolitana, do mesmo switch central do cloud base, da mesma entrada de prédio ou do mesmo plano de controle China Telecom, a segunda linha AS pode não proteger o cliente da falha que o preocupa.

A linguagem de aprovisionamento adequada não é hostil. Um comprador pode perguntar: "Para o serviço que estamos comprando, qual AS de origem, quais ASNs upstream, prefixos, zonas de disponibilidade e salas de dados físicas estão no escopo? Qual caminho é principal? Qual caminho é testado? Qual caminho está simplesmente disponível para o operador em outro lugar na rede?" Essa distinção impede que uma forte rede China Telecom seja vendida a mais como resiliência completa multioperadora.

A mistura de prefixos mostra hospedagem, acesso e superfícies parceiras juntos

A lista pública de prefixos é ampla o suficiente para sugerir mais de uma superfície comercial. Muitos prefixos visíveis são espaço de rede simples Chinanet Shaanxi. O RDAP da APNIC para36.41.64.0/20resolve em uma alocação mais ampla CHINANET-SN, e o rótulo de contato administrativo coloca o escritório de comunicação de dados em Xi'an. O RDAP da APNIC para113.142.128.0/17também resolve em uma alocação CHINANET-SN. Esses blocos apoiam o caso de que AS134768 transporta recursos de endereços China Telecom Shaanxi, mesmo que algumas descrições legadas usem a ortografia "Shanxi(SN)" de forma a confundir Shaanxi e Shanxi. O contexto do contato Xi'an é a âncora prática.

Outros recursos roteados tornam a fronteira operacional mais complicada. bgp.tools lista vários blocos de 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 de 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 roteamento verificada. bgp.tools também mostra prefixos descritos como Baidu e não-Shaanxi Chinanet sob a página AS134768. A presença desses recursos não é evidência de malfeito. É evidência de que o AS de origem, o cliente, o detentor do recurso e o posicionamento das instalações podem divergir.

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

IPinfoilustra por que isso importa. Ele reporta 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. Este é um sinal de mercado útil: o ASN parece hospedar tráfego web denso em domínios. Isso 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 de 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 China Telecom Shaanxi, espaço do cliente, espaço de parceiro ou espaço compartilhado Tianyi Cloud? Quem controla o DNS reverso, o tratamento de abuso, 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 roteamento em um mapa de dependência real.

O rótulo cloud base aponta para capacidade física

Os sinais públicos de instalações tornam o nome "Cloud Base" mais que decorativo. Um relatório de visita de 2025 da Escola de Economia e Gestão da Universidade do Noroeste descreve abase de computação em nuvem Shaanxi da China Telecomcomo tendo começado sua construção em 2013 e entrado em operação oficial em 2015. O mesmo relatório a descreve como um grande centro de computação em nuvem e big data do oeste da China, com salas de computador de padrão T4, PUE tão baixo quanto 1,25, mais de 10.000 racks, opções de armários de 5 kW, 8 kW, 12 kW e mais refrigerados a líquido, uma reivindicação de exibição de largura de banda de exportação de 22T e um papel como um dos nós backbone IDC centrais da China Telecom. Indica também que os estudantes viram a refrigeração, distribuição de energia, capacidades de segurança e arquitetura de nuvem governamental provincial.

Isso é mais forte que uma página de produto vaga porque descreve atributos físicos: racks, densidade de potência, design de refrigeração, proteção contra incêndio, largura de banda e um papel de campus. Também corresponde historicamente a um relatório de 2015 da Data Center Dynamics sobre abase de computação em nuvem de Xi'an da China Telecom, que descrevia a abertura de uma base cloud na região oeste e notava a estratégia mais ampla de nós de nuvem regionais da China Telecom. Páginas secundárias e de parceiros, incluindo adescrição de nó da Fenghuoyune umartigo da Phoenix Shaanxi de 2018sobre serviços cloud Tianyi entrepreneurship, também localizam a base cloud de Shaanxi na nova zona de Xixian, cidade nova de Fengxi, e discutem capacidade IDC, cloud e colocation.

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

Um número de racks não é uma declaração sobre disponibilidade de racks vazios, margem de energia, switches de reserva, inventário de hardware, janelas de migração de cliente ou distribuição atual entre cloud, cargas de trabalho governamentais, acesso à internet, linhas alugadas e serviços parceiros.

A conclusão mais útil é a especificidade física com uma ressalva. Os clientes devem supor que existe um campus significativo de cloud e IDC China Telecom associado à história do cloud base de Shaanxi. Eles não devem supor que todo serviço roteado via AS134768 está fisicamente em uma sala nomeada, apoiado por todo o campus, ou protegido por cada funcionalidade de redundância descrita em uma visita pública. Uma base cloud pode hospedar vários ambientes logicamente separados. Alguns podem ter recuperação de desastre em dois locais. 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 cliente.

O comprador deve, portanto, perguntar pela declaração de posicionamento real: campus, prédio, classe de sala, rack ou mapa de zona de disponibilidade, design de energia, classe de refrigeração, caminho de cross-connect, escopo de política de manutenção e se o serviço está em uma plataforma compartilhada ou rack dedicado. A resposta importa mais que a escala total da base.

Capacidade instalada não é capacidade utilizável

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

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. Um número de racks não diz muito sobre a segunda e terceira categorias. Se toda a capacidade de alta densidade de reserva está reservada para cargas de trabalho de nuvem governamental, um servidor hospedado comercial pode não se beneficiar.

Se o pool de armazenamento de backup é grande mas a largura de banda de restauração é estreita, um cliente pode ter backup sem caminho de recuperação. Se a base cloud tem 22T de largura de banda de exportação exibida mas o nível de produto do cliente é limitado em throughput ou mono-hospedado em um segmento de serviço, a largura de banda principal não define o modo de falha do cliente.

A documentação pública do Tianyi Cloud reforça essa visão em camadas. Apágina inicial do Tianyi Cloudapresenta a marca em torno da integração cloud-rede, segurança, personalização dedicada e múltiplas formas de nuvem, incluindo serviços cloud públicos, privados, dedicados, híbridos, edge e full-stack. Sua documentação ECS pararegiões e zonas de disponibilidadeexplica que uma zona de disponibilidade é um ou mais centros de dados físicos em uma região, com alimentação e rede independentes, e diz que o objetivo é o isolamento de falhas, exceto para grandes desastres ou quedas de energia importantes. Essa é uma declaração de arquitetura sensata. Também significa que o cliente deve saber se a carga de trabalho comprada cobre realmente múltiplas zonas, ou se está apenas em um pool de recursos local.

O mesmo vale para capacidade bare-metal, VPS, colocation e serviços gerenciados. Um cliente comprando um armário quer energia de reserva, mãos remotas, prazo de cross-connect, hardware de substituição e janelas de manutenção. Um cliente comprando máquinas virtuais quer o tamanho do cluster de hipervisores, replicação de armazenamento, isolamento de snapshots, exportação de imagens e posicionamento de domínios de falha. Um cliente comprando nuvem para o setor público quer conformidade política, localização do backup, controles de identidade e recuperação de desastre testada.

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 é perguntar por uma declaração de capacidade em caso de falha. Quanto de computação, armazenamento, largura de banda e suporte resta se um rack, host, switch, prateleira de armazenamento, fonte de alimentação ou rota upstream falhar? O pool restante pode suportar a carga normal do cliente, ou apenas manter os clientes prioritários online? O cliente precisa comprar uma segunda zona de disponibilidade ou um produto separado de recuperação de desastre para receber essa proteção? Sem essa resposta, "cloud base" permanece um rótulo de instalação, não uma garantia de resiliência.

A energia, a refrigeração e as janelas de reparo decidem a falha

As páginas de centros de dados frequentemente apresentam energia e refrigeração como orgulho técnico. Os clientes devem lê-las como determinantes de falha. O relatório de visita da Universidade do Noroeste indica que a base de Shaanxi dispõe de salas de padrão T4, baixo PUE, opções de racks de alta densidade e capacidades avançadas de refrigeração e segurança. A página Fenghuoyun descreve sistemas de alimentação de reserva, serviços do tipo colocation, comutação central e reivindicações de certificação de segurança.

Um artigo da Phoenix Shaanxi de 2018 indica que a base tinha uma 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 um substituto para condições de serviço específicas do cliente.

A redundância de energia tem vários níveis. As fontes de alimentação utilitárias podem ser diversificadas, mas o quadro de distribuição ainda pode ser comum. Sistemas UPS podem ser redundantes, mas a duração da bateria pode ser curta. 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. PDUs de rack podem ter alimentações A e B, mas um cliente pode acidentalmente conectar ambas as alimentações em um único lado.

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

A redundância de refrigeração também tem níveis. Um baixo PUE é valioso, mas não é uma métrica de disponibilidade. Diz algo sobre eficiência e design. Não diz se uma fileira dada tem margem de refrigeração suficiente após uma falha de um chiller, bomba ou unidade de tratamento de ar. Não diz se os armários de alta densidade refrigerados a líquido podem continuar operando durante a manutenção. Não diz ao cliente se um evento de rebaixamento temporário forçará o deslocamento de 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 exigir um engenheiro autorizado a modificar BGP. Uma falha de armazenamento pode exigir escalação 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. O tamanho da China Telecom não elimina essas etapas; dá ao operador mais recursos para gerenciá-las se o processo estiver preparado.

O cliente deve perguntar pelo caminho do incidente em termos simples. Quem abre o ticket interno? Quem pode entrar na sala? Quais peças estão estocadas no local? Quais mudanças exigem uma janela de manutenção? Como os clientes são notificados se a manutenção planejada afeta um edge cloud, uma alimentação, um plano de armazenamento ou uma rota IP? O SLA exclui a manutenção planejada? Quais serviços são creditados e quais são simplesmente suportados no melhor esforço? Esses detalhes são menos glamorosos que um número de racks, mas determinam se uma falha se torna um evento curto ou uma longa migração.

Os sinais de domínio hospedado requerem manuseio cuidadoso

As contas de domínios hospedados do IPinfo fazem AS134768 parecer uma rede de hospedagem, e isso é uma evidência de mercado útil. Ele reporta mais de 23.000 domínios hospedados no ASN, com concentrações em um pequeno conjunto de IPs. bgp.tools também rotula o tipo de rede como conteúdo. O conjunto de produtos públicos do Tianyi Cloud inclui hosts cloud elásticos, hosts cloud de aplicação, serviços de máquina física, armazenamento, backup, recuperação de desastre e outras ofertas de infraestrutura. Juntos, esses sinais apoiam a premissa central: a rede cloud base faz parte de uma superfície de capacidade hospedada orientada ao cliente.

Eles não provam o serviço exato por trás de um domínio hospedado. Um domínio pode apontar para hospedagem compartilhada, plataforma de revendedor, firewall de aplicação, proxy reverso, equipamento de cliente em colocation, servidor legado, aplicação governamental interna ou cliente corporativo usando um serviço IP estático. A concentração de endereços IP não é a mesma que concentração de contas cloud.

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 de recurso registrado. Isso torna a cadeia operacional mais complicada que "China Telecom Shaanxi possui cada site no IP".

Essa distinção importa durante uma falha. Se um cliente está em um IP de hospedagem compartilhada, um incidente de abuso por outro locatário pode afetar a reputação, a entregabilidade de e-mails ou a filtragem. Se um cliente está em um espaço de endereço de parceiro roteado, os contatos de origem de rota e abuso podem não corresponder facilmente ao contrato. Se um cliente está em uma nuvem privada virtual com IP elástico, a migração pode exigir mudanças de DNS e failover de endpoint.

Se um cliente está em colocation com um roteador de propriedade do cliente, o provedor pode ser responsável pela alimentação e cross-connects mas não pelo sistema operacional ou aplicação do cliente.

O artigo trata, portanto, as contas de domínios hospedados como um sinal de mercado não oficial, não uma evidência de capacidade final. Elas sugerem que AS134768 é usado para tráfego web e de infraestrutura orientado ao cliente. Elas não podem estabelecer quem possui os servidores, se as cargas de trabalho são copiadas em segurança, se a locação é isolada, se existe um caminho de restauração testado, ou se o cliente pode exportar uma imagem VM, um dump de banco de dados, um arquivo de caixa de correio ou uma conta completa do tipo cPanel durante o estresse.

A evidência definitiva seria uma documentação de produto ligada ao serviço real: alocação de endereço, design de isolamento de locatário, escopo de backup e snapshots, formatos de exportação, tratamento de abuso, controles DDoS, controle de DNS reverso, política de reputação de e-mail e suporte a migração. Sem esses detalhes, a escala de domínios hospedados é uma razão para fazer melhores perguntas, não uma razão para relaxar.

A localidade dos dados é um argumento de venda e uma restrição

O campo de região para este perfil é CN, e as evidências públicas suportam uma superfície operacional baseada na China. A APNIC lista o AS na China. Os relatórios sobre a base cloud de Shaanxi colocam o campus físico na região de Xi'an/Xixian. As páginas de produto e os documentos de serviço do Tianyi Cloud são orientados para a China. Essa presença local pode ser valiosa para cargas de trabalho chinesas do setor público, reguladas e sensíveis à latência. Também pode limitar como um cliente projeta backups, acesso ao suporte e caminhos de saída.

O ambiente legal chinês torna o posicionamento de dados mais que uma preferência de aprovisionamento. 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 infraestruturas críticas de informação na China continental. ALei de Segurança de Dadosestabelece um quadro 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 tratamento de informações pessoais e transferência transfronteiriça. Os deveres exatos dependem do cliente, do tipo de dados e do arranjo de serviço, mas a direção é clara: as regras de localização, acesso e transferência importam.

Para clientes de 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 localizados. A segunda é a localidade de backup: onde snapshots, arquivos, réplicas de recuperação de desastre e logs são armazenados. A terceira é a localidade administrativa: quem pode acessar os sistemas, de onde, sob qual entidade legal e qual processo de suporte. Um serviço pode ser hospedado localmente mas usar gerenciamento remoto, ferramentas de segurança externas ou backup inter-região.

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

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

A leitura mais segura é que a infraestrutura local na China é uma funcionalidade 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 de uma saída rápida. A tabela de roteamento de AS134768 não pode responder a essas perguntas. Apenas os termos de serviço e o acordo de tratamento de dados podem.

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

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

Na prática, um comprador deve esperar exclusões. A maioria dos SLAs de nuvem exclui manutenção planejada, falhas de configuração do lado do cliente, problemas de conta e pagamento, eventos de força maior e falhas fora da fronteira de serviço definida 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 desastre protegem apenas dados ou configuração selecionados pelo cliente. Nada disso é incomum. É por isso que a leitura do acordo específico do serviço é importante.

Para AS134768, a fronteira contratual deve ser testada em relação aos principais caminhos de falha. Se a rota upstream falhar, isso é coberto pela disponibilidade da rede ou excluído como manutenção do backbone? Se um rack perder energia, o cliente recebe um 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 DDoS colocar o IP de um cliente em null-route, qual é o caminho de escalação?

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

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

O melhor contrato de nuvem torna as dependências invisíveis visíveis. Ele estabelece a fronteira de 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 objetivo de resposta e as obrigações do cliente. Se AS134768 é a superfície de roteamento e Tianyi Cloud ou uma unidade China Telecom Shaanxi é o provedor de serviços, o cliente precisa tanto dos fatos de roteamento quanto dos fatos contratuais no mesmo arquivo.

Principais caminhos de falha a testar

O primeiro caminho de falha é a falha de rack ou instalação. Isso inclui energia do rack, refrigeração de fileira, erros de PDU, switches top-of-rack, cross-connects, painéis de fibra, acesso físico e erros de manutenção. Os relatórios públicos sobre a base cloud sugerem uma instalação substancial, mas a escala da instalação não elimina a falha local. Os clientes devem saber se seu serviço é mono-rack, mono-sala, mono-prédio, multi-zona ou dois locais.

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

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

O quarto caminho é a falha de suporte. A rede cloud base está dentro de uma grande organização operadora, o que pode ser uma força se a escalação for madura. Isso também pode criar um risco de transferência entre as operações locais, operações do backbone, operações de nuvem, suporte ao cliente, faturamento, segurança e equipes parceiras. O cliente deve saber qual escritório possui cada tipo de incidente e qual nível de gravidade aciona uma escalação 24h.

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

O sexto caminho é a falha de migração. Os clientes frequentemente saem de uma plataforma durante o estresse, quando uma aplicação está instável ou o negócio perdeu a confiança. Este é o pior momento para descobrir que os endereços IP não podem ser movidos, 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 pagas. A migração deve ser ensaiada quando o serviço está saudável.

Esses testes não exigem desconfiança. São diligências razoáveis ordinárias para qualquer provedor de capacidade hospedada cujas evidências de rede pública são mais fortes que as evidências de fronteira de serviço público.

O que melhoraria o nível de evidência

AS134768 merece um nível de evidência de rede Médio porque possui roteamento público sólido, identidade oficial APNIC e contexto de nuvem física plausível. Para alcançar Alto, as evidências públicas ou contratuais deveriam conectar a tabela de roteamento ao serviço do cliente mais diretamente.

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

A segunda melhoria seria uma evidência dos limites da instalação. Os clientes não precisam de uma planta baixa pública, mas precisam saber se sua carga de trabalho está na base cloud Xixian/Fengxi, outro centro de dados de Shaanxi, um pool regional Tianyi Cloud, um rack de parceiro ou um armário de propriedade do cliente. A declaração deveria incluir a classe de energia, as hipóteses de densidade de rack, a política de janela de manutenção, o plano de peças de reposição e se o serviço é mono-zona ou multi-zona.

A terceira melhoria seria uma evidência de recuperação. Um provedor sólido 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 de cliente. Pode dizer quais falhas são cobertas por failover automático e quais exigem um ticket manual. Pode também estabelecer objetivos de tempo de recuperação e ponto de recuperação realistas por produto.

A quarta melhoria seria uma evidência de localidade de dados e saída. O provedor deveria descrever o local de produção, local de backup, local de logs, acesso de subcontratados, controle de chaves de criptografia, formatos de exportação, retenção após rescisão e restrições de transferência transfronteiriça. Para cargas de trabalho governamentais ou reguladas, deveria distinguir conformidade legal de conveniência comercial.

A quinta melhoria seria uma evidência de incidente. Uma página de status, um resumo do histórico de incidentes, um calendário de manutenção, uma matriz de gravidade de suporte e um modelo de relatório pós-incidente fariam a diferença entre uma grande tabela de roteamento e um serviço ao cliente confiável. 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 assumir.

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

Conclusão: rotas sólidas, resiliência condicional

A rede CHINANET SHAANXI province Cloud Base é um sujeito de infraestrutura ativo. APNIC, RIPEstat, bgp.tools, Hurricane Electric e IPinfo suportam todos o mesmo fato central: AS134768 é uma rede viva de cloud base China Telecom Shaanxi com uma pegada substancial 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 adormecida.

A ressalva operacional é igualmente clara. O BGP público mostra acessibilidade, não propriedade de racks. Os registros de endereços APNIC mostram detentores de recursos e contatos, não cargas de trabalho de clientes. As contas de domínios hospedados sugerem uso web e de hospedagem, não qualidade de backup.

Os relatórios de visita da base cloud e páginas de parceiros apontam para um verdadeiro campus de centros de dados e nuvem na região de Xi'an, mas não dizem a um cliente qual produto é mono-zona, qual é multi-zona, qual caminho usa AS4809, qual rack tem energia de reserva, ou qual equipe de suporte restaura um servidor com falha às 2 da manhã.

Para um comprador, a posição prática é uma confiança disciplinada. Trate a rede como viva. Trate o contexto da base cloud China Telecom Shaanxi como significativo. Depois, peça as evidências que realmente decidem as falhas: prefixo de produto, zona de disponibilidade, caminho upstream, propriedade ROA, energia do rack, margem de refrigeração, hardware de reposição, escopo de backup, prova de restauração, escalação de suporte, exclusões de manutenção, regras de continuidade de faturamento e condições de exportação de dados.

A capacidade hospedada não é sem peso. Em Shaanxi, como em qualquer lugar, são roteadores, fibras, salas de energia, loops de refrigeração, portas de switch, filas de suporte e contratos. AS134768 torna essa capacidade visível na internet. Não elimina a necessidade de verificar a cadeia física e operacional abaixo.