Sihe Cloud Shanghai Technology Co., Ltd. vende uma capacidade hospedada que ainda depende de racks, de trânsito e de janelas de manutenção

Resumo

• O registroAPNIC para AS151217identificaSIHE-SHCTcomo Sihe Cloud Shanghai Technology Co., Ltd., na 1508 Kunyang Road, em Xangai. A empresa também detém o bloco IPv4 portátil160.19.76.0/23e o bloco IPv6 portátil2401:9e20::/32, todos registrados em maio de 2024 com contatossihe.aicorrespondentes.
• O AS151217 em si não está ativo publicamente.O status de roteamento do RIPEnão relata nenhum espaço IPv4 ou IPv6 anunciado, nenhum vizinho observado e visibilidade nula entre seus pares na tabela completa. A alocação IPv6 da empresa de Xangai também não é roteada.
• O bloco IPv4 é diferente:O RIPE vê160.19.76.0/23em cada par IPv4 ascendente, originado do AS9808, China Mobile. A rota é visível desde junho de 2024. Isso prova a acessibilidade pública do recurso de endereços, não uma operação de rede independente pelo AS151217 ou um local de rack específico.
• Umavitrine ativa da Sihe Cloudvende máquinas virtuais, contêineres, bancos de dados gerenciados, armazenamento de objetos e armazenamento de arquivos, apoiada por umconsoleacessível e umcentro de documentação. No entanto, essas páginas públicas e oacordo de serviço padrãoidentificam a Haining Sihe Cloud Computing Technology Co., Ltd. como fornecedora. Elas não explicam o papel da empresa de Xangai na prestação de serviços de varejo.
• A conclusão prudente é, portanto, estreita. A Sihe Cloud Shanghai Technology Co., Ltd. controla de forma demonstrável recursos de números da Internet e possui um bloco IPv4 roteado através de uma operadora importante. As evidências públicas não estabelecem que ela possui um data center, opera a nuvem voltada para o cliente, controla uma periferia multioperadora, mantém uma reserva de migração ou assume as obrigações de suporte e restituição de dados vendidos sob o nome Sihe.

A rota ativa é o fato mais sólido, e ela cria a questão mais difícil

Pequenas empresas de nuvem são frequentemente mais fáceis de encontrar através de recursos públicos da Internet vinculados a seus nomes legais. Este é o caso aqui, mas os registros não formam a imagem simples sugerida por um nome de empresa. O registro AS151217 nomeia a Sihe Cloud Shanghai Technology Co., Ltd., fornece o nome de rede SIHE-SHCT e localiza o contato administrativo no segundo andar do Edifício 2, 1508 Kunyang Road, distrito de Minhang, Xangai. O registro ocorreu em 11 de maio de 2024. Os contatos administrativo, técnico e de abuso usam todos o domínio sihe.ai.

Na mesma data, a empresa recebeu dois recursos de endereços portáteis. O primeiro, 160.19.76.0/23, cobre 512 endereços IPv4. O segundo, 2401:9e20::/32, é uma alocação IPv6 grande o suficiente para suportar um enorme número de sub-redes de clientes. Não são meras menções de diretório. São registros de recursos com autoridade, mantidos através da APNIC e CNNIC. Eles estabelecem que a empresa de Xangai é a detentora nomeada dos recursos e possui uma superfície de contato operacional reconhecida para abusos e administração de rede.

O que eles não estabelecem é igualmente importante. Um endereço de escritório em um registro da Internet não é um endereço de data center. Um bloco portátil não revela se o detentor possui os roteadores, aluga um rack, usa um serviço de anúncio gerenciado por uma operadora, atribui endereços a clientes, reserva espaço para implantação futura ou delegou a operação diária a outra empresa. As diretrizes de registro de recursos da APNIC indicam que uma organização é elegível para um ASN quando é multi-homed com uma política de roteamento distinta, ou pode demonstrar que atenderá a esses critérios logo após receber o número.

Possuir o identificador é, portanto, uma opção e uma intenção de operar uma política de roteamento distinta, não a prova de que a opção está sendo exercida atualmente.

O bloco IPv4 da empresa de Xangai está, no entanto, ativo. As informações de rede do RIPE mapeiam todo o /23 para o AS9808. A visualização do status de roteamento registra o AS9808 como origem, reporta visibilidade em todos os 325 pares IPv4 disponíveis no ponto de observação e data a primeira rota vista em 7 de junho de 2024. O histórico de roteamento mostra intervalos visíveis repetidos sob a mesma origem a partir de junho de 2024. A rota não é uma alocação de registro esquecida. Ela atinge a tabela global.

Isso torna a questão central mais aguda, não mais fácil. Se um cliente receber um endereço deste bloco, a rota pública indica que a rede da China Mobile é a origem visível para o resto da Internet. A rota não passa pelo AS151217. A empresa de Xangai pode ter um acordo comercial que lhe dá controle legítimo e útil sobre o endereçamento, filtragem e atribuições de clientes, mas o caminho público não revela as condições. Quando um incidente requer uma mudança urgente de rota, uma ação de mitigação ou uma retirada de prefixo, os clientes precisam saber qual parte pode fazer essa mudança e qual parte apenas abre um ticket.

AS151217 está atribuído mas silencioso

Não há ambiguidade na visão atual do coletor do ASN próprio da empresa de Xangai. A visão geral AS do RIPE marca AS151217 como não anunciado. Sua resposta de status de roteamento reporta zero prefixos IPv4, zero prefixos IPv6, nenhuma primeira rota vista, nenhuma última rota vista e nenhum vizinho observado. A visibilidade é nula entre todos os 325 pares IPv4 e 322 pares IPv6 na tabela completa. A resposta de prefixos anunciados está vazia, e a visão de vizinhos não reporta nenhum vizinho esquerdo, direito, único ou incerto.

Evidências de topologia independentes apontam na mesma direção. O registro AS Rank da CAIDA identifica SIHE-SHCT na China, mas o marca como não visto, sem grau de fornecedor, par ou cliente e sem cone de endereços ou prefixos. O relatório CIDR indica que o ASN não é usado para anunciar um prefixo na tabela global ou como AS de trânsito visível. Uma consulta ao PeeringDB não retorna nenhum objeto de rede. A participação no PeeringDB é voluntária, então a ausência não é prova de falta de interconexão. No entanto, combinado com os dados do coletor, não oferece suporte a uma presença de peering público ou instalação sob o AS151217.

O silêncio não significa que a empresa está inativa em todos os sentidos. Ela pode usar endereços atribuídos por um provedor, colocar equipamentos atrás de uma operadora, operar redes privadas ou solicitar que outro ASN anuncie seu espaço portátil. O /23 roteado mostra que a última dessas possibilidades não é teórica. A distinção importa porque um prefixo originado de uma operadora pode suportar um serviço de hospedagem perfeitamente funcional.

Isso simplesmente dá ao cliente um modelo de controle diferente daquele em que a empresa de hospedagem opera visivelmente sua própria periferia e possui relações upstream observáveis de forma independente.

A alocação IPv6 portátil também está silenciosa. O status do RIPE para 2401:9e20::/32 não encontra nenhuma origem, nenhuma rota mais específica, nenhuma rota menos específica e visibilidade nula entre os pares IPv6 disponíveis. A alocação é administrativamente substancial, mas operacionalmente ausente da tabela pública. Essa lacuna importa para clientes que esperam um serviço dual-stack, pois um recurso IPv6 no papel não é equivalente a um serviço IPv6 roteado com atribuições de clientes testadas, filtragem, monitoramento e resposta a incidentes.

O quadro de segurança de roteamento também é escasso. O validador RPKI do RIPE retorna unknown para o par AS9808 e 160.19.76.0/23 porque não encontra nenhuma autorização de origem de rota validada. Desconhecido não significa inválido e não é prova de sequestro. Significa que o sistema criptográfico público não fornece autorização positiva de que o AS9808 pode anunciar este prefixo. Para um bloco portátil roteado através de terceiros, uma autorização válida tornaria a origem pretendida mais explícita e reduziria uma categoria de ambiguidade de roteamento.

A origem pertence à China Mobile, não ao ASN do detentor do recurso

O registro APNIC para AS9808 identifica CHINAMOBILE-CN como China Mobile Communications Group Co., Ltd. É uma rede de operadora importante com escala e presença de rota muito além do /23 da empresa de Xangai. Sua presença como origem dá ao bloco acessibilidade global e um caminho de qualidade de operadora para a Internet mais ampla. Isso não diz a um cliente se a empresa de Xangai compra trânsito, compra um circuito de acesso, aluga capacidade de hospedagem, usa um produto de anúncio de endereços ou tem outro acordo.

Essa diferença entre alocação e origem não é meramente uma questão técnica de roteamento. O detentor do recurso pode ser responsável pela atribuição de endereços e contatos de abuso, enquanto a rede de origem controla a política de borda visível para o mundo. Um ataque de negação de serviço pode exigir ação de ambas as partes: o provedor de serviços identifica o alvo e a resposta desejada, enquanto a operadora aplica filtragem ou limpeza em um ponto onde o tráfego ainda pode ser absorvido. Um vazamento de rota pode exigir que a origem mude de política.

Uma janela de manutenção programada no transporte da operadora pode desconectar servidores que permanecem ligados e saudáveis. Uma disputa comercial sobre o circuito pode tornar uma alocação de endereços válida inacessível.

A rota pública também revela apenas uma origem, não diversidade. Um serviço multioperadora ainda pode anunciar um prefixo através de um único ASN enquanto usa outras operadoras de maneiras que os coletores não expõem, mas não há base pública para supor isso aqui. O AS151217 não tem nenhum vizinho visível. O /23 tem uma única origem visível. A ausência de entrada de rede no PeeringDB não deixa nenhuma lista voluntária de pontos de troca, instalações ou política de interconexão.

Um comprador deve, portanto, tratar a diversidade de operadoras como uma questão de engenharia sem resposta, em vez de deduzi-la da existência de um ASN ou de declarações gerais em um site comercial vinculado.

O transporte físico é tão importante quanto a rota lógica. Dois contratos com nomes de operadoras diferentes ainda podem compartilhar uma única entrada de edifício, um único caminho de fibra, um único roteador de agregação ou um único duto metropolitano. Inversamente, uma operadora pode às vezes fornecer caminhos verdadeiramente diversos. Provar a resiliência requer diagramas de roteamento, identificadores de circuitos, caminhos de entrada, pontos de demarcação, responsabilidade de manutenção e resultados de testes de falha. Uma lista de logotipos não pode fazer esse trabalho.

Os dados públicos para a empresa de Xangai nem divulgam a instalação na qual o bloco roteado termina, portanto a primeira tarefa é estabelecer o local antes de avaliar a diversidade internamente.

O serviço Sihe comercializável aponta para uma empresa contratante diferente

Existe um serviço comercial funcional sob o nome Sihe. A página inicial da Sihe Cloud anuncia máquinas virtuais elásticas, computação por contêineres, bancos de dados relacionais gerenciados, balanceamento de carga, armazenamento de objetos, armazenamento de arquivos e proteção contra ataques de negação de serviço distribuída. Ela remete a um console de gerenciamento acessível onde um usuário pode se registrar, e a um centro de documentação com instruções sobre produtos, páginas de preços e termos de serviço. Estes são sinais operacionais mais fortes do que um site corporativo inativo ou um simples registro de registro.

Eles mostram uma superfície de cliente mantida com produtos descritos com detalhes suficientes para suportar uso real.

Mas o nome legal neste serviço não é Sihe Cloud Shanghai Technology Co., Ltd. Os metadados da página inicial, a descrição da empresa e o rodapé identificam a Haining Sihe Cloud Computing Technology Co., Ltd. A página sobre informa que esta empresa de Haining foi fundada em 2018 e descreve computação em nuvem, design e fabricação de equipamentos, bem como construção e operação de IDC. Ela fornece um número de atendimento ao cliente e um endereço na 180 Canghai Road, em Haining, Zhejiang.

O rodapé da documentação também nomeia a Haining Sihe e exibe um registro ICP de Zhejiang e um número de licença de empresa de telecomunicações de valor adicionado.

O acordo de serviço padrão e SLA é mais explícito. Ele afirma que a Haining Sihe Cloud Computing Technology Co., Ltd. contrata com o usuário para fornecer a plataforma de computação em nuvem Sihe. Nomeia a 180 Canghai Road, Haining, como local de execução. Promete serviço operacional 24 horas por dia, disponibilidade mensal de pelo menos 99,9% e início de resposta dentro de 30 minutos após um problema técnico. Também define exclusões, obrigações de pagamento, direitos de suspensão, condições de rescisão e recuperação de recursos.

Nenhuma dessas páginas atribui um papel à empresa de Xangai. Os contatos sihe.ai compartilhados, o mesmo nome Sihe e a proximidade comercial óbvia podem indicar uma organização ou cooperação comum. Eles não podem estabelecer por si mesmos a propriedade, afiliação, mandato, subcontratação ou responsabilidade conjunta. O contrato público permite que o provedor de serviços transfira direitos ou obrigações em circunstâncias especificadas, mas não identifica a entidade de Xangai como a parte que opera o bloco roteado, os racks ou o suporte técnico.

Essa fronteira deve permanecer intacta. A empresa de Xangai pode ser descrita como a detentora do AS151217 e das duas alocações portáteis porque o registro diz isso. A empresa de Haining pode ser descrita como a provedora pública porque a vitrine e os termos dizem isso. O bloco IPv4 pode ser descrito como originado da China Mobile porque a rota diz isso. Unir esses três fatos em uma única cadeia corporativa e operacional requer um acordo, um registro de propriedade ou uma divulgação técnica de primeira mão que não é pública.

A vitrine é acessível através de uma quarta superfície de rede

O serviço web visível não utiliza atualmente o bloco IPv4 portátil da empresa de Xangai. O DNS público para a página inicial, o console e o site de documentação leva através de hosts nomeados Deyang na Sihe para 222.213.119.154. As informações de rede do RIPE colocam este endereço em 222.208.0.0/13, originado do AS4134. O registro de endereço da APNIC identifica a rede de cobertura como CHINANET-SC, a rede Sichuan da China Telecom.

Trata-se de uma visão instantânea da periferia do serviço, não de um mapa da infraestrutura de aplicação ou armazenamento. Um rótulo DNS contendo Deyang pode refletir uma convenção de nomenclatura de uma operadora; não prova o edifício em que cada servidor está localizado. Um ASN de origem identifica a rede que anuncia o ponto de extremidade, não o proprietário do servidor por trás. Um frontend web também pode ser separado das regiões de computação e armazenamento. A observação continua útil porque mostra que as superfícies de cliente mais visíveis da Sihe não são alcançadas através do AS151217 nem do 160.19.76.0/23 da empresa de Xangai.

Os clientes devem, portanto, evitar usar a rota do site como prova para o posicionamento de sua carga de trabalho. A periferia pública pode ser um balanceador de carga, um proxy reverso, um endpoint de site de armazenamento de objetos ou um host de serviço combinado. O console pode controlar máquinas em outro lugar. A documentação pode ser servida independentemente da produção.

Para localizar uma carga de trabalho, as evidências relevantes são o endereço de instância atribuído, o endpoint de armazenamento, traceroutes a partir de redes de acesso úteis, a região contratual, a divulgação da instalação e os compromissos de localização de dados do provedor.

A separação também cria um padrão de falha fácil de ignorar. A vitrine e o console podem falhar enquanto as máquinas dos clientes permanecem acessíveis. As máquinas dos clientes podem falhar enquanto o console parece saudável. A documentação pode permanecer online durante uma falha do plano de controle. O /23 de Xangai originado da operadora pode permanecer visível enquanto um rack atrás perde energia, ou ser retirado enquanto cada servidor permanece ligado.

Um modelo de status confiável precisa de verificações separadas para acesso à conta, operações de controle, acessibilidade de computação, operações de armazenamento, DNS, cada prefixo público e cada zona anunciada.

Um catálogo de produtos descreve obrigações, não a capacidade instalada

A documentação ECS descreve máquinas virtuais que podem ser configuradas por processador, memória e disco, expostas através de vários protocolos de rede, monitoradas no console e escaladas ou reduzidas conforme a demanda. Ela também indica que, se um host físico falhar, a plataforma migrará automaticamente as máquinas virtuais para uma máquina saudável, ao mesmo tempo em que aconselha os clientes a configurar seus serviços para iniciar automaticamente. Esta é uma promessa operacional concreta.

Implica um agendador, armazenamento compartilhado ou um método de migração de disco funcional, capacidade de reserva de host, detecção de saúde e um host de destino compatível com a carga de trabalho com falha.

A documentação RDS vai além na responsabilidade gerenciada. Ela indica que o provedor gerencia a infraestrutura, disponibilidade, backup e restauração, atualizações e migração em caso de falha, e oferece modelos de banco de dados de nó único e multinó. Um cliente lendo esta descrição não está alugando apenas tempo de CPU. O cliente depende de uma equipe de operações para distinguir uma falha de host de uma falha de banco de dados, manter backups suficientemente separados para sobreviver à falha relevante, testar restaurações e preservar a consistência durante o failover.

Os produtos de armazenamento multiplicam essas dependências. A página de armazenamento de objetos alega armazenamento distribuído, cópias automáticas em diferentes dispositivos e data centers, alta disponibilidade, escalonamento automático e acesso através de uma interface de objetos amplamente utilizada. O tutorial de linha de comando S3 mostra um caminho de exportação usando ferramentas compatíveis com S3 e credenciais de acesso. A página NAS descreve discos em nuvem redundantes, montagem multi-instância e acesso compartilhado a arquivos.

Essas páginas estabelecem uma superfície de produtos comercializáveis. Elas não contam os hosts físicos, discos, portas, racks, consumo de energia ou reserva de failback não utilizada por trás. Elas não identificam quais produtos usam o bloco portátil da empresa de Xangai. Elas não mostram se as cópias de objetos ocupam edifícios independentes, zonas de incêndio independentes ou simplesmente dispositivos diferentes na mesma sala. Elas não fornecem compromissos de ponto de recuperação ou tempo de recuperação específicos do cliente. A diferença entre um recurso documentado e a capacidade instalada é onde o risco da nuvem normalmente se esconde.

A página de precificação ECS precifica processador, memória, disco e tráfego de saída como unidades de consumo separáveis e afirma que o preço do console prevalece. Isso é economicamente inteligível para um comprador, mas cada unidade corresponde a uma infraestrutura finita. Um CPU virtual é uma parte de um CPU host. Um gigabyte de memória deve estar instalado em um servidor. Uma alocação de disco consome mídia, controladores, tráfego de replicação e um estoque de reposição. A transferência de saída consome um compromisso da operadora e potencialmente uma porta congestionada.

O contador de detalhes não revela o compromisso de compra do provedor nem a reserva disponível durante uma falha.

A capacidade instalada, comercializável e recuperável são quantidades diferentes

Uma operadora de nuvem pode anunciar um amplo catálogo enquanto tem pouca capacidade de reserva no exato domínio de falha que importa. A capacidade passa por vários estágios. Um site pode ser planejado, construído e energizado. Racks podem ser instalados, mas vazios. Servidores podem ser instalados, mas aguardando provisionamento de rede ou armazenamento. Hosts podem ser provisionados, mas já alocados. Recursos podem estar tecnicamente livres, mas reservados para manutenção, replicação ou recuperação de falhas. Apenas o restante é comercializável com segurança.

A página inicial da Sihe alega três salas de máquinas ou zonas de disponibilidade com resfriamento e rede independentes, alimentações duplas de duas subestações, acesso de rede multilínhas, resfriamento N+1, usina fotovoltaica autoconstruída, 20 Gb de largura de banda pública e rede interna de 50 GbE ou 400 GbE. Essas são alegações significativas porque descrevem escolhas de design físico e lógico. Elas não são acompanhadas de nomes de instalações, endereços de sites, diagramas unifilares elétricos, detalhes de circuitos de operadoras, carga provisionada, utilização, relatórios de auditoria ou testes de failover.

As alegações devem, portanto, ser lidas como representações do provedor, não como medidas da capacidade atual disponível para os clientes.

A palavra 'três' é particularmente fácil de interpretar demais. Três salas no mesmo edifício não oferecem a mesma proteção que três sites em sistemas de utilidade pública, inundação, incêndio e operadoras distintos. Três zonas lógicas ainda podem compartilhar um plano de controle ou estrutura de armazenamento. O resfriamento independente dentro das salas ainda pode depender de um único sistema de água ou elétrico do edifício. Duas alimentações elétricas podem convergir para a mesma subestação, mesmo quadro de distribuição ou mesmo transformador, apesar da intenção de design de separá-las.

Uma instalação solar pode reduzir o custo de energia sem manter a carga do servidor durante uma falha de rede. Cada alegação precisa de um mapa dos domínios de falha.

Para a entidade de Xangai, a lacuna de localização vem primeiro. Seu endereço de registro na Kunyang Road é um endereço de contato administrativo e não deve ser promovido a local de rack. O acordo de serviço de Haining fornece um local de execução do contrato, mas não uma lista de data centers. A periferia web usa o espaço de endereçamento de Sichuan e rótulos Deyang, mas isso não localiza toda a nuvem. O /23 de Xangai é originado da China Mobile, mas uma origem de operadora não divulga qual cidade ou edifício contém o equipamento de terminação.

As evidências públicas, portanto, suportam uma zona de serviço na China, não um mapa preciso dos ativos instalados.

Essa incerteza muda as compras. Um comprador não pode calcular o risco correlacionado entre computação, banco de dados e armazenamento de objetos até saber se suas cópias primárias e de recuperação compartilham um site. Não pode avaliar a continuidade de energia sem conhecer o rack contratual e o caminho de alimentação. Não pode julgar a diversidade de operadoras sem ver os circuitos e entradas. Não pode avaliar a substituição de hardware sem conhecer o tipo de parque e o estoque local de peças sobressalentes.

Em uma nuvem pequena, um número modesto de hosts ou discos não utilizados pode fazer a diferença entre uma migração rápida e uma fila prolongada.

A árvore de falhas começa abaixo da máquina virtual

Um cliente vê uma instância, um endereço e um botão de console. O operador de serviço vê uma cadeia de dependências. Na base está a instalação: entrada elétrica, equipamentos de comutação, fontes de alimentação ininterrupta, baterias, geradores, resfriamento, sistemas de incêndio, segurança física e mão de obra de manutenção. Acima estão os racks, unidades de distribuição de energia, switches de topo de rack, fontes de alimentação de servidor, processadores, memória, mídia local, redes de armazenamento e controladores de gerenciamento.

Acima destes estão o hipervisor, o agendador, a rede virtual, o serviço de imagens, o sistema de identidade, o sistema de faturamento e o console do cliente.

Uma falha em qualquer nível pode produzir um sintoma de cliente semelhante. Uma máquina virtual morta pode ser um problema de sistema operacional convidado, um host esgotado, um disco com falha, uma falha de switch, uma pausa de armazenamento, um evento de energia de rack ou uma suspensão de conta. A rota pode permanecer visível durante a maioria dessas falhas. Inversamente, uma falha de rota pode fazer uma máquina saudável parecer morta do exterior. O diagnóstico depende, portanto, da observabilidade em cada camada e de uma equipe de suporte autorizada a atravessar fronteiras organizacionais.

A rota de Xangai adiciona uma dependência de operadora a esta árvore. O AS9808 é a origem pública para 160.19.76.0/23. Se um cliente neste bloco perder sua conectividade, o lado da hospedagem deve decidir se a falha está dentro da rede virtual, no switch voltado para o servidor, no transporte da operadora, no backbone da operadora, na propagação de rota ou em uma rede de acesso remota. Se a empresa não controla diretamente os roteadores de origem, a qualidade da escalada se torna parte da qualidade do serviço.

As questões práticas são: quem detém a conta da operadora, qual prioridade o circuito recebe, se os engenheiros podem ligar diretamente para o centro de operações de rede e se as mudanças de rota de emergência requerem aprovação comercial.

O estoque de hardware cria outro ramo. A promessa de migração automática da ECS pressupõe um destino saudável com capacidade suficiente em CPU, memória e armazenamento. Se vários hosts compartilharem uma falha de energia ou resfriamento, a plataforma deve absorver mais de uma máquina por vez. Se o armazenamento de origem estiver danificado ou isolado, a migração ao vivo pode não ser possível. Se o destino tiver uma geração de CPU ou perfil de dispositivo diferente, algumas cargas de trabalho podem não iniciar corretamente.

Um provedor pode atender à demanda de vendas comum, mas carecer da reserva concentrada necessária durante um evento de site.

O tempo de reparo não é apenas o tempo necessário para substituir uma peça. Inclui detecção, aprovação de acesso, viagem do técnico, isolamento da falha, identificação da peça sobressalente, aprovação de mudança, trabalho físico, firmware ou configuração, reconstrução de dados, validação e retorno ao serviço. Uma troca de hardware de quatro horas pode se tornar um incidente de cliente muito mais longo se a fonte de alimentação ou o disco correto não estiver localizado. O material público não divulga o parque, pessoal no local, política de peças sobressalentes ou acordo de acesso da Sihe Cloud Shanghai.

Essas omissões não são prova de má prática. São limites ao que um cliente pode assumir com confiança.

As alegações de redundância devem sobreviver a testes de causa comum

As alegações da página inicial sobre três zonas, alimentação dupla, multilínhas e N+1 descrevem as categorias certas de resiliência. O teste é se elas eliminam uma causa compartilhada. Duas alimentações elétricas só são úteis se um único disjuntor, chave de transferência automática, caminho de cabos ou procedimento de manutenção não puder colocar ambas fora de serviço. Duas operadoras só são úteis se não convergirem no mesmo conduíte, mesma entrada, mesmo divisor óptico ou mesmo backbone upstream. O resfriamento N+1 só é útil na carga de projeto e apenas se a energia, os controles e a rejeição de calor permanecerem disponíveis.

As evidências de roteamento atualmente não demonstram uma periferia multioperadora para a empresa de Xangai. O AS151217 está silencioso e não tem vizinhos observados. Seu bloco IPv4 tem uma única origem, AS9808. Seu bloco IPv6 não é roteado. Isso não refuta um segundo serviço de acesso, uma interconexão privada ou um circuito de backup. Significa que o cliente não pode validar a diversidade inspecionando a rota pública. O provedor deve divulgá-la ou demonstrá-la em outro nível.

A evidência mais útil seria uma matriz de site e circuito. Para cada zona anunciada, nomearia a operadora da instalação, cidade, sala, alimentação elétrica, limite de resfriamento, operadora, transporte de circuito, origem externa, caminho de backbone interno, réplica de armazenamento e dependência do plano de controle. Distinguiria a capacidade ativo-ativo de um backup frio ou com capacidade limitada. Indicaria se o /23 de Xangai é usado para instâncias de clientes, serviços de infraestrutura, capacidade futura ou outro propósito. Também indicaria se o failover preserva o mesmo endereço de cliente ou requer mudanças de DNS e endereço.

Os testes importam mais do que os diagramas. Uma retirada controlada de rota pode mostrar se um caminho de backup realmente transporta tráfego. Uma evacuação de host pode mostrar se existe uma reserva de migração. Um exercício de restauração pode mostrar se os backups são legíveis e se as credenciais sobrevivem a um incidente no plano de controle. Um teste de transferência de energia pode mostrar se o rack permanece energizado. Um exercício de suporte pode mostrar se as pessoas certas respondem no prazo prometido. Sem resultados, a redundância continua sendo uma intenção de design.

A especificação BGP explica como as redes trocam acessibilidade e caminhos AS, enquanto as orientações operacionais da RFC 7454 cobrem filtragem, proteção de sessões e controles como limites máximos de prefixos. Essas práticas reduzem o risco de roteamento, mas não podem ser deduzidas de um ASN registrado. O silêncio do AS151217 significa que não há operação pública visível em relação à qual avaliá-las. Para o /23 ativo, a política relevante é principalmente a política da origem AS9808 e o acordo comercial que a autoriza e rege.

A recuperação é um problema de capacidade antes de ser um recurso de software

As páginas de produtos fazem várias alegações de recuperação: migração de host ECS, backup de banco de dados e migração em caso de falha, cópias de objetos em diferentes dispositivos e data centers, armazenamento de arquivos redundante, snapshots e imagens. Cada uma pode ser valiosa. Nenhuma elimina a necessidade de perguntar quanta capacidade está reservada, onde residem as cópias e como a restauração se comporta sob estresse.

Para máquinas virtuais, um recurso de migração deve ser separado em casos planejados e não planejados. A evacuação planejada pode mover cargas de trabalho enquanto o host de origem permanece saudável. Uma falha repentina de host pode exigir a reinicialização de uma máquina virtual em outro lugar a partir de armazenamento compartilhado ou disco replicado. Isso cria um tempo de inatividade mesmo que a movimentação seja chamada de automática. O tempo de recuperação do cliente depende então da detecção de falha, da capacidade do agendador, da disponibilidade do disco, do comportamento de inicialização e da recuperação do aplicativo.

A instrução ECS de configurar a inicialização automática é uma dica útil de que a configuração do cliente continua sendo parte da continuidade.

Para bancos de dados, as métricas essenciais são o ponto de recuperação e o tempo de recuperação. Uma configuração multinó pode reduzir a interrupção se as réplicas estiverem atualizadas e o mecanismo de failover puder estabelecer um primário seguro. Os backups protegem contra uma classe diferente de problemas, incluindo exclusão acidental ou corrupção, mas apenas se forem antigos o suficiente para preceder os danos e separados o suficiente para sobreviver à falha. A página pública do RDS descreve alta disponibilidade e backup em termos gerais.

Ela não publica topologia específica do cliente, cronograma de retenção, resultado de teste de restauração ou garantia para qualquer uma das métricas.

Para armazenamento de objetos, o acesso compatível com S3 é um recurso de portabilidade promissor. O método documentado s3cmd significa que os clientes podem usar ferramentas familiares em vez de uma interface puramente proprietária. Mas uma interface não é um plano de saída. Exportações grandes dependem do comportamento de listagem, número de objetos, compatibilidade de metadados, credenciais, largura de banda de saída, limitação e taxas. Um cliente que pode teoricamente copiar centenas de terabytes pode ainda precisar de semanas para fazê-lo através de um link restrito.

Para armazenamento de arquivos, a consistência do aplicativo pode ser mais difícil do que a cópia de blocos. Um banco de dados aberto ou um sistema de arquivos compartilhado ativo pode exigir snapshots coordenados, quiescência ou backups em nível de aplicativo. Discos redundantes protegem contra algumas falhas de hardware, mas não necessariamente contra erro de operador, exclusão maliciosa, comprometimento de conta ou evento em escala de site. O design correto de recuperação geralmente inclui uma cópia controlada sob credenciais separadas e, para cargas de trabalho críticas, fora do domínio de falha do provedor.

Um cliente deve testar uma restauração externa antes de precisar dela. Exportar uma imagem de máquina virtual representativa ou reconstruir a partir da configuração. Restaurar um banco de dados em um ambiente controlado de forma independente. Copiar um conjunto de objetos significativos com metadados e verificar somas de verificação. Recriar os controles de acesso. Medir a taxa de transferência em tempo normal e de pico. Registrar quais etapas exigem o console Sihe ou suporte técnico. Esses testes transformam a portabilidade de uma esperança contratual em uma propriedade observada.

O suporte, a faturação e o estado do contrato podem parar uma infraestrutura saudável

A disponibilidade da nuvem é em parte administrativa. O acordo de serviço da Sihe promete suporte operacional 365x24 e afirma que a resposta começará dentro de 30 minutos após um problema técnico. Não promete resolução em 30 minutos. Essa diferença é sensata, pois o reparo depende da falha, mas os compradores devem torná-la explícita em suas próprias expectativas. Eles devem saber quais canais são monitorados, como a gravidade é atribuída, quando um engenheiro em vez do atendimento ao cliente intervém e como um incidente de operadora é escalado.

O acordo exclui vários tipos de tempo de inatividade de seu cálculo de disponibilidade, incluindo manutenção de rotina, causas atribuíveis ao usuário, causas de terceiros e força maior. Também dá ao provedor de serviços o direito de interromper o serviço por obrigações não pagas, usos prejudiciais especificados, requisitos regulatórios e outras violações. Em caso de rescisão, permite que o provedor recupere os recursos do cliente e descarte ou limpe os recursos ou equipamentos anteriormente usados pelo cliente. Essas condições tornam o estado da conta e o pagamento parte da cadeia de infraestrutura.

Essa cadeia pode falhar silenciosamente. Um aviso de pagamento enviado para um endereço não monitorado pode resultar em suspensão. Um funcionário que saiu pode reter a única credencial de administrador. A verificação de nome real ou solicitações regulatórias podem bloquear alterações de conta. Uma denúncia de abuso pode acionar filtragem urgente. Uma discordância contratual pode atrasar uma exportação enquanto as máquinas permanecem tecnicamente saudáveis.

Os clientes devem separar os contatos de faturamento, segurança e técnicos; usar credenciais organizacionais compartilhadas; manter um inventário de ativos externos; e definir um caminho de retorno de dados de emergência antes que uma disputa ocorra.

A fronteira entre as entidades importa novamente aqui. O acordo padrão publicado nomeia a Haining Sihe como provedora. O bloco IPv4 portátil nomeia a empresa de Xangai como detentora. O AS9808 da China Mobile é a origem da rota. Se um endereço de cliente neste bloco for suspenso ou inacessível, é preciso saber qual contrato rege o endereço, qual empresa controla a conta, qual empresa fala com a operadora e qual parte possui o equipamento que contém os dados. Uma marca compartilhada não substitui essa alocação de responsabilidade.

O número de disponibilidade mensal de 99,9% também precisa ser traduzido em consequências operacionais. Em um mês de 30 dias, 0,1% representa cerca de 43 minutos. A manutenção excluída e eventos de terceiros podem aumentar o tempo de inatividade sofrido pelo cliente sem reduzir o cálculo contratual. Um crédito, se disponível, não restaura transações perdidas nem repara dados corrompidos. A questão de provisionamento útil não é se a porcentagem parece familiar; é saber se a arquitetura de serviço, as exclusões, as evidências e o plano de recuperação correspondem ao modelo de perda real do cliente.

A localidade dos dados é uma cadeia de cópias e controladores

Todos os registros de empresa e rede identificados estão na China, mas 'na China' não é uma resposta completa de localização de dados. O registro da empresa de Xangai aponta para Minhang. O acordo de serviço padrão aponta para Haining. A periferia da vitrine aponta para um endereço da China Telecom Sichuan e hosts nomeados Deyang. O bloco IPv4 é transportado pela China Mobile, sem localização pública de instalação. A documentação do produto alega cópias de armazenamento em vários dispositivos e data centers. Esses fatos descrevem vários locais e papéis sem mapear os dados primários e secundários de um cliente.

A localidade deve ser documentada por tipo de dados. Uma máquina virtual tem discos de sistema e dados, snapshots, imagens, logs, metadados de console e credenciais. Um banco de dados gerenciado tem dados primários, réplicas, logs de transação, backups e registros de monitoramento. O armazenamento de objetos tem objetos, metadados, índices, logs de acesso e possivelmente cópias em cache. As interações de suporte podem conter nomes de clientes, endereços e detalhes de sistema. A faturação e a verificação de nome real adicionam outro conjunto de registros pessoais e corporativos.

Cada um pode ter um controlador, período de retenção e local diferentes.

A Lei de Proteção de Informações Pessoais da China estabelece um quadro nacional para o tratamento de informações pessoais, e suas disposições transfronteiriças impõem condições quando informações pessoais são fornecidas fora da China. As evidências públicas não mostram que a empresa de Xangai ou o serviço Sihe transfere informações pessoais de clientes para o exterior. A lei é importante aqui porque os clientes não podem avaliar suas próprias obrigações até saberem qual entidade legal processa quais dados, para onde vão as cópias e quais subcontratados ou operadores podem acessá-los.

A classificação oficial chinesa de serviços de telecomunicações descreve a atividade IDC em termos físicos: instalações, colocação e manutenção de equipamentos do cliente, servidores e armazenamento alugados, linhas de comunicação e largura de banda. Essa definição é uma correção útil para a metáfora da nuvem sem atrito. Mesmo um serviço virtual depende de uma combinação licenciada e contratual de salas, hardware, linhas e pessoas. As declarações públicas de que a empresa de Haining possui licenças relevantes não estabelecem qual licença, instalação ou responsabilidade operacional pertence ao detentor de recursos de Xangai.

Um plano de localidade do cliente deve, portanto, nomear a entidade contratante, a operadora da instalação, a cidade, a região primária, a região de backup, os locais de acesso ao suporte, as origens de rede e o caminho de exportação. Deve indicar se os dados do cliente alguma vez entram no bloco portátil da empresa de Xangai e se o tráfego do bloco é processado ou registrado por outra parte. Deve identificar a base legal e o processo de aprovação para suporte remoto. Também deve definir o que acontece com backups, snapshots e logs após a rescisão.

Quem é afetado quando a cadeia falha

As vítimas imediatas não se limitam às equipes de infraestrutura. Uma pequena empresa pode operar seu site público, sistema de inventário e arquivos de pessoal em uma única conta. Uma empresa de software pode colocar contêineres de produção, um banco de dados gerenciado e armazenamento de objetos no mesmo serviço, criando uma dependência correlacionada entre aplicação, estado e backups. Um sistema de vídeo ou industrial pode gerar uma carga sustentada de armazenamento e rede difícil de mover rapidamente. Um desenvolvedor individual pode contar com uma instância de baixo custo sem um segundo provedor ou backup local.

Cada produto falha de forma diferente. A perda da rota da operadora desconecta cada endereço acessível externamente no bloco afetado, mesmo que os hosts estejam saudáveis. A perda de um rack ou estrutura de armazenamento pode danificar um subconjunto de instâncias enquanto a rota permanece visível. A perda do plano de controle bloqueia provisionamento, reinicialização e alterações de credenciais. A perda do armazenamento de objetos pode quebrar aplicações que ainda têm computação funcional. A perda do RDS pode parar transações enquanto as páginas estáticas permanecem online.

A perda de acesso à faturação ou uma suspensão de conta pode atravessar tudo.

O raio de impacto depende se as zonas anunciadas são independentes e se os clientes distribuem deliberadamente as cargas de trabalho. A migração automática pode reduzir uma falha de um único host, mas concentrar a demanda nos hosts restantes. Um banco de dados multinó pode sobreviver a um nó, mas não a uma falha de armazenamento compartilhado ou plano de controle. A replicação de objetos pode sobreviver a um disco, mas não a uma exclusão em escala de conta se cada cópia seguir a mesma autoridade. A diversidade de operadoras pode proteger um circuito, mas não um erro de política de roteamento compartilhada.

A arquitetura deve corresponder à ameaça.

Os clientes downstream também herdam a fronteira da operadora. Se uma empresa de software vende um serviço sobre uma instância hospedada pela Sihe, seus próprios usuários podem nunca saber que a rota pública é originada da China Mobile, que o contrato padrão nomeia a Haining Sihe ou que o endereço está registrado em nome da empresa de Xangai. Durante uma falha, o provedor downstream se torna o tradutor entre uma cadeia de infraestrutura opaca e usuários que precisam de estimativas claras de recuperação. É por isso que a contratação de nuvem pequena não é apenas uma comparação de preços.

É um planejamento de continuidade para todos os níveis abaixo na pilha.

As evidências que esclareceriam o papel de Xangai

A primeira divulgação útil seria uma breve declaração da Sihe Cloud Shanghai Technology Co., Ltd. explicando seu papel atual. Ela opera recursos de rede para o serviço de Haining, detém endereços em nome de uma empresa relacionada, fornece capacidade em Xangai, gerencia um contrato de operadora ou prepara infraestrutura futura? Quais serviços usam 160.19.76.0/23? Por que o AS151217 não é a origem? O 2401:9e20::/32 está planejado para implantação? Respostas claras ligariam os fatos do registro a um propósito operacional sem exigir a divulgação de detalhes sensíveis do cliente.

A segunda seria uma prova de autoridade de rota e resiliência. Uma autorização de origem de rota válida para a origem pretendida melhoraria o sinal de segurança pública. Uma carta de autorização ou um arquivo de operadora equivalente poderia confirmar que o anúncio do AS9808 é intencional. Um diagrama de rede poderia mostrar a demarcação, o caminho de backup, as responsabilidades de filtragem e a cadeia de escalada. O histórico de monitoramento de rota e um resultado de failover controlado mostrariam que o design funciona.

A terceira seria uma declaração limitada sobre instalações e capacidade. Não precisa revelar as coordenadas exatas dos racks. Deve nomear a cidade e a operadora da instalação para cada zona anunciada, distinguir o espaço próprio do espaço alugado, indicar a energia comissionada e a reserva utilizável atual em grandes faixas, identificar se as zonas compartilham um edifício e divulgar o número de entradas de operadoras independentes. Deve separar a capacidade de projeto do equipamento instalado e o equipamento instalado da capacidade de failback disponível para o cliente.

A quarta seriam evidências de recuperação. Publicar ou fornecer sob acordo o método de evacuação de host, a política de capacidade de reserva, a retenção de snapshots e backups, os alvos de recuperação de banco de dados, os domínios de falha da replicação de objetos e os resultados de testes de restauração recentes. Dar aos clientes uma taxa de exportação medida e explicar se a exportação permanece disponível durante suspensão ou rescisão. Indicar quais ações exigem o console e quais podem ser realizadas através de um caminho de suporte de emergência.

A quinta seria uma matriz de responsabilidade entre a empresa de Xangai, o provedor de Haining, a operadora e o operador da instalação. Para incidentes de roteamento, substituição de hardware, relatórios de segurança, suspensão de faturamento, solicitações regulatórias, restituição de dados e rescisão de contrato, deve nomear a parte responsável e o caminho de escalada. Este único documento faria mais pela confiança do cliente do que uma longa lista de recursos, pois exporia as transferências onde o tempo é geralmente perdido.

Veredito: um recurso roteado com uma fronteira de serviço não resolvida

A Sihe Cloud Shanghai Technology Co., Ltd. é mais do que um nome em um arquivo antigo. Ela detém o AS151217, um /23 IPv4 portátil e um /32 IPv6 portátil, todos registrados com contatos consistentes em Xangai e sihe.ai. Seu bloco IPv4 é roteado publicamente, visível globalmente e originado do AS9808 da China Mobile desde junho de 2024. Esta é uma atividade de rede tangível ligada a um recurso que a empresa controla.

As mesmas evidências param antes de mostrar uma rede de Xangai operada de forma independente. O AS151217 não anuncia nada, não tem vizinhos observados e não tem histórico de prefixos visível. A alocação IPv6 está dormente. A rota IPv4 usa o ASN de outra empresa e não tem autorização de origem de rota validada na visão RPKI observada. Nenhuma instalação pública, inventário de racks, transporte de operadora, equipe de suporte ou carga de trabalho de cliente está especificamente vinculada à entidade de Xangai.

O serviço Sihe Cloud ativo adiciona substância comercial, mas não uma atribuição clara. Sua vitrine, console, documentação e contrato demonstram que os clientes podem comprar e operar produtos de nuvem sob o nome Sihe. Eles também identificam a Haining Sihe Cloud Computing Technology Co., Ltd. como a provedora pública e usam uma periferia web voltada para o cliente no espaço China Telecom Sichuan. Os documentos públicos não explicam como o detentor de recursos de Xangai participa.

A nota de evidência resultante é baixa para a cadeia exata entidade-infraestrutura, apesar das fortes evidências para os fatos individuais de registro e rota. Os clientes não devem deduzir que a empresa de Xangai possui um data center, opera três sites independentes, opera uma periferia multioperadora ou assume o SLA de varejo simplesmente porque seu /23 está ativo e seu nome compartilha a marca Sihe. Devem perguntar quem controla a origem, onde os endereços terminam, qual empresa possui ou aluga os racks, quanta reserva de migração existe, quem tem a obrigação de suporte e como os dados saem sob pressão.

Este é o significado físico da capacidade hospedada. Uma máquina virtual pode ser provisionada em minutos, mas sua continuidade sempre depende de um rack energizado, um host disponível, um caminho de armazenamento funcional, uma operadora disposta e capaz de anunciar a rota, um técnico com a peça de reposição correta e um contrato que mantenha os direitos de conta e exportação intactos. Para a Sihe Cloud Shanghai Technology Co., Ltd., a rota IPv4 pública prova que parte dessa cadeia está ativa. Também torna os elos não divulgados impossíveis de ignorar.