Sumário

  • A SIANET pode ser vinculada a uma empresa brasileira ativa, AS53101, espaço de endereço público, dois provedores de trânsito observados e uma conexão de 10 Gbps no IX.br São Paulo, dando aos compradores mais para inspecionar do que uma descrição genérica de serviço em nuvem.
  • O ônus restante da aquisição é substancial: as páginas públicas da SIANET afirmam uma meta de uptime de 99,9%, energia redundante e suporte 24 horas, mas não publicam as regras de medição, créditos de serviço, histórico de incidentes, objetivos de recuperação, evidências de teste de restauração ou metas de resposta necessárias para transformar essas afirmações em garantia operacional.

Um ASN visível muda o ponto de partida, não o veredito

A parte mais difícil de avaliar um provedor de infraestrutura pequeno ou regional é muitas vezes decidir se o nome público corresponde a um sistema operacional. A SIANET supera esse primeiro obstáculo. A página da empresa na Serasa Experian identifica a SIANET Data Center Provedores Ltda sob CNPJ 10.470.642/0001-08, registra status ativo e data de fundação em novembro de 2008, e classifica sua atividade principal como processamento de dados, provisão de serviços de aplicação e hospedagem na internet. O site da empresa usa a marca SIANET Business Hosting e fornece um endereço em São Paulo e número de telefone.

O PeeringDB conecta o nome mais longo SIANET Data Center e Provedores Ltda-ME ao mesmo site e ao AS53101.

Essa cadeia de identidade importa porque a aquisição de serviços em nuvem está cheia de sinais suaves: um domínio polido, um amplo menu de serviços, um rótulo de data center e uma equipe de conta. A SIANET também deixa rastros técnicos mais duros. No momento da revisão, o bgp.tools mostrava o AS53101 como uma rede ativa alocada sob o NIC.br, originando dois agregados IPv4: 177.107.208.0/21 e 187.103.144.0/20. Seu material de registro vincula o ASN e esses recursos ao mesmo CNPJ. O PeeringDB lista a rede no IX.br São Paulo com uma porta de 10 Gbps, um contato de operações de rede nomeado, uma política de peering aberta e escopo regional.

A visão de roteamento também mostrou dois upstreams, AS4230 da Claro e AS10429 da Telefônica Brasil. Esta é uma evidência útil de uma superfície de conectividade real e alguma diversidade de upstream. Não é prova de que cada serviço hospedado está corretamente dual-homed, que a capacidade é suficiente durante um incidente, ou que o tráfego do cliente fará failover dentro de um intervalo aceitável.

Uma equipe de aquisição deve, portanto, tratar o ASN como um artefato inicial para due diligence técnica: solicitar exportações de rotas atuais, compromissos de trânsito, folga de tráfego, procedimentos de manutenção e uma explicação de como os serviços do cliente são mapeados na rede visível.

Há uma razão adicional para insistir em um instantâneo de rede datado. O perfil auto-mantido do PeeringDB lista dez prefixos IPv4 e dois prefixos IPv6, enquanto a visão de roteamento independente observou dois agregados IPv4 originados e nenhum IPv6 originado no momento da revisão. Esses valores podem descrever coisas diferentes, incluindo limites de prefixo configurados versus rotas então visíveis na internet. A diferença não é em si evidência de uma falha. É evidência de que um campo de perfil não deve ser confundido com o estado atual da rota.

O limite do serviço abrange quatro produtos diferentes

A oferta pública da SIANET não é uma nuvem uniforme. Ela abrange hospedagem compartilhada e dedicada, equipamento de propriedade do cliente em colocation, infraestrutura virtual vendida como computação em nuvem e serviços gerenciados de continuidade ou técnicos. Cada um muda a responsabilidade de forma diferente.

A página de hospedagem diz que servidores dedicados podem ser configurados de acordo com os requisitos do cliente, enquanto a hospedagem compartilhada visa sites e aplicações mais simples. Ela anuncia backup automatizado diário, suporte Linux e Windows, monitoramento e personalização de planos. A colocation move o limite do equipamento: o cliente traz servidores para a instalação da SIANET e depende da SIANET para ambiente físico, conectividade e acesso operacional.

A página de nuvem apresenta capacidade virtual que pode ser ajustada através de um painel automatizado, reduzindo a necessidade de abrir tickets de suporte para mudanças rotineiras. A oferta de backup do site descreve replicação para um data center secundário e até mesmo um local de trabalho opcional a partir do qual a equipe poderia continuar as operações se o escritório principal se tornasse inacessível.

Esses são serviços materialmente diferentes, não rótulos intercambiáveis. Um cliente de hospedagem compartilhada está exposto a controles de locação e política da plataforma. Um cliente de hospedagem dedicada precisa de compromissos de substituição e reconstrução de hardware. Um cliente de colocation mantém mais controle sobre a configuração do servidor, mas deve entender a cobertura de mãos remotas, peças sobressalentes, janelas de acesso e propriedade de cross-connects. Um cliente de nuvem depende mais fortemente do painel de controle, do estado de provisionamento e da camada de virtualização do provedor.

Um cliente de continuidade precisa de evidência de que a replicação e a recuperação realmente funcionam juntas.

A distinção também afeta a comparação de preços. Uma nuvem hiperescala pode fornecer um catálogo de serviços muito maior, controles de identidade granulares e material de auditoria extenso, mas pode impor custos de egresso, arquitetura e mão de obra especializada. A colocation pode proporcionar maior controle físico, mas deixa o cliente comprando, mantendo e renovando equipamentos. A infraestrutura própria pode preservar a máxima liberdade de configuração, ao mesmo tempo que cria um grande ônus em energia, refrigeração, rede, segurança e cobertura de incidentes.

A vantagem potencial da SIANET é mais restrita: infraestrutura local com suporte em português e uma equipe de serviço que pode absorver parte desse trabalho. O prêmio só se justifica se o contrato e as evidências do provedor reduzirem a supervisão do cliente mais do que aumentam a dependência do fornecedor.

As alegações físicas são específicas o suficiente para testar

A página de infraestrutura da empresa contém mais detalhes do que sua linguagem ampla de nuvem. A SIANET diz que a instalação usa dois geradores em arranjo redundante, com até 20 horas de operação antes do reabastecimento de combustível, e dois grupos de fonte de alimentação ininterrupta escaláveis que suportam aproximadamente 15 segundos antes que os geradores assumam a carga. Ela descreve firewalls ativo-ativo, dois sistemas de prevenção de intrusão perimetral, detecção e supressão de incêndio, resfriamento controlado e várias camadas de acesso físico, incluindo autorização biométrica para a sala do data center.

Essas declarações criam uma agenda de inspeção útil. Um comprador pode solicitar datas de teste de carga dos geradores, contratos de combustível, registros de manutenção, resultados de teste de bateria do UPS, diagramas elétricos unifilares, redundância de resfriamento, registros de inspeção do sistema de incêndio e evidências de que a manutenção não derruba a redundância anunciada. Sem esses materiais, os números permanecem afirmações do provedor. Com eles, o comprador pode testar se o design funciona sob modos de falha normais, e não apenas em uma descrição de vendas.

O mesmo princípio se aplica à conectividade. A SIANET diz que seu equipamento core e de borda baseado em Cisco é redundante e que múltiplos provedores podem propagar seu espaço de endereço através de BGP. O ASN observado, as relações de trânsito e a conexão de exchange suportam a existência desse papel de rede. Eles não estabelecem a disponibilidade da aplicação. Um serviço hospedado ainda pode falhar devido a um problema interno de comutação, estado de firewall, dependência de DNS, interrupção de armazenamento, gargalo de capacidade ou uma política de rota incorreta.

A diversidade de caminhos de internet é uma camada no argumento de disponibilidade, não o argumento inteiro.

É aqui que a declaração pública de uptime de 99,9% precisa ser traduzida. Se medida ao longo de um mês de 30 dias, 99,9% permite cerca de 43 minutos de indisponibilidade. Mas essa aritmética é apenas ilustrativa porque a página pública não define o período de medição, o endpoint monitorado, as exclusões, o tratamento de manutenção programada ou o remédio. Ela também não publica um histórico de status a partir do qual um comprador pudesse comparar a promessa com o serviço observado. O compromisso relevante é aquele no contrato de serviço, não a porcentagem na página inicial.

A automação reduz tickets, mas concentra o controle

A SIANET diz que seu painel de nuvem dá aos clientes controle de um data center virtual sem ações manuais de suporte. Isso pode remover trabalho repetitivo de provisionamento: um cliente pode redimensionar ou configurar recursos sem esperar que um operador processe cada solicitação. Para uma pequena equipe de plataforma, este é um benefício significativo. A questão é o que acontece com o estado em torno dessas ações.

Um plano de controle útil deve mostrar quem mudou um recurso, o que mudou, quando mudou, se a operação foi bem-sucedida, quanto custará e como reverter. Deve suportar funções separadas para administradores, operadores e auditores; autenticação forte; logs de atividade duráveis; relatórios de uso e orçamento; e um caminho de saída documentado para máquinas virtuais e dados. A página pública de nuvem da SIANET explica a proposta básica de autoatendimento, mas não estabelece essa superfície de governança. Seus valores de recurso ilustrados não devem ser lidos como inventário ao vivo ou capacidade garantida.

Isso importa sob pressão, não apenas durante a configuração. Se um cliente não puder obter capacidade, o painel deve distinguir cota, escassez física, status da conta e falha técnica. Se um redimensionamento for parcialmente bem-sucedido, a trilha de auditoria deve preservar o estado antigo e o novo. Se uma credencial de usuário for comprometida, o cliente deve poder revogar o acesso e identificar ações afetadas. Se o painel estiver indisponível, deve haver um caminho operacional alternativo e autenticado. A automação economiza trabalho quando torna o estado legível.

Ela cria um novo risco de concentração quando meramente esconde o trabalho manual atrás de uma tela.

Os compradores devem, portanto, solicitar uma demonstração construída em torno de falhas: criar um recurso, alterá-lo, remover os direitos de um usuário, recuperar-se de uma operação malsucedida, exportar o histórico de atividades e reconciliar o uso com a fatura. O resultado dirá mais sobre o modelo operacional do que uma lista de controles deslizantes máximos.

A localidade só é útil quando seus limites são explícitos

A presença pública da SIANET está fortemente associada a São Paulo. O site da empresa, a entrada do PeeringDB e a conexão de exchange apontam para lá, e os serviços são apresentados a clientes brasileiros em português. Para cargas de trabalho que atendem usuários em ou perto de São Paulo, isso pode oferecer vantagens de latência, idioma e suporte de conta. Para organizações que se preocupam em manter dados no Brasil, também pode ser comercialmente relevante.

Mas um escritório local, um ASN local e uma alegação de instalação local não respondem por si só a perguntas de residência de dados. Um cliente precisa saber onde os dados de produção, réplicas, snapshots, backups, logs e artefatos de suporte são armazenados; se subcontratados podem acessá-los; onde os serviços do plano de controle são executados; e se a recuperação pode mover dados para fora do local acordado. Colocation, servidores hospedados, instâncias de nuvem e o serviço de site secundário podem ter respostas diferentes.

A página de backup do site torna a incerteza particularmente importante. Ela descreve dados ou servidores replicados em um data center secundário, mas o material público não identifica um objetivo de ponto de recuperação, objetivo de tempo de recuperação, modo de replicação, frequência de teste ou a separação exata entre os locais primário e secundário. Um serviço de continuidade deve ser julgado por exercícios de restauração bem-sucedidos e mapeamento de dependências. Uma segunda cópia que compartilha um domínio de falha de energia, rede, credencial ou operador pode não fornecer a independência que o cliente espera.

Antes de assinar, um comprador deve obter um mapa de localização para cada classe de dados, uma lista de subprocessadores, procedimentos de exclusão e destruição de mídia, termos de criptografia e propriedade de chaves, e um processo de saída testado. A soberania de dados não é alcançada escolhendo um nome brasileiro. É alcançada mantendo a localização e os fatos de controle anexados à carga de trabalho ao longo de sua vida.

O suporte faz parte da infraestrutura

A SIANET anuncia suporte em português 24 horas por dia, sete dias por semana, por telefone ou ticket. Sua página de infraestrutura descreve uma equipe de operações que monitora os recursos do cliente, fornece tratamento de primeiro nível e ativa suporte de segundo e terceiro nível. Esta é uma descrição crível de uma superfície de escalonamento local e pode ser mais acessível a um cliente brasileiro do que uma fila padronizada distante.

No entanto, a disponibilidade de uma fila é diferente da responsabilidade por um resultado. As páginas públicas não declaram metas de reconhecimento ou restauração por gravidade, tempo de escalonamento, propriedade do incidente, intervalos de comunicação ou créditos de serviço. Elas também não mostram se o monitoramento cobre apenas a infraestrutura ou inclui o sistema operacional e aplicação do cliente. Esses limites decidem se o suporte reduz o trabalho ou inicia uma rodada de transferência de responsabilidade durante uma interrupção.

O registro público contém um sinal útil de prova de serviço além das próprias páginas da empresa. O registro de contratos municipais de Nazaré Paulista nomeia a SIANET como fornecedora para instalação, configuração inicial e aluguel de infraestrutura de TI com manutenção. O Contrato 74/2024 vigorou de julho de 2024 a julho de 2025 e teve um valor de R$48.999,60. Isso demonstra que um comprador público contratou a SIANET para um serviço de infraestrutura definido. Não revela tempo de atividade, qualidade de resolução ou satisfação do cliente, portanto, não deve ser estendido a um endosso de desempenho.

Um exercício de aquisição deve transformar a promessa de suporte em uma tabela: definições de gravidade, objetivos de resposta e restauração, níveis de escalonamento nomeados, autoridade após o expediente, obrigações do cliente, comunicações, retenção de evidências e remédios. Deve então testar o caminho antes de um incidente sério. Abra um ticket de baixo risco, escale-o, solicite o histórico de atividades e verifique se ambos os lados concordam com a propriedade. O suporte local é valioso quando encurta o tempo de diagnóstico e decisão, não apenas quando alguém atende no mesmo idioma.

O pacote de evidências do comprador deve sobreviver a uma interrupção

O caso prático para a SIANET baseia-se na combinação de sua identidade técnica visível com evidências que são menos visíveis publicamente. AS53101, espaço de endereço e participação no IX.br mostram que a empresa operou seus próprios recursos de rede. O site apresenta superfícies distintas de hospedagem, nuvem, colocation, recuperação e suporte. A página de infraestrutura fornece alegações testáveis sobre energia, segurança de rede e controles físicos. O contrato municipal adiciona um exemplo concreto de infraestrutura fornecida com manutenção.

O que permanece não comprovado publicamente é o desempenho desse sistema ao longo do tempo. Um comprador sério deve solicitar doze meses de dados de disponibilidade e incidentes para o serviço relevante, a fórmula exata do SLA, política de capacidade e oversubscription, resultados de backup e restauração, garantia de segurança, histórico de gerenciamento de mudanças, desempenho de suporte por gravidade e evidências recentes de testes de failover de energia e rede.

A solicitação deve corresponder ao produto que está sendo comprado; evidência de colocation não substitui evidência de plano de controle de nuvem, e uma rota de rede não substitui recuperação de armazenamento.

A regra de decisão é direta. A SIANET não deve ser descartada como um rótulo de hospedagem sem fundamento: a identidade legal e o rastro de recursos de rede são substanciais. Nem o ASN visível deve ser promovido a uma conclusão de confiabilidade geral. Trate a empresa como um provedor operacional cujos fatos públicos mais fortes merecem uma due diligence mais profunda. A compra se torna defensável quando a SIANET puder conectar esses fatos ao rack específico, host, recurso virtual, conjunto de backup e obrigação de suporte dos quais o cliente dependerá.