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

Resumo

• "Datalogika" Ltd. emite sinais operacionais atuais: seu site público vende colocation em um data center em Dolgoprudny, o painel de controle JPE.ru oferece produtos de rack, meio rack, servidor único e servidor alugado, e o RIPEstat mostrou AS51520 anunciado em 12 de julho de 2026 com 768 endereços IPv4 e ampla visibilidade IPv4.
• A ancoragem física é incomumente precisa para um pequeno hospedeiro. "Datalogika" indica que sua sala tem 170 m², 70 racks abertos, potência média de 4,2 kW e máxima de 7 kW por rack, um UPS de 400 kVA, um transformador de 400 kW, um gerador a diesel de 550 kW, 5 000 litros de combustível e autonomia reivindicada de 48 horas.
• As evidências públicas ainda são incompletas onde a resiliência dos clientes está em jogo. Não há teste de carga público, certificação, contrato upstream, mapa de roteamento da operadora, plano de peças sobressalentes, registro de pessoal de suporte, procedimento de acesso às instalações, registro de restauração de backup ou plano de migração de cliente.
• A melhor leitura é uma pequena operadora de hospedagem russa ativa, com uma história local significativa e um AS visível, e não uma plataforma em nuvem cuja capacidade utilizável, diversidade física ou limites de recuperação podem ser deduzidos apenas do marketing.

A venda é um rack antes de ser uma nuvem

A palavra "hospedado" pode dar a impressão de um serviço elástico, mas a oferta da "Datalogika" é fisicamente brutal. O site da empresa indica que ela colocará o equipamento do cliente em seu próprio data center em Moscou, e a página vende um rack completo ou um espaço por unidade. A seção de preços públicos atual emdatalogika.rulista um rack com 4 kW a partir de 80.000 RUB por mês e um espaço por unidade com 0,3 kW a partir de 3.100 RUB por mês. Ela indica que a potência média fornecida a um rack é de 4,2 kW, a máxima de 7 kW, que os canais globais de Internet no data center excedem 100 Gb, e que uma porta de Internet "Full View" de 100 Mb está incluída gratuitamente.

Não é a linguagem de uma região hyperscale abstrata. É a linguagem de uma sala, de uma PDU de rack, de uma interconexão, de uma equipe de suporte e de uma fatura. A mesma página indica que a montagem, a conexão, a configuração dos equipamentos de telecomunicação e o suporte 24 horas por dia, 7 dias por semana estão incluídos para os clientes. Ela também anuncia interfaces de 100 Mb, 1 Gb, 10 Gb, 40 Gb e 100 Gb, e especifica que, sob solicitação, "Datalogika" pode conectar um cliente a qualquer fornecedor por meio de um canal de camada 2.

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

O painel de controle público torna a oferta mais tangível. A página da loja WHMCS da JPE.ru paracolocação de equipamentolista três produtos: colocação de servidor único a partir de 3.100 RUB por mês, aluguel de rack completo a partir de 80.000 RUB por mês e aluguel de meio rack a partir de 52.000 RUB por mês. Uma página separada da JPE.ru paraaluguel de servidoroferece servidores configuráveis a partir de 2.350 RUB, com opções de CPU, memória, disco, chassi e canal. A página de produto WHMCS correspondente paraservidores alugadoslista "Аренда сервера - Конструктор" ao mesmo preço inicial e indica 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 discos e configuração. Um cliente que aluga um servidor depende do chassi sobressalente, processadores, memória, discos, práticas de instalação e fila de intervenção remota do anfitrião.

Em ambos os casos, o serviço visível ao cliente pode ser um site, um sistema de faturamento, um servidor de jogo, um provedor de e-mail, um aplicativo empresarial ou um 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, híbrida. Ela vende espaço em rack, colocação unitária e capacidade de servidor hospedado a partir do mesmo ambiente de marca pública. Os compradores não devem reduzir isso a uma única promessa. Um cliente de colocation 1U precisa de clareza sobre o acesso ao seu próprio hardware, suportes de substituição, limites de intervenção remota e transferência de operadora. Um cliente de rack completo precisa de margem de potência, restrições de refrigeração, condições de interconexão e um plano para o trabalho dentro do rack durante a manutenção da sala compartilhada.

Um cliente de servidor alugado precisa de inventário, tempo de reconstrução, política de retenção de discos, disponibilidade de imagens e o caminho de saída do serviço. As páginas públicas mostram o menu. Elas não mostram como a cozinha se comporta em horários de pico.

A ancoragem física é incomumente visível

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

A sala em si é descrita em termos operacionais. A "Datalogika" indica que a área da sala é de 170 m² e que 70 racks de servidores abertos estão instalados. Ela nomeia um UPS Gamatronic Power+ de 400 kVA e especifica que ele fornece 10 minutos de operação após a perda da energia elétrica. Ela indica que o data center possui seu próprio transformador de 400 kW, um gerador a diesel contêiner Wilson de 550 kW, um reservatório de combustível de 5.000 litros e combustível suficiente para 48 horas de operação autônoma.

Ela especifica que a transferência do transformador para o gerador leva um minuto, enquanto o UPS sustenta os equipamentos.

A refrigeração também é precisa. A "Datalogika" indica o uso de climatizadores industriais de precisão Hiref com capacidade de refrigeração de 76 kW em esquema 4+1. O ar frio é fornecido sob um piso elevado de 0,4 m em corredores frios. O acesso é descrito como controlado por crachá, com guardas, videomonitoramento e extinção automática 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 refrigeração, localização do condensador, manutenção do painel de incêndio, controle de acesso e a quantidade real de carga de TI instalada na sala.

A empresa também usa a linguagem de níveis (Tier), mas a leitura cuidadosa é restrita. O site indica que o data center "corresponde" aos requisitos de confiabilidade de nível Tier 3, com um prédio cercado separado, duplicação N+1 e infraestruturas e comunicações redundantes. Um artigo da "Datalogika" sobrecomo escolher um data centerdiscute explicitamente a existência de um certificado Tier III e diz que a certificação tem um custo; ele indica que a JPE orientou seu trabalho e equipamento técnico para esses padrões e convida clientes potenciais a avaliar a conformidade. Osistema de classificação de níveisdo Uptime Institute trata a certificação Tier como um quadro de avaliação formal, e sua explicação do Tier III enfatiza a mantenabilidade concorrente. Sem recompensa pública ou certificado apresentado ao cliente, a menção Tier 3 da "Datalogika" deve ser lida como uma afirmação de design e operação, não como evidência de instalação certificada.

Os números em si também precisam de contexto de carga. Um transformador de 400 kW, um gerador de 550 kW e um UPS de 400 kVA podem ser críveis para uma pequena sala, mas a margem depende do consumo real de TI, carga de refrigeração, estado da bateria do UPS, fator de potência, práticas de desvio de manutenção, confiabilidade de partida do gerador e quantos racks estão efetivamente vendidos em alta densidade. Setenta racks na média anunciada de 4,2 kW implicariam 294 kW de carga de TI antes de refrigeração 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 extrair a potência máxima ao mesmo tempo, quantos racks estão instalados e vendidos, ou como a sala aloca a potência quando vários clientes solicitam mais.

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

A pegada da empresa apoia a continuidade, não a escala

Os sinais jurídicos 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 da empresa russa noAudit-it, citando registros públicos oficiais, lista a entidade legal como ativa, fornece o endereço de Dolgoprudny, identifica a atividade principal como documentação de telecomunicações, indica que o registro ocorreu em 16 de setembro de 2008 e relata uma receita de 2025 de 28,3 milhões de RUB.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. Uma receita de 2025 de cerca de 28,3 milhões de RUB é compatível com uma pequena sala, pessoal limitado, adoção modesta de colocation, vendas de servidores alugados e trabalhos de hospedagem relacionados. Isso 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 uma empresa relacionada possui ativos fora desta entidade legal.

A família de sites dá outro sinal de continuidade. A página principal da "Datalogika" redireciona paralk.jpe.rupara seleção de produtos e para a 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 no prefixo 91.194.2.0/23 originado do AS51520.

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

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

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

O preço deve financiar o relógio de reparo

Os preços públicos da "Datalogika" são baixos o suficiente para que a economia faça parte da história da resiliência. Um espaço de servidor único por 3.100 RUB por mês, um construtor de servidor alugado por 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 venda. Eles são o pool do qual o hospedeiro deve pagar eletricidade, refrigeração, combustível, provedores upstream, switches, óptica, peças de servidor, software, contabilidade, aluguel ou custos imobiliários, impostos, visitas de manutenção e as pessoas que respondem quando algo falha.

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

É por isso que o artigo não trata os itens anunciados como "gratuitos" como sendo sem custo. Uma porta incluída de 100 Mb consome capacidade de switch, capacidade de roteamento e largura de banda upstream. Montagem e configuração incluídas consomem tempo de pessoal. O transporte do equipamento do cliente por conta da empresa consome tempo de veículo, risco de embalagem e um dia de 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 reproduzível.

Essas inclusões podem ser uma vantagem real para um pequeno cliente que de outra forma precisaria coordenar vários fornecedores. Elas também podem se tornar uma fila quando muitos clientes precisam das mesmas pessoas ao mesmo tempo.

A receita de 2025 relatada peloAudit-itfornece contexto de escala sem provar qualidade de serviço. Uma receita de 28,3 milhões de RUB pode sustentar 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 supor um estoque profundo de peças sobressalentes, uma grande equipe de engenheiros noturnos, vários locais remotos ou trânsito excedente comprado para eventos de pico raros. A suposição correta não é fraqueza. A suposição correta é que cada recurso de recuperação prometido deve ser financiado deliberadamente.

É também por isso que os clientes de meio rack e rack completo não devem comparar apenas os preços mensais básicos. Eles devem perguntar como os excessos de potência são cobrados, se as interconexões incorrem em taxas recorrentes, se as interfaces de maior velocidade exigem upgrade de porta, se um cliente pode comprar largura de banda comprometida em vez de acesso compartilhado, se as tarefas de intervenção remota têm limites de tempo e se o trabalho de emergência é precificado de forma diferente do trabalho planejado. Um preço base baixo com extras pagos pode ser perfeitamente razoável se o contrato o especificar.

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

Para clientes de servidores alugados, 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 hospedeiro deve recuperar o custo do chassi, discos, memória, energia, refrigeração, posição no rack e tempo de substituição ao longo de vários meses. Isso tende a favorecer construções padrão, substituição instantânea limitada e controle cuidadoso de solicitações incomuns.

Clientes que precisam de reconstruções rápidas, retenção especial de discos, alta resistência de gravação, muita memória ou alto compromisso de rede devem esperar pagar mais ou receber uma promessa escrita mais restrita.

O teste de compra mais útil não é "a "Datalogika" é barata?", mas "o que o preço compra em caso de falha?" Se a resposta for uma sala modesta, um endereço russo nomeado, ajuda prática concreta e capacidade alugada na melhor das hipóteses, 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 deduzidos de uma taxa de hospedagem geral.

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

A evidência operacional atual mais sólida é a alcançabilidade de rede. Avisão geral AS do RIPEstat para AS51520identifica o titular comoRH "Datalogika" Ltd.e marcou o ASN anunciado no momento da observação de 12 de julho de 2026. Ostatus de roteamentodo RIPEstat mostrou dois prefixos IPv4, 768 endereços IPv4, visibilidade em 326 dos 327 pares IPv4 do RIPE RIS e nenhuma rota IPv6 visível. Suavisão de prefixos anunciadoslistava 91.194.2.0/23 e 94.232.251.0/24.

A imagem dos 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.O registro 91.194.2.0/23vincula o bloco a ORG-DL620-RIPE, país RU e status provider-independent atribuído.O registro 94.232.251.0/24é diferente: é um espaço agregável por provedor atribuído com a 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 bloco de endereços roteado da "Datalogika" deve ser separado em espaço detido ou registrado pela "Datalogika" e espaço roteado pela "Datalogika" mas registrado em outra organização. A distinção não é necessariamente um problema. Operadores de hospedagem frequentemente originam espaço de cliente, empresa relacionada ou detido por provedor. Isso 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.

A portabilidade de endereços, gerenciamento de contatos de abuso, filtragem de prefixos, mudanças de RPKI e reoriginação de emergência podem todos depender de quem controla o recurso e quem pode assinar ou manter os objetos de rota.

RPKI adiciona a mesma nuance. O endpoint de validação do RIPEstat retornoudesconhecidopara AS51520 originando 91.194.2.0/23, enquanto oresultado para 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 rota inválida, mas uma rota desconhecida dá menos garantia criptográfica do que uma rota válida.

As páginas de roteamento secundárias concordam amplamente na forma enquanto adicionam mais nomes.bgp.tools para AS51520identifica"Datalogika" Ltd., indica que o AS origina dois prefixos IPv4 e nenhum IPv6, lista provedores upstream 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.. Apágina BGP do Hurricane Electric para AS51520relata dois prefixos IPv4 originados, nenhum prefixo IPv6 originado, 768 endereços IPv4 originados, 31 pares IPv4 observados e três trocas de Internet: Eurasia Peering IX em Moscou, PITER-IX Moscou e Sibir-IX em Krasnoyarsk.

PeeringDB é mais conservador. Suaentrada API de rede para AS51520nomeia "Krasnoyarsk network", vincula o sitehttp://www.kraslan.ru, indica que a política é aberta, e registra um número de IX e nenhuma instalação. Suaentrada netixlanmostra uma porta 10Gb operacional no Eurasia Peering IX com endereço IPv4 185.232.60.109. A diferença entre a imagem autodeclarada de um IX pelo PeeringDB e a visão de troca mais ampla do HE é exatamente por que um artigo não deve assimilar uma página de roteamento a diversidade física. A Internet pública pode ver as adjacências; ela não vê todas as ordens de interconexão, compromissos de porta, condições de manutenção, entradas de fibra ou salas compartilhadas.

Avisão de vizinhos do RIPEstatrelatou 20 vizinhos observados no momento da pesquisa, com AS31500 carregando de longe o maior peso visível naquele endpoint. Isso apoia a suposição da atribuição de que a Global Network Management é o provedor upstream visível principal, mas o resultado ainda necessita de redação cuidadosa. "Vizinho observado" não é o mesmo que contrato de provedor. Alguns vizinhos são pares, alguns podem ser downstream, alguns podem ser artefatos de servidor de rotas, e alguns podem aparecer ou desaparecer com a política. O fato de AS51520 ter vários vizinhos observados é bom. O fato de um provedor upstream visível dominar é uma questão de resiliência.

A diversidade de trânsito não é diversidade de restauração

A própria página da "Datalogika" indica que os canais globais de Internet no data center excedem 100 Gb e que ela 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 evidência de que um determinado cliente recebe um caminho de 100 Gb comprometido. Canais globais de Internet não são o mesmo que capacidade de failover não congestionada. Se o maior provedor upstream falhar, a questão é quanto tráfego de cliente os caminhos sobreviventes podem transportar sem perda, jitter ou limitação comercial.

É aqui que a economia dos pequenos hospedeiros se torna prática. Um grande operador pode ter trânsito de reserva, múltiplas fibras urbanas, caminhos ópticos separados, um segundo centro de operações e comunicações formais para incidentes principais. Um pequeno hospedeiro ainda pode ser confiável, especialmente se sua base de clientes é modesta e seus técnicos conhecem cada rack. Mas um pequeno hospedeiro tem menos lugares para esconder o estresse. Um roteador com falha, um par saturado, um técnico indisponível, uma porta de instalação fechada ou uma janela de manutenção de provedor podem afetar uma grande parte da base de clientes.

Orelatório de 2024 da ENISA sobre incidentes de segurança em telecomunicaçõesé ú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 software defeituoso ou mudanças de atualização estão entre as principais causas técnicas relacionadas a erro humano. Resumos de incidentes mais antigos da ENISA também identificaram falhas de sistema e cortes de energia como motores recorrentes de interrupções. Essas categorias se relacionam diretamente a um pequeno hospedeiro: obras civis podem cortar um caminho de fibra; uma mudança de roteador pode vazar ou retirar rotas; uma transição de energia pode expor uma cadeia de UPS fraca; um lote de discos defeituoso pode esgotar as peças sobressalentes.

A oferta pública da "Datalogika" menciona suporte 24 horas por dia, 7 dias por semana, montagem e configuração incluídos e intervenção remota em seus conselhos de artigo. Ela não publica registro de pessoal de suporte, sequência de escalação, lista de roteadores sobressalentes, SLA de reparo de interconexão, calendário de manutenção, página de status, arquivo de falhas ou registro pós-incidente. Essas ausências não são constatações de mau desempenho. São limites ao que um comprador pode deduzir. Um hospedeiro pode ter excelentes procedimentos privados e publicar pouco.

Um comprador com cargas de trabalho públicas deve pedir para ver os procedimentos antes de considerar o serviço como resiliente.

O relógio de reparo também muda de acordo com o tipo de falha. Um disco defeituoso 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 de cliente com falha em colocation pode exigir que o cliente forneça peças ou autorize uma tarefa prática. Um módulo de UPS com falha pode exigir suporte do fabricante. Um corte de fibra pode ser responsabilidade de uma transportadora upstream ou metropolitana. Um vazamento de rota pode exigir coordenação com pares, servidores de rotas e trânsito.

Uma falha no painel de faturamento pode bloquear a ação do cliente mesmo que os pacotes continuem fluindo. O cliente experimenta uma falha; o hospedeiro 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 sólidas nas especificações da sala e na ordenação de produtos, mas o registro público é mais fraco na restauração medida. A lacuna é onde um comprador deve negociar.

A localidade é um recurso, mas também encolhe o caminho de saída

A "Datalogika" vende explicitamente um endereço russo como valioso para empresas que tratam dados pessoais de usuários. Esta afirmação corresponde ao contexto de mercado. A entrada WILMAP de Stanford sobre aLei Federal nº 242-FZresume a regra de localização de dados pessoais russa como exigindo o processamento de dados pessoais de cidadãos russos 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. Ela pode melhorar a postura de conformidade, reduzir o tempo de viagem para clientes da região de Moscou, apoiar um serviço prático em russo e manter o hardware portador de dados em uma jurisdição conhecida. Ela também pode reduzir a portabilidade se o serviço depender de endereços IP locais, contratos locais, suporte em russo, peças sobressalentes no local ou arranjos de transportadora 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, modificar 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 na Rússia, a sala de Dolgoprudny pode satisfazer o requisito de localização. Mas se o cliente mais tarde 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 de instalação.

Um segundo local russo pode exigir outro fornecedor 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, retenção 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 pressão. Isso não torna o serviço inadequado. Significa que o comprador possui a pergunta.

A localização dos dados também afeta o gerenciamento de imagens e discos 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 defeituosos são tratados? Um cliente pode solicitar destruição, devolução, retenção ou prova de apagamento? Se o cliente coloca seu próprio equipamento, o hospedeiro pode remover a mídia apenas com aprovação por escrito? Se o hospedeiro 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, mas elas são centrais para a promessa implícita de 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 que valorizam a abordagem prática de um pequeno operador. Não deve ser tratada como capacidade de nuvem automaticamente portável. A localidade não é apenas uma coordenada geográfica; é uma restrição de recuperação e saída.

Seis falhas definem o verdadeiro serviço

Uma falha de energia ou refrigeração de um rack

A história da sala começa com energia e refrigeração. A "Datalogika" nomeia seu UPS, transformador, gerador, reserva de combustível e sistema de refrigeração. Um cliente deve perguntar como esses componentes se relacionam com seu próprio rack. As alimentações A e B estão disponíveis? Cada rack tem alimentação redundante? O que acontece quando um caminho de alimentação é 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 do máximo de 7 kW? Os racks de alta densidade estão distribuídos pelos corredores frios ou agrupados?

Como uma falha de uma unidade de refrigeração é testada sob calor de verão?

As partes interessadas não são apenas os clientes de um único rack. Se a refrigeração é restrita, os 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 estão mais fracas do que o esperado, a janela de partida prometida do gerador se torna mais apertada. A página pública indica que a manutenção preventiva não para o data center. Um comprador deve perguntar sobre o último evento de manutenção onde isso foi demonstrado.

Uma falha de provedor upstream ou 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. o bgp.tools lista AS31500 e AS5467 como provedores upstream, e o HE lista três trocas de Internet. Isso é evidência positiva de que a "Datalogika" não está apenas fazendo NAT atrás da banda larga de outro provedor. Ela tem um AS, origina seu espaço de endereçamento e faz peering ou trânsito em roteamento público.

A questão da falha é se os caminhos sobreviventes podem transportar a carga do cliente. Se o AS31500 for retirado, todos os prefixos permanecem visíveis por outros caminhos? O comportamento de 94.232.251.0/24 é diferente de 91.194.2.0/23 porque o controle de registro difere? Os filtros de rota, limites máximos de prefixo e configurações de RPKI são testados? Existe um contato para mudanças de rota documentado fora da sala afetada? O painel do cliente e o e-mail de suporte são acessíveis por um caminho diferente? A visibilidade BGP pública não responde a essas perguntas; ela 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, HDDs de 1 TB a 10 TB, SSDs de 240 GB a 960 GB e chassis 1U a 3U com uma ou duas fontes de alimentação. Isso é uma oferta de hardware configurável, não uma divulgação de estoque. Um pequeno hospedeiro pode fazer isso bem se armazenar peças comuns e manter limites claros em construções personalizadas.

Ele pode ter dificuldades se uma falha afetar um chassi raro, um tamanho de disco que não está mais em estoque, um controlador antigo, uma peça de alimentação dupla ou um cliente que precisa de uma substituição exata.

O comprador deve perguntar quais componentes são armazenados 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 hospedeiro deve indicar se um cliente recebe hardware de substituição, hardware temporário ou reparo adiado. Para colocation, o cliente deve saber quais tarefas a intervenção remota executará e quais exigem que o cliente envie peças ou vá ao local.

Um gargalo de suporte

O suporte 24 horas por dia, 7 dias por semana só tem valor se a fila de suporte tiver pessoas suficientes com autoridade suficiente. A página pública da "Datalogika" indica que o suporte é gratuito para todos os clientes e a página de artigo indica que o equipamento está sob observação contínua por especialistas do serviço técnico. O registro público não identifica o número de funcionários, padrões de turno, subcontratados, autoridade de escalação, cobertura de idioma, metas de resposta a chamados ou prática de incidente simultâneo.

Pequenos operadores frequentemente ganham porque engenheiros experientes respondem diretamente em vez de rotear 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 fazer trabalho elétrico, quem pode tocar nos suportes do cliente, quem pode autorizar escalações de transportadora e o que acontece se vários clientes solicitarem intervenção remota durante a mesma falha.

Uma falha de faturamento ou painel de controle

A porta de entrada do cliente importa. As páginas de produtos públicos e o fluxo de login estão em lk.jpe.ru, que resolve na mesma faixa de endereços 91.194.2.0/23. O painel WHMCS é um meio normal para um pequeno hospedeiro vender, faturar e suportar serviços. Ele também se torna parte da superfície de resiliência. Se a mesma falha de instalação ou roteamento afetar tanto as cargas de trabalho dos clientes quanto o painel, os clientes podem perder o canal comum para chamados, pedidos e faturas exatamente quando mais precisam.

O comprador deve solicitar um caminho de suporte fora de banda: telefone, e-mail alternativo, página de status externa ou contato de escalação nomeado. Ele 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 em momentos de estresse.

Uma falha de migração ou saída

A falha final não é uma falha súbita, mas uma mudança que não pode ser concluída. Um cliente pode sair por 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 retirada física, embalagem remota, alfândega ou transporte, regras sobre mídia portadora de dados e tempo de inatividade coordenado.

Para servidores alugados, a saída pode envolver exportação de imagem, janelas rsync, alterações de DNS, atualizações de firewall, renumeração e verificação de que os discos antigos foram apagados ou devolvidos conforme a regra acordada.

As páginas públicas da "Datalogika" não definem portabilidade de dados. Elas também não mostram se os clientes podem trazer seu próprio espaço IP, anunciá-lo via AS51520, reter um bloco após sair ou transferir endereços para outro provedor. Isso é normal para um pequeno site público, mas deve ser coberto nos termos do contrato. O pior momento para descobrir que um hospedeiro 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 auditoria completa para começar. Ele precisa de uma tabela que divida cada serviço prometido em proprietários e relógios de restauração. Para energia, ele deve perguntar a carga atual do rack, a data do último teste de bateria do UPS, a data do último teste do gerador, o contrato de combustível, a prática de desvio de manutenção e a potência máxima segura por rack em caso de degradação de refrigeração. Para refrigeração, ele deve perguntar como o design 4+1 da Hiref se comporta quando uma unidade falha, onde a temperatura é medida e se os racks de alta densidade são desclassificados.

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

Para hardware, ele deve perguntar o que a "Datalogika" possui, o que o cliente possui e o que um fornecedor relacionado possui. Ele deve perguntar sobre discos sobressalentes, fontes de alimentação sobressalentes, portas de switch sobressalentes, óptica, trilhos, limites de intervenção e prazos de substituição por produto. Clientes de servidores alugados 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 a intervenção remota pode trocar discos, conectar um carrinho de diagnóstico, reposicionar memória, mover um patch cord ou enviar hardware com defeito.

Para suporte, ele deve perguntar acesso noturno, nomes de escalação, metas de resposta e restauração, gerenciamento de falhas simultâneas e caminho de comunicação se o painel WHMCS estiver inacessível. Ele deve testar os caminhos de telefone e e-mail antes de assinar. Ele também deve perguntar se faturas, avisos de suspensão e eventos de renovação podem ser gerenciados manualmente se o painel falhar.

Para localidade, ele deve perguntar se todos os dados do cliente permanecem na instalação de Dolgoprudny, se backups são oferecidos, se suporte terceirizado vê sistemas de clientes, o que acontece com discos defeituosos e quais evidências estão disponíveis para eliminação de mídia portadora de dados. A afirmação de localização russa só é útil se o gerenciamento operacional de mídia, backups e migração também for explícito.

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

O veredito operacional

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

O teto é mais baixo do que a linguagem de marketing pode sugerir. Uma afirmação de alinhamento Tier 3 não é o mesmo que uma certificação pública concedida. Uma opção de interface de 100 Gb não é o mesmo que capacidade de failover comprometida. Uma afirmação de 48 horas de combustível de gerador não é o mesmo que um incidente de vários dias testado. Múltiplos pares não são o mesmo que entradas de fibra separadas. Um endereço russo não é o mesmo que um plano abrangente de soberania de dados e saída. Um botão de pedido WHMCS não é o mesmo que um 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, a mesa de suporte e o painel do cliente são estressados juntos. O melhor caso da "Datalogika" é atraente: um pequeno operador prático com uma sala específica, preços moderados, suporte local e visibilidade de roteamento suficiente para atender clientes que precisam de capacidade de rack ou servidor localizada na Rússia. Seu pior caso é concentração: uma sala, uma equipe pequena, um bloco de endereços e dependências de fornecedor 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 corresponda a um pequeno hospedeiro físico, ou exija evidências antes de colocar cargas de trabalho que exigem 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 falha os torne óbvios.