Résumé
- "Datalogika" Ltd. émet des signaux d'exploitation actuels: son site public vend de la colocation dans un centre de données à Dolgoprudny, le panneau de commande JPE.ru propose des produits de baie, demi-baie, serveur unique et serveur loué, et RIPEstat a montré AS51520 annoncé le 12 juillet 2026 avec 768 adresses IPv4 et une large visibilité IPv4.
- L'ancrage physique est inhabituellement précis pour un petit hébergeur. "Datalogika" indique que sa salle fait 170 m², 70 baies ouvertes, une puissance moyenne de 4,2 kW et maximale de 7 kW par baie, un onduleur de 400 kVA, un poste de transformation de 400 kW, un groupe électrogène diesel de 550 kW, 5 000 litres de carburant et une autonomie revendiquée de 48 heures.
- Les preuves publiques sont encore incomplètes là où se joue la résilience des clients. Il n'existe aucun test de charge public, certification, contrat d'amont, carte de routage opérateur, planning de pièces détachées, registre du personnel d'assistance, procédure d'accès aux installations, enregistrement de restauration de sauvegarde ou plan de migration client.
- La meilleure lecture est un petit opérateur d'hébergement russe actif, avec une histoire locale significative et un AS visible, et non une plateforme cloud dont la capacité utilisable, la diversité physique ou les limites de récupération peuvent être déduites du seul marketing.
La vente est une baie avant d'être un cloud
Le mot "hébergé" peut donner l'impression d'un service élastique, mais l'offre de "Datalogika" est physiquement brutale. Le site de l'entreprise indique qu'elle placera l'équipement du client dans son propre centre de données à Moscou, et la page vend soit une baie complète, soit un emplacement par unité. La section tarifaire publique actuelle surdatalogika.ruliste une baie avec 4 kW à partir de 80 000 RUB par mois et un emplacement par unité avec 0,3 kW à partir de 3 100 RUB par mois. Elle indique que la puissance moyenne fournie à une baie est de 4,2 kW, le maximum de 7 kW, que les canaux Internet globaux dans le centre de données dépassent 100 Gb, et qu'un port Internet "Full View" de 100 Mb est inclus gratuitement.
Ce n'est pas le langage d'une région hyperscale abstraite. C'est le langage d'une salle, d'une PDU de baie, d'une interconnexion, d'une équipe de support et d'une facture. La même page indique que le montage, la connexion, la configuration des équipements de télécommunication et le support 24h/24 et 7j/7 sont inclus pour les clients. Elle annonce également des interfaces 100 Mb, 1 Gb, 10 Gb, 40 Gb et 100 Gb, et précise que, sur demande, "Datalogika" peut connecter un client à n'importe quel fournisseur via un canal de couche 2.
La promesse est large; la conséquence physique est que chaque commande client doit consommer un port, une marge de puissance, un chemin de câble, une capacité de commutateur, du temps technicien et une relation commerciale avec le transporteur sélectionné.
Le panneau de commande public rend l'offre plus tangible. La page de boutique WHMCS de JPE.ru pourle placement d'équipementliste trois produits: placement d'un seul serveur à partir de 3 100 RUB par mois, location de baie complète à partir de 80 000 RUB par mois et location de demi-baie à partir de 52 000 RUB par mois. Une page JPE.ru séparée pourla location de serveurpropose des serveurs configurables à partir de 2 350 RUB, avec options de CPU, mémoire, disque, châssis et canal. La page de produit WHMCS correspondante pourles serveurs louésliste "Aренда сервера - Конструктор" au même prix de départ et indique que 100 Mb/s plus une adresse IPv4 sont inclus gratuitement.
Cela importe car la colocation et les serveurs loués échouent différemment. Un client en colocation apporte son propre équipement et conserve donc plus de responsabilité pour le cycle de vie du matériel, l'état du système d'exploitation, le remplacement des disques et la configuration. Un client louant un serveur dépend du châssis de rechange, des processeurs, de la mémoire, des disques, des pratiques d'installation et de la file d'attente d'intervention à distance de l'hôte.
Dans les deux cas, le service visible du client peut être un site web, un système de facturation, un serveur de jeu, un hébergeur de messagerie, une application d'entreprise ou un nœud de stockage, mais le chemin de rétablissement commence par une personne atteignant une baie sous tension et décidant quel composant physique a échoué.
L'identité commerciale de "Datalogika" est donc hybride. Elle vend de l'espace baie, du placement unitaire et de la capacité de serveur hébergée depuis le même environnement de marque publique. Les acheteurs ne devraient pas réduire cela à une seule promesse. Un client de colocation 1U a besoin de clarté sur l'accès à son propre matériel, les supports de remplacement, les limites d'intervention à distance et le transfert opérateur.
Un client de baie complète a besoin de marge de puissance, de contraintes de refroidissement, de conditions d'interconnexion et d'un plan pour le travail à l'intérieur de la baie pendant la maintenance de la salle partagée. Un client de serveur loué a besoin d'inventaire, de temps de reconstruction, de politique de conservation des disques, de disponibilité des images et du chemin de sortie du service. Les pages publiques montrent le menu. Elles ne montrent pas comment la cuisine se comporte en période d'affluence.
L'ancrage physique est inhabituellement visible
"Datalogika" fournit une description d'installation plus détaillée que beaucoup de petits hébergeurs. La section installation deson siteplace le bâtiment du centre de données à Dolgoprudny, dans l'oblast de Moscou, au 3 rue Zhukovskogo, et précise que cette adresse russe est importante pour les entreprises traitant les données personnelles des utilisateurs. Le pied de page répète le nom légal en russe, l'adresse de Dolgoprudny, l'INN 5008048758, le KPP 500801001 et l'OGRN 1085047011334. L'objet organisation de RIPE pourORG-DL620-RIPEnomme également"Datalogika" Ltd., donne le pays RU, le numéro d'enregistrement 1085047011334 et utilise la même adresse de rue à Dolgoprudny.
La salle elle-même est décrite en termes opérationnels. "Datalogika" indique que la superficie de la salle est de 170 m² et que 70 baies de serveurs ouvertes sont installées. Elle nomme un onduleur Gamatronic Power+ de 400 kVA et précise qu'il assure 10 minutes de fonctionnement après la perte de l'alimentation secteur. Elle indique que le centre de données possède son propre poste de transformation de 400 kW, un groupe électrogène diesel conteneurisé Wilson de 550 kW, une réserve de carburant de 5 000 litres et assez de carburant pour 48 heures de fonctionnement autonome.
Elle précise que le transfert du poste de transformation au groupe électrogène se fait en une minute, tandis que l'onduleur porte les équipements.
Le refroidissement est également précis. "Datalogika" indique utiliser des climatiseurs industriels de précision Hiref avec une capacité de refroidissement de 76 kW dans un schéma 4+1. L'air froid est fourni sous un plancher surélevé de 0,4 m dans des couloirs froids. L'accès est décrit comme contrôlé par badge, avec des gardes, une vidéosurveillance et une extinction automatique par gaz inerte.
Ce sont des affirmations utiles car elles identifient les éléments qui doivent être inspectés: charge de l'onduleur, historique des tests du groupe électrogène, contrats de carburant, capacité de refroidissement, emplacement du condenseur, maintenance du tableau incendie, contrôle d'accès et la quantité réelle de charge informatique installée dans la salle.
L'entreprise utilise également le langage des niveaux (Tier), mais la lecture prudente est étroite. Le site indique que le centre de données "correspond" aux exigences de fiabilité de niveau Tier 3, avec un bâtiment clôturé séparé, une duplication N+1 et des infrastructures et communications redondantes. Un article de "Datalogika" surcomment choisir un centre de donnéesdiscute explicitement de l'existence d'un certificat Tier III et dit que la certification a un coût; il indique que JPE a orienté son travail et son équipement technique vers ces normes et invite les clients potentiels à évaluer la conformité. Lesystème de classification des niveauxde l'Uptime Institute traite la certification Tier comme un cadre d'évaluation formel, et son explication du Tier III met l'accent sur la maintenabilité concurrente. Sans récompense publique ou certificat présenté au client, la mention Tier 3 de "Datalogika" doit être lue comme une affirmation de conception et d'exploitation, non comme une preuve d'installation certifiée.
Les chiffres eux-mêmes ont également besoin d'un contexte de charge. Un transformateur de 400 kW, un groupe électrogène de 550 kW et un onduleur de 400 kVA peuvent être crédibles pour une petite salle, mais la marge dépend de la consommation informatique réelle, de la charge de refroidissement, de l'état de la batterie de l'onduleur, du facteur de puissance, des pratiques de dérivation de maintenance, de la fiabilité du démarrage du groupe électrogène et du nombre de baies effectivement vendues à haute densité.
Soixante-dix baies à la moyenne annoncée de 4,2 kW impliqueraient 294 kW de charge informatique avant refroidissement et autres frais généraux. Soixante-dix baies au maximum annoncé de 7 kW impliqueraient 490 kW de charge informatique avant frais généraux. La page publique ne dit pas si chaque baie peut tirer la puissance maximale en même temps, combien de baies sont installées et vendues, ou comment la salle alloue la puissance lorsque plusieurs clients demandent plus.
C'est la différence entre capacité installée et capacité utilisable. La capacité installée est l'équipement nommé sur le site web. La capacité utilisable est ce qui reste après prise en compte de la maintenance, de la chaleur, des batteries, du carburant, des limites amont, des pièces détachées et du temps de support. La description publique de l'installation est suffisamment solide pour rendre "Datalogika" digne d'une vérification diligente. Elle n'est pas assez solide pour tarifer une migration critique sans visite sur site, relevés de charge et exercice de panne.
L'empreinte de l'entreprise soutient la continuité, pas l'échelle
Les signaux juridiques et de service public s'alignent autour d'une petite entreprise de longue date. Le pied de page dedatalogika.rudonne les identifiants légaux et les coordonnées bancaires. La page de profil d'entreprise russe surAudit-it, citant des registres publics officiels, liste l'entité légale comme active, donne l'adresse de Dolgoprudny, identifie l'activité principale comme documentation des télécommunications, indique que l'enregistrement a eu lieu le 16 septembre 2008, et rapporte un chiffre d'affaires 2025 de 28,3 millions de RUB.ZachestnyBiznesprésente indépendamment le même OGRN, INN, date d'enregistrement, statut actif et adresse.
Ces miroirs d'entreprise ne sont pas la même chose que de la télémétrie opérationnelle. Ils sont utiles pour l'échelle et la continuité, pas pour la qualité de service. Un chiffre d'affaires 2025 d'environ 28,3 millions de RUB est compatible avec une petite salle, un personnel limité, une adoption modeste de la colocation, des ventes de serveurs loués et des travaux d'hébergement connexes.
Cela ne prouve pas combien de clients sont actifs, combien de baies sont pleines, si l'entreprise possède le bâtiment, combien d'employés sont d'astreinte, combien de dettes sont liées à l'équipement de l'installation, ou si une entreprise connexe détient des actifs en dehors de cette entité légale.
La famille de sites donne un autre signal de continuité. La page principale de "Datalogika" renvoie verslk.jpe.rupour la sélection de produits et vers la marque JPE.ru dans le panneau client. Une requête DNS public Google pour lesenregistrements A de datalogika.rurésout le site principal en 91.194.2.25, tandis quejpe.rurésout également en 91.194.2.25 etlk.jpe.rurésout en 91.194.2.17. Lesenregistrements NS de datalogika.rusontns1.datalogika.ruetns2.datalogika.ru. Ces adresses se situent dans le préfixe 91.194.2.0/23 originaire de AS51520.
C'est une preuve que les portes d'entrée publiques des ventes et des comptes sont servies depuis le même parc d'adresses que "Datalogika" origine. Ce n'est pas une garantie que le panneau client, l'état de facturation, le catalogue de services et les canaux de support survivent à une perte de ce parc.
Si le site public, la boutique et le panneau de contrôle résident tous dans la même salle et le même bloc routé, alors une panne de l'installation de Dolgoprudny pourrait affecter non seulement les charges de travail hébergées des clients, mais aussi la capacité du client à ouvrir un ticket, commander un remplacement ou lire une page de statut. Si l'un de ces services est mis en miroir ailleurs, les pages publiques ne le disent pas.
L'histoire du service doit donc être traitée comme active mais petite. "Datalogika" n'est pas simplement un domaine parqué avec un texte obsolète: les pages de commande renvoient des produits actifs, l'AS est annoncé, les identifiants d'entreprise restent cohérents et le site annonce des prix mensuels actuels qui diffèrent des anciennes méta-descriptions sur certaines pages d'articles. Mais les petites entreprises actives peuvent encore avoir des chemins de défaillance concentrés. La continuité indique à qui appeler.
Elle ne dit pas combien d'appels simultanés l'entreprise peut gérer lorsqu'une baie, un commutateur ou un fournisseur amont tombe en panne.
Le prix doit financer l'horloge de réparation
Les prix publics de "Datalogika" sont suffisamment bas pour que l'économie fasse partie de l'histoire de la résilience. Un emplacement de serveur unique à 3 100 RUB par mois, un constructeur de serveur loué à 2 350 RUB par mois et une baie complète à partir de 80 000 RUB par mois ne sont pas que des chiffres de vente.
Ils sont le pool à partir duquel l'hébergeur doit payer l'électricité, le refroidissement, le carburant, les fournisseurs amont, les commutateurs, l'optique, les pièces de serveur, les logiciels, la comptabilité, le loyer ou les coûts immobiliers, les taxes, les visites de maintenance et les personnes qui répondent quand quelque chose échoue. Le service peut encore être bon à ces prix, mais seulement si l'offre est strictement définie et les hypothèses d'exploitation sont honnêtes.
C'est pourquoi l'article ne traite pas les éléments annoncés comme "gratuits" comme étant sans coût. Un port inclus de 100 Mb consomme de la capacité de commutateur, de la capacité de routage et de la bande passante amont. Le montage et la configuration inclus consomment du temps du personnel. Le déplacement de l'équipement du client aux frais de l'entreprise consomme du temps de véhicule, un risque d'emballage et une journée de technicien. Une installation gratuite de système d'exploitation sur un serveur loué consomme du temps de construction et une pratique d'installation reproductible.
Ces inclusions peuvent être un véritable avantage pour un petit client qui devrait sinon coordonner plusieurs fournisseurs. Elles peuvent aussi devenir une file d'attente lorsque de nombreux clients ont besoin des mêmes personnes en même temps.
Le chiffre d'affaires 2025 rapporté parAudit-itdonne un contexte d'échelle sans prouver la qualité de service. Un chiffre d'affaires de 28,3 millions de RUB peut soutenir une opération de niche significative, surtout si l'installation est compacte, le personnel expérimenté et les clients achètent des forfaits simples. Ce n'est pas le genre d'échelle qui permet à un acheteur de supposer un stock profond de pièces détachées, une grande équipe d'ingénieurs de nuit, plusieurs sites distants ou du transit excédentaire acheté pour des événements de pointe rares. L'hypothèse juste n'est pas la faiblesse. L'hypothèse juste est que chaque fonctionnalité de rétablissement promise doit être financée délibérément.
C'est aussi pourquoi les clients de demi-baie et de baie complète ne devraient pas comparer uniquement les prix mensuels de base. Ils devraient demander comment les dépassements de puissance sont facturés, si les interconnexions entraînent des frais récurrents, si les interfaces à plus haut débit nécessitent une mise à niveau du port, si un client peut acheter de la bande passante engagée plutôt qu'un accès partagé, si les tâches d'intervention à distance ont des limites de temps, et si le travail d'urgence est tarifé différemment du travail planifié.
Un prix de base bas avec des extras payants peut être parfaitement raisonnable si le contrat le précise. Un prix de base bas qui absorbe silencieusement un travail de rétablissement à forte intervention peut devenir fragile pendant une mauvaise semaine.
Pour les clients de serveurs loués, la même arithmétique s'applique au matériel. Si un service mensuel à 2 350 RUB comprend une adresse IPv4 et un chemin 100 Mb, l'hébergeur doit récupérer le coût du châssis, des disques, de la mémoire, de l'alimentation, du refroidissement, de la position en baie et du temps de remplacement sur plusieurs mois. Cela tend à favoriser les constructions standard, le remplacement instantané limité et un contrôle attentif des demandes inhabituelles.
Les clients qui ont besoin de reconstructions rapides, de conservation spéciale des disques, d'une endurance d'écriture élevée, de grande mémoire ou d'un engagement réseau élevé doivent s'attendre à payer plus ou à recevoir une promesse écrite plus restreinte.
Le test d'achat le plus utile n'est donc pas "est-ce que "Datalogika" est bon marché?" mais "qu'achète le prix en cas de panne?" Si la réponse est une salle modeste, une adresse russe nommée, une aide pratique concrète et une capacité louée au mieux, l'offre peut être attractive. Si l'acheteur a besoin de chemins de basculement réservés, de matériel de remplacement garanti, de récupération hors site et d'une réponse de support mesurée, ces fonctionnalités doivent apparaître comme des engagements payés plutôt que d'être déduites d'un tarif d'hébergement général.
AS51520 est réel, mais les preuves de routage ont des limites
La preuve opérationnelle courante la plus solide est la joignabilité réseau. L'aperçu AS de RIPEstat pour AS51520identifie le titulaire commeRH "Datalogika" Ltd.et a marqué l'ASN annoncé au moment de l'observation du 12 juillet 2026. Lestatut de routagede RIPEstat a montré deux préfixes IPv4, 768 adresses IPv4, une visibilité chez 326 des 327 pairs IPv4 de RIPE RIS et aucune route IPv6 visible. Savue des préfixes annoncéslistait 91.194.2.0/23 et 94.232.251.0/24.
L'image des ressources enregistrées est inégale d'une manière utile. Lavue whois de RIPEstat pour AS51520montre aut-num AS51520, as-name RH, organisation ORG-DL620-RIPE, statut ASSIGNED, créé le 16 septembre 2010 et dernière modification le 24 décembre 2025.L'enregistrement 91.194.2.0/23lie le bloc à ORG-DL620-RIPE, pays RU et statut fournisseur-indépendant attribué.L'enregistrement 94.232.251.0/24est différent: il s'agit d'un espace agrégable fournisseur attribué avec l'organisation ORG-LA1341-RIPE, et l'enregistrement d'organisation RIPE pourORG-LA1341-RIPEnomme"RealHost" Ltd.à Krasnoyarsk. L'objet de route montre toujours l'origine AS51520.
Pour un acheteur, cela signifie que le parc d'adresses routé de "Datalogika" doit être séparé en espace détenu ou enregistré par "Datalogika" et espace routé par "Datalogika" mais enregistré auprès d'une autre organisation. La distinction n'est pas nécessairement un problème. Les opérateurs d'hébergement originent souvent de l'espace client, d'entreprise liée ou détenu par un fournisseur. Cela compte lors de la sortie et de la réponse aux incidents. Si un service client est numéroté depuis 91.194.2.0/23, le contrôle contractuel et de registre peut être différent d'un service numéroté depuis 94.232.251.0/24.
La portabilité des adresses, la gestion des contacts d'abus, le filtrage des préfixes, les changements RPKI et la réorigination d'urgence peuvent tous dépendre de qui contrôle la ressource et qui peut signer ou maintenir les objets de route.
RPKI ajoute la même nuance. Le point de terminaison de validation de RIPEstat a renvoyéinconnupour AS51520 originant 91.194.2.0/23, tandis que lerésultat pour 94.232.251.0/24a renvoyé valide avec une longueur maximale /24. Inconnu n'est pas invalide; cela signifie qu'aucune autorisation d'origine de route correspondante n'était disponible dans ce résultat de validation. Un réseau appliquant une validation stricte d'origine ne rejetterait pas une route inconnue pour la même raison qu'il rejetterait une route invalide, mais une route inconnue donne moins d'assurance cryptographique qu'une route valide.
Les pages de routage secondaires sont globalement d'accord sur la forme tout en ajoutant plus de noms.bgp.tools pour AS51520identifie"Datalogika" Ltd., indique que l'AS origine deux préfixes IPv4 et aucun IPv6, liste les fournisseurs amont AS31500 Global Network Management Inc et AS5467, et montre le préfixe 91.194.2.0/23 sous"Datalogika" Ltd.et 94.232.251.0/24 sous"RealHost" Ltd.. Lapage BGP de Hurricane Electric pour AS51520rapporte deux préfixes IPv4 origines, aucun préfixe IPv6 origine, 768 adresses IPv4 origines, 31 pairs IPv4 observés et trois échanges Internet: Eurasia Peering IX à Moscou, PITER-IX Moscou et Sibir-IX à Krasnoyarsk.
PeeringDB est plus conservateur. Sonentrée API réseau pour AS51520nomme "Krasnoyarsk network", lie le site webhttp://www.kraslan.ru, indique que la politique est ouverte, et enregistre un nombre de IX et aucune installation. Sonentrée netixlanmontre un port 10Gb opérationnel à Eurasia Peering IX avec l'adresse IPv4 185.232.60.109. La différence entre l'image auto-déclarée d'un IX par PeeringDB et la vue d'échange plus large de HE est exactement pourquoi un article ne devrait pas assimiler une page de routage à une diversité physique. L'Internet public peut voir les adjacences; il ne voit pas toutes les commandes d'interconnexion, les engagements de port, les conditions de maintenance, les entrées de fibre ou les salles partagées.
Lavue voisine de RIPEstata rapporté 20 voisins observés au moment de la recherche, avec AS31500 portant de loin le poids visible le plus important dans ce point de terminaison. Cela soutient l'hypothèse de l'affectation selon laquelle Global Network Management est le fournisseur amont visible principal, mais le résultat nécessite encore une formulation prudente. "Voisin observé" n'est pas la même chose qu'un contrat de fournisseur. Certains voisins sont des pairs, certains peuvent être des avals, certains peuvent être des artefacts de serveur de routes, et certains peuvent apparaître ou disparaître avec la politique. Le fait que AS51520 ait plusieurs voisins observés est bon. Le fait qu'un fournisseur amont visible domine est une question de résilience.
La diversité du transit n'est pas la diversité de la restauration
La propre page de "Datalogika" indique que les canaux Internet globaux dans le centre de données dépassent 100 Gb et qu'elle peut fournir des interfaces jusqu'à 100 Gb. L'affirmation est utile mais incomplète. Une interface capable de 100 Gb est une option de port, pas la preuve qu'un client donné reçoit un chemin de 100 Gb engagé. Les canaux Internet globaux ne sont pas la même chose qu'une capacité de basculement non congestionnée. Si le plus grand fournisseur amont tombe en panne, la question est de savoir combien de trafic client les chemins survivants peuvent transporter sans perte, gigue ou limitation commerciale.
C'est là que l'économie des petits hébergeurs devient pratique. Un grand opérateur peut disposer de transit de réserve, de plusieurs fibres urbaines, de chemins optiques séparés, d'un deuxième centre d'opérations et de communications formelles pour les incidents majeurs. Un petit hébergeur peut encore être fiable, surtout si son mix de clients est modeste et que ses techniciens connaissent chaque baie. Mais un petit hébergeur a moins d'endroits pour cacher le stress.
Un routeur défaillant, un pair saturé, un technicien indisponible, une porte d'installation fermée ou une fenêtre de maintenance d'un fournisseur peuvent affecter une grande partie de la base de clients.
Lerapport 2024 d'ENISA sur les incidents de sécurité des télécommunicationsest utile ici non pas parce qu'il dit quoi que ce soit sur "Datalogika", mais parce qu'il identifie les mécanismes de défaillance courants dans les incidents de télécommunications: les coupures de câble et les logiciels défectueux ou les changements de mise à jour figurent en bonne place parmi les causes techniques liées à l'erreur humaine. Les résumés d'incidents plus anciens d'ENISA ont également identifié les défaillances système et les coupures de courant comme des moteurs récurrents de pannes. Ces catégories se rapportent directement à un petit hébergeur: des travaux civils peuvent couper un chemin de fibre; un changement de routeur peut fuir ou retirer des routes; une transition de puissance peut exposer une chaîne d'onduleur faible; un lot de disques défaillant peut épuiser les pièces de rechange.
L'offre publique de "Datalogika" mentionne un support 24h/24 et 7j/7, le montage et la configuration inclus, et l'intervention à distance dans ses conseils d'article. Elle ne publie pas de registre du personnel d'assistance, de séquence d'escalade, de liste de routeurs de rechange, de SLA de réparation d'interconnexion, de calendrier de maintenance, de page de statut, d'archive de pannes ou d'enregistrement post-incident. Ces absences ne sont pas des constats de mauvaise performance. Ce sont des limites à ce qu'un acheteur peut déduire. Un hébergeur peut avoir d'excellentes procédures privées et publier peu.
Un acheteur avec des charges de travail publiques devrait demander à voir les procédures avant de considérer le service comme résilient.
L'horloge de réparation change également selon le type de panne. Un disque défectueux dans un serveur loué peut être un échange matériel le jour même si la pièce est sur place et que l'ingénieur peut accéder à la baie. Un serveur client défaillant en colocation peut nécessiter que le client fournisse des pièces ou autorise une tâche pratique. Un module d'onduleur défaillant peut nécessiter le support du fournisseur. Une coupure de fibre peut incomber à un transporteur amont ou métropolitain. Une fuite de route peut nécessiter une coordination avec les pairs, les serveurs de routes et le transit.
Une panne du panneau de facturation peut bloquer l'action du client même si les paquets continuent de circuler. Le client vit une panne; l'hébergeur vit plusieurs propriétaires.
C'est pourquoi "fenêtres de réparation" appartient au titre. Le service n'est pas seulement vendu en prix mensuels. Il est vendu dans le temps entre la première alarme et la fonction rétablie. Les pages publiques de "Datalogika" sont solides sur les spécifications de la salle et la commande de produits, mais le dossier public est plus faible sur la restauration mesurée. L'écart est là où un acheteur devrait négocier.
La localité est une fonctionnalité, mais elle rétrécit aussi le chemin de sortie
"Datalogika" vend explicitement une adresse russe comme précieuse pour les entreprises qui traitent les données personnelles des utilisateurs. Cette affirmation correspond au contexte du marché. L'entrée WILMAP de Stanford sur laloi fédérale n° 242-FZrésume la règle de localisation des données personnelles russes comme exigeant le traitement des données personnelles des citoyens russes avec des serveurs situés en Russie. Une salle à Dolgoprudny peut donc être un atout commercial pour les clients qui veulent une infrastructure hébergée en Russie sans utiliser un cloud plus grand ou un hôtel d'opérateur plus cher.
La localité a deux faces. Elle peut améliorer la posture de conformité, réduire le temps de trajet pour les clients de la région de Moscou, soutenir un service pratique en russe et garder le matériel porteur de données dans une juridiction connue. Elle peut aussi réduire la portabilité si le service repose sur des adresses IP locales, des contrats locaux, un support en russe, des pièces de rechange sur place ou des arrangements de transporteur difficiles à reproduire ailleurs.
Un client doit savoir si quitter signifie expédier ses propres serveurs, copier des images disque vers un nouveau serveur loué, renuméroter depuis l'espace AS51520, changer le DNS, modifier les filtres amont ou attendre un transfert de fournisseur à fournisseur.
L'adresse de l'installation de "Datalogika" est particulièrement importante pour les clients de colocation. Si un client a des raisons réglementaires, contractuelles ou de sécurité de garder un serveur en Russie, la salle de Dolgoprudny peut satisfaire l'exigence de localisation. Mais si le client a besoin plus tard d'un deuxième site, d'une sauvegarde hors site ou d'un standby actif, la même exigence de localisation devient une contrainte de conception. Une sauvegarde dans un autre pays peut être inacceptable pour certaines données. Une sauvegarde dans la même salle peut ne pas survivre au même incident d'installation.
Un deuxième site russe peut nécessiter un autre fournisseur et un plan de déplacement des données testé.
Les pages publiques ne montrent pas un tel plan. Elles ne font pas la publicité de réplication multi-site, de stockage d'objets, de sauvegarde gérée, de conservation de supports hors site, de basculement inter-région ou d'une deuxième installation russe. La page de location de serveur annonce l'installation de système d'exploitation et du matériel configurable; la page de colocation annonce la capacité de baie et d'unité; le panneau WHMCS accepte les commandes. Aucune de ces surfaces ne décrit comment un client part sous pression. Cela ne rend pas le service inadapté. Cela signifie que l'acheteur possède la question.
La localisation des données affecte également la gestion des images et des disques après une panne. Si "Datalogika" loue un serveur à un client, qui contrôle les anciens disques après le remplacement? Comment les disques défaillants sont-ils traités? Un client peut-il demander la destruction, le retour, la conservation ou une preuve d'effacement? Si le client place son propre équipement, l'hébergeur peut-il retirer les supports uniquement avec une approbation écrite? Si l'hébergeur migre un client vers un matériel de remplacement, où est stockée la copie intermédiaire?
Le dossier public ne répond pas à ces questions, mais elles sont centrales pour la promesse implicite d'une adresse physique russe.
La conclusion la plus sûre est que "Datalogika" peut être intéressant pour les clients qui ont besoin d'une capacité de baie ou de serveur localisée en Russie et qui apprécient l'approche pratique d'un petit opérateur. Il ne faut pas le traiter comme une capacité cloud automatiquement portable. La localité n'est pas seulement une coordonnée géographique; c'est une contrainte de rétablissement et de sortie.
Six pannes définissent le vrai service
Un défaut d'alimentation ou de refroidissement d'une baie
L'histoire de la salle commence par l'alimentation et le refroidissement. "Datalogika" nomme son onduleur, son transformateur, son groupe électrogène, sa réserve de carburant et son dispositif de refroidissement. Un client doit demander comment ces composants se rapportent à sa propre baie. Les alimentations A et B sont-elles disponibles? Chaque baie a-t-elle une alimentation redondante? Que se passe-t-il lorsqu'un chemin d'alimentation est isolé pour maintenance? Quel est l'intervalle de mesure au niveau de la baie? À quel point le client est-il proche de la moyenne de 4,2 kW ou du maximum de 7 kW?
Les baies haute densité sont-elles réparties sur les allées froides ou regroupées? Comment une défaillance d'une unité de refroidissement est-elle testée sous la chaleur estivale?
Les parties concernées ne sont pas seulement les clients d'une seule baie. Si le refroidissement est contraint, les baies voisines peuvent être déclassées. Si la livraison de carburant est retardée, toute la salle peut faire face à une décision d'arrêt. Si les batteries de l'onduleur sont plus faibles que prévu, la fenêtre de démarrage promise du groupe électrogène devient plus serrée. La page publique indique que la maintenance préventive n'arrête pas le centre de données. Un acheteur devrait demander le dernier événement de maintenance au cours duquel cela a été démontré.
Une panne de fournisseur amont ou de peering
Le routage de AS51520 est visible et IPv4 uniquement dans l'observation publique. RIPEstat montre deux préfixes annoncés et 20 voisins observés. bgp.tools liste AS31500 et AS5467 comme fournisseurs amont, et HE liste trois échanges Internet. C'est une preuve positive que "Datalogika" ne se contente pas de faire du NAT derrière le haut débit d'un autre fournisseur. Elle a un AS, elle origine son espace d'adressage et elle fait du peering ou du transit en routage public.
La question de la panne est de savoir si les chemins survivants peuvent transporter la charge client. Si AS31500 est retiré, tous les préfixes restent-ils visibles via d'autres chemins? Le comportement de 94.232.251.0/24 est-il différent de celui de 91.194.2.0/23 parce que le contrôle du registre diffère? Les filtres de route, les limites de préfixe maximum et les paramètres RPKI sont-ils testés? Existe-t-il un contact pour les changements de route documenté en dehors de la salle concernée? Le panneau client et le courriel de support sont-ils accessibles via un chemin différent?
La visibilité BGP publique ne répond pas à ces questions; elle montre seulement que les routes sont là maintenant.
Une pénurie de stock de matériel
La page de serveur loué de "Datalogika" annonce des processeurs de 4 cœurs / 4 threads à 8 cœurs / 16 threads, de la mémoire de 8 Go à 96 Go, des HDD de 1 To à 10 To, des SSD de 240 Go à 960 Go, et des châssis 1U à 3U avec une ou deux alimentations. C'est une offre de matériel configurable, pas une divulgation de stock. Un petit hébergeur peut bien livrer cela s'il stocke des pièces courantes et maintient des limites claires sur les constructions personnalisées.
Il peut avoir du mal si une panne affecte un châssis rare, une taille de disque qui n'est plus en stock, un ancien contrôleur, une pièce à double alimentation ou un client qui a besoin d'un remplacement exact.
L'acheteur doit demander quels composants sont stockés sur place, lesquels sont commandés après la panne, quels substituts sont acceptables et comment un serveur est reconstruit lorsque la pièce exacte n'est pas disponible. Pour les serveurs loués, l'hébergeur doit indiquer si un client reçoit un matériel de remplacement, un matériel temporaire ou une réparation différée. Pour la colocation, le client doit savoir quelles tâches l'intervention à distance effectuera et lesquelles nécessitent que le client expédie des pièces ou se rende sur place.
Un goulot d'étranglement du support
Le support 24h/24 et 7j/7 n'a de valeur que si la file d'attente de support dispose d'assez de personnes avec assez d'autorité. La page publique de "Datalogika" indique que le support est gratuit pour tous les clients et la page d'article indique que l'équipement est sous observation continue par des spécialistes du service technique. Le dossier public n'identifie pas le nombre d'employés, les schémas d'équipe, les sous-traitants, l'autorité d'escalade, la couverture linguistique, les objectifs de réponse aux tickets ou la pratique en cas d'incident simultané.
Les petits opérateurs gagnent souvent parce que des ingénieurs expérimentés répondent directement au lieu de router chaque tâche vers un centre d'appels distant. Cet avantage disparaît lorsqu'un ingénieur est responsable de trop de clients ou lorsqu'un incident d'installation bloque l'accès physique. Les acheteurs doivent demander qui peut entrer dans la salle la nuit, qui peut effectuer des travaux électriques, qui peut toucher aux supports du client, qui peut autoriser les escalades de transporteur et ce qui se passe si plusieurs clients demandent une intervention à distance pendant la même panne.
Une panne de facturation ou de panneau de contrôle
La porte d'entrée client compte. Les pages de produits publics et le flux de connexion se trouvent sous lk.jpe.ru, qui résout dans la même plage d'adresses 91.194.2.0/23. Le panneau WHMCS est un moyen normal pour un petit hébergeur de vendre, facturer et supporter les services. Il devient également partie de la surface de résilience. Si la même panne d'installation ou de routage affecte à la fois les charges de travail des clients et le panneau, les clients peuvent perdre le canal ordinaire pour les tickets, les commandes et les factures au moment même où ils en ont besoin.
L'acheteur doit demander un chemin de support hors bande: téléphone, courriel alternatif, page de statut externe ou contact d'escalade nommé. Il doit également demander ce qui se passe pour la facturation récurrente si le panneau est indisponible, si la logique de suspension de service est manuelle ou automatisée, et comment l'accès au compte est restauré après un problème d'identité ou de session. Un service hébergé n'est pas que des paquets et de l'alimentation; c'est aussi la capacité du client à obtenir une action en période de stress.
Une panne de migration ou de sortie
La panne finale n'est pas une panne soudaine mais un déménagement qui ne peut pas être achevé. Un client peut partir à cause de la croissance, de l'exposition aux sanctions, d'un changement de prix, d'un changement de conformité, d'une acquisition, d'un problème de performance ou du besoin d'un deuxième site. Pour la colocation, la sortie peut impliquer un retrait physique, un emballage à distance, une gestion douanière ou de transporteur, des règles sur les supports porteurs de données et un temps d'arrêt coordonné.
Pour les serveurs loués, la sortie peut impliquer l'exportation d'image, des fenêtres rsync, des changements DNS, des mises à jour de pare-feu, une renumérotation et la vérification que les anciens disques sont effacés ou retournés selon la règle convenue.
Les pages publiques de "Datalogika" ne définissent pas la portabilité des données. Elles ne montrent pas non plus si les clients peuvent apporter leur propre espace IP, l'annoncer via AS51520, conserver un bloc après leur départ ou transférer des adresses vers un autre fournisseur. C'est normal pour un petit site public, mais cela devrait être couvert dans les termes du contrat. Le pire moment pour apprendre qu'un hébergeur ne peut pas produire une image utilisable, expédier rapidement du matériel ou maintenir les routes pendant un déménagement est après qu'un service de production est déjà sous pression.
Les questions de diligence raisonnable sont concrètes
L'acheteur n'a pas besoin d'un grand audit pour commencer. Il a besoin d'un tableau qui divise chaque service promis en propriétaires et horloges de restauration. Pour l'alimentation, il doit demander la charge actuelle de la baie, la date du dernier test de batterie de l'onduleur, la date du dernier test du groupe électrogène, le contrat de carburant, la pratique de dérivation de maintenance et la puissance maximale sûre par baie en cas de dégradation du refroidissement.
Pour le refroidissement, il doit demander comment la conception 4+1 de Hiref se comporte lorsqu'une unité est en panne, où la température est mesurée et si les baies haute densité sont déclassées.
Pour le réseau, il doit demander les contrats amont réels, les débits engagés, les vitesses de port, la participation aux serveurs de routes, les préfixes couverts par RPKI, les contacts de filtrage de route et l'enregistrement de test de basculement pour chaque préfixe. Il doit séparer 91.194.2.0/23 de 94.232.251.0/24 car les enregistrements de registre diffèrent. Il doit demander si IPv6 est disponible même si aucune route IPv6 visible n'est apparue dans l'observation RIPEstat. Il doit demander si le panneau client, le courriel de support et les communications de statut dépendent des mêmes routes AS51520.
Pour le matériel, il doit demander ce que "Datalogika" possède, ce que le client possède et ce qu'un fournisseur lié possède. Il doit demander les disques de rechange, les alimentations de rechange, les ports de commutateur de rechange, l'optique, les rails, les limites d'intervention et les délais de remplacement par produit. Les clients de serveurs loués doivent demander si le service est soutenu par des machines de rechange identiques ou par une file d'attente de construction.
Les clients de colocation doivent demander si l'intervention à distance peut changer des disques, connecter un chariot de diagnostic, replacer de la mémoire, déplacer un cordon de brassage ou expédier du matériel défaillant.
Pour le support, il doit demander l'accès de nuit, les noms d'escalade, les objectifs de réponse et de restauration, la gestion des pannes simultanées et le chemin de communication si le panneau WHMCS est inaccessible. Il doit tester les chemins téléphonique et courriel avant de signer. Il doit également demander si les factures, les avis de suspension et les événements de renouvellement peuvent être gérés manuellement si le panneau est en panne.
Pour la localité, il doit demander si toutes les données client restent dans l'installation de Dolgoprudny, si des sauvegardes sont proposées, si un support externalisé voit les systèmes clients, ce qui arrive aux disques défaillants et quelles preuves sont disponibles pour l'élimination des supports porteurs de données. L'affirmation de localisation russe n'est utile que si la gestion opérationnelle des supports, des sauvegardes et de la migration est également explicite.
Aucune de ces questions n'est exotique. Ce sont les questions ordinaires cachées derrière un prix mensuel bas. "Datalogika" publie suffisamment de détails pour rendre les questions dignes d'être posées. Elle n'en publie pas assez pour permettre aux acheteurs de les sauter.
Le verdict opérationnel
"Datalogika" Ltd. doit être traitée comme un petit opérateur d'hébergement actif avec de réelles preuves d'infrastructure publique. L'entreprise a une adresse cohérente à Dolgoprudny sur son propre site et dans l'enregistrement d'organisation RIPE, un système de commande JPE.ru accessible, des produits de colocation et de location de serveurs, une description détaillée de l'installation, un AS annoncé, deux préfixes IPv4 visibles, un contact d'abus public sur son propre domaine et des pages de routage externes qui montrent une présence amont et d'échange. C'est un plancher significatif.
Le plafond est plus bas que ce que le langage marketing peut laisser entendre. Une affirmation d'alignement Tier 3 n'est pas la même chose qu'une certification publique récompensée. Une option d'interface 100 Gb n'est pas la même chose qu'une capacité de basculement engagée. Une affirmation de 48 heures de carburant de groupe électrogène n'est pas la même chose qu'un incident de plusieurs jours testé. Plusieurs pairs ne sont pas la même chose que des entrées de fibre séparées. Une adresse russe n'est pas la même chose qu'un plan complet de souveraineté des données et de sortie.
Un bouton de commande WHMCS n'est pas la même chose qu'un stock de matériel.
La lacune de preuve la plus importante n'est pas de savoir si l'entreprise existe. C'est comment la capacité se rétablit lorsque la salle, la route, le bureau de support et le panneau client sont stressés ensemble. Le meilleur cas de "Datalogika" est attractif: un petit opérateur pratique avec une salle spécifique, des prix modérés, un support local et une visibilité de routage suffisante pour servir les clients qui ont besoin d'une capacité de baie ou de serveur localisée en Russie.
Son cas le plus faible est la concentration: une salle, une petite équipe, un parc d'adresses et des dépendances fournisseur qui peuvent ne pas être visibles jusqu'à ce qu'une fenêtre de réparation s'ouvre.
Cela rend la règle d'achat simple. Utilisez "Datalogika" pour les charges de travail dont le risque correspond à un petit hébergeur physique, ou exigez des preuves avant de placer des charges de travail qui nécessitent un basculement mesuré, une continuité hors site ou une portabilité rapide. L'entreprise vend de la capacité hébergée, mais le service est toujours fait de baies, d'alimentation, de transit, de matériel et de personnes. Le travail de l'acheteur est de rendre chacun de ces éléments visible avant que la première panne ne les rende évidents.

