"Datalogika" Ltd. vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A "Datalogika" Ltd. apresenta sinais operacionais ativos: seu site público vende colocation em um prédio de data center em Dolgoprudny, o painel de pedidos JPE.ru lista produtos de rack, meio rack, servidor único e servidor alugado, e o RIPEstat mostrou o AS51520 anunciado em 12 de julho de 2026 com 768 endereços IPv4 e ampla visibilidade IPv4.
• A âncora física é excepcionalmente específica para um pequeno host. A Datalogika afirma que seu salão tem 170 m², 70 racks abertos, média de 4,2 kW e máximo de 7 kW por rack, um UPS de 400 kVA, uma subestação transformadora de 400 kW, um gerador a diesel de 550 kW, 5.000 litros de combustível e uma autonomia declarada de 48 horas.
• As evidências públicas ainda são incompletas onde a resiliência do cliente é decidida. Não há teste de carga público, certificação, contrato upstream, mapa de rotas da operadora, cronograma de peças de reposição, escala de suporte, procedimento de acesso à instalação, registro de backup e restore ou plano de migração de clientes.
• A melhor interpretação é de um operador de hospedagem russo, ativo e pequeno, com uma história local significativa e um AS visível, não uma plataforma de nuvem cuja capacidade utilizável, diversidade física ou limites de recuperação possam ser inferidos apenas a partir do marketing.

A venda é um rack antes de ser uma nuvem

A palavra "hospedado" pode fazer um serviço parecer elástico, mas a oferta da Datalogika é fisicamente direta. O site da empresa afirma que colocará o equipamento do cliente em seu próprio data center em Moscou, e a página vende um rack completo ou colocação por unidade. A seção de tarifas públicas atuais emdatalogika.rulista um rack com 4 kW a partir de 80.000 RUB por mês e colocação por unidade com 0,3 kW a partir de 3.100 RUB por mês. Diz que a potência média fornecida a um rack é de 4,2 kW, o máximo é de 7 kW, os canais agregados de internet no data center excedem 100 Gb, e uma porta de internet "Full View" de 100 Mb está incluída gratuitamente.

Essa não é a linguagem de uma região hyperscale abstrata. É a linguagem de uma sala, um PDU de rack, um cross-connect, um turno de suporte e uma conta. A mesma página diz que montagem, conexão, configuração de equipamentos de telecomunicações e suporte 24 horas estão incluídos para os clientes. Também anuncia interfaces de 100 Mb, 1 Gb, 10 Gb, 40 Gb e 100 Gb, e afirma que, sob solicitação, a Datalogika pode conectar um cliente a qualquer provedor por meio de um canal Layer 2.

A promessa é ampla; a consequência física é que cada pedido de cliente consome uma porta, margem de energia, caminho de cabo, capacidade de switch, tempo de técnico e um relacionamento comercial com a operadora selecionada.

O painel de pedidos público torna a oferta mais tangível. A página da loja WHMCS do JPE.ru paracolocação de equipamentoslista três produtos: colocação de servidor único a partir de 3.100 RUB mensais, aluguel de rack completo a partir de 80.000 RUB mensais e aluguel de meio rack a partir de 52.000 RUB mensais. Uma página separada do JPE.ru paraaluguel de servidoranuncia servidores configuráveis a partir de 2.350 RUB, com opções de CPU, memória, disco, chassi e canal. A página correspondente de produtos WHMCS paraservidores alugadoslista "Aренда сервера - Конструктор" com o mesmo preço inicial e afirma que 100 Mb/s mais um endereço IPv4 estão incluídos gratuitamente.

Isso importa porque colocation e servidores alugados falham de forma diferente. Um cliente de colocation traz seu próprio equipamento e, portanto, mantém mais responsabilidade pelo ciclo de vida do hardware, estado do sistema operacional, substituição de disco e configuração. Um cliente de servidor alugado depende do chassi sobressalente, processadores, memória, unidades, prática de instalação e fila de suporte remoto do host.

Em ambos os casos, o serviço visível do cliente pode ser um site, sistema de faturamento, servidor de jogo, host de e-mail, aplicativo empresarial ou nó de armazenamento, mas o caminho de recuperação começa com uma pessoa alcançando um rack energizado e decidindo qual componente físico falhou.

A identidade comercial da Datalogika é, portanto, um híbrido. Ela vende espaço de rack, colocação por unidade e capacidade de servidor hospedado a partir do mesmo ambiente de marca pública. Os compradores não devem resumir tudo em uma única promessa. Um cliente de colocation 1U precisa de clareza sobre o acesso ao seu próprio hardware, mídia de substituição, limites de suporte remoto e handoff da operadora. Um cliente de rack completo precisa de margem de energia, restrições de resfriamento, termos de cross-connect e um plano para trabalho dentro do rack durante a manutenção em sala compartilhada.

Um cliente de servidor alugado passa de inventário, tempo de reconstrução, política de retenção de disco, disponibilidade de imagem e o caminho de transferência para fora do serviço. As páginas públicas mostram o menu. Elas não mostram como a cozinha se comporta durante uma correria.

A âncora física é excepcionalmente visível

A Datalogika fornece uma descrição da instalação mais detalhada do que muitos hosts pequenos. A seção de instalação doseu sitelocaliza o prédio do data center em Dolgoprudny, Oblast de Moscou, na Rua Zhukovskogo, 3, e diz que esse endereço russo é importante para empresas que processam dados pessoais de usuários. O rodapé repete o nome legal em russo, o endereço em Dolgoprudny, INN 5008048758, KPP 500801001 e OGRN 1085047011334. O objeto de organização do RIPE paraORG-DL620-RIPEtambém nomeia"Datalogika" Ltd., define o país como RU, fornece o número de registro 1085047011334 e usa o mesmo endereço em Dolgoprudny.

A própria sala é descrita em termos operacionais. A Datalogika diz que a área do salão é de 170 m² e que 70 racks de servidores abertos estão instalados. Ela nomeia um UPS Gamatronic Power+ de 400 kVA e afirma que fornece 10 minutos de operação após a perda de energia da rede. Diz que o data center possui sua própria subestação transformadora de 400 kW, um gerador a diesel Wilson containerizado de 550 kW, uma reserva de combustível de 5.000 litros e combustível suficiente para 48 horas de operação autônoma. Afirma que a transferência da subestação para o gerador ocorre em menos de um minuto, enquanto o UPS mantém os equipamentos.

O resfriamento é igualmente específico. A Datalogika diz que usa condicionadores de ar de precisão industrial Hiref com 76 kW de capacidade de resfriamento em um esquema 4+1. O ar frio é fornecido sob um piso elevado de 0,4 m em corredores frios. O acesso é descrito como controlado por passagem, com guardas, vigilância por vídeo e supressão de incêndio por gás inerte.

Essas são afirmações úteis porque identificam os elementos que precisam ser inspecionados: carga do UPS, histórico de teste do gerador, contratos de combustível, capacidade de resfriamento, posicionamento do condensador, manutenção do painel de incêndio, controle de acesso e a quantidade real de carga de TI instalada no salão.

A empresa também usa linguagem de Tier, mas a leitura segura é restrita. O site diz que o data center "corresponde" aos requisitos de confiabilidade Tier 3, com um prédio separado cercado, duplicação N+1 e infraestrutura e comunicações redundantes. Um artigo da Datalogika emcomo escolher um data centerdiscute explicitamente se um certificado Tier III existe e diz que a certificação tem um custo; afirma que a JPE orientou seu trabalho e equipamentos técnicos para esses padrões e convida potenciais clientes a avaliar a conformidade. OSistema de Classificação de Tierdo Uptime Institute trata a certificação Tier como uma estrutura formal de avaliação, e sua explicação do Tier III enfatiza a manutenção concorrente. A menos que uma premiação pública ou certificado voltado ao cliente seja mostrado, a fraseologia Tier 3 da Datalogika deve ser lida como uma alegação de design e operações, não como prova de uma instalação certificada.

Os números em si também precisam de contexto de carga. Um transformador de 400 kW, gerador de 550 kW e UPS de 400 kVA podem ser críveis para um salão pequeno, mas a margem depende do consumo real de TI, carga de resfriamento, condição da bateria do UPS, fator de potência, prática de bypass de manutenção, confiabilidade de partida do gerador e o número de racks realmente vendidos em alta densidade. Setenta racks na média anunciada de 4,2 kW implicariam 294 kW de carga de TI antes do resfriamento e outras despesas gerais. Setenta racks no máximo anunciado de 7 kW implicariam 490 kW de carga de TI antes das despesas gerais.

A página pública não diz se cada rack pode consumir a potência máxima ao mesmo tempo, quantos racks estão instalados e vendidos, ou como a sala aloca energia quando vários clientes pedem mais.

Essa é a diferença entre capacidade instalada e capacidade utilizável. Capacidade instalada é o equipamento nomeado no site. Capacidade utilizável é o que resta após manutenção, calor, baterias, combustível, limites upstream, peças de reposição e tempo de suporte serem contabilizados. A descrição pública da instalação é forte o suficiente para tornar a Datalogika digna de diligência. Não é forte o suficiente para precificar uma migração crítica sem uma visita ao local, leituras de carga e um exercício de falha.

A pegada da empresa suporta continuidade, não escala

Os sinais legais e de serviço público se alinham em torno de uma pequena empresa de longa data. O rodapé dedatalogika.rufornece os identificadores legais e dados bancários. A página de perfil corporativo russo emAudit-it, citando registros oficiais abertos, lista a entidade legal como ativa, fornece o endereço em Dolgoprudny, identifica a atividade principal como documentação de telecomunicações, diz que o registro ocorreu em 16 de setembro de 2008 e relata receita de 28,3 milhões de RUB em 2025.ZachestnyBiznesapresenta independentemente o mesmo OGRN, INN, data de registro, status ativo e endereço.

Esses espelhos corporativos não são a mesma coisa que telemetria operacional. Eles são úteis para escala e continuidade, não para qualidade de serviço. Um valor de receita de 28,3 milhões de RUB em 2025 é compatível com uma sala pequena, equipe limitada, adoção modesta de colocation, vendas de servidores alugados e trabalho de hospedagem relacionado. Não prova quantos clientes estão ativos, quantos racks estão cheios, se a empresa possui o prédio, quantos funcionários estão de plantão, quanta dívida está vinculada ao equipamento da instalação ou se um negócio relacionado possui ativos fora dessa entidade legal.

A família de sites dá outro sinal de continuidade. A página principal da Datalogika vincula alk.jpe.rupara seleção de produtos e à marca JPE.ru no painel do cliente. Uma consulta DNS pública do Google pararegistros A de datalogika.ruresolve o site principal para 91.194.2.25, enquantojpe.rutambém resolve para 91.194.2.25 elk.jpe.ruresolve para 91.194.2.17. Osregistros NS de datalogika.rusãons1.datalogika.ruens2.datalogika.ru. Esses endereços estão dentro do prefixo 91.194.2.0/23 originado pelo AS51520.

Isso é evidência de que as portas de entrada públicas de vendas e contas são servidas a partir do mesmo conjunto de endereços que a Datalogika origina. Não é uma garantia de que o painel do cliente, estado de faturamento, catálogo de serviços e canais de suporte sobrevivem a uma perda desse conjunto. Se o site público, loja e painel de controle estão todos na mesma sala e no mesmo bloco roteado, então uma interrupção na instalação de Dolgoprudny pode afetar não apenas as cargas de trabalho hospedadas do cliente, mas também a capacidade do cliente de abrir um ticket, solicitar uma substituição ou ler uma página de status.

Se algum desses serviços é espelhado em outro lugar, as páginas públicas não dizem.

A história do serviço deve, portanto, ser tratada como ativa, mas pequena. A Datalogika não é meramente um domínio estacionado com texto desatualizado: as páginas de pedidos retornam produtos ativos, o AS é anunciado, os identificadores corporativos permanecem coerentes e o site anuncia preços mensais atuais que diferem de meta descrições mais antigas em algumas páginas de artigos. Mas pequenas empresas ativas ainda podem ter caminhos de falha concentrados. A continuidade diz ao comprador a quem ligar. Não diz ao comprador quantas chamadas simultâneas a empresa pode gerenciar quando um rack, switch ou upstream falha.

O preço tem que financiar o relógio de reparo

Os preços públicos da Datalogika são baixos o suficiente para tornar a economia parte da história de resiliência. Um slot de servidor único a 3.100 RUB por mês, um construtor de servidor alugado a 2.350 RUB por mês e um rack completo a partir de 80.000 RUB por mês não são apenas números de vendas. Eles são o pool do qual o host deve pagar por eletricidade, resfriamento, combustível, upstreams, switches, óptica, peças de servidor, software, contabilidade, aluguel ou custos de propriedade, impostos, visitas de manutenção e as pessoas que atendem quando algo falha.

O serviço ainda pode ser bom a esses preços, mas apenas se a oferta for estritamente definida e as premissas operacionais forem honestas.

É por isso que o artigo não trata os itens anunciados como "grátis" como sem custo. Uma porta incluída de 100 Mb consome capacidade de switch, capacidade de roteamento e margem upstream. Montagem e configuração incluídas consomem tempo de equipe. Mover o equipamento de um cliente às custas da empresa consome tempo de veículo, risco de embalagem e o dia de um técnico. Uma instalação gratuita de sistema operacional em um servidor alugado consome tempo de construção e uma prática de instalação repetível. Essas inclusões podem ser uma vantagem real para um pequeno cliente que de outra forma teria que coordenar vários fornecedores.

Elas também podem se tornar uma fila quando muitos clientes precisam das mesmas pessoas ao mesmo tempo.

O valor de receita de 2025 relatado porAudit-itfornece contexto de escala sem provar qualidade de serviço. Receita de 28,3 milhões de RUB pode suportar uma operação de nicho significativa, especialmente se a instalação for compacta, a equipe experiente e os clientes comprarem pacotes simples. Não é o tipo de escala que permite a um comprador assumir um estoque profundo de peças sobressalentes, um grande banco de engenheiros noturnos, vários locais distantes ou trânsito excedente comprado para eventos de pico raros. A suposição justa não é fraqueza. A suposição justa é que todo recurso de recuperação prometido deve ser financiado deliberadamente.

É também por isso que clientes de meio rack e rack completo não devem comparar apenas preços mensais de destaque. Eles devem perguntar como os excedentes de energia são cobrados, se os cross-connects têm tarifas recorrentes, se interfaces de velocidade superior exigem um upgrade de porta, se um cliente pode comprar largura de banda comprometida em vez de acesso compartilhado, se as tarefas de suporte remoto têm limites de tempo e se o trabalho de emergência é precificado de forma diferente do trabalho programado. Um preço base baixo com extras pagos pode ser perfeitamente razoável se o contrato disser isso.

Um preço base baixo que absorve silenciosamente trabalho de recuperação de alto contato pode se tornar frágil durante uma semana ruim.

Para clientes de servidor alugado, a mesma aritmética se aplica ao hardware. Se um serviço mensal de 2.350 RUB inclui um endereço IPv4 e um caminho de 100 Mb, o host tem que recuperar o custo do chassi, discos, memória, energia, resfriamento, posição no rack e tempo de substituição ao longo de muitos meses. Isso tende a favorecer construções padrão, substituição imediata limitada e controle cuidadoso de solicitações incomuns.

Clientes que precisam de reconstruções rápidas, custódia especial de disco, alta resistência de gravação, memória grande ou alto comprometimento na rede devem esperar pagar mais ou receber uma promessa escrita mais restrita.

O teste de compra mais útil é, portanto, não "a Datalogika é barata?" mas "o que o preço compra durante uma falha?" Se a resposta for uma sala modesta, um endereço russo nomeado, ajuda prática e capacidade alugada de melhor esforço, a oferta pode ser atraente. Se o comprador precisa de caminhos de failover reservados, hardware de substituição garantido, recuperação fora do local e resposta de suporte medida, esses recursos devem aparecer como compromissos pagos, em vez de serem inferidos a partir de uma tarifa geral de hospedagem.

AS51520 é real, mas as evidências de roteamento têm limites

A evidência operacional atual mais forte é a acessibilidade de rede. Avisão geral do AS do RIPEstat para AS51520identifica o titular comoRH "Datalogika" Ltd.e marcou o ASN como anunciado no momento de observação de 12 de julho de 2026. Ostatus de roteamento do RIPEstatmostrou dois prefixos IPv4, 768 endereços IPv4, visibilidade em 326 de 327 peers IPv4 RIPE RIS e nenhuma rota IPv6 visível. Suavisão de prefixos anunciadoslistou 91.194.2.0/23 e 94.232.251.0/24.

O quadro de recursos registrados é desigual de uma forma útil. Avisão whois do RIPEstat para AS51520mostra aut-num AS51520, as-name RH, organização ORG-DL620-RIPE, status ASSIGNED, criado em 16 de setembro de 2010 e última modificação em 24 de dezembro de 2025. Oregistro de 91.194.2.0/23vincula o bloco à ORG-DL620-RIPE, país RU e status provider-independent. Oregistro de 94.232.251.0/24é diferente: é espaço provider-aggregatable atribuído à organização ORG-LA1341-RIPE, e o registro de organização RIPE paraORG-LA1341-RIPEnomeia"RealHost" Ltd.em Krasnoyarsk. O objeto de rota ainda mostra origem AS51520.

Para um comprador, isso significa que o conjunto de endereços roteados da Datalogika deve ser separado em espaço próprio ou registrado pela Datalogika e espaço roteado pela Datalogika, mas registrado para outra organização. A distinção não é necessariamente um problema. Operadores de hospedagem frequentemente originam espaço de cliente, empresa relacionada ou fornecedor. Importa durante a saída e resposta a incidentes. Se um serviço de cliente é numerado a partir de 91.194.2.0/23, o controle contratual e de registro pode ser diferente de um serviço numerado a partir de 94.232.251.0/24.

Portabilidade de endereço, tratamento de contato de abuso, filtragem de prefixo, mudanças de RPKI e reoriginação de emergência podem depender de quem controla o recurso e quem pode assinar ou manter objetos de rota.

O RPKI adiciona a mesma nuance. O endpoint de validação do RIPEstat retornoudesconhecidopara AS51520 originando 91.194.2.0/23, enquanto oresultado de 94.232.251.0/24retornou válido com comprimento máximo /24. Desconhecido não é inválido; significa que nenhuma autorização de origem de rota correspondente estava disponível naquele resultado de validação. Uma rede aplicando validação de origem estrita não rejeitaria uma rota desconhecida pela mesma razão que rejeitaria uma inválida, mas uma rota desconhecida dá menos garantia criptográfica do que uma válida.

Páginas de roteamento secundárias concordam amplamente com a forma, enquanto adicionam mais nomes.bgp.tools para AS51520identifica"Datalogika" Ltd., diz que o AS origina dois prefixos IPv4 e nenhum IPv6, lista upstreams AS31500 Global Network Management Inc e AS5467, e mostra o prefixo 91.194.2.0/23 sob"Datalogika" Ltd.e 94.232.251.0/24 sob"RealHost" Ltd.. A página BGP da Hurricane Electric paraAS51520relata dois prefixos IPv4 originados, nenhum prefixo IPv6 originado, 768 endereços IPv4 originados, 31 peers IPv4 observados e três trocas de internet: Eurasia Peering IX em Moscou, PITER-IX Moscou e Sibir-IX em Krasnoyarsk.

O PeeringDB é mais conservador. Suaentrada de API de rede para AS51520nomeia "Krasnoyarsk network", vincula o sitehttp://www.kraslan.ru, diz que a política é aberta e registra uma contagem de IX e nenhuma instalação. Suaentrada netixlanmostra uma porta operacional de 10Gb na Eurasia Peering IX com endereço IPv4 185.232.60.109. A diferença entre a imagem auto-relatada de um IX do PeeringDB e a visão de troca mais ampla da HE é exatamente por que um artigo não deve igualar uma página de roteamento com diversidade física. A internet pública pode ver adjacências; ela não vê todos os pedidos de cross-connect, compromissos de porta, termos de manutenção, entradas de fibra ou salas compartilhadas.

Oneighbour view do RIPEstatrelatou 20 vizinhos observados no momento da pesquisa, com AS31500 carregando de longe o maior peso visível naquele endpoint. Isso apoia a hipótese de que a Global Network Management é o principal upstream visível, mas o resultado ainda precisa de redação cuidadosa. "Vizinho observado" não é o mesmo que contrato de fornecedor. Alguns vizinhos são peers, alguns podem ser downstreams, alguns podem ser artefatos de route server, e alguns podem aparecer ou desaparecer com a política. O fato de que AS51520 tem múltiplos vizinhos observados é bom. O fato de que um upstream visível domina é uma questão de resiliência.

Diversidade de trânsito não é o mesmo que diversidade de restauração

A própria página da Datalogika diz que os canais agregados de internet no data center excedem 100 Gb e que pode fornecer interfaces de até 100 Gb. A afirmação é útil, mas incompleta. Uma interface capaz de 100 Gb é uma opção de porta, não prova que um determinado cliente recebe um caminho comprometido de 100 Gb. Canais agregados de internet não são o mesmo que capacidade de failover sem congestionamento. Se o maior upstream falhar, a questão é quanto tráfego do cliente os caminhos sobreviventes podem transportar sem perda, jitter ou limitação comercial.

É aqui que a economia de pequenos hosts se torna prática. Uma grande operadora pode transportar trânsito de reserva, múltiplas fibras urbanas, caminhos ópticos separados, um segundo centro de operações e comunicações formais de incidentes principais. Um host pequeno ainda pode ser confiável, especialmente se sua mistura de clientes for modesta e seus técnicos conhecerem todos os racks. Mas um host pequeno tem menos lugares para esconder estresse. Um roteador com falha, um peer saturado, um técnico indisponível, um portão de instalação fechado ou uma janela de manutenção de fornecedor podem afetar uma grande parte da base de clientes.

Orelatório de incidentes de segurança em telecomunicações da ENISA 2024é útil aqui não porque diz algo sobre a Datalogika, mas porque identifica mecanismos de falha comuns em incidentes de telecomunicações: cortes de cabo e falhas de software ou alterações de atualização aparecem com destaque entre causas técnicas ligadas a erro humano. Resumos de incidentes mais antigos da ENISA também identificaram falhas de sistema e cortes de energia como impulsionadores recorrentes de interrupções. Essas categorias mapeiam diretamente em um host pequeno: trabalho civil pode cortar um caminho de fibra; uma mudança de roteador pode vazar ou retirar rotas; uma transição de energia pode expor uma cadeia fraca de UPS; um lote de disco com falha pode esgotar as peças de reposição.

A oferta pública da Datalogika menciona suporte 24/7, montagem e configuração incluídas e suporte remoto em sua orientação de artigos. Não publica uma escala de suporte, sequência de escalonamento, lista de roteadores sobressalentes, SLA de reparo de cross-connect, calendário de manutenção, página de status, arquivo de interrupções ou registro pós-incidente. Essas ausências não são constatações de mau desempenho. São limites sobre o que um comprador pode inferir. Um host pode ter excelentes procedimentos privados e ainda publicar pouco.

Um comprador que carrega cargas de trabalho voltadas ao público deve pedir para ver os procedimentos antes de tratar o serviço como resiliente.

O relógio de reparo também muda por tipo de falha. Um disco ruim em um servidor alugado pode ser uma troca de hardware no mesmo dia se a peça estiver no local e o engenheiro puder acessar o rack. Um servidor com falha de propriedade do cliente em colocation pode exigir que o cliente forneça peças ou autorize uma tarefa prática. Um módulo UPS com falha pode exigir suporte do fornecedor. Um corte de fibra pode ficar com uma operadora upstream ou metropolitana. Um vazamento de rota pode exigir coordenação com peers, route servers e trânsito. Falha no painel de faturamento pode bloquear a ação do cliente mesmo que os pacotes continuem fluindo.

O cliente experimenta uma interrupção; o host experimenta vários proprietários.

É por isso que "janelas de reparo" pertence ao título. O serviço não é vendido apenas em preços mensais. É vendido no tempo entre o primeiro alarme e a função restaurada. As páginas públicas da Datalogika são fortes em especificação de sala e pedido de produtos, mas o registro público é mais fraco em restauração medida. A lacuna é onde um comprador deve negociar.

Localidade é uma característica, mas também restringe o caminho de saída

A Datalogika vende explicitamente um endereço russo como valioso para empresas que processam dados pessoais de usuários. Essa afirmação se encaixa no contexto de mercado. A entrada do WILMAP de Stanford sobre aLei Federal nº 242-FZresume a regra de localização de dados pessoais russos como exigindo que o processamento de dados pessoais de cidadãos russos seja feito com servidores localizados na Rússia. Uma sala em Dolgoprudny pode, portanto, ser um ativo comercial para clientes que desejam infraestrutura hospedada na Rússia sem usar uma nuvem maior ou um hotel de operadora mais caro.

A localidade tem dois lados. Pode melhorar a postura de conformidade, reduzir o tempo de viagem para clientes da área de Moscou, apoiar serviço prático em russo e manter hardware com dados em uma jurisdição conhecida. Também pode reduzir a portabilidade se o serviço depender de endereços IP locais, contratos locais, suporte em russo, peças de reposição na sala ou acordos de operadora difíceis de reproduzir em outro lugar.

Um cliente deve saber se sair significa enviar seus próprios servidores, copiar imagens de disco para um novo servidor alugado, renumerar a partir do espaço AS51520, alterar DNS, alterar filtros upstream ou esperar por uma transferência de provedor para provedor.

O endereço da instalação da Datalogika é particularmente importante para clientes de colocation. Se um cliente tem razões regulatórias, contratuais ou de segurança para manter um servidor dentro da Rússia, a sala em Dolgoprudny pode satisfazer o requisito de localização. Mas se o cliente depois precisar de um segundo local, um backup fora do local ou um standby ativo, o mesmo requisito de localização se torna uma restrição de design. Um backup em outro país pode ser inaceitável para alguns dados. Um backup na mesma sala pode não sobreviver ao mesmo incidente na instalação.

Um segundo local russo pode exigir outro provedor e um plano de movimentação de dados testado.

As páginas públicas não mostram tal plano. Elas não anunciam replicação multi-site, armazenamento de objetos, backup gerenciado, custódia de mídia fora do local, failover entre regiões ou uma segunda instalação russa. A página de aluguel de servidor anuncia instalação de sistema operacional e hardware configurável; a página de colocation anuncia capacidade de rack e unidade; o painel WHMCS aceita pedidos. Nenhuma dessas superfícies descreve como um cliente sai sob estresse. Isso não torna o serviço inadequado. Significa que o comprador assume a questão.

A localidade dos dados também afeta o manuseio de imagem e disco após uma falha. Se a Datalogika aluga um servidor para um cliente, quem controla os discos antigos após a substituição? Como os discos com falha são tratados? Um cliente pode solicitar destruição, devolução, retenção ou evidência de limpeza? Se o cliente coloca seu próprio equipamento, o host pode remover a mídia apenas com aprovação por escrito? Se o host migra um cliente para hardware de substituição, onde a cópia intermediária é armazenada? O registro público não responde a essas perguntas, ainda que elas sejam centrais para a promessa implícita em um endereço físico russo.

A conclusão mais segura é que a Datalogika pode ser interessante para clientes que precisam de capacidade de rack ou servidor localizada na Rússia e valorizam a abordagem prática de um operador menor. Não deve ser tratada como capacidade de nuvem automaticamente portátil. Localidade não é apenas uma coordenada de mapa; é uma restrição de recuperação e saída.

Seis falhas definem o serviço real

Uma falha de energia ou resfriamento do rack

A história da sala começa com energia e resfriamento. A Datalogika nomeia seu UPS, transformador, gerador, reserva de combustível e arranjo de resfriamento. Um cliente deve perguntar como esses componentes mapeiam para seu próprio rack. As alimentações A e B estão disponíveis? Cada rack tem energia redundante? O que acontece quando um caminho de energia é isolado para manutenção? Qual é o intervalo de medição no nível do rack? Quão próximo o cliente está da média de 4,2 kW ou máximo de 7 kW? Os racks de alta densidade são espalhados por corredores frios ou agrupados? Como uma falha de unidade de resfriamento é testada sob calor de verão?

As partes afetadas não são apenas os clientes em um rack. Se o resfriamento é restrito, racks vizinhos podem ser desclassificados. Se a entrega de combustível é atrasada, toda a sala pode enfrentar uma decisão de desligamento. Se as baterias do UPS são mais fracas do que o esperado, a janela de partida do gerador prometida se torna mais apertada. A página pública diz que a manutenção preventiva não para o data center. Um comprador deve perguntar pelo último evento de manutenção em que isso foi demonstrado.

Uma falha upstream ou de peering

O roteamento do AS51520 é visível e apenas IPv4 na observação pública. O RIPEstat mostra dois prefixos anunciados e 20 vizinhos observados. bgp.tools lista AS31500 e AS5467 como upstreams, e HE lista três trocas de internet. Esta é uma evidência positiva de que a Datalogika não está apenas NAT atrás da banda larga de varejo de outro provedor. Ela tem um AS, origina seu espaço de endereço e faz peering ou trânsito no roteamento público.

A questão de falha é se os caminhos sobreviventes podem transportar a carga do cliente. Se AS31500 é removido, todos os prefixos permanecem visíveis através de outros caminhos? O 94.232.251.0/24 se comporta de forma diferente do 91.194.2.0/23 porque o controle de registro difere? Filtros de rota, limites de máximo prefixo e configurações de RPKI são testados? Existe um contato documentado para mudança de rota fora da sala afetada? O painel do cliente e o e-mail de suporte são alcançáveis através de um caminho diferente? A visibilidade pública do BGP não responde a essas perguntas; mostra apenas que as rotas estão lá agora.

Uma escassez de estoque de hardware

A página de servidor alugado da Datalogika anuncia processadores de 4 núcleos / 4 threads a 8 núcleos / 16 threads, memória de 8 GB a 96 GB, HDD de 1 TB a 10 TB, SSD de 240 GB a 960 GB e chassis de 1U a 3U com uma ou duas fontes de alimentação. Esta é uma oferta de hardware configurável, não uma divulgação de inventário. Um host pequeno pode entregar isso bem se estocar peças comuns e manter limites claros em construções personalizadas. Pode ter dificuldades se uma falha afetar um chassi raro, um tamanho de disco não mais disponível, um controlador antigo, uma peça de PSU dupla ou um cliente que precisa de substituição exata.

O comprador deve perguntar quais componentes são estocados no local, quais são encomendados após a falha, quais substitutos são aceitáveis e como um servidor é reconstruído quando a peça exata não está disponível. Para servidores alugados, o host deve declarar se o cliente recebe hardware de substituição, hardware temporário ou reparo atrasado. Para colocation, o cliente deve saber quais tarefas o suporte remoto realizará e quais exigem que o cliente envie peças ou compareça ao local.

Um gargalo de suporte

Suporte 24 horas é valioso apenas se a fila de suporte tiver pessoas suficientes com autoridade suficiente. A página pública da Datalogika diz que o suporte é gratuito para todos os clientes e a página do artigo diz que o equipamento está sob observação contínua de especialistas em serviço técnico. O registro público não identifica número de funcionários, padrão de turno, subcontratados, autoridade de escalonamento, cobertura de idioma, metas de resposta a tickets ou prática de incidentes simultâneos.

Pequenos operadores muitas vezes vencem porque engenheiros experientes respondem diretamente em vez de encaminhar cada tarefa para um call center distante. Essa vantagem desaparece quando um engenheiro é responsável por muitos clientes ou quando um incidente na instalação bloqueia o acesso físico. Os compradores devem perguntar quem pode entrar na sala à noite, quem pode realizar trabalho elétrico, quem pode tocar na mídia do cliente, quem pode autorizar escalonamentos de operadora e o que acontece se vários clientes solicitarem suporte remoto durante a mesma interrupção.

Uma interrupção do painel de faturamento ou controle

A porta de entrada do cliente importa. As páginas públicas de produtos e o fluxo de login estão sob lk.jpe.ru, que resolve para a mesma faixa de endereço 91.194.2.0/23. O painel WHMCS é uma maneira normal para um host pequeno vender, faturar e suportar serviços. Também se torna parte da superfície de resiliência. Se a mesma falha de instalação ou rota afetar tanto as cargas de trabalho do cliente quanto o painel, os clientes podem perder o canal normal para tickets, pedidos e faturas no exato momento em que precisam.

O comprador deve perguntar por uma rota de suporte fora de banda: telefone, e-mail alternativo, página de status externa ou contato de escalonamento nomeado. Também deve perguntar o que acontece com o faturamento recorrente se o painel estiver indisponível, se a lógica de suspensão de serviço é manual ou automatizada e como o acesso à conta é restaurado após um problema de identidade ou sessão. Um serviço hospedado não é apenas pacotes e energia; é também a capacidade do cliente de obter ação durante o estresse.

Uma falha de migração ou saída

A falha final não é uma interrupção súbita, mas uma mudança que não pode ser concluída. Um cliente pode sair devido a crescimento, exposição a sanções, mudança de preço, mudança de conformidade, aquisição, problema de desempenho ou necessidade de um segundo local. Para colocation, a saída pode envolver coleta física, embalagem remota, alfândega ou manuseio de transportadora, regras de mídia com dados e tempo de inatividade coordenado.

Para servidores alugados, a saída pode envolver exportação de imagem, janelas rsync, mudanças de DNS, atualizações de firewall, renumeração e verificação de que os discos antigos são limpos ou devolvidos sob a regra acordada.

As páginas públicas da Datalogika não definem portabilidade de dados. Também não mostram se os clientes podem trazer seu próprio espaço IP, anunciá-lo através do AS51520, reter um bloco após a saída ou mover endereços para outro provedor. Isso é normal para um site público pequeno, mas deve ser coberto nos termos contratuais. O pior momento para aprender que um host não pode produzir uma imagem utilizável, enviar hardware rapidamente ou manter rotas durante uma mudança é depois que um serviço de produção já está sob pressão.

As perguntas de due diligence são concretas

O comprador não precisa de uma grande auditoria para começar. Precisa de uma tabela que divida cada serviço prometido em proprietários e relógios de restauração. Para energia, deve perguntar pela carga atual do rack, data do teste de bateria do UPS, data do teste do gerador, contrato de combustível, prática de bypass de manutenção e draw seguro máximo por rack durante resfriamento comprometido. Para resfriamento, deve perguntar como o design 4+1 do Hiref se comporta quando uma unidade está inativa, onde a temperatura é medida e se os racks de alta densidade são desclassificados.

Para rede, deve perguntar pelos contratos upstream reais, taxas comprometidas, velocidades de porta, participação em route server, prefixos cobertos por RPKI, contatos de filtro de rota e o registro de teste de failover para cada prefixo. Deve separar 91.194.2.0/23 de 94.232.251.0/24 porque os registros de registro diferem. Deve perguntar se o IPv6 está disponível, mesmo que nenhuma rota IPv6 visível tenha aparecido na observação do RIPEstat. Deve perguntar se o painel do cliente, e-mail de suporte e comunicação de status dependem das mesmas rotas AS51520.

Para hardware, deve perguntar o que a Datalogika possui, o que o cliente possui e o que um fornecedor relacionado possui. Deve perguntar por discos sobressalentes, fontes de alimentação sobressalentes, portas de switch sobressalentes, óptica, trilhos, limites de suporte remoto e tempo de substituição por produto. Clientes de servidor alugado devem perguntar se o serviço é apoiado por máquinas sobressalentes idênticas ou por uma fila de construção. Clientes de colocation devem perguntar se o suporte remoto pode trocar unidades, conectar um crash cart, reinstalar memória, mover um patch cord ou enviar equipamento com falha.

Para suporte, deve perguntar por acesso noturno, nomes de escalonamento, metas de resposta e restauração, manuseio de falhas simultâneas e o caminho de comunicação se o painel WHMCS estiver inacessível. Deve testar os caminhos de telefone e e-mail antes de assinar. Também deve perguntar se faturas, avisos de suspensão e eventos de renovação podem ser tratados manualmente se o painel estiver inativo.

Para localidade, deve perguntar se todos os dados do cliente permanecem na instalação de Dolgoprudny, se backups são oferecidos, se algum suporte terceirizado vê sistemas do cliente, o que acontece com unidades com falha e qual evidência está disponível para descarte de mídia com dados. A alegação de localização russa é útil apenas se o manuseio operacional de mídia, backup e migração for igualmente explícito.

Nenhuma dessas perguntas é exótica. São as perguntas comuns escondidas sob um preço mensal baixo. A Datalogika publica detalhes suficientes para tornar as perguntas dignas de serem feitas. Não publica o suficiente para permitir que os compradores as ignorem.

O veredito operacional

A "Datalogika" Ltd. deve ser tratada como um operador de hospedagem pequeno e ativo com evidências reais de infraestrutura pública. A empresa tem um endereço coerente em Dolgoprudny em seu próprio site e registro de organização RIPE, um sistema de pedidos JPE.ru acessível, produtos de colocation e servidor alugado, uma descrição detalhada da instalação, um AS anunciado, dois prefixos IPv4 visíveis, um contato público de abuso em seu próprio domínio e páginas de roteamento externas que mostram presença upstream e de troca. Esse é um piso significativo.

O teto é mais baixo do que a linguagem de marketing pode implicar. Uma alegação de alinhamento Tier 3 não é o mesmo que um prêmio de certificação pública. Uma opção de interface de 100 Gb não é o mesmo que capacidade de failover comprometida. Uma alegação de combustível de gerador por 48 horas não é o mesmo que um incidente testado de vários dias. Múltiplos peers não são o mesmo que entradas de fibra separadas. Um endereço russo não é o mesmo que um plano completo de soberania de dados e saída. Um botão de pedido WHMCS não é o mesmo que estoque de hardware.

A lacuna de evidência mais importante não é se a empresa existe. É como a capacidade se recupera quando a sala, a rota, o balcão de suporte e o painel do cliente são estressados juntos. O melhor caso da Datalogika é atraente: um operador pequeno e prático com uma sala específica, preços modestos, suporte local e visibilidade de roteamento suficiente para atender clientes que precisam de capacidade de rack ou servidor localizada na Rússia. Seu caso mais fraco é a concentração: uma sala, uma equipe pequena, um conjunto de endereços e dependências de fornecedores que podem não ser visíveis até que uma janela de reparo se abra.

Isso torna a regra de compra simples. Use a Datalogika para cargas de trabalho cujo risco se encaixa em um host físico pequeno, ou exija prova antes de colocar cargas de trabalho que precisam de failover medido, continuidade fora do local ou portabilidade rápida. A empresa vende capacidade hospedada, mas o serviço ainda é feito de racks, energia, trânsito, hardware e pessoas. O trabalho do comprador é tornar cada um desses elementos visíveis antes que a primeira interrupção os torne óbvios.