CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. vend une capacité hébergée qui dépend des racks, du transit et des fenêtres de réparation

Résumé

• CloudTeknoloji est la société derrière daha.net. Lapage d'informations commercialespublique nomme CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. comme entité légale, donne daha.net comme marque, liste l'adresse d'Istanbul, le téléphone, le numéro MERSIS et le numéro du registre du commerce, et décrit l'hébergement, le serveur cloud, le domaine, SSL, la messagerie et les services informatiques associés.
• La revendication d'infrastructure est spécifique mais pas entièrement indépendante. Lapage à proposindique que les systèmes daha.net sont gérés depuis Istanbul 4. Levent et hébergés dans le centre de données ICS d'Istanbul, avec des affirmations de Tier III, PCI/DSS, capacité Internet redondante, fibre indépendante des opérateurs, UPS, alimentation A+B, sécurité physique et refroidissement. Les lecteurs doivent considérer ces déclarations comme des affirmations de l'entreprise, sauf confirmation dans les contrats clients ou les certificats d'installation.
• L'empreinte de routage publique est actuelle et étroite. L'aperçu AS de RIPEstatmontre AS202048 annoncé pour CloudTeknoloji, et lesdonnées de préfixes annoncésmontrent un préfixe visible, 46.28.232.0/24, dans la fenêtre de fin juin au 12 juillet 2026. Lescomptes de préfixes RISmontrent un préfixe IPv4 d'origine, aucun préfixe de transit et aucun préfixe IPv6 d'origine.
• La principale question pour le client n'est pas de savoir si daha.net existe. C'est dans quelle mesure le site web, le VPS, la messagerie, le DNS, la sauvegarde et le plan de migration du client dépendent d'une seule installation à Istanbul, d'un petit bloc d'adresses routées, du chemin amont ICS actuellement observé, des fenêtres de réponse du support et des conditions contractuelles qui placent une partie de la responsabilité de sauvegarde et de perte de données sur le client.

L'entreprise est plus claire que de nombreux noms d'hébergement légers

L'identité publique de CloudTeknoloji est inhabituellement bien définie pour un petit opérateur d'hébergement. Lapage d'informations commercialesde daha.net donne le titre légal comme CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S., indique que daha.net est la marque, liste Maslak comme bureau des impôts, donne le numéro fiscal 5470543764, le numéro MERSIS 0547054376400001 et le numéro du registre du commerce 759033, et dit que l'entreprise a été fondée en 2010. La même page liste une adresse à Sultan Selim Mahallesi, NEF 09 Plaza 4. Levent B Blok No:7/121, Kagithane, Istanbul, plus les détails de téléphone, fax, email et KEP.

Cela a de l'importance car il ne s'agit pas simplement d'un hébergement anonyme vendant des domaines. Un acheteur peut relier la marque, l'entreprise, l'adresse, l'identité du registre et l'identité du réseau public. L'enregistrement d'organisationde RIPE pour ORG-SBHv1-RIPE liste Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. en Turquie, montre le même numéro de registre du commerce, identifie le type d'organisation comme LIR, et donne une adresse à Kagithane, Istanbul et un numéro de téléphone. L'enregistrement aut-numde RIPE pour AS202048 nomme l'AS comme CloudTeknoloji, le décrit comme Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S., et le lie à la même organisation RIPE.

L'histoire de la marque complète ensuite l'offre orientée client. Lapage à proposdit que daha.net opère depuis 2010 et sert des clients individuels et professionnels avec des services d'hébergement et de serveur. Elle présente la marque comme faisant partie de Cloud Teknoloji Bilisim Hizmetleri Ticaret Anonim Sirketi, et décrit un ensemble de services qui comprend l'hébergement, le serveur cloud, l'hébergement revendeur, le domaine, SSL et la messagerie d'entreprise. Lapage de contactdonne les téléphone public, fax, emails de support, adresse et détails KEP, de sorte que les acheteurs disposent d'une voie visible pour les ventes, le support et les notifications formelles.

L'entreprise n'opère donc pas derrière une vitrine complètement opaque. Les éléments de preuve soutiennent l'existence d'un véritable fournisseur d'hébergement turc, d'une société légale nommée, d'un canal de vente au détail sous marque, d'une identité LIR RIPE et d'un AS annoncé. La réserve ne commence pas au niveau de l'identité, mais de l'échelle et de la redondance. Les archives publiques peuvent prouver l'entreprise et un réseau routé.

Elles ne prouvent pas la quantité de matériel déployé, le nombre de racks sous contrôle direct, la capacité de réserve, la fréquence des tests de basculement, ni si la récupération des clients peut être effectuée sans le site principal d'Istanbul.

L'empreinte routée est réelle, actuelle et petite

L'image du réseau public est simple. L'aperçu AS de RIPEstat pour AS202048a montré le titulaire comme CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. et a indiqué l'AS comme annoncé le 12 juillet 2026. Lesdonnées de préfixes annoncés de RIPEstatont montré un préfixe visible, 46.28.232.0/24, du 28 juin 2026 au 12 juillet 2026. Lescomptes de préfixes RIS de RIPEstatont montré un préfixe IPv4 d'origine, zéro préfixe IPv4 de transit, zéro préfixe IPv6 d'origine et zéro préfixe IPv6 de transit au moment de la requête du 12 juillet.

Cela suffit à démontrer un fonctionnement public en direct. L'aperçu de préfixe de RIPEstat pour 46.28.232.0/24marque le /24 comme annoncé par AS202048. Lesdonnées de statut de routage de RIPEstatont montré que 325 sur 326 pairs de flux complet IPv4 voyaient la route au moment de l'échantillonnage, avec un préfixe IPv4 visible et 256 adresses d'espace IPv4 annoncé. Elles ont également montré zéro espace IPv6 visible et un voisin observé. Lavalidation RPKIa renvoyé une ROA valide pour AS202048 et 46.28.232.0/24, avec une longueur maximale de 24.

Les mêmes éléments limitent cependant la revendication. Un seul /24 est une petite empreinte d'adresses publiques. Il peut transporter des serveurs de noms faisant autorité, des nœuds d'hébergement, des relais de messagerie, des points de terminaison de gestion, des services VPS clients ou des systèmes de surveillance, mais il ne constitue pas la preuve d'une vaste région cloud régionale. L'absence d'origine IPv6 visible est particulièrement notable pour un vendeur moderne de cloud et d'hébergement.

La visibilité IPv4 uniquement ne rend pas les services inutilisables, mais elle indique que les clients ayant besoin de services publics double pile doivent demander explicitement la disponibilité IPv6 plutôt que de la supposer existante.

Il n'y a pas non plus d'entrée PeeringDB publique pour cet ASN: larecherche PeeringDB pour l'ASN 202048renvoie un ensemble de données vide. L'absence de PeeringDB n'est pas une preuve de faiblesse technique. De nombreux petits fournisseurs s'appuient sur le transit amont et ne maintiennent pas de profils d'échange publics. Néanmoins, cela supprime un lieu indépendant commun où les opérateurs publient la présence dans les installations, les niveaux de trafic, la politique de peering, les contacts NOC et les connexions d'échange. Pour CloudTeknoloji, les données publiques visibles disent « AS routé réel, un /24 IPv4 actuel, autorisation de route valide, pas d'origine IPv6 visible, pas de profil de peering public. »

C'est un niveau de preuve moyen, pas négatif. Le réseau est visible et actuel, mais cela laisse le client demander des preuves privées pour la capacité multi-site, la diversité de transit, la capacité de réserve des hôtes et la conception du chemin de récupération.

La limite des racks est Istanbul, pas un cloud sans lieu

Le langage des installations de l'entreprise est suffisamment précis pour façonner la conversation sur le risque. Lapage à proposdit que les systèmes sont gérés depuis un centre d'opérations à Istanbul 4. Levent et hébergés dans le centre de données ICS situé à Istanbul, décrit comme certifié PCI/DSS et de norme Tier III. Elle revendique également plus de 100 Gbps de capacité d'accès Internet redondante, de la fibre indépendante des opérateurs, des systèmes d'alimentation et d'UPS entièrement redondants, une double alimentation A+B, la sécurité physique et le refroidissement. Lapolitique de servicerépète la revendication de localisation plus simplement: les serveurs daha.net sont hébergés dans le centre de données ICS d'Istanbul, Tier III.

Cela transforme le mot marketing « cloud » en un lieu. Le service du client dépend des racks à Istanbul, d'un opérateur d'installation, de la distribution électrique, du refroidissement, du câblage, des interconnexions, des ports de commutation, des sessions de transit, du stockage, de l'inventaire matériel et des personnes capables d'effectuer des réparations. Certains de ces éléments peuvent être directement contrôlés par CloudTeknoloji. D'autres relèvent du centre de données ICS ou des opérateurs amont.

Les pages publiques ne divulguent pas quels racks sont loués, quel équipement CloudTeknoloji possède, quelle part de la capacité de l'installation est réservée à daha.net, ni si les mêmes produits peuvent basculer vers une autre ville turque ou un autre pays.

La distinction est importante pour la localité des données. L'offre de CloudTeknoloji est attrayante pour les clients turcs en partie parce qu'elle semble conserver la capacité d'hébergement et de serveur en Turquie. Lapage VDSannonce un emplacement à Istanbul, une virtualisation VMware ESXi et des packages VDS adossés à du SSD. Lapage Pro Cloudannonce à nouveau un emplacement à Istanbul, avec des processeurs Xeon Gold 6138, un support géré et un stockage SSD NVMe. Lapage d'hébergementannonce un hébergement situé à Istanbul, Linux LiteSpeed, Windows IIS, SSL gratuit et sauvegardes hebdomadaires. Lesdonnées de géolocalisation de RIPEstat pour 46.28.232.0/24placent également le préfixe public en Turquie au moment du contrôle.

Mais la localité n'est pas la même chose que la résilience. Une installation turque peut répondre aux exigences de juridiction, de latence ou de support linguistique du client tout en laissant ce client exposé à une défaillance d'un seul site. Si le principal service hébergé, la copie de sauvegarde, le portail de support et le DNS du client dépendent tous du même campus ou du même point de raccordement opérateur, le client a un contrôle local mais une indépendance limitée.

Une revendication de continuité plus solide nommerait un second site, un emplacement de restauration testé, un domaine administratif distinct, un objectif de temps de récupération défini et un chemin d'exportation clair.

Le catalogue de services vend des couches, pas seulement des serveurs

La gamme de produits de daha.net est plus large que celle d'un simple atelier VPS. Lapage d'informations commercialesindique que l'entreprise opère dans l'hébergement web, le serveur cloud, l'enregistrement de domaines, les certificats SSL, la messagerie et les services informatiques connexes. La navigation et les pages produits montrent la même ampleur:serveurs cloud VDS standard,serveurs Pro Cloud gérés,hébergement web, hébergement WordPress, hébergement revendeur, hébergement entreprise, services de domaine, certificats SSL, licences de panneau de contrôle, Microsoft 365, messagerie en masse et services de maintenance de serveur.

Cette ampleur est commercialement utile. Une petite entreprise peut acheter le domaine, l'hébergement, la messagerie, le certificat, le VPS et le support auprès d'un seul fournisseur. Une agence peut conserver les domaines et sites clients sous un seul compte. Un site de commerce électronique turc peut choisir une infrastructure hébergée à Istanbul et un support en langue turque au lieu d'apprendre une console hyperscale. Un client qui a dépassé l'hébergement partagé peut passer à VDS ou Pro Cloud géré sans changer de marque.

Cette même ampleur rend également la dépendance plus difficile à inspecter. L'enregistrement de domaine dépend des canaux de registre et de bureau d'enregistrement. La messagerie peut dépendre de plateformes externes ainsi que du DNS et du support locaux. SSL dépend des autorités de certification et des délais de validation. VDS dépend des hyperviseurs, du stockage et du réseau. Le cloud géré dépend de l'accès du personnel et de la discipline de changement. La maintenance du serveur dépend des compétences et de la disponibilité des ingénieurs.

Une facture groupée peut donner l'impression que tout cela constitue un seul service, alors que la chaîne de défaillance traverse plusieurs opérateurs.

Les pages publiques de CloudTeknoloji font un travail décent en nommant certains ingrédients techniques. La page VDS annonce VMware ESXi, stockage SSD, accès root complet, processeurs Intel Xeon E5-2695 V4 et des tailles de package allant de machines à deux cœurs plus petites jusqu'à des niveaux à six cœurs, 8 Go de RAM et 80 Go SSD. La page Pro Cloud annonce Xeon Gold 6138, SSD NVMe, ressources allouées, service géré, mises à jour de sécurité, optimisation et suivi technique. La page d'hébergement annonce Linux LiteSpeed, Windows IIS, SSD NVMe, cPanel ou Plesk et des sauvegardes hebdomadaires. Ce ne sont pas des mots à la mode vides.

Ils identifient des familles de produits et certaines classes de matériel.

Pourtant, les informations publiques s'arrêtent avant les questions de capacité les plus difficiles. Combien d'hôtes physiques soutiennent chaque famille de plan? Quel est le ratio de sursouscription? Combien de nœuds de réserve peuvent absorber la défaillance d'un hôte? Les systèmes de stockage VDS sont-ils locaux, partagés, répliqués ou sauvegardés par des snapshots? Le niveau Pro Cloud fonctionne-t-il sur des hôtes différents du VDS standard, ou simplement sur une classe de ressources supérieure avec un support géré? Les dépôts de sauvegarde sont-ils en dehors de la couche de stockage de production?

Un client peut-il exporter une image de VM, ou seulement des fichiers et des sauvegardes de panneau de contrôle? Ces questions déterminent si un plan vendu est confortable uniquement les jours normaux ou durable pendant les jours de réparation.

La route semble maintenant dépendre du côté ICS de l'installation

Le chemin de routage public pointe vers la limite installation/opérateur. L'enregistrement aut-numde la base de données RIPE pour AS202048 contient des lignes de politique d'import et d'export pour AS48678, AS42910 et AS214588. Cependant, lacohérence de routage AS de RIPEstatmontre une différence entre la politique enregistrée et le routage observé: AS214588 est dans BGP et dans les données de politique, tandis que AS48678 et AS42910 apparaissent dans les données de politique mais n'ont pas été observés dans BGP au moment de l'échantillonnage. Lesdonnées des voisins ASN de RIPEstatont également signalé un voisin unique du côté gauche, AS214588, pour la dernière période disponible.

AS214588 n'est pas un saut aléatoire sans rapport. L'enregistrement AS214588de RIPE le nommeicsteknoloji, et l'aperçu AS214588 de RIPEstatdonne le titulaire comme ICS Bilisim Teknolojileri Danismanlik Hizmetleri A.S. Les données de politique AS214588 montrent des relations amont avec Turkcell/Superonline, Turk Telekom et Vodafone. L'échantillon d'état BGP pour 46.28.232.0/24montre de même des chemins globaux atteignant AS202048 via AS214588 dans les routes échantillonnées.

Cela ne prouve pas que CloudTeknoloji n'a pas de lien de sauvegarde privé, de chemin de fibre noire et de récupération hors bande. Les collecteurs BGP publics ne montrent que ce qui est globalement visible à un moment donné. Mais pour un client achetant une capacité hébergée, le chemin public actuel reste significatif. Si le service Internet public de AS202048 est actuellement atteint via AS214588, alors la coordination avec l'installation et l'amont du côté ICS fait partie de la surface d'exploitation de CloudTeknoloji.

Une erreur de routage, un litige commercial, un défaut d'interconnexion, un problème d'atténuation DDoS, un événement électrique, une défaillance de l'opérateur ou un transfert mal configuré sur ce chemin peut affecter les clients de CloudTeknoloji même si leur VM est en bonne santé.

La question pratique est la diversité de transit. La propre page de l'entreprise CloudTeknoloji revendique une fibre indépendante des opérateurs et une capacité Internet redondante de plus de 100 Gbps pour son infrastructure. C'est une affirmation forte, mais la vue AS publique montre un voisin observé à la périphérie de CloudTeknoloji. Ces deux déclarations peuvent coexister si l'installation sous-jacente a plusieurs opérateurs tandis que le propre AS de CloudTeknoloji utilise actuellement le réseau ICS comme point de transfert de transit public.

Elles peuvent également coexister si les options de sauvegarde sont réservées à l'usage de l'installation, aux circuits privés ou au basculement manuel plutôt que d'être visibles en tant que sessions BGP simultanées. Le client doit demander quelle interprétation s'applique.

Pour les services critiques, la réponse doit être contractuelle et technique. Les clients doivent savoir si leurs IP publiques restent joignables via un second amont si AS214588 est altéré, s'il y a un basculement de route automatique, si le filtrage DDoS dépend du même chemin, et si le DNS, les panneaux de gestion et les portails de support restent joignables si la route principale AS202048 est retirée. Sans ces réponses, les preuves publiques soutiennent une vue prudente: la route actuelle est réelle, proprement autorisée et visible, mais concentrée extérieurement.

La capacité hébergée est vendue comme instantanée, mais la réparation ne l'est pas

La page VDS met l'accent sur une configuration rapide et des augmentations faciles de ressources. Elle indique que les serveurs cloud utilisent la virtualisation VMware ESXi, le stockage SSD, l'accès root complet et des ressources isolées, et elle annonce des mises à niveau de ressources via le panneau client. La page Pro Cloud va plus loin, en vendant un service géré, des ressources allouées, des processeurs Xeon Gold et du SSD NVMe pour des sites plus lourds, des SaaS, des agences, du commerce électronique et des projets à fort trafic. C'est la promesse client: prendre un serveur sans posséder de serveur.

La réalité opérationnelle est plus lente. Un serveur virtuel peut être créé en quelques minutes, mais le substrat physique tombe toujours en panne en quelques heures. Les disques échouent. Les reconstructions RAID consomment des E/S. Les hôtes nécessitent des mises à jour de firmware. Les ports de commutation se comportent mal. Les hyperviseurs ont besoin de correctifs. Les travaux de sauvegarde manquent des fenêtres. Un pool de stockage peut être plein même lorsque la page de compte indique que le plan est actif. Le mot cloud public ne supprime pas la boîte de pièces.

Lapolitique de serviceest utile car elle admet une partie de cette friction. Elle indique que les comptes payés par carte de crédit peuvent s'activer en quelques minutes, mais que les services au-delà de l'hébergement et de l'enregistrement de domaine - y compris les serveurs cloud, les licences, les certificats SSL et la messagerie en masse - peuvent prendre jusqu'à huit heures pour être installés ou livrés en dehors des heures ouvrables. Elle indique que les commandes par virement bancaire nécessitent un avis de paiement et des vérifications. Elle indique que les services d'hébergement et de serveur cloud impayés sont supprimés des serveurs après 30 jours. Elle indique également que les serveurs cloud utilisent un pool partagé de 10 Mbit sauf si le client loue une ligne pour une limite différente.

Ces détails ne rendent pas le produit mauvais. Ils le rendent fini. « Instantané » est une expérience de vente pour le chemin commun. La livraison en dehors des heures de travail, les mises à niveau de capacité, l'installation de logiciels personnalisés, les changements de ligne et les comptes en souffrance ont des règles différentes. Un client planifiant une migration vers CloudTeknoloji ne doit pas supposer que chaque changement de ressource, ajout de licence ou exception de bande passante est automatique.

Il doit demander si la bande passante par défaut du plan est suffisante, si l'option payante change uniquement la limite de débit ou aussi la priorité de route, si la renumérotation IP est requise pour les changements de ligne, et si les augmentations de ressources ont des contraintes au niveau de l'hôte.

Le langage du pool partagé de 10 Mbit est particulièrement important. De nombreux acheteurs de VDS pensent d'abord aux cœurs, à la RAM et au disque. Le débit réseau ne devient souvent visible que lorsqu'un site est attaqué, qu'une restauration de sauvegarde s'exécute, qu'une campagne de commerce électronique commence ou qu'un fichier multimédia doit être distribué. Un pool partagé de 10 Mbit peut suffire pour des sites professionnels calmes, mais il ne remplace pas un chemin de récupération à haut débit testé.

Si un client s'attend à restaurer rapidement des centaines de gigaoctets ou à servir de grands pics de trafic, la règle de débit réseau doit faire partie de la discussion de conception avant que la commande ne soit passée.

Les engagements de support sont visibles, mais ils ne sont pas tous identiques

daha.net publie plusieurs déclarations de support, et elles doivent être lues ensemble plutôt que de manière sélective. Lapolitique de serviceliste le support téléphonique en semaine du lundi au vendredi, de 09h00 à 17h30, le support comptable en semaine pendant la même fenêtre, et le support technique par email sept jours sur sept, 24 heures sur 24, avec une garantie de réponse de 60 minutes. Plus loin dans la même politique, la section support client indique que daha.net s'engage à répondre dans les 60 minutes pendant les heures de travail et dans les huit heures en dehors des heures de travail. Lapage à proposet lapage de contactfont également référence à la disponibilité téléphonique en semaine et à l'accès continu par email ou ticket de support.

La nuance compte. Une réponse n'est pas la même chose qu'une réparation. Une réponse peut confirmer la réception, identifier le service affecté, demander des informations d'identification ou dire qu'un fournisseur a été contacté. La réparation peut dépendre du personnel de l'installation, des ingénieurs amont, du stock de matériel, d'une licence de fournisseur, de l'administrateur du client ou d'un registre de domaine. Pour le support d'hébergement de routine, une réponse de 60 minutes peut être suffisante.

Pour une caisse de commerce électronique en panne, une panne de messagerie, un ERP inaccessible, un serveur compromis ou une restauration de base de données échouée, le client a besoin de conditions d'escalade, pas seulement de conditions de première réponse.

L'histoire du support de CloudTeknoloji est plus solide que celle d'un hébergeur économique sans contact car elle publie des numéros de téléphone, des emails de support, un chemin de ticket, une adresse professionnelle, une adresse KEP et des conditions écrites. Le risque est que ces mêmes conditions publiées montrent également des limites naturelles: la couverture téléphonique n'est pas 24 heures, la livraison de certains services non essentiels peut attendre en dehors des heures de travail, et le délai de réponse en dehors des heures est décrit de deux manières.

Un acheteur doit demander quelle clause contrôle son produit spécifique, si le Pro Cloud géré bénéficie d'une escalade différente du VDS non géré, si la réponse d'urgence inclut une intervention au niveau de l'installation, et s'il existe un système de gravité nommé avec des objectifs de temps de réparation.

Le personnel recoupe également la migration. La page VDS annonce un support de migration gratuit, y compris le déplacement de sites web et de bases de données sans perte de données ni interruption de service. Cela est précieux si c'est vrai dans le cas d'un client, mais cela doit être délimité. Déplacer un site web cPanel n'est pas la même chose que déplacer une application personnalisée, un serveur Windows, une base de données en direct, une archive de messagerie, une zone DNS, une configuration DNSSEC, une liste blanche de pare-feu, des tâches cron et des intégrations tierces.

Les clients doivent demander ce que couvre la « migration gratuite », ce qui doit être préparé par le client, si la migration est planifiée, si le retour en arrière est inclus, et combien de temps l'ancien site doit rester en ligne.

Les fenêtres de maintenance sont explicites et suffisamment grandes pour avoir de l'importance

La clause de maintenance est l'un des signes les plus clairs que le cloud de CloudTeknoloji reste une infrastructure ordinaire. Lapolitique de serviceindique que lorsque la maintenance du serveur, le déplacement ou les mises à jour matérielles sont nécessaires, les clients sont avertis une semaine, trois jours et un jour avant l'interruption. Elle indique que ces interruptions ne dépasseront pas un total de 96 heures par an et ne seront pas effectuées pendant les heures de travail sauf nécessité. Elle exclut également la responsabilité pour force majeure en cas de retard, d'incomplétude ou de non-exécution.

Quatre-vingt-seize heures par an n'est pas un objectif de temps d'arrêt; c'est un plafond de maintenance tel qu'écrit dans la politique. Même ainsi, c'est un nombre de planification significatif pour le client. Une entreprise qui ne lit que le langage de disponibilité de la page d'hébergement peut s'attendre à un service quasi continu. Une entreprise qui lit la politique voit que le travail d'infrastructure planifié peut consommer un nombre important d'heures au cours d'une année.

Cela peut être acceptable pour des sites à faible risque, des environnements de développement, des brochures de petites entreprises ou des applications locales non critiques. Cela ne suffit pas pour un client dont la prise de commandes, le centre d'appels, les flux de paiement ou les systèmes de clinique doivent fonctionner pendant chaque nuit de maintenance.

La question importante est de savoir comment la maintenance est isolée. Un hôte peut-il être vidé pendant que les charges de travail se poursuivent ailleurs? Les clients VDS sont-ils migrés en direct entre les hôtes? La maintenance du stockage nécessite-t-elle des temps d'arrêt? Les événements de maintenance du réseau sont-ils redondants au niveau du commutateur ou du transit? Les clients Pro Cloud peuvent-ils acheter une disponibilité plus élevée que le VDS standard? Les restaurations de sauvegarde sont-elles testées après le remplacement du matériel?

L'avis d'une semaine, trois jours, un jour s'applique-t-il à toutes les maintenances ou seulement aux temps d'arrêt prévus? La politique fournit le modèle d'alerte public, mais le client a besoin de détails d'architecture.

Cela affecte également les clients agences et revendeurs. Si un revendeur héberge des dizaines de sites clients sur daha.net, un événement de maintenance peut devenir des dizaines d'emails clients. Si un fournisseur de services gérés utilise daha.net comme couche VPS turque, une nuit de réparation peut affecter tous les clients en aval. Si un opérateur de commerce électronique a une campagne planifiée, l'avis de maintenance doit être compatible avec les fenêtres de gel. La capacité hébergée devient un calendrier partagé, pas seulement un graphique de ressources.

Le langage de sauvegarde est utile car il n'est pas trop rassurant

Le langage de sauvegarde de daha.net est plus honnête que de nombreuses pages d'hébergement, et il doit être lu attentivement. Les pages de produits d'hébergement et de VDS annoncent des fonctionnalités de sauvegarde hebdomadaire ou périodique. Lapolitique de servicedonne la règle plus dure: les serveurs d'hébergement sont sauvegardés chaque semaine et chaque mois, les services de serveur ne sont pas sauvegardés sauf si le client achète un service de sauvegarde, les sauvegardes peuvent être défectueuses ou inutilisables, aucune garantie n'est donnée aux clients à partir de ces sauvegardes, et la sauvegarde du compte est la responsabilité du client. Elle indique également que lorsqu'un client a besoin d'une sauvegarde effectuée par daha.net, l'entreprise peut fournir une sauvegarde disponible à sa discrétion, en fonction du système de sauvegarde.

Ce langage devrait éloigner les clients de la pensée magique. Une étiquette de sauvegarde sur un plan d'hébergement n'est pas la même chose qu'un service de restauration garanti. Pour l'hébergement partagé, les sauvegardes hebdomadaires et mensuelles peuvent aider à la suppression accidentelle ou à la défaillance du site, mais la politique décline toute garantie de récupération. Pour les services VDS et serveur, la politique indique que la sauvegarde n'est pas incluse sauf achat.

Pour les charges de travail critiques, l'acheteur doit supposer qu'il a besoin de son propre plan de sauvegarde testé jusqu'à ce que les conditions écrites disent le contraire.

La différence entre « la sauvegarde existe » et « la restauration fonctionne » est centrale pour cette entreprise. CloudTeknoloji vend une capacité hébergée, mais le client peut encore posséder la protection des données. Un site WordPress peut être sauvegardé au niveau de l'application vers un compte de stockage externe. Un VDS peut effectuer un snapshot vers une région distincte. Une base de données peut diffuser des répliques ou des dumps vers un second fournisseur. Le DNS peut être hébergé chez un opérateur distinct.

Le client peut réduire le risque en faisant de CloudTeknoloji l'hôte principal sans en faire le seul endroit où les données existent.

Le client doit poser cinq questions de sauvegarde avant d'utiliser daha.net pour quoi que ce soit d'important. Premièrement, la sauvegarde est-elle incluse pour ce produit exact, ou doit-elle être achetée séparément? Deuxièmement, où la sauvegarde est-elle stockée par rapport au système principal hébergé par ICS? Troisièmement, à quelle fréquence une restauration est-elle testée? Quatrièmement, qui a les clés de chiffrement et les droits d'administration? Cinquièmement, combien de temps prendrait une restauration complète au débit réseau par défaut?

La politique publique répond à une partie de la première question et avertit que les autres comptent.

La facturation, l'annulation et la suppression des données font partie de la disponibilité

Les articles sur l'infrastructure se concentrent souvent sur les routes et les racks, mais les conditions de CloudTeknoloji montrent que l'état commercial peut être tout aussi important. Lapolitique de serviceindique que les commandes impayées pendant sept jours sont automatiquement annulées. Elle indique que les services d'hébergement et de serveur cloud qui ne sont pas renouvelés sont complètement supprimés des serveurs un mois après la période de renouvellement. Elle indique que l'annulation du service supprime le compte ainsi que les sauvegardes. Elle restreint également l'admissibilité au remboursement pour certains modules complémentaires, licences, domaines, SSL et autres services, et indique que l'admissibilité au remboursement du serveur cloud peut disparaître si l'équipe technique installe des modules complémentaires ou des logiciels à la demande du client.

Pour un site web grand public, ces conditions peuvent être courantes. Pour une charge de travail professionnelle, elles constituent une dépendance. Une défaillance de carte de paiement, un litige de facture, un retard d'approvisionnement ou un changement de personnel peut se transformer en suppression de données si le renouvellement n'est pas contrôlé. Un client quittant daha.net doit exporter les fichiers, bases de données, DNS, boîtes aux lettres, certificats, clés, licences et images de serveur avant l'annulation ou le non-renouvellement.

Un client qui s'appuie sur les sauvegardes pour le retour en arrière doit comprendre si ces sauvegardes disparaissent avec le compte.

C'est là que l'économie de l'hébergement rencontre le risque. Un fournisseur local groupé peut être moins cher et plus facile que de construire une infrastructure redondante à partir de zéro. Mais un hébergement moins cher repousse souvent une partie de la responsabilité opérationnelle vers le client: discipline de renouvellement, sauvegardes, préparation à la migration, stockage des informations d'identification, gestion du verrouillage de domaine, TTL DNS et copies de restauration hors fournisseur. Le client doit avoir un plan de départ dès le premier jour, pas après un incident.

Le plan de départ est simple en principe. Conservez l'accès au bureau d'enregistrement indépendant lorsque c'est possible. Conservez les exportations DNS. Conservez les sauvegardes hors plateforme. Sachez quelles adresses IP sont liées aux listes blanches. Conservez une liste à jour des certificats SSL et des dates de renouvellement. Testez la restauration d'un site vers un autre fournisseur. Conservez la continuité de la messagerie en dehors d'un seul compte d'hébergement web si la messagerie est critique. Rien de tout cela ne signifie éviter CloudTeknoloji.

Cela signifie l'utiliser comme un fournisseur, pas comme la seule copie de l'entreprise.

La souveraineté des données est un véritable argument de vente avec un compromis de récupération

Pour les clients turcs, l'hébergement local peut être précieux. Il peut réduire la latence vers les utilisateurs nationaux, simplifier le support linguistique et fiscal, maintenir les contrats sous une juridiction familière, et soutenir les préférences de localité des données. Les pages officielles de CloudTeknoloji s'appuient sur ce profil local: bureaux à Istanbul, installation à Istanbul, support turc, acceptation des commandes uniquement en Turquie dans la politique, identité juridique turque, adresse KEP et un ensemble de services visant l'hébergement local, les domaines et la messagerie d'entreprise. Lavue de géolocalisation pour 46.28.232.0/24aligne également le préfixe public visible sur la Turquie.

La localité peut cependant concentrer le risque si elle n'est pas associée à une récupération indépendante. Un client qui doit conserver des données en Turquie peut encore avoir besoin d'un second site turc, d'un second fournisseur, d'un second compte de sauvegarde ou au moins d'un arrangement DNS et de restauration distinct. Un client qui peut utiliser une copie de récupération à l'étranger peut obtenir une séparation géographique plus facile mais doit tenir compte des limites juridiques, de confidentialité et contractuelles. Les pages publiques de CloudTeknoloji ne résolvent pas ce compromis.

Elles montrent un fournisseur centré sur la Turquie. Elles ne publient pas une architecture de récupération multi-site complète.

La bonne conclusion n'est pas que l'hébergement local turc est faible. C'est que la souveraineté et la résilience sont des objectifs de conception distincts. Le premier demande où vivent les données et quelle loi s'applique. Le second demande si un client peut continuer après une défaillance de site, de route, de stockage, de personnel ou de compte. CloudTeknoloji peut aider avec le premier en gardant les services à Istanbul. Le client doit encore vérifier le second.

Cela est particulièrement vrai pour les clients ayant des charges de travail réglementées, réputationnelles ou sensibles aux revenus. Une école, une clinique, une agence, un site de commerce électronique ou un bureau professionnel peut choisir daha.net parce que le bureau d'assistance parle la même langue, l'entité juridique est joignable et le serveur est à Istanbul. C'est rationnel. Mais si le même service est également le seul hôte DNS, le seul hôte de messagerie, le seul emplacement de sauvegarde et le seul chemin vers le support, alors un avantage local devient un point de défaillance unique opérationnel.

La solution n'est pas abstraite: sauvegarde séparée, DNS séparé, basculement documenté, restauration testée et escalade écrite.

Qui est affecté lorsque ce système tombe en panne

Le premier groupe affecté est celui des clients d'hébergement partagé. Ce sont les utilisateurs les plus susceptibles de ressentir les limites de la plateforme mais les moins susceptibles de comprendre l'installation derrière eux. Une défaillance de l'hébergement partagé peut mettre hors ligne à la fois les sites web, les boîtes aux lettres, les bases de données, les panneaux de contrôle et les chemins de renouvellement SSL. Le client peut ne pas avoir d'accès root ou de contrôle direct de la sauvegarde.

Les clauses de non-responsabilité de la politique de service en matière de sauvegarde importent donc le plus pour les clients les moins techniques.

Le deuxième groupe est celui des clients VDS et Pro Cloud. Ils ont plus de contrôle, mais ils héritent également de plus de responsabilités. Un client VDS non géré a un accès root et peut construire sa propre pile, mais les mises à jour du système d'exploitation, la sécurité des applications, la sauvegarde de la base de données et la planification de la restauration peuvent incomber au client. Un client Pro Cloud géré peut obtenir plus d'aide, mais doit encore confirmer exactement quelles couches sont gérées, lesquelles font l'objet d'un support au mieux et lesquelles restent la propriété du client.

Le troisième groupe est celui des agences et des revendeurs. Ils transforment un fournisseur amont en de nombreuses promesses en aval. S'ils achètent de l'hébergement revendeur, de la capacité VDS ou des serveurs gérés auprès de daha.net, leurs propres clients peuvent voir l'agence comme l'opérateur. Une fenêtre de maintenance daha.net, une file d'attente de support ou un problème de route devient un incident d'agence. Ces clients ont besoin de mises à jour de statut, de modèles de communication client, de sauvegardes de migration et de limites de service claires avant que les problèmes ne commencent.

Le quatrième groupe est celui des clients de domaine et de messagerie. L'expiration de domaine, les limitations de transfert, les erreurs DNS et les échecs de routage de messagerie peuvent durer plus longtemps qu'une panne web. La politique de service décrit les avis de renouvellement de domaine, le renouvellement automatique, les périodes de restauration et les conditions de transfert. Les clients qui placent le domaine, le DNS, l'hébergement et la messagerie sous un seul compte obtiennent une commodité. Ils placent également le renouvellement, les informations d'identification et l'escalade de support en un seul endroit.

Séparer l'accès à la propriété du contrôle de l'hébergement peut réduire ce risque.

Le dernier groupe affecté est CloudTeknoloji lui-même. Un petit AS public et une route concentrée ne signifient pas automatiquement une faiblesse opérationnelle, mais ils signifient que chaque incident public peut avoir un poids réputationnel. Si les clients voient la marque comme un partenaire de fiabilité local, ils s'attendront à des avis clairs, des pages de statut honnêtes, des mises à jour de réparation rapides et une aide pratique à la migration. La politique de service publique reconnaît déjà les avis de maintenance et la réponse du support.

Le prochain signal de maturité serait un historique d'incidents transparent et des conditions de récupération spécifiques aux produits.

Ce qui réglerait les questions ouvertes

Le dossier public est suffisant pour un profil prudent, mais pas assez pour une évaluation de résilience à haute confiance. Cinq divulgations supplémentaires modifieraient sensiblement la note.

Premièrement, CloudTeknoloji pourrait publier ou fournir sous contrat une limite d'installation et de propriété: quels services fonctionnent dans le centre de données ICS, lesquels sont sur du matériel appartenant à CloudTeknoloji, lesquels sont une capacité louée et lesquels dépendent de fournisseurs tiers. Deuxièmement, elle pourrait publier les conditions de sauvegarde spécifiques aux produits: sauvegardes incluses, sauvegardes payantes, rétention, emplacement hors site, temps de restauration, test de restauration et responsabilité du client.

Troisièmement, elle pourrait énoncer la conception de transit pour AS202048: amonts actuels, comportement de basculement, gestion DDoS, disponibilité IPv6 et si AS48678 ou AS42910 restent des options de sauvegarde disponibles ou seulement des lignes de politique historique. Quatrièmement, elle pourrait fournir des engagements de maintenance et d'urgence par niveau de produit, en distinguant la réponse de la réparation.

Cinquièmement, elle pourrait documenter les droits de sortie: exportations de VM, sauvegardes du panneau de contrôle, exportation de zone DNS, support de transfert de domaine, limites de portabilité IP et délais de suppression de compte.

Certains de ces détails peuvent déjà exister dans les contrats clients ou les propositions commerciales. La question est la vérifiabilité publique. De l'extérieur, l'entreprise a une empreinte d'identité plus solide que de nombreux hébergeurs, une route en direct et autorisée, et une histoire d'hébergement cohérente à Istanbul. Elle a également un petit réseau public visible, pas d'origine IPv6 visible, un chemin amont observé via ICS, et des conditions de service qui placent une responsabilité de sauvegarde et de renouvellement significative sur le client.

Le travail de l'acheteur est de faire correspondre la criticité de la charge de travail à ces preuves. Un site de brochure à faible risque, un petit site WordPress, une configuration de messagerie d'entreprise locale ou un VPS de développement peuvent convenir confortablement. Une vitrine à fort trafic, un entrepôt de données réglementé, un service d'urgence public, une application critique pour les paiements ou une plateforme multi-clients de revendeur devraient exiger des preuves écrites de redondance et de restauration avant de déplacer la production.

En résumé

CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. ne mérite ni le rejet ni la confiance aveugle. L'entreprise derrière daha.net est identifiable, a fonctionné sous une identité commerciale turque visible, publie des informations de contact et juridiques, vend un large catalogue d'hébergement, revendique un hébergement dans une installation à Istanbul et porte un AS public en direct. La route publique pour AS202048 est annoncée, visible par les collecteurs et couverte par une autorisation RPKI valide pour 46.28.232.0/24.

La prudence vient du fait que l'empreinte publique est étroite. Un /24 IPv4 visible, pas d'origine IPv6 visible, pas de profil PeeringDB public et un seul voisin AS actuellement observé ne prouvent pas une large redondance. Les conditions de service officielles rappellent également aux clients que les serveurs cloud, les sauvegardes, la maintenance, les heures de support, la bande passante et l'état de renouvellement ont des limites.

En termes simples, CloudTeknoloji vend une capacité hébergée qui peut être précieuse pour les entreprises turques, mais cette capacité dépend encore des racks, du transit, de l'alimentation, du remplacement du matériel, de la réponse du personnel et de la propre discipline de sauvegarde et de migration du client.

La bonne posture de l'acheteur est pratique: utiliser le fournisseur local lorsque son hébergement à Istanbul, son support turc et ses services groupés correspondent à la charge de travail, mais faire en sorte que le fournisseur montre le chemin de récupération. Demandez où se trouvent les données, où se trouve la sauvegarde, quelle route bascule, comment les réparations sont escaladées, à quelle vitesse une restauration complète peut s'exécuter, ce qui se passe après le non-renouvellement, et comment le client part proprement.

Tant que ces réponses ne sont pas écrites et testées, les preuves publiques soutiennent un profil d'infrastructure de confiance moyenne: fonctionnement réel, profondeur limitée du réseau public et questions de récupération qui comptent plus que le mot « cloud ».