Spidernet Cloud Solutions vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Le site web de Spidernet commercialise plusieurs formes d'hébergement professionnel, mais il ne mentionne aucun bâtiment de centre de données, opérateur d'installation, plateforme cloud, configuration matérielle, topologie électrique, ensemble de transporteurs, engagement de niveau de service ou historique d'incidents publics. L'offre est visible; la conception opérationnelle ne l'est pas.
• L'APNIC a enregistré l'AS154632 de Spidernet le 17 avril 2026 et a alloué162.4.2.0/23, soit 512 adresses IPv4, le 20 avril. Le 12 juillet, l'AS154632 n'originait aucune route, tandis que162.4.2.0/24était visible mondialement via l'AS151988 de Go2Cloud Solutions. L'autre moitié,162.4.3.0/24, n'était pas visible.
• Chaque chemin public échantillonné vers le préfixe actif de Spidernet se terminait parAS18229 AS151988: CtrlS immédiatement en amont de Go2Cloud, qui originait le bloc de Spidernet. Cela prouve la joignabilité via cette chaîne, et non une diversité de routes physiques, une bande passante de réserve, un second site ou une relation commerciale directe sous quelque forme que ce soit.
• Les pages de vente publiques ont été substantiellement assemblées pour la dernière fois en 2021 et décrivent à plusieurs reprises une autre entreprise, Surchi Infotech. Elles fournissent des descriptions de service génériques plutôt que des spécifications actuelles, des prix, des conditions de sauvegarde, des objectifs de restauration ou des procédures de migration.
• Le niveau de preuve est faible. Un acheteur doit exiger un emplacement d'hébergement nommé, l'entité contractante, les opérateurs d'installation et de réseau, des points et délais de reprise testés, la propriété des sauvegardes, les procédures d'escalade du support, les règles de maintenance, les procédures d'exportation des données et un second domaine de défaillance avant de confier une charge de travail irremplaçable à ce service.

Un catalogue cloud sans carte d'infrastructure

Spidernet Cloud Solutions présente une proposition d'hébergement pour petites entreprises familière. Sa navigation listel'hébergement cloud de bases de données,l'hébergement d'email,ERP cloud,l'hébergement de fichiers,l'hébergement Tally,l'hébergement de sites webetla maintenance de serveurs. La page d'accueil propose également le développement de logiciels et d'applications. Prise au pied de la lettre, il ne s'agit pas d'un seul produit mais d'une pile: calcul, stockage, bases de données, messagerie, applications métier, diffusion web publique et support humain.

Chaque couche a un coût physique. Une base de données hébergée occupe de la mémoire, du temps processeur et du stockage durable. L'email nécessite du stockage, du filtrage, une gestion de réputation et un DNS fiable. Une session Tally ou ERP nécessite un serveur, une licence logicielle, une latence stable et un moyen de reconnecter le personnel après une panne. Un site web a besoin d'adresses, de routage, de serveurs web et de certificats.

Tous dépendent en fin de compte de matériel sous tension dans un centre de données, de connexions croisées vers les réseaux en amont, de pièces de rechange et de personnes autorisées à réparer ou déplacer le service.

Spidernet ne publie pas cette carte sous-jacente. Aucune des pages de service n'identifie une ville d'hébergement, une installation, un opérateur de racks, une plate-forme matérielle, une architecture de stockage, un hyperviseur, une zone de disponibilité, un transporteur en amont ou un site de reprise après sinistre. Lapage de contactdonne une adresse de bureau à Karol Bagh, un numéro de téléphone et une adresse e-mail. Elle ne dit pas que les serveurs clients sont installés à cette adresse, et il ne faut jamais confondre une adresse de bureau avec un emplacement de centre de données.

La distinction n'est pas pointilleuse. Si Spidernet loue des machines virtuelles à un autre cloud, loue des serveurs dédiés, colocalise ses propres hôtes, revend les instances d'un partenaire ou gère l'équipement appartenant aux clients, la réponse change quant à savoir qui contrôle chaque réparation. Cela change qui peut remplacer un disque défaillant, qui peut rediriger le trafic, qui possède les sauvegardes, qui reçoit un ticket d'incident, qui autorise l'accès d'urgence et qui demeure responsable quand un fournisseur en accuse un autre. Les pages publiques ne choisissent pas parmi ces modèles opérationnels.

L'abstraction du cloud peut donner l'impression que la capacité est détachée du lieu. Ladéfinition du cloud computing par le NISTprécise que l'abstraction repose toujours sur une couche physique de ressources serveur, stockage et réseau. Elle note également que les clients ne peuvent connaître l'emplacement qu'à un niveau supérieur comme le pays, l'État ou le centre de données. Les pages de Spidernet ne fournissent même pas systématiquement ce niveau de placement pour les services proposés.

La première conclusion est donc modeste mais importante: Spidernet possède un catalogue de services réel et un contact commercial joignable, mais ce catalogue ne peut pas être converti en un inventaire d'actifs opérationnels. Un client potentiel peut voir ce que l'entreprise veut vendre. Il ne peut pas voir où le service s'exécute, quelle capacité est mise en service ou quels composants sont partagés.

L'identité publique nécessite un contrat signé, pas une correspondance de nom

L'enregistrement d'identité le plus solide actuel provient du registre Internet régional.L'enregistrement APNIC pour l'AS154632nomme Spidernet Cloud Solutions, indique l'adresse de Karol Bagh utilisée sur le site web de l'entreprise, et donne le même numéro de téléphone. Il désigne Lalit Jain comme contact administratif et technique et utilise des adresses e-mail enspidernet.net.in. Cette concordance fait du site web et de l'organisation APNIC une identité opérationnelle cohérente.

Une entité juridique au nom similaire apparaît également dans les services d'informations sur les sociétés indiennes.Le profil ZaubaCorpenregistre Spidernet Cloud Solutions LLP, numéro AAQ-6356, constituée à Delhi en septembre 2019. Mais le profil donne une adresse enregistrée à Pitampura et les associés désignés Kumar Roshan et Jatin Kumar. Ces détails ne correspondent pas à l'adresse de Karol Bagh ni au contact Lalit Jain figurant dans les enregistrements APNIC.

Le nom partagé est un signal, pas une preuve que le LLP est la contrepartie derrière l'opération d'hébergement actuelle. Les entreprises peuvent déménager, nommer du personnel, opérer sous des marques ou utiliser des adresses de service. Les agrégateurs de registres peuvent avoir du retard. Rien de tout cela ne permet à un client de présumer le lien juridique. La facture, le bon de commande, l'enregistrement fiscal et le contrat de service doivent nommer la partie contractante, son numéro d'enregistrement et son adresse.

Le même document doit indiquer si cette partie possède l'équipement, agit en tant que revendeur ou assure la gestion de l'infrastructure d'un autre fournisseur.

Le site web lui-même rend ce besoin particulièrement aigu. Lapage À proposindique que « Surchi Infotech » fournit les services décrits. Les pages d'hébergement de bases de données, d'email, d'ERP, de fichiers, de Tally, de sites web et de maintenance répètent le nom Surchi. Lapage de confidentialitéfait référence àsurchiinfotech.com, et l'avis de non-responsabilitéattribue les déclarations et responsabilités à Surchi Infotech. Pendant ce temps, l'en-tête, les coordonnées et le domaine présentent Spider Net.

Il peut s'agir d'un ancien contenu réutilisé lors de la construction du site, d'un accord commercial antérieur ou d'une simple erreur éditoriale. Les preuves publiques ne permettent pas de trancher. Elles établissent en revanche ce que les pages ne peuvent pas faire: elles ne peuvent pas identifier de manière fiable la partie qui promet le service cloud ni les conditions qui le régissent. Une déclaration de confidentialité rédigée pour un autre domaine ne peut pas répondre à la question de savoir qui contrôle les données personnelles d'un client de Spidernet.

Un avis de non-responsabilité nommant une autre entreprise ne peut pas définir la responsabilité de Spidernet en cas d'indisponibilité.

L'âge du matériel renforce cette prudence. L'enregistrement WordPress public pour la page des bases de donnéesde Spidernet et les enregistrements correspondants pour la plupart des pages de cloud et de support serveur datent leur dernière modification de juin 2021. Le pied de page indique copyright 2021. Les enregistrements réseau sont arrivés près de cinq ans plus tard, en avril 2026. Une entreprise peut ajouter de l'infrastructure sans reconstruire son site web, mais les acheteurs ne doivent pas considérer un ancien contenu générique comme un cahier des charges technique actuel.

Cette limite est importante pour la reprise. Durant un mois ordinaire, un client peut n'interagir qu'avec un commercial ou un ingénieur support familier. Pendant une panne, l'autorité suit les contrats. La partie ayant la relation client peut ne pas contrôler le rack; la partie contrôlant le rack peut ne pas contrôler le réseau; le détenteur de l'adresse peut ne pas être l'origine de la route; et la personne capable de remplacer un disque peut travailler pour une quatrième entreprise. Une matrice de responsabilité signée a plus de valeur qu'un nom de marque partagé.

Les ressources de numérotation d'avril montrent une opération en transition

L'empreinte réseau de Spidernet est suffisamment récente pour se lire presque comme une séquence de mise en service. L'APNIC a enregistré l'organisationORG-SCS6-APle 7 avril 2026. Elle a enregistré l'AS154632 le 17 avril. Le 20 avril, elle a alloué162.4.2.0à162.4.3.255, un/23portable contenant 512 adresses IPv4. Les enregistrements du registre sont actifs et utilisent le domaine, l'adresse et les coordonnées de Spidernet.

Quelques heures après l'allocation d'adresses, une route plus spécifique est apparue. L'historique de l'état de routage pour162.4.2.0/24du RIPE NCCa observé pour la première fois le préfixe à 16h00 UTC le 20 avril, originaé par l'AS151988. Au moment de l'observation du 12 juillet, il était visible pour l'ensemble des 326 pairs de la table de routage complète IPv4 de l'échantillon RIPE RIS. Uncontrôle de validation de l'origine de route RPKIa constaté une autorisation valide pour l'AS151988 d'originer ce/24.

Ce sont des contrôles significatifs. Un espace d'adressage portable donne à Spidernet un actif d'adressage qui ne se limite pas à un emprunt à un compte d'hébergement web. Une autorisation de route valide réduit une catégorie d'annonces d'origine accidentelles ou non autorisées. La visibilité mondiale signifie que la route n'était pas une expérience locale vue par seulement quelques réseaux. Le/24actif était joignable en tant que destination de routage sur l'Internet mesuré.

Les limites sont tout aussi concrètes. Lavue RIPEstat de l'AS154632ne montrait aucune première route, aucune dernière route, aucun espace d'adressage IPv4 ou IPv6 et aucun voisin observé le 12 juillet. Saliste de préfixes annoncésétait vide. Unrapport CIDRdistinct décrivait également l'ASN comme non annoncé et non visible en tant qu'AS de transit.

Spidernet détenait donc un système autonome mais ne l'utilisait pas comme origine de routage visible. Son préfixe actif était originaé par l'AS151988 de Go2Cloud Solutions Private Limited. La seconde moitié de l'allocation de Spidernet,162.4.3.0/24, n'était pas visible dans la table globale. Aucun préfixe IPv6 n'était associé à l'ASN de Spidernet dans l'instantané.

Ce schéma peut être tout à fait légitime. Un client peut demander à son fournisseur de transit ou d'hébergement d'originer un espace portable pendant qu'il prépare ses propres routeurs. Il peut préférer le BGP géré par le fournisseur. Il peut n'annoncer délibérément que les adresses dont il a besoin. Il peut réserver l'autre/24pour la croissance, la migration ou un second site. Ce que le schéma ne peut pas prouver, c'est que l'AS154632 dispose d'un transit indépendant, que le/24inutilisé est installé sur un équipement de secours, ou qu'un second centre de données peut l'annoncer après une panne.

La conclusion sur l'état opérationnel n'est donc ni « rien n'existe » ni « un réseau cloud est entièrement mis en service ». Un préfixe de Spidernet était actif, visible mondialement et correctement autorisé. La propre identité de routage de Spidernet était dormante. Cela ressemble à un arrangement réseau jeune ou dépendant du fournisseur, et il doit être évalué comme tel jusqu'à ce qu'une conception réseau actuelle montre le contraire.

Un préfixe actif suit une chaîne de fournisseurs visible unique

Le préfixe actif révèle également où le contrôle quitte Spidernet. Lavue AS151988 de Hurricane Electricidentifie l'origine comme Go2Cloud Solutions Private Limited et liste162.4.2.0/24comme espace d'adressage de Spidernet Cloud Solutions. L'instantané AS151988 de RIPEstatmontrait ce réseau originaant trois/24IPv4, sans routes IPv6 et avec un voisin observé.

Dans leschemins de looking-glass publics pour le préfixe de Spidernet, les deux derniers réseaux étaient systématiquement AS18229 suivi d'AS151988. L'AS18229 appartient à CtrlS. En d'autres termes, les collecteurs de routes voyaient Go2Cloud originaant le préfixe de Spidernet et atteignant l'Internet plus large immédiatement via CtrlS. Les chemins en amont au-delà de CtrlS variaient, mais la périphérie visible la plus proche du préfixe ne variait pas.

Il s'agit de preuves réseau, pas d'une déclaration de propriété. Les chemins BGP ne révèlent pas quelle entreprise possède le serveur, qui paie pour l'interconnexion, quel accord commercial existe, ou quel bâtiment contient le routeur. Ils ne montrent pas si une session de sauvegarde privée est configurée mais inactive. Ils montrent que chaque route publique échantillonnée dépendait de l'AS151988 comme origine et de l'AS18229 comme amont immédiat.

Cette chaîne crée au moins trois questions de défaillance distinctes. Premièrement, Spidernet peut-il continuer à fonctionner si son accord avec le fournisseur d'origine est suspendu, mal configuré ou non renouvelé? Deuxièmement, Go2Cloud peut-il atteindre un autre amont si la connexion CtrlS ou le routeur concerné tombe en panne? Troisièmement, le service client peut-il survivre à un problème de centre de données même si le BGP reste sain? La table de routage ne répond à aucune de ces questions avec de la redondance.

Les allégations de portefeuille peuvent masquer le problème. CtrlS est un important opérateur de centres de données et de réseau, et Go2Cloud commercialise publiquement des serveurs gérés et une infrastructure cloud. Leurs capacités ne se transposent pas automatiquement en une conception bi-site pour Spidernet. Une seule machine virtuelle dans une installation performante reste une seule machine virtuelle. Une route via un grand transporteur constitue une périphérie visible, sauf s'il existe une autre périphérie testée indépendamment pour la même charge de travail.

Ni l'AS154632 ni l'AS151988 n'avaient de profil réseau public dans l'API PeeringDB pour Spidernetou l'API PeeringDB pour Go2Cloudau moment de la vérification. PeeringDB est volontaire, donc l'absence ne constitue pas une preuve de mauvaise ingénierie. Cela signifie qu'il n'y a pas d'inventaire public tenu par l'opérateur des installations, points d'échange, échelles de trafic, politiques d'interconnexion ou contacts d'exploitation réseau pour corroborer une empreinte diversifiée.

Un acheteur n'a pas besoin que Spidernet exploite un réseau dorsal mondial. Il a besoin d'une limite de service honnête. Si tout le trafic passe par un seul fournisseur sur un seul site, le service doit être tarifé, sauvegardé et souscrit comme un service à fournisseur unique. Si Spidernet revendique un transit redondant, il doit nommer le second amont, montrer un second chemin BGP, indiquer la capacité survivante et expliquer si l'entrée physique et le chemin d'alimentation sont séparés.

Les adresses allouées ne sont pas une capacité cloud utilisable

L'allocation/23crée un chiffre accrocheur: 512 adresses IPv4. Ce n'est pas la même chose que 512 serveurs commercialisables, 512 clients actifs ni même 512 adresses d'hôte utilisables. Les conventions réseau et de diffusion, les affectations de passerelles, les périphériques d'infrastructure, les contrôles anti-abus et le sous-réseautage des clients réduisent l'espace utilisable. Plus important encore, seul un/24était routé dans l'instantané du 12 juillet.

Même 256 adresses routées disent peu de choses sur le calcul. Un fournisseur peut placer de nombreux sites web derrière une seule adresse, attribuer plusieurs adresses à un même pare-feu, réserver des adresses pour de futurs clients ou router un sous-réseau vide. À l'inverse, des machines virtuelles en adressage privé peuvent se trouver derrière une petite périphérie publique. Le nombre d'adresses IP ne révèle pas le nombre de cœurs de processeur, la mémoire, le stockage, les performances d'entrée/sortie ou la sursouscription.

Les mesures externes sont maigres. Lapage IPinfo pour le préfixe de Spidernetassociait la plage à l'entreprise et à l'AS151988, mais ne rapportait aucun domaine hébergé ni aucune adresse répondant à son récent scan ping. Un hôte peut bloquer intentionnellement ICMP, et l'attribution de domaine peut manquer des services privés ou nouvellement déployés. Ces observations négatives ne prouvent pas que le réseau est vide. Elles renforcent le fait que les données publiques ne démontrent pas un parc clients actif substantiel.

Le propre site de vente de l'entreprise ne constitue pas une preuve pour le nouveau bloc. Au moment de la vérification,spidernet.net.inrésolvait en82.180.143.143, un espace d'adressage associé àl'AS47583 d'Hostinger, et non à l'allocation portable de Spidernet. Son serveur de messagerie pointait vers Rediffmail Pro, et ses serveurs DNS faisant autorité utilisaient des serveurs de noms tiers. L'externalisation d'un site web d'entreprise, de la messagerie et du DNS est courante. Cela signifie simplement que ces services ne peuvent pas être comptabilisés comme des charges de travail prouvant l'utilisation du nouveau réseau.

La capacité installée doit être mesurée à plusieurs couches. Au niveau de l'adressage, un/24était installé dans le routage mondial et un autre ne l'était pas. Au niveau du routage, le propre ASN de l'entreprise n'était pas installé comme origine active. Au niveau du serveur, aucun décompte public d'hôtes ni inventaire matériel n'était disponible. Au niveau du stockage, aucune capacité brute ou utilisable n'était publiée. Au niveau de la résilience, il n'y avait aucune preuve d'un second site conservant une copie à jour des données client.

La capacité utilisable est encore plus réduite. Un rack de 20 serveurs ne représente pas 20 serveurs de capacité client sûre si tous sont pleins, s'il n'y a pas d'hôte de rechange pour l'évacuation, ou si la reconstruction du stockage consomme la marge d'entrée/sortie restante. Un second circuit de transit n'est pas une redondance utilisable s'il ne peut pas supporter le pic normal. Une sauvegarde n'est pas une capacité de reprise utilisable si la restauration n'a jamais été chronométrée. Spidernet ne publie aucune de ces mesures d'utilisation ou de marge de capacité.

Cela rend l'économie du service opaque. L'hébergement à bas coût fonctionne souvent en mutualisant le matériel, la bande passante et le travail de support. La mutualisation n'est pas une mauvaise pratique en soi; elle est à la base de beaucoup de cloud computing. Le risque apparaît lorsqu'un fournisseur vend de l'élasticité ou de la résilience sans conserver de ressources de réserve. Les clients doivent savoir si leur paiement leur achète une allocation réservée, un partage équitable, un service au mieux ou une instance gérée d'un autre fournisseur.

Chaque produit a un chemin de défaillance différent

Le menu de services de Spidernet regroupe plusieurs charges de travail sous l'étiquette cloud, mais leurs exigences de reprise diffèrent. Une assurance générique que les serveurs sont maintenus ne peut pas toutes les couvrir.

Pour une base de données hébergée, la question cruciale est la limite transactionnelle. Un instantané de serveur pris une fois par jour peut perdre près de 24 heures de modifications. Une base de données répliquée peut réduire la perte, mais seulement si le réplica est à jour, isolé de la même défaillance de stockage et protégé contre une suppression erronée qui se propage. Lapage d'hébergement de bases de donnéesmentionne PostgreSQL, MySQL et SQL Server et décrit un service géré. Elle ne fournit aucun objectif de point de reprise, temps de restauration, prise en charge des versions, conception de la réplication, rétention des sauvegardes ou format d'exportation.

La messagerie électronique a une chaîne de dépendance différente. Les messages entrants dépendent du DNS, des enregistrements MX, de la réputation des adresses, des systèmes anti-spam, du stockage et de l'authentification des comptes. Une panne de stockage peut rendre l'ancien courrier inaccessible tandis que les nouveaux messages sont mis en file d'attente ailleurs; une erreur DNS peut détourner la livraison; un compte compromis peut envoyer du spam et nuire à la réputation des adresses partagées. Lapage d'hébergement d'emailde Spidernet revendique des serveurs dédiés et des dispositions sans spam, mais ne fournit aucun quota de boîte aux lettres, conception de redondance, journalisation, rétention, norme d'authentification, méthode de continuité ou objectif de reprise.

L'hébergement de fichiers concentre les documents professionnels dans un stockage partagé. La disponibilité ne dépend pas seulement de la redondance des disques, mais aussi des métadonnées, des services d'identité, des autorisations et d'une copie non corrompue en dehors du domaine de défaillance principal. Lapage d'hébergement de fichiersde Spidernet explique l'idée générale des systèmes de fichiers cloud partagés. Elle n'indique pas où les fichiers résident, si le stockage est répliqué, comment les versions sont conservées, comment le matériel supprimé est récupéré ou à quelle vitesse un client peut exporter un grand ensemble de données.

L'hébergement ERP et Tally ajoute des dépendances de session et de licence. Le personnel peut atteindre un bureau à distance ou un serveur d'applications via l'Internet public. Si la route tombe en panne, la comptabilité, l'inventaire, la paie ou le traitement des commandes peuvent s'arrêter même si les données sous-jacentes restent intactes. Une mise à jour logicielle peut être aussi perturbatrice qu'une panne matérielle. Lapage ERPpromet l'implémentation et le support, tandis que lapage Tallymentionne des sauvegardes standard et la protection des données. Aucune ne spécifie les versions d'applications, la responsabilité des licences, les fenêtres de maintenance, la simultanéité des utilisateurs, la propriété de la base de données, la fréquence des sauvegardes, les tests de restauration ou un chemin de retour à un fonctionnement local.

L'hébergement de sites web peut être plus facile à recréer si le client contrôle son code, sa base de données et son DNS. Cela devient difficile lorsque le fournisseur est le seul à détenir la base de données actuelle, les clés de certificat ou les identifiants de domaine. Lapage d'hébergement de sites webde Spidernet est une introduction à la sélection d'hébergeurs commerciaux plutôt qu'un descriptif des plans de Spidernet. Elle n'offre aucune spécification de stockage, de trafic, d'exécution, de panneau de contrôle, de sauvegarde, de sécurité ou de disponibilité.

La leçon commune est que « sauvegarde » et « cloud » ne sont pas des conceptions de reprise. Chaque produit nécessite une unité de perte nommée, une séquence de restauration testée et une personne autorisée à la démarrer. Une coupure de route de cinq minutes, une carte mère défaillante, un stockage corrompu, un événement de ransomware et la résiliation d'un contrat de fournisseur exigent des réponses différentes.

Les racks, l'alimentation et les pièces demeurent la fondation cachée

Aucune source publique n'a identifié un centre de données appartenant à Spidernet ou même l'installation partenaire desservant162.4.2.0/24. La route via Go2Cloud et CtrlS peut suggérer l'endroit où une interconnexion existe, mais le BGP ne peut pas localiser le matériel client. Les bases de données de géolocalisation peuvent être des indices utiles et sont souvent erronées au niveau du bâtiment. La conclusion responsable est que l'emplacement physique reste non vérifié.

Sans site nommé, la résilience électrique ne peut pas être évaluée. Un cahier des charges d'installation sérieux décrirait les alimentations électriques, les systèmes d'alimentation sans interruption, la topologie des générateurs, l'autonomie en carburant, les contournements de maintenance et le chemin A/B vers le serveur ou le rack commandé. Il expliquerait si les deux alimentations d'un serveur à double cordon atteignent des chaînes de distribution séparées. Spidernet ne publie rien de tout cela, et aucune description générique de l'hébergement cloud ne peut s'y substituer.

Le refroidissement présente la même opacité. Un serveur peut rester sous tension tout en limitant sa puissance ou en s'arrêtant parce que le refroidissement de la salle, le flux d'air du rack ou un ventilateur local est tombé en panne. Une température extérieure élevée, une erreur de maintenance ou un rack dense peuvent supprimer la marge de capacité. Les clients ont besoin d'alarmes, de plages de fonctionnement et d'un plan d'intervention lié à la salle réelle. Aucune donnée de ce type n'est publique pour l'offre de Spidernet.

Le stock de matériel est une contrainte particulièrement pratique pour un petit fournisseur. La virtualisation peut déplacer un invité loin d'un hôte défaillant seulement si un autre hôte a une capacité compatible et que le stockage partagé reste disponible. Un serveur dédié ne peut pas être migré à chaud de la même manière. Le remplacement dépend des disques, alimentations, mémoires, contrôleurs en stock ou d'un châssis de rechange complet. L'entreprise ne publie pas de catalogue matériel, de politique de stock ou d'objectif de remplacement.

Lapage de maintenance de serveurreconnaît que les composants se détériorent et que la maintenance est nécessaire pour réduire les temps d'arrêt. Pourtant, elle présente la maintenance comme un plan générique et nomme à nouveau Surchi Infotech. Elle ne dit pas si Spidernet surveille les serveurs des clients, si le support est à distance ou sur site, quelles heures sont couvertes, ce qui constitue une urgence ou à quelle vitesse un technicien peut atteindre le rack.

Les fenêtres de réparation sont donc une caractéristique de service de premier ordre. « 24/7 » est souvent utilisé pour décrire la soumission de tickets, pas l'intervention garantie. Un client doit distinguer le temps de réponse, le temps de diagnostic, le temps d'accès au site, le temps de livraison des pièces et le temps de restauration. Il doit demander si les week-ends et les jours fériés modifient chaque objectif. Si l'opérateur d'installation fournit une intervention à distance, le contrat doit indiquer comment Spidernet escalade et qui paie pour le travail d'urgence.

La maintenance planifiée a également besoin d'une règle. La maintenance du micrologiciel, de l'hyperviseur, du réseau, de l'alimentation et du refroidissement peut toutes nécessiter une prise de risque. Un service mature indique les préavis, les dates d'interdiction, la durée maximale, la redondance pendant les travaux et le droit du client de s'y opposer. Le site public de Spidernet ne fournit pas de calendrier de maintenance, de page d'état ou de planning de niveau de service.

La concentration du support peut transformer une panne en une longue interruption

La surface de contact publique est étroite: un numéro de téléphone, des adresses e-mail génériques et une adresse postale. Les enregistrements APNIC identifient un contact administratif et technique nommé. Cela suffit pour joindre l'organisation; ce n'est pas une preuve d'un centre d'opérations doté de personnel, d'une rotation d'astreinte ou de chemins d'escalade séparés.

La concentration du support est importante parce que les premières minutes d'un incident sont diagnostiques. Un client a besoin de quelqu'un qui puisse distinguer une erreur d'application d'une panne de stockage, d'un retrait de route, d'une licence expirée, d'un disque plein ou d'une suspension de facturation. Si chaque problème commence par une boîte de réception générale, le fournisseur a besoin d'un moyen interne pour alerter le bon opérateur. Aucune structure de ce type n'est publiée.

La chaîne s'allonge lorsqu'un autre réseau origina le bloc d'adresses. Un incident de connectivité peut nécessiter que le client contacte Spidernet, que Spidernet contacte Go2Cloud et que Go2Cloud contacte son installation ou son amont. Chaque partie peut avoir ses propres définitions de gravité et exigences de preuve. Un traceroute fourni par le client peut ne pas suffire; l'amont peut vouloir des journaux de routeur; l'installation peut attendre un contact autorisé. Les minutes s'accumulent aux frontières contractuelles.

La défaillance du contrat fournisseur peut être plus dommageable qu'une panne d'équipement. Si une facture est contestée ou si un compte revendeur est suspendu, les serveurs et les routes peuvent disparaître alors que le matériel reste sain. Parce que le préfixe de Spidernet est actuellement originaé par l'AS151988, la continuité dépend du droit de maintenir ou de transférer cette annonce. Les adresses portables n'aident que si Spidernet dispose des identifiants, des objets de route, des autorisations et d'un autre réseau volontaire prêt à les annoncer.

Les conditions de facturation ne sont pas publiées sur le site de Spidernet. Il n'y a pas de période de grâce visible, de procédure de suspension, de période de conservation des données après annulation, de règle de remboursement ou de promesse d'accès à l'exportation en cas de litige. Les clients ne doivent pas déduire ces protections. Ils doivent les obtenir dans le bon de commande, en particulier pour les charges de travail de comptabilité et de messagerie qui deviennent urgentes dès que l'accès cesse.

Il en va de même pour les plaintes pour abus. Les réseaux d'hébergement reçoivent des signalements de spam, de scans, de sites web compromis et de contenu illégal. Un fournisseur peut annuler la route d'une adresse ou suspendre un serveur pour protéger le réseau plus large. Le contrat client doit indiquer le préavis, l'enquête, l'action d'urgence et l'appel. L'APNIC liste une boîte aux lettres d'abus, ce qui est un contact opérationnel utile, mais une boîte aux lettres seule ne définit pas comment une plainte erronée ou malveillante est traitée.

La reprise nécessite un second domaine de défaillance, pas une seconde copie dans le même rack

Les preuves publiques ne soutiennent aucune affirmation de capacité multi-site. Le162.4.3.0/24inutilisé de Spidernet pourrait éventuellement soutenir un autre déploiement, mais un sous-réseau non annoncé n'est pas un site de reprise. De même, une sauvegarde sur un autre disque dans la même baie de stockage ne survit pas à la défaillance de la baie; une réplique dans la même salle peut ne pas survivre à une perte d'alimentation ou de refroidissement; et deux sessions réseau partageant un même fournisseur ne survivent pas à la défaillance de ce fournisseur.

Une conception résiliente minimale commence par les domaines de défaillance. Les copies primaire et de reprise ne doivent pas partager le même hôte, contrôleur de stockage, alimentation du rack, salle, routeur d'accès ou installation lorsque l'impact métier exige une protection contre ces défaillances. Le chemin réseau vers le site de reprise doit être joignable indépendamment. Les services d'identité et DNS nécessaires pour l'activer ne doivent pas dépendre uniquement du site défaillant.

Les objectifs de reprise doivent être numériques. L'objectif de point de reprise répond à la quantité de données pouvant être perdues; l'objectif de temps de reprise répond à la durée pendant laquelle le service peut rester indisponible. Ce ne sont pas les mêmes que la fréquence de sauvegarde. Une sauvegarde effectuée toutes les heures peut encore nécessiter deux jours pour être restaurée si le fournisseur n'a jamais répété le processus ou manque de matériel de rechange.

Leguide de planification d'urgence du NISTrecommande une analyse d'impact sur l'activité, des contrôles préventifs, des stratégies de reprise, un site de secours le cas échéant, des tests et une maintenance continue. Bien que rédigé pour les systèmes d'information fédéraux, la séquence est utile pour tout acheteur. Elle transforme « nous faisons des sauvegardes » en un ensemble de questions sur ce qui est protégé, comment cela revient et qui prouve que cela fonctionne.

Pour Spidernet, la preuve décisive serait un rapport de restauration daté. Il devrait montrer une base de données ou une application représentative restaurée à partir d'une copie isolée, la quantité de données perdues, le temps écoulé, la capacité disponible sur le site de reprise et toutes les étapes manuelles. Un test réseau devrait montrer le point de terminaison de reprise joignable sans l'arrangement d'origine principal. Les résultats n'ont pas besoin d'être publics, mais un client sérieux devrait être autorisé à les examiner.

Les clients doivent également détenir leur propre export. Les extraits de base de données, les archives de messagerie, les instantanés du système de fichiers, la configuration des applications, les zones DNS et les enregistrements de licence doivent être récupérables dans des formats documentés. Les clés de chiffrement doivent être disponibles sans le fournisseur défaillant. L'intervalle d'exportation doit refléter la tolérance de l'entreprise, et la restauration doit être testée en dehors de l'environnement de Spidernet.

La portabilité des données est un contrôle économique autant que technique. Un service peu coûteux à l'entrée mais coûteux à quitter peut enfermer un client dans des prix croissants ou un support faible. Le contrat doit indiquer la bande passante d'exportation, les frais, l'assistance, le format, le calendrier et la suppression après la sortie. Aucune des pages produits publiques ne fournit ces conditions.

La localisation n'est pas résolue, et certains clients ne peuvent pas l'ignorer

Spidernet est enregistré dans la région indienne de l'APNIC et présente un contact à New Delhi. La route active passe par des organisations indiennes. Aucun de ces faits ne prouve que les données clients, les sauvegardes ou l'accès au support restent en Inde. Un pays d'enregistrement IP est un attribut administratif, pas une coordonnée de salle de serveurs. Un fournisseur peut router un espace d'adressage indien vers une autre ville ou un autre pays, et une équipe de gestion peut accéder à un serveur à distance.

Les offres d'hébergement de bases de données, de fichiers, d'email, d'ERP et de Tally de l'entreprise peuvent contenir des informations personnelles, financières et opérationnelles. Les acheteurs ont donc besoin d'un planning de localisation des données listant le site principal, le site de sauvegarde, le stockage des journaux, les lieux d'accès au support et les sous-traitants. « Cloud en Inde » devrait signifier un engagement pays nommé, pas une déduction d'un numéro de téléphone à Delhi.

La position juridique de l'Inde est également plus précise que le vaste slogan de la localisation des données. LaLoi de 2023 sur la protection des données personnelles numériquesa une entrée en vigueur progressive, avec des obligations centrales prenant effet à des dates différentes. Elle ne crée pas une règle générale simple selon laquelle chaque charge de travail doit rester en Inde. Les clients doivent évaluer les dispositions en vigueur pour leur rôle et leurs données au moment pertinent plutôt que de se fier au mot cloud.

Les règles sectorielles peuvent être plus étroites et plus strictes. Ladirective de 2018 de la Reserve Bank of India sur les données des systèmes de paiementoblige les fournisseurs de systèmes couverts à stocker l'intégralité des données relatives aux systèmes de paiement uniquement dans des systèmes situés en Inde, sous réserve de son traitement déclaré d'une branche de transaction étrangère. Cette exigence s'applique au contexte des paiements réglementés, et non automatiquement à chaque client de Spidernet. Un entité à un système de paiement envisageant des bases de données hébergées ou un ERP ne peut pas accepter un emplacement non spécifié.

Les obligations opérationnelles sont également pertinentes. Lapage des directives de cybersécurité du CERT-Inrépertorie des exigences affectant les fournisseurs de services, les centres de données, les fournisseurs de VPS et les fournisseurs cloud, notamment le signalement des incidents, la synchronisation de l'heure, la conservation des journaux et la validation des abonnés. Lesdirectives elles-mêmesaccordent une réelle importance aux enregistrements et à la réponse aux incidents. Un acheteur doit demander quelle partie conserve les journaux requis, où ils sont stockés, comment les horloges sont synchronisées et qui signale un incident.

Spidernet ne publie aucun accord de traitement des données, liste de sous-traitants, liste de localisation, calendrier de conservation ou condition de notification d'incident pour ses services d'hébergement. Sa page de confidentialité nomme un domaine et une entreprise différents. Tant qu'un contrat en vigueur ne fournit pas les informations manquantes, les preuves de souveraineté des données restent faibles.

À quoi ressemblerait une panne pour les clients

Les principaux chemins de défaillance ne sont pas théoriques même si aucune panne spécifique de Spidernet n'a été trouvée dans les archives publiques.

Une panne de rack ou d'hôte affecterait d'abord les machines virtuelles ou les serveurs dédiés sur cet équipement. Les clients pourraient voir des sessions figées, des sites web indisponibles ou des délais d'expiration de base de données. La reprise dépendrait de la capacité de calcul de réserve, de l'intégrité du stockage et d'un technicien ou d'un système d'orchestration capable de redémarrer la charge de travail ailleurs. Sans conception publiée d'évacuation d'hôte, les clients ne peuvent pas supposer un déplacement automatique.

Une panne en amont ou de l'origine de route rendrait les serveurs sains injoignables. Comme le préfixe actif est originaé par l'AS151988 et sort visiblement via l'AS18229, une erreur à l'une ou l'autre frontière pourrait supprimer l'accès public. Une seconde copie d'application utilisant le même préfixe et chemin pourrait échouer en même temps. La reprise nécessiterait une autre annonce, un autre fournisseur, une adresse différente, un changement DNS ou un basculement au niveau applicatif que les clients ont déjà configuré.

Une panne de stockage ou de sauvegarde pourrait être plus silencieuse. L'application peut continuer à fonctionner tandis que les sauvegardes s'arrêtent, laissant la faiblesse non découverte jusqu'à un événement de suppression ou de corruption. Le client apprend alors que la rétention nominale est incomplète ou que les informations d'identification de restauration sont manquantes. La seule défense fiable est la surveillance de l'achèvement des sauvegardes ainsi que des tests de restauration périodiques.

Une défaillance du support prolonge tout autre événement. Si aucune personne autorisée ne répond, une action matérielle de dix minutes devient une interruption de plusieurs heures. Si le revendeur doit attendre un ticket en amont, la priorité dépend de son contrat avec ce fournisseur. Les objectifs de réponse visibles par le client doivent donc inclure la chaîne de fournisseurs, pas seulement le temps d'accusé de réception de Spidernet.

Une défaillance de facturation ou de contrat peut supprimer le service brusquement. Des erreurs de renouvellement automatique, une utilisation contestée, l'expiration d'une licence ou un solde de compte en amont peuvent déclencher une suspension. Le client a besoin d'une échelle de notification, d'un contact d'urgence, d'une période de grâce et d'un droit d'exportation en lecture seule. Pour les enregistrements financiers et les emails, la perte d'accès peut créer des conséquences juridiques et opérationnelles avant que les données ne soient physiquement perdues.

Un échec de migration peut piéger le client lors d'une sortie par ailleurs planifiée. Les versions de base de données peuvent différer, les archives de messagerie peuvent être incomplètes, les autorisations de fichiers peuvent ne pas correspondre, et un environnement Tally peut dépendre de la configuration ou des licences détenues par l'hébergeur. Le chemin de migration doit être répété pendant que la relation est saine.

Les personnes touchées vont au-delà de l'équipe informatique de l'acheteur. Les employés peuvent perdre des sessions de comptabilité ou d'ERP. Les clients peuvent être incapables de passer des commandes ou de recevoir des messages. Les fournisseurs peuvent ne pas recevoir de bons de commande. Le personnel financier peut manquer des déclarations ou des fenêtres de rapprochement. Une petite charge de travail hébergée peut reposer sur un processus métier étonnamment vaste.

Les preuves qu'un acheteur devrait exiger

La demande de diligence raisonnable pour Spidernet peut être concise car les lacunes publiques sont claires.

Premièrement, identifier le contrat. La commande doit nommer la contrepartie légale, les détails fiscaux, les conditions générales, le lieu du service, l'opérateur d'installation, le fournisseur d'origine réseau et tout fournisseur cloud ou matériel. Elle doit résoudre les références à Surchi Infotech et dire quelles conditions de confidentialité et de responsabilité s'appliquent réellement.

Deuxièmement, identifier l'actif. Le fournisseur doit indiquer si le client reçoit un hébergement partagé, une machine virtuelle, une instance cloud gérée, un serveur dédié ou une colocation. Il doit lister le processeur, la mémoire, la classe de stockage, l'engagement réseau, l'allocation d'adresses et la politique de sursouscription. Pour l'équipement dédié, il doit donner des objectifs de pièces de rechange. Pour le service virtuel, il doit indiquer la capacité d'évacuation.

Troisièmement, identifier les domaines de défaillance. L'acheteur doit recevoir la ville et l'installation pour le service principal et la copie de reprise, ainsi qu'une explication de la séparation de l'alimentation, du refroidissement, du stockage et du réseau. Une déclaration selon laquelle deux sites existent est insuffisante si les deux reposent sur un seul arrangement d'origine ou si la réplication n'a jamais été testée.

Quatrièmement, définir la reprise. Le contrat doit inclure les objectifs de point et de temps de reprise, la fréquence des sauvegardes, la rétention, l'immuabilité, le chiffrement, les tests de restauration et l'exportation client. Les crédits ne sont utiles qu'une fois que le fournisseur a expliqué comment le service revient; un petit crédit ne récupère pas les comptes ou transactions perdus.

Cinquièmement, définir les opérations. Le planning doit donner les heures de support, les niveaux de gravité, les objectifs d'accusé de réception et d'intervention, les contacts d'escalade, le préavis de maintenance, les droits de maintenance d'urgence, le signalement des incidents et l'examen post-incident. Il doit distinguer les actions de Spidernet de celles effectuées par une installation ou un fournisseur en amont.

Sixièmement, prouver le réseau. Si Spidernet a l'intention que l'AS154632 fournisse une autonomie, il doit montrer quand l'ASN originaera les routes, quels amonts le serviront et comment le basculement sera testé. Si le routage originaé par le fournisseur est le modèle permanent, il doit documenter la procédure de transfert et d'origine d'urgence pour son/23portable. La disponibilité IPv6 doit être indiquée plutôt que supposée.

Enfin, tester la sortie. Avant une utilisation en production, le client doit exporter les données et les restaurer dans un environnement indépendant. Il doit déplacer un nom DNS de test, valider l'accès utilisateur, mesurer le temps de transfert et enregistrer les identifiants requis. L'exercice est le moyen le plus clair de découvrir une dépendance cachée pendant qu'il est encore temps de la corriger.

Un préfixe actif est un début, pas un certificat de résilience

Spidernet Cloud Solutions dispose de plus de preuves opérationnelles que ne le suggérerait son site web daté seul. L'APNIC lui a délivré un enregistrement d'organisation, un système autonome et un espace IPv4 portable. La moitié de cet espace était visible mondialement quelques heures après l'allocation et restait entièrement visible dans l'instantané de routage du 12 juillet avec une autorisation d'origine de route valide. Ce sont de réelles étapes vers un service réseau.

Mais la conception visible est étroite. L'AS154632 n'était pas actif. Un/24était annoncé via l'AS151988 de Go2Cloud, dont le seul voisin immédiat observé était l'AS18229 de CtrlS. L'autre/24n'était pas routé. Aucune preuve publique n'a établi un second site, une seconde origine, IPv6, des domaines hébergés actifs sur le nouveau bloc, une résilience au niveau de l'installation, du matériel de rechange ou une reprise testée.

Les pages commerciales élargissent la revendication sans combler ces lacunes. Elles annoncent plusieurs charges de travail métier importantes mais fournissent des descriptions anciennes, multi-marques et aucun planning de service actuel. Leur silence sur l'emplacement, le matériel, le support, la sauvegarde et la sortie n'est pas une preuve que ces capacités n'existent pas. C'est la preuve que les clients ne peuvent pas s'y fier tant qu'elles n'apparaissent pas dans une spécification signée et ne sont pas testées.

Spidernet est peut-être en train de construire un nouveau réseau, d'utiliser délibérément un modèle originaé par le fournisseur, ou de servir des clients dont l'infrastructure n'est pas publiquement mesurable. Le niveau de preuve équitable est faible, avec une note positive pour les nouvelles ressources portables et la route active valide. Le chemin d'amélioration est simple: publier ou divulguer la limite opérationnelle, activer ou expliquer la stratégie ASN, prouver un second domaine de défaillance et montrer qu'un client peut restaurer et partir.

D'ici là, l'offre cloud reste dépendante de racks non nommés, d'une chaîne de transit visible unique et de fenêtres de réparation contrôlées en partie au-delà de la frontière publique de Spidernet.