Resumo
- O AS131316 apresentava sete anúncios IPv4 visíveis cobrindo 2.048 endereços em 15 de julho de 2026. O PeeringDB listava conexões de troca operacionais de 10 Gbps em Melbourne e Perth e uma conexão EdgeIX de 1 Gbps em Melbourne, enquanto o RIPE RIS via a rede através de 325 de seus 326 pares IPv4.
- A ficha atual de nuvem dedicada começa em 200 AUD mais GST e promete um VPS baseado em CWP com redundância de computação, armazenamento e rede. Ela não identifica a infraestrutura de nuvem, um segundo local de computação, o número de racks, a disposição do armazenamento, o projeto de energia, o pool de hosts de reserva, o objetivo de recuperação nem o resultado testado de failover.
- O mesmo documento de quatro páginas fornece duas descrições de recursos diferentes: pelo menos 2 vCPU, 8 GB de RAM e 50 GB de SSD no início, depois um VPS de 6 núcleos, 16 GB de RAM e 150 GB de SSD em seu resumo final. Um cliente precisa do orçamento e do cronograma de serviço para determinar o que está realmente reservado.
- A operação de rede atual é bem suportada, mas a resiliência da capacidade hospedada não é. A avaliação justa é Médio para a rede visível e Baixo para as evidências públicas de redundância física da nuvem, capacidade de reserva utilizável e restauração do cliente.
O número mais claro está na borda da rede, não dentro da nuvem
A Slnet Hosting possui uma pegada de rede pública mais substancial do que seu nome compacto sugere. Às 08:00 UTC de 15 de julho de 2026, avisão do estado de roteamento para AS131316do RIPEstat contava sete prefixos IPv4, 2.048 endereços anunciados, cinco vizinhos observados e uma visibilidade de 325 dos 326 pares RIS IPv4. A primeira rota observada datava de julho de 2011. Não se trata de um registro adormecido mantido em uma prateleira. É um sistema autônomo de longa data cujas rotas eram quase universalmente visíveis pelos coletores nesse instantâneo.
O registro de interconexão também é específico. Operfil PeeringDBmantido pelo operador lista uma porta 10 Gbps na IX Australia Melbourne, uma segunda porta 10 Gbps na IX Australia Perth e uma porta 1 Gbps na EdgeIX Melbourne. As três entradas estão marcadas como operacionais e incluem todas as endereços de troca IPv4 e IPv6. Alista de entidadesda EdgeIX mostra independentemente o Screw Loose Software, AS131316, em uma conexão de 1 Gbps. Esses registros estabelecem uma borda de rede australiana leste-oeste crível.
Eles não estabelecem a capacidade da nuvem vendida a um cliente. Uma porta de troca é um lugar onde uma rede pode trocar tráfego. Não é uma contagem de hipervisores, uma garantia de replicação de armazenamento, uma reserva de energia ou uma prova de que a carga de trabalho de um cliente pode reiniciar na outra cidade. Somar 10, 10 e 1 para obter um título de 21 Gbps seria aritmeticamente fácil e operacionalmente enganoso. As portas estão em diferentes trocas, podem servir tráfego diferente e podem ser limitadas por trânsito, política de roteamento, links internos, portas de servidor ou a própria carga de trabalho.
O número de hospedagem voltado ao cliente vem de um documento diferente. Aficha de serviço de hospedagem em nuvem dedicadada Screwloose IT de dezembro de 2025 anuncia um contêiner VPS a partir de 200 AUD mais GST por mês. Ela afirma que a plataforma inclui redundância subjacente entre computação, armazenamento e rede. No entanto, não nomeia o data center, o número de salas ou racks independentes, a localização da cópia de backup, o tempo de recuperação, o ponto de recuperação, nem o teste de failover mais recente.
Essa lacuna define a história. A Slnet pode provar uma borda roteada ao vivo. Pode provar que um produto de hospedagem atual existe. O registro público não conecta essas duas camadas em um design de recuperação verificável.
Slnet é o nome da rede dentro de uma empresa australiana de serviços mais ampla
Os nomes em torno do AS131316 precisam ser desembaraçados antes de julgar a propriedade. Oregistro de sistema autônomoda APNIC chama a rede deSLNET-AU, a descreve como Slnet Hosting e identifica o reclamante como Screw Loose Software. O registro está ativo desde 7 de junho de 2011 e foi modificado pela última vez em setembro de 2024. O PeeringDB usa Screw Loose Software como nome da organização e ScrewlooseIT como nome alternativo.
O site comercial atual usa Screwloose IT. Seus documentos de clientes exibem ABN 59 160 395 479. Oregistro ABNdo governo australiano identifica esse número como Australian Client Services Pty. Ltd., uma empresa privada ativa, e lista Screwloose IT e Hostone entre seus nomes comerciais registrados. Em outras palavras, Slnet Hosting é melhor compreendida como a identidade pública de roteamento e hospedagem associada a uma empresa australiana mais ampla de serviços gerenciados de TI, telecomunicações e nuvem. Não deve ser tratada como uma empresa separadamente verificada apenas porque o ASN tem um rótulo distinto.
O histórico de primeira parte fornece um contexto útil. Apágina da empresada Screwloose IT afirma que investiu em presença em data center em 2009 e começou a oferecer hospedagem Exchange, hospedagem de sites e aplicativos web, servidores em nuvem e desktops em nuvem. Afirma que a empresa entrou em telecomunicações em 2013 e posteriormente adquiriu uma presença na Austrália Ocidental através da Host One. Umanúncio separado da Host Oneindica que a aquisição entrou em vigor em 1º de janeiro de 2022 e adicionou uma equipe em Perth e três horas extras de suporte a cada dia através da cooperação entre Perth e Melbourne.
Essas duas páginas não apresentam uma linha do tempo perfeitamente alinhada: um histórico data a expansão para a Austrália Ocidental em 2018, enquanto o anúncio da aquisição dá 2022. A divergência não apaga a rede visível nem o ABN atual. Isso significa que a data exata e a estrutura legal da integração da Host One devem vir de documentos e contratos corporativos, e não de uma linha do tempo de marketing.
Apágina de contatoagora lista escritórios em Osborne Park, Mulgrave, Milton e Bondi. Estes são sinais valiosos de suporte e área de serviço. Não são endereços de datacenters. Um escritório pode abrigar engenheiros e pessoal de contabilidade enquanto os servidores dos clientes estão em uma instalação terceirizada em outro lugar. Nenhum dos escritórios listados deve ser considerado um site de nuvem sem uma declaração de instalação separada.
Esse limite de propriedade conta durante uma falha. A Australian Client Services pode controlar o relacionamento com o cliente, a configuração da plataforma, seus próprios servidores, a política de roteamento do AS131316 e a escalada. Um operador de colocation controla o acesso ao edifício, a distribuição de energia e as mãos remotas. Operadores de trânsito e troca controlam outras partes do caminho. O cliente controla o design do aplicativo, as cópias independentes e a capacidade de se mudar. O nome na fatura não pode remover essas outras dependências.
Dois produtos de hospedagem expõem dois modelos de capacidade muito diferentes
A documentação atual do produto descreve tanto hospedagem compartilhada quanto um contêiner de nuvem dedicado. Aficha de serviço de hospedagem de siteprecifica a hospedagem web compartilhada em 15 AUD mais GST por mês. Ela fornece uma conta CWP, um endereço público compartilhado e uma pilha atual Apache ou Nginx, PHP e MariaDB ou MySQL. A CPU, a memória e as entradas e saídas de disco são compartilhadas entre os clientes. O documento adverte expressamente que o uso intenso de um cliente pode afetar outros, que algumas configurações não podem ser alteradas no nível da conta e que a reputação de e-mail é compartilhada.
Este é um arranjo simples de hospedagem compartilhada. O provedor mantém a disponibilidade do servidor compartilhado, os serviços comuns, a segurança básica e a saúde do servidor. O cliente ou desenvolvedor mantém o site, o código, os plugins, os temas, o uso do banco de dados e as contas administrativas. Correções de SO, reparos de CWP, trabalhos de desempenho, remoção de malware, reparo de site e a maioria das restaurações estão fora do plano de 15 AUD. Migração e restauração sem falha de servidor podem ser adquiridas como serviços profissionais.
O produto dedicado move o limite, mas não o elimina. A ficha de hospedagem em nuvem dedicada descreve um contêiner VPS com um endereço estático dedicado, uma alocação de largura de banda dedicada e isolamento no nível root. Promete pelo menos 2 vCPU, 8 GB de RAM e 50 GB de armazenamento SSD, dimensionados através de um orçamento formal. Também lista um firewall de aplicação web, regras ModSecurity, proteções FirewallD ou CSF, detecção de ataques, registro, monitoramento e reinicializações automáticas de serviço, se necessário.
O provedor aceita a responsabilidade de manter o VPS disponível, operar a CPU, RAM e armazenamento alocados, manter sua infraestrutura de nuvem e manter ativos os controles básicos de segurança. Mas as taxas não incluem correções do sistema operacional, atualizações do CWP, upgrades da pilha do servidor, ajuste de desempenho, hardening mais forte, solução de problemas do site ou resposta a incidentes para uma violação no nível do servidor. A restauração de um site comprometido está fora do escopo, e a restauração a partir de um backup é incluída apenas quando a necessidade decorre de uma falha do servidor.
Isso não é uma crítica a um contrato incomum. A hospedagem é frequentemente dividida em camadas de instalação, plataforma, sistema e aplicação. O ponto importante é que a página de vendas atual chama a oferta da Screwloose de um serviço de nuvem profissional e afirma que especialistas locais fornecem suporte contínuo, enquanto as fichas de inclusões formais traçam uma linha mais estreita em torno das taxas básicas de hospedagem. Um comprador deve decidir se quer um contêiner isolado, um sistema operacional gerenciado, uma aplicação gerenciada, ou os três.
A fatura pode parecer um serviço de nuvem único enquanto a recuperação atravessa várias responsabilidades precificadas separadamente.
As descrições de 2 núcleos e 6 núcleos não podem ambas definir um mesmo mínimo padrão
A ficha dedicada contém um problema de especificação concreto. A seção 2 afirma que cada ambiente dedicado incluirá pelo menos 2 núcleos vCPU, 8 GB de RAM e 50 GB de armazenamento SSD. A seção 6, na última página, resume o plano como um VPS dedicado de 6 núcleos, 16 GB de RAM e 150 GB de SSD. O documento não explica se a configuração maior é um exemplo, um plano revisado, um resíduo específico do cliente ou o produto padrão real.
Isso é importante porque a contabilidade de capacidade começa com a unidade vendida. Se o contêiner básico reserva dois núcleos virtuais e 8 GB, sua densidade de host e economia de preço diferem de um serviço de seis núcleos e 16 GB. Um disco de 50 GB cria um fardo de backup, snapshot e migração diferente de 150 GB. A frase "a partir de" já deixa espaço para orçamentos; o resumo contraditório torna o orçamento essencial em vez de adicional.
Um cliente não deve resolver a divergência a seu favor. Deve solicitar um cronograma de serviço assinado que indique se a CPU é compartilhada, limitada, burstable ou fixada; se "núcleo" significa vCPU ou núcleo físico; se a memória é reservada; se o armazenamento é local ou distribuído; se 50 GB ou 150 GB estão incluídos; e se o endereço estático vem do AS131316. Também deve perguntar o que significa "alocação de largura de banda dedicada" em megabits por segundo, se é uma velocidade de porta ou uma taxa garantida, e quais controles de congestionamento ou uso justo se aplicam.
A divergência também limita qualquer estimativa de capacidade instalada. Os dados de roteamento público fornecem 2.048 endereços, mas um endereço não equivale a um VPS e muitos endereços podem servir roteadores, hosts compartilhados, redes de clientes ou atribuições dormentes. As fichas de produto fornecem recursos por conta, mas não número de hosts. O PeeringDB fornece velocidades de porta, mas não capacidade de fabric do lado do servidor.
A declaração de capacidade defensável é, portanto, estreita. A Slnet possui um pool de endereços roteados real e conectividade de troca declarada. A Screwloose vende pelo menos um nível de hospedagem compartilhada e um nível VPS sob orçamento. O número total de servidores, núcleos virtuais, terabytes, racks e pedidos disponíveis permanece não divulgado.
Sete rotas IPv4 válidas mostram uma operação atual, não capacidade de computação de reserva
O pool de rotas é incomumente ordenado. Aresposta de prefixos anunciadosdo RIPEstat mostrou estas sete rotas continuamente visíveis na janela observada de 1 a 15 de julho:103.4.122.0/24,103.4.123.0/24,103.50.12.0/24,103.50.13.0/24,103.100.199.0/24,103.114.34.0/24e103.172.76.0/23. Juntas, elas contêm 2.048 endereços IPv4.
Os registros da APNIC revelam o histórico por trás do conjunto. Os registros103.4.122.0/24e103.4.123.0/24carregam o nome SLNET.103.50.13.0/24está registrado sob Hostone Pty Ltd.103.114.34.0/24nomeia Screw Loose Software. A alocação103.172.76.0/23nomeia Australian Client Services Pty Ltd. Outro /24 visível é retirado de um bloco registrado sob Bottle Communications. Esses rótulos são consistentes com uma rede montada através de nomes operacionais e títulos de propriedade de endereços adquiridos ou vinculados, mas não provam por si mesmos o contrato atual que rege cada bloco.
As sete verificações de origem retornaram válidas no RIPEstat quando testadas contra AS131316. Por exemplo, avalidação 103.172.76.0/23encontrou uma autorização de origem de rota correspondente com comprimento máximo de /23. Um RPKI válido é valioso: permite que redes de pares rejeitem uma origem não autorizada para a rota coberta. Ele não mantém o roteador autorizado ligado, não evita uma política ruim, não adiciona largura de banda e não restaura um servidor com falha.
A borda pública também não tinha espaço IPv6 originado no instantâneo do RIPE. Isso é notável porque cada entrada de troca do PeeringDB inclui uma interface IPv6. Um endereço IPv6 em uma LAN de troca mostra que o roteador pode participar dela; não é o mesmo que originar prefixos IPv6 de clientes. Um comprador que precisa de IPv6 nativo deve solicitar uma alocação específica ao serviço e testá-la, em vez de inferir disponibilidade a partir das linhas de troca.
As sete rotas são uma evidência sólida de que o operador permanece ativo. Elas não podem dizer a um comprador quantos endereços estão livres, quanto inventário de servidor está disponível por trás deles, se os pools de endereços de Perth e Melbourne correspondem a computação separada, ou se o endereço de um cliente pode se mover durante uma falha de site.
Três linhas de troca não são um mapa rodoviário físico
O PeeringDB rotula as conexões de troca de 10 Gbps de Melbourne e Perth como operacionais, e a entrada mais recente da EdgeIX Melbourne foi atualizada em março de 2026. Avisão das entidades WA-IXda Packet Clearing House também lista AS131316 em27.106.192.207, fornecendo corroboração independente da identidade de troca de Perth. A rede está claramente representada em ambas as cidades.
O que está ausente é igualmente importante. A API do PeeringDB não retorna nenhum registro de instalação para AS131316. Isso não prova que a rede não possui racks ou não aluga colocation. O PeeringDB é autogerenciado e incompleto. Significa apenas que o perfil público não identifica os edifícios onde estão localizados os roteadores ou os sistemas de hospedagem da Slnet. Os nomes de troca identificam os tecidos metropolitanos, não as suítes exatas, as fontes de energia ou os caminhos de cabos.
Uma conexão de troca pode ser entregue de várias maneiras. Um roteador pode estar em uma das instalações listadas da troca. Um operador pode estender a LAN da troca através de transporte para outro edifício. Um revendedor pode fornecer uma conexão virtual. Uma única porta física pode transportar vários serviços lógicos. Sem registro de instalação ou declaração do operador, uma linha de troca deve ser tratada como uma presença metropolitana lógica com uma velocidade de porta declarada, não uma rota traçada através de um edifício nomeado.
O mesmo cuidado se aplica à geolocalização dos endereços. O IPinfo coloca os endereços AS131316 responsivos em Melbourne e Perth e observou um caminho curto recente para103.172.76.1de uma sonda em Perth. Isso é um sinal de mercado útil. As bases de dados de geolocalização podem ser baseadas em registro, latência, roteamento e submissões do operador, e podem estar erradas no nível do edifício ou mesmo da cidade. Um resultado de sonda mostra um ponto final de rede respondendo com baixa latência de um local; não mostra o rack que contém os discos do cliente.
Os escritórios da Screwloose não podem preencher a lacuna. Um escritório de suporte em Osborne Park não é automaticamente o site do roteador WA-IX. Um escritório em Mulgrave não é automaticamente a nuvem de Melbourne. A declaração de 2009 sobre presença em data center estabelece que a empresa entrou na infraestrutura hospedada, mas não nomeia uma instalação atual. A aquisição da Host One apoia uma presença comercial e de rede na Austrália Ocidental, mas não especifica que os contêineres VPS se replicam entre Perth e Melbourne.
O mapa que pode ser desenhado de forma responsável tem dois nós de rede no nível da cidade, Melbourne e Perth, mais quatro escritórios comerciais. Não pode incluir uma instalação de nuvem exata, uma rota de dados do cliente ou uma linha de failover entre cidades. Estes permanecem questões de provisionamento.
A redundância deve ser anexada a um domínio de falha
"Redundância da infraestrutura subjacente" parece completa porque nomeia computação, armazenamento e rede. Para tornar a frase operacional, cada camada precisa de um componente independente e uma falha definida que ela deve sobreviver.
Redundância de computação pode significar um host físico de reserva, um cluster que pode reiniciar um contêiner, migração ao vivo, ou simplesmente múltiplas fontes de alimentação em um único chassi. Esses designs têm resultados diferentes. Um host de reserva pode absorver uma falha apenas se tiver CPU, memória, acesso a armazenamento e configuração de rede compatíveis suficientes. A migração ao vivo ajuda durante a manutenção planejada, mas pode não ajudar após uma falha súbita de host ou armazenamento. Dois hosts no mesmo rack ainda compartilham a energia e a comutação do rack.
Redundância de armazenamento pode significar discos espelhados, RAID, volumes replicados, snapshots ou backups. O espelhamento pode sobreviver a uma falha de disco, mas replica imediatamente a corrupção. Um snapshot pode proteger contra uma alteração errônea, mas permanece no mesmo array. A replicação pode melhorar a disponibilidade, mas mantém a mesma dependência do operador e da conta. Um backup só se torna útil quando pode ser restaurado com as aplicações, configurações, credenciais e configuração de rede necessárias para a retomada do serviço.
Redundância de rede pode significar links duplos, dois switches, dois roteadores, provedores de acesso separados ou entradas de edifício fisicamente diversas. As três portas de troca do PeeringDB criam opções úteis, e avisão dos vizinhosdo RIPEstat observou Kinetix Networks, Simtronic, Hurricane Electric e dois vizinhos de menor confiança. Mas a adjacência BGP observada não revela os contratos, a participação de tráfego, os caminhos de fibra ou se o failover foi testado. Dois provedores de acesso lógicos podem compartilhar uma fila de transportadora ou um domínio de energia.
Redundância de energia não é descrita na ficha de hospedagem. O material público não especifica o número de alimentações elétricas, a topologia do UPS, a autonomia do gerador, a densidade de potência dos racks ou se o equipamento da Slnet usa alimentações A e B. Estes são normalmente fatos no nível da instalação e podem estar disponíveis sob confidencialidade, mas não podem ser inferidos de uma conexão de troca.
A pergunta relevante do cliente não é "É redundante?" Mas "Quais falhas únicas este serviço pode sobreviver sem ação do cliente, e o que acontece após duas falhas relacionadas?" Uma resposta útil nomeia o host primário e secundário, a cópia de armazenamento, o rack e a instalação, o gatilho da reinicialização, o intervalo de perda de dados esperado, o tempo de restauração previsto e o último exercício bem-sucedido. Nenhum documento público da Slnet fornece essa cadeia.
O primeiro caminho de falha começa dentro do VPS
Uma aplicação hospedada pela Slnet pode falhar enquanto o AS131316 permanece perfeitamente visível. O sistema operacional convidado pode travar. Um sistema de arquivos cheio pode parar um banco de dados. Um componente CWP não corrigido pode ser comprometido. Um plugin do site pode esgotar a memória. Um certificado pode expirar. Nesses casos, os roteadores, a energia da instalação e o host físico podem estar todos saudáveis.
A ficha de serviço dedicado traça esse limite claramente. O provedor monitora a alcançabilidade básica e mantém as ferramentas básicas de firewall ativas, mas as correções do sistema operacional, atualizações do CWP, upgrades da pilha web, ajuste proativo e hardening mais forte não estão incluídos. A recuperação após comprometimento no nível do site também está fora das taxas básicas. Um cliente que pensava que "hospedagem em nuvem profissional" incluía administração de sistema gerenciada pode descobrir a diferença durante o incidente.
O segundo caminho de falha é o host. Uma CPU, módulo de memória, placa-mãe, placa de rede, disco, controlador ou fonte de alimentação pode falhar. O registro público não divulga quantos hosts existem, se os discos do cliente são locais, se um cluster pode reiniciar um contêiner em outro lugar, quanta memória reservada é mantida livre, ou se peças sobressalentes estão no local. A reinicialização automática de serviço é útil para um processo travado; não é prova de que um chassi com falha pode ser substituído dentro de um prazo.
O terceiro caminho é o armazenamento compartilhado ou pool de servidores. Um VPS dedicado pode ter recursos convidados reservados enquanto compartilha os arrays de armazenamento, switches e sistemas de controle com outros contêineres. Uma conta de hospedagem compartilhada vai além: a ficha do produto afirma explicitamente que os clientes compartilham CPU, memória e entrada/saída de disco, e um usuário pesado pode afetar outros. A pressão sobre a capacidade pode, portanto, aparecer como páginas lentas, consultas de banco de dados atrasadas ou falhas de e-mail antes de aparecer como uma falha completa.
O quarto caminho é o rack e a instalação. Um disjuntor, uma unidade de distribuição de energia, um evento de resfriamento, uma restrição de acesso ou um erro de manutenção pode afetar vários hosts ao mesmo tempo. A redundância dentro de um chassi é inútil se ambas as fontes de alimentação usam a mesma fonte. Um host de reserva no mesmo rack pode estar indisponível durante uma falha de rack. Sem um segundo domínio de falha nomeado, a reivindicação pública de redundância deve ser tratada como local a uma arquitetura não divulgada.
Nenhum desses riscos prova uma má operação. Eles definem as evidências de que um comprador sério precisa. Os documentos atuais da Slnet estabelecem as responsabilidades e as características do produto. Eles não publicam o histórico de falhas, as métricas de status ou os resultados de restauração cronometrados que mostrariam como as camadas se comportam sob estresse.
Backups são prometidos no marketing e atribuídos ao cliente nos termos
Apágina de serviços em nuvemda Screwloose afirma que a nuvem está sempre com backup e coloca a redundância no centro da solução. O material de migração mais amplo recomenda cópias imutáveis, objetivos de tempo de recuperação e ponto de recuperação acordados, restaurações de teste de rotina e planos de restauração. Estas são práticas sensatas.
Os documentos legais e de produto são mais condicionais. OsTermos e Condições Geraisestipulam que o cliente é o único responsável por fazer backup e proteger os dados conectados ou fornecidos com o serviço. A ficha dedicada exclui a restauração de um site a partir do backup, a menos que a necessidade decorra de uma falha do servidor. A ficha compartilhada também limita as restaurações incluídas e torna outras restaurações faturáveis.
Essas declarações podem coexistir se o serviço mantiver cópias de infraestrutura enquanto o cliente permanece responsável pela continuidade dos negócios. Mas os documentos públicos não definem a distinção. Eles não especificam a frequência do backup, retenção, criptografia, imutabilidade, localização, suporte, separação de contas, largura de banda de restauração ou cronograma de exclusão. Eles não dizem se "sempre com backup" se aplica a cada VPS, apenas a compromissos gerenciados, ou apenas a certas classes de dados.
Oguia de avaliação Essential Eightdo Centro Australiano de Segurança Cibernética distingue ter cópias da prova de restauração. Ele pergunta se os dados, aplicações e configurações podem ser restaurados para um ponto comum no tempo e se a recuperação completa ou parcial foi exercitada. Esta distinção é diretamente relevante aqui. Uma cópia de disco sem a configuração correta do CWP, estado do banco de dados, DNS, chaves e regras de firewall pode não recriar um serviço funcional.
Um cliente da Slnet deve fazer duas perguntas. Primeiro, qual cópia o provedor mantém para se recuperar de sua própria falha de host ou armazenamento? Segundo, qual cópia o cliente pode recuperar independentemente se o provedor, conta ou instalação estiver indisponível? A segunda cópia deve incluir dados e configuração suficiente para reconstruir em outra plataforma. Deve ser testada fora da conta de hospedagem principal.
Sem essas respostas, a interpretação mais segura é conservadora: a redundância do provedor pode melhorar a disponibilidade normal, mas o cliente permanece dono da continuidade. Esta é também a posição mais consistente com os termos e condições publicados.
A diversidade de roteamento só ajuda quando o servidor é alcançável a partir da borda
As relações de rede observadas do AS131316 reduzem a probabilidade de que uma única adjacência lógica seja toda a borda pública. O RIPEstat viu dois vizinhos de alto poder à esquerda, AS134143 e AS55707, mais Hurricane Electric e duas relações incertas. O PeeringDB mostra participação no servidor de roteamento em todas as três trocas. As autorizações de origem de rota públicas cobrem todos os sete prefixos visíveis. Esta é uma postura de roteamento mais forte do que um pequeno host com um bloco de endereços atribuído por um provedor e sem AS independente.
No entanto, cada verificação de rede responde a uma pergunta limitada. O RPKI ajuda outras redes a distinguir uma origem autorizada. Não impede a Slnet de retirar uma rota ou anunciar um caminho ruim. Um servidor de roteamento de troca ajuda a estabelecer muitos peers eficientemente, mas não substitui o trânsito pago para toda a Internet. Uma porta de 10 Gbps pode transportar tráfego de troca local enquanto o tráfego do cliente para outro destino usa um caminho de trânsito menor ou congestionado. Uma borda em Perth e uma borda em Melbourne ainda podem depender de um único plano de controle interno ou de um único contrato de provedor.
OsTermos e Condições Geraisreconhecem diretamente o limite do provedor. Eles permitem que a Screwloose use e varie uma mistura de sua própria infraestrutura e de terceiros, dizem que o serviço pode depender de equipamentos e arranjos de terceiros, e permitem a rescisão se um terceiro parar de fornecer um serviço necessário. Eles também isentam de responsabilidade, na medida permitida por lei, por falhas na infraestrutura de rede de terceiros.
Para um cliente hospedado, a resiliência de roteamento deve ser testada da carga de trabalho para fora. O VPS está duplamente conectado a roteadores de borda separados? Esses roteadores estão no mesmo edifício? O prefixo do cliente aparece em ambas as relações de trânsito? Uma rota pode se mover entre cidades sem mover o servidor? A mitigação de DDoS introduz outra dependência? Existe um console fora de banda quando a rota pública falha?
O IPv6 merece seu próprio teste. As interfaces de troca do PeeringDB são dual-stack, mas o RIPEstat não viu nenhum prefixo IPv6 originado em 15 de julho. Um cliente não deve supor que seu VPS tenha IPv6 roteado globalmente apenas porque o roteador de borda tem um endereço de troca. O pedido deve indicar o prefixo atribuído, a origem e o limite de suporte.
O registro de rede pública da Slnet é bom o suficiente para fazer perguntas precisas. Não é detalhado o suficiente para respondê-las em nome do operador.
O reparo depende de pessoas, escopo e relógio
A Screwloose apresenta o suporte local como um diferenciador. A página de nuvem afirma que especialistas gerenciam a migração e o suporte contínuo, e que o horário do helpdesk é de segunda a sexta, das 9h às 17h. O anúncio da aquisição da Host One afirma que as equipes de Perth e Melbourne estendem a cobertura de suporte diário em três horas. A página de contato atual lista a mesma janela de escritório durante a semana em quatro cidades.
OSLA de Serviços de TI Gerenciadospublicado adiciona detalhes para clientes que compram esse serviço. O suporte regular remoto e por e-mail funciona das 9h às 17h, horário da Austrália Ocidental. Chamadas após o horário são encaminhadas para um celular, se possível, e tratadas com o melhor esforço, com um serviço de resposta externa como backup. Incidentes urgentes têm um objetivo de resposta de zero a quatro horas úteis, enquanto prioridades médias e baixas podem levar mais tempo. O primeiro domingo de cada mês é reservado para manutenção do sistema com aviso prévio se houver expectativa de interrupção.
Este SLA não é automaticamente o SLA de hospedagem. Ele rege um acordo de serviços de TI gerenciados nomeado e pode ser substituído por um cronograma específico do cliente. A ficha VPS dedicada oferece monitoramento básico, mas não publica nenhuma prioridade de incidente, tempo de confirmação de recebimento, objetivo de restauração, crédito de serviço ou compromisso de engenheiro 24 horas para o produto de hospedagem em si.
Oprocedimento de tratamento de reclamaçõesfornece escalonamento para defeitos, serviço, acordos e faturamento. Promete confirmação de recebimento imediata quando um representante atende por telefone e confirmação de recebimento em até dois dias úteis para e-mails ou mensagens gravadas, seguido de escalonamento ao gerente, se necessário. Este é um caminho útil para os direitos do cliente. Não é um canal de reparo de emergência e não deve ser confundido com tal.
Quando um host falha às 2h da manhã de um sábado, os fatos decisivos são práticos: o monitoramento alerta um engenheiro; esse engenheiro pode acessar o hipervisor e o armazenamento; mãos remotas estão disponíveis na instalação; hardware compatível está no local; quem pode autorizar um failover; e como o cliente é informado? Um helpdesk de segunda a sexta pode coexistir com recuperação automatizada e engenharia de plantão, mas os documentos de hospedagem públicos não definem esse arranjo.
A força de trabalho de suporte é uma capacidade. Um engenheiro pode lidar com uma reinicialização de rotina. Um evento de instalação ou roteamento pode produzir muitas chamadas simultâneas, exigir escalonamento de provedor e consumir as mesmas pessoas que se comunicam com os clientes. A superfície de escritório nacional da Slnet é um sinal positivo. O tamanho da equipe, a profundidade do plantão e os procedimentos de emergência permanecem não divulgados.
Faturamento e contratos de provedor podem parar um servidor saudável
Nem toda falha começa com hardware quebrado. Os Termos e Condições Gerais da Screwloose permitem que ela restrinja, suspenda ou rescinda o serviço quando dinheiro é devido. Eles também permitem a rescisão se um terceiro necessário parar de fornecer o serviço. Essas cláusulas criam dois caminhos de falha não técnicos: a conta do cliente e a cadeia de suprimentos do provedor.
Uma suspensão por faturamento pode tornar um VPS saudável inacessível. Uma fatura contestada, um cartão expirado ou um erro administrativo podem levar ao mesmo sintoma visível para o cliente que uma falha de roteador. Os termos preveem um caminho para contestação de faturamento e exigem que os valores não contestados sejam pagos. Eles não especificam se a exportação de emergência de dados permanece disponível durante uma disputa ou suspensão.
O caminho do provedor é igualmente importante. A Slnet pode possuir roteadores e servidores enquanto aluga espaço em rack, energia, fibra, trânsito ou mãos remotas. Um contrato de instalação, uma fatura de transportadora ou uma retirada comercial podem forçar uma migração sem que nenhum equipamento falhe. O uso de infraestrutura de terceiros pela Screwloose é explícito em seus termos. Os materiais públicos não nomeiam a instalação de nuvem ou os provedores, portanto os clientes não podem avaliar a concentração, a duração do contrato ou as opções de substituição apenas a partir do site.
O histórico da Host One mostra por que a continuidade dos negócios é importante. As operações e o espaço de endereçamento da Austrália Ocidental aparecem na pegada atual do AS131316, mas as páginas públicas oferecem datas diferentes para a integração. Isso não sinaliza um problema presente. Ilustra como as combinações de empresas podem mover pessoas, endereços e serviços de clientes através de fronteiras organizacionais enquanto o nome da rede permanece estável.
A proteção relevante é um contrato que separa o acesso aos dados de uma disputa de conta, define um aviso prévio antes de uma retirada planejada, indica quanto tempo os dados são mantidos após a rescisão e exige assistência razoável para migração. Um cliente também deve manter informações de contato atuais, métodos de pagamento e contatos de escalonamento fora do ambiente hospedado. Se o único cofre de senhas, sistema de e-mail ou portal de suporte está hospedado no serviço afetado, a recuperação administrativa se torna mais difícil.
A economia da nuvem muitas vezes torna essas dependências invisíveis durante a operação normal. O cliente paga um valor mensal único, enquanto o provedor paga vários fornecedores e aloca pessoal limitado. A continuidade depende de cada elo permanecer disponível ou substituível dentro da tolerância do cliente.
A portabilidade para no endereço, a menos que o contrato diga o contrário
Oplaybook de migração para nuvemde 2026 da Screwloose recomenda inventário, perfil de desempenho, objetivos de recuperação, cópias imutáveis, grupos piloto, cortes progressivos, sincronização delta e um caminho de retorno testado. Ele também afirma que as cargas de trabalho e os backups devem permanecer nas regiões australianas quando a localidade é importante. Este é um conselho de migração sensato.
As fichas de inclusões de hospedagem tornam a migração uma atividade paga ou separadamente contratada. A migração de hospedagem compartilhada pode atrair taxas de serviços profissionais. A ficha dedicada afirma que o gerenciamento da aplicação pertence ao cliente ou ao desenvolvedor. Isso significa que uma mudança da Slnet para outro provedor pode exigir tanto a cooperação da infraestrutura quanto o trabalho da aplicação.
Os endereços IP são particularmente claros. A cláusula 12 dos Termos e Condições Gerais afirma que um endereço é emitido apenas durante o serviço, o direito do cliente de usá-lo termina na rescisão, e a Screwloose controla o roteamento associado e a delegação de DNS. Um cliente normal não pode, portanto, assumir que um endereço estático do AS131316 seguirá seu VPS para outro lugar.
As consequências vão além do DNS. Os parceiros podem colocar o endereço antigo na lista de permissões. A reputação de e-mail pode estar vinculada a ele. Logs de segurança, certificados, regras de firewall, sistemas de pagamento e APIs remotas podem depender dele. Clientes de hospedagem compartilhada enfrentam um limite adicional de reputação, pois a ficha do serviço afirma que eles compartilham o endereço público e a reputação de e-mail com outras contas.
Um teste prático de saída deve reconstruir uma carga de trabalho representativa em um provedor independente usando um novo endereço. Deve restaurar dados atuais, girar credenciais, atualizar DNS, substituir listas de permissões, validar e-mail de saída, verificar monitoramento e medir o tempo decorrido. O cliente deve saber quais artefatos podem ser exportados: dumps de banco de dados, arquivos web, imagens de disco virtual, configuração do CWP, zonas DNS, logs, certificados e arquivos de backup.
O registro público não diz se uma imagem VPS da Slnet é exportável, se snapshots existem, ou quão rápido um disco completo pode ser recuperado. Diz que o cliente possui os backups e o gerenciamento da aplicação. Até que o pedido diga mais, a portabilidade deve ser projetada pelo cliente, em vez de assumida a partir da palavra nuvem.
O perímetro australiano é visível; a localidade da carga de trabalho não
Cada sinal de identidade forte aponta para a Austrália. A APNIC atribui ao AS131316 um código de país australiano. O PeeringDB indica que seu perímetro geográfico é a Austrália. O ABN está ativo, a empresa tem nomes comerciais australianos e os escritórios públicos cobrem Austrália Ocidental, Victoria, Queensland e Nova Gales do Sul. A borda de roteamento é declarada em Melbourne e Perth. O material atual de migração e hospedagem da Screwloose discute repetidamente empresas australianas e residência de dados australiana.
Isso apoia um perímetro operacional australiano. Isso não prova onde reside cada carga de trabalho, backup, log ou sistema de suporte. Um código de país de registro descreve o detentor do recurso, não o servidor. Uma cidade de troca descreve a interconexão, não o armazenamento. Um escritório descreve a presença comercial, não um rack. Mesmo um VPS primário australiano pode ter um backup no exterior, um serviço de monitoramento, um relé de e-mail ou uma ferramenta de suporte.
A distinção importa sob regras de privacidade e provisionamento. Oguia APP 8do Escritório do Comissário de Informação Australiano explica que uma entidade australiana pode permanecer responsável quando divulga informações pessoais a um destinatário no exterior. Ele também distingue a divulgação de certos usos estritamente controlados por contratados e aponta para os termos do contrato, acesso, recuperação, exclusão e subcontratados como fatos relevantes. Simplesmente comprar de uma empresa australiana não responde a essas perguntas.
A própriacomparação de hospedagem em nuvemda Screwloose aconselha os clientes a confirmar que os backups, logs e ferramentas de suporte permanecem locais, não apenas o servidor principal. Esta é exatamente a divulgação que falta na ficha VPS dedicada. A página explica o teste correto de diligência, mas não publica um cronograma de localização para o produto da Slnet.
Um cliente regulamentado ou sensível à localidade deve perguntar pelo país e estado da instalação primária, a localização da cópia secundária, os países de acesso ao suporte, os subcontratados, os locais de monitoramento e registro, e o que muda durante o failover. Ele também deve perguntar se Melbourne e Perth são ambos locais de computação contratáveis ou apenas locais de rede. Se o serviço falhar para outra plataforma, a localização e o controlador contratual podem mudar no momento em que a localidade mais importa.
Um provedor pode vender além da Austrália sem operar uma nuvem distribuída globalmente. As evidências públicas apoiam uma rede australiana e uma empresa de serviços australiana. Não apoiam um parque de computação multi-país.
A economia recompensa o uso, enquanto a resiliência consome capacidade ociosa
A 15 AUD por mês, a hospedagem compartilhada opera por mutualização. Muitos sites pequenos compartilham um servidor, um endereço, uma reputação de e-mail, uma pilha de software e uma estrutura de suporte. A 200 AUD e acima, o produto VPS compra mais isolamento e uma alocação de recursos maior, mas ainda está em infraestrutura física compartilhada, a menos que o pedido indique o contrário. Nenhum preço pode ser compreendido sem uso.
Os provedores recuperam o custo de servidores, armazenamento, espaço em rack, energia, trânsito, endereços, software e mão de obra vendendo fatias do parque instalado. Capacidade ociosa é cara. Um host de reserva rende pouco até que algo falhe. Uma segunda cidade requer equipamento, licenças, conectividade e manutenção mesmo quando os clientes não a estão usando ativamente. A retenção de backups consome armazenamento; restaurações de teste consomem pessoal e computação temporária. Uma resiliência autêntica tem, portanto, um custo que pode não caber no plano mais barato.
O pool de endereços e a presença de troca da Slnet lhe dão economias úteis. Ela pode rotear seus próprios blocos, fazer peering localmente em dois mercados e distribuir a engenharia de rede entre hospedagem, Internet e outros serviços gerenciados. A integração da Host One também pode distribuir o suporte entre fusos horários na Austrália. Estas são vantagens plausíveis ancoradas em ativos visíveis.
As restrições são igualmente ancoradas. A hospedagem compartilhada admite efeitos de vizinho barulhento. A ficha dedicada deixa seus recursos básicos inconsistentes. O perfil de tráfego no PeeringDB é de apenas 100-1000 Mbps e foi atualizado pela última vez em 2024, bem abaixo da soma das velocidades de porta declaradas; porque os níveis de tráfego são faixas autodeclaradas e as velocidades de porta são máximos, nenhum número prova a carga atual. O registro público não fornece nenhuma capacidade vendida, reservada ou livre.
Para um cliente, a comparação correta não é simplesmente 15 AUD contra 200 AUD. É o custo para atingir um objetivo de disponibilidade. Um pequeno site vitrine com backups externos e sem dependência de receita pode racionalmente aceitar hospedagem compartilhada. Uma aplicação de negócios pode exigir um SO gerenciado, backup independente, um ambiente secundário, resposta após o expediente e recuperação testada. Esses acréscimos podem exceder o preço base da computação, mas compram as camadas que transformam um VPS em um plano de continuidade.
O serviço mais barato não é necessariamente ruim, e o mais caro não é automaticamente resiliente. A chave é saber se o preço inclui as falhas que o cliente não pode absorver.
O que os clientes devem pedir à Slnet para demonstrar
O primeiro pedido deve ser um cronograma de serviço corrigido. Deve resolver o desacordo entre 2 vCPU e 6 núcleos, indicar a memória reservada e a capacidade SSD, definir a largura de banda dedicada, identificar os limites de virtualização e armazenamento, e listar cada opção de suporte paga necessária para correções, resposta a incidentes e restauração.
O segundo deve ser um cronograma de localização. Deve distinguir escritórios, pontos de rede e locais de computação. Para cada local de nuvem ativo, deve nomear o operador da instalação, o estado ou país, se a Slnet possui ou aluga o hardware, e se um segundo local está disponível para cargas de trabalho de clientes. Se os nomes das instalações não puderem ser tornados públicos, ainda podem ser divulgados sob contrato com o cliente.
O terceiro deve ser uma declaração de domínio de falha. Quais componentes são duplicados? Os hosts estão espalhados por racks? A replicação de armazenamento atravessa racks ou instalações? Os caminhos de rede saem por transportadoras e entradas de edifício separadas? Alimentações A e B são usadas? Qual falha aciona uma reinicialização automática, e qual requer uma pessoa?
O quarto deve documentar a capacidade operacional. Um comprador não precisa de inventário sensível ao cliente, mas pode perguntar pela política de margem atual, metas de hosts de reserva, limites de espaço livre de armazenamento, política de uso de portas, estoque de reposição de hardware e as condições sob as quais novos pedidos são atrasados. Equipamento instalado, equipamento ligado, equipamento operacional e capacidade imediatamente utilizável devem ser separados.
O quinto deve ser um resultado de recuperação. Pergunte pela data e escopo da mais recente evacuação de host, restauração de armazenamento e exercício no nível do site. Pergunte pelo tempo de recuperação medido e perda de dados, quaisquer etapas manuais, e se o teste usou uma cópia fora da conta primária e do domínio de falha.
O sexto deve cobrir a rede. Pergunte qual provedor upstream transporta o prefixo do cliente, se Melbourne e Perth são fisicamente independentes, como os controles de origem de rota e vazamento de rota são mantidos, se IPv6 nativo está disponível, e como um endereço muda durante a recuperação. As portas de troca devem ser tratadas como evidências de apoio, não a resposta completa.
O sétimo deve definir a cobertura humana. Qual número é atendido fora do horário para uma falha de hospedagem? Quem tem acesso à instalação? Quais objetivos de confirmação de recebimento e restauração se aplicam? Quando são as janelas de manutenção, qual aviso é dado, e quais créditos de serviço se aplicam?
O oitavo deve cobrir a saída. O cliente pode exportar uma imagem completa, banco de dados, zona DNS, logs e backups? Por quanto tempo os dados são retidos após cancelamento ou suspensão? A exportação pode continuar durante uma disputa de faturamento? Quais endereços, licenças e configurações do painel de controle não podem ser movidos?
O nono deve tratar da localidade. Onde os dados de produção, backups, logs e ferramentas de suporte estão armazenados? Quem pode acessá-los de fora da Austrália? Quais subcontratados estão envolvidos? O failover muda a jurisdição?
O décimo deve ser um teste realizado pelo cliente. Construa uma pequena carga de trabalho, meça rotas e latência, force uma reinicialização da aplicação, restaure a partir de uma cópia independente e reconstrua em outro lugar. Uma demonstração comercial bem-sucedida mostra que um serviço pode iniciar. Um exercício de recuperação mostra se ele pode voltar.
Uma borda australiana ativa envolve uma nuvem incompletamente descrita
A Slnet Hosting não deve ser descartada como um nome sem substância operacional. O AS131316 está ativo e é de longa duração. Sete anúncios IPv4 eram quase universalmente visíveis na data de publicação. As sete origens verificadas eram válidas em RPKI. Os registros de peering mostram conexões de troca operacionais em Melbourne e Perth, e a EdgeIX corrobora independentemente a presença de 1 Gbps em Melbourne. A empresa atual tem um ABN ativo, escritórios nacionais, publicações atuais de 2026 e ofertas explícitas de hospedagem compartilhada e dedicada.
A incerteza começa onde começa a resiliência do cliente. O PeeringDB não nomeia nenhuma instalação para a rede. Os documentos de hospedagem não nomeiam nenhum local de nuvem. A ficha dedicada promete computação, armazenamento e rede redundantes, mas não fornece topologia nem teste. Seu próprio resumo de recursos entra em conflito com sua especificação mínima. O material público não divulga o número de racks, número de hosts, armazenamento bruto ou utilizável, energia, uso atual, peças sobressalentes, capacidade vendida, retenção de backups, resultados de restauração ou um segundo local de computação contratável.
Isso produz uma avaliação dividida. A operação de rede merece uma nota Média nas evidências, aproximando-se de Forte em visibilidade de rota e identidade, mas prejudicada pela falta de detalhes sobre instalação e caminho físico. A resiliência da capacidade hospedada merece uma nota Baixa, pois os fatos físicos e de recuperação decisivos não estão disponíveis. Nenhuma nota prevê uma falha. Elas medem o que um cliente pode verificar antes de uma falha.
A distinção mais importante é entre alcance e recuperação. A Slnet demonstrou alcance: seus prefixos são visíveis e suas portas de troca cobrem duas metrópoles australianas. A recuperação requer um conjunto diferente de evidências: computação de reserva compatível, cópias de armazenamento independentes, separação de energia e roteamento, pessoas com acesso, um relógio definido e um caminho de saída para o cliente. Até que esses detalhes sejam anexados ao VPS de 200 AUD, a promessa hospedada permanece dependente de uma infraestrutura que o público só pode ver em sua borda de rede.