CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. vend une capacité hébergée qui dépend toujours de baies, de transit et de fenêtres de maintenance

Résumé

• CloudTeknoloji est la société derrière daha.net. Lapage d'informations commercialespublique nomme CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. comme l'entreprise légale, donne daha.net comme marque, liste l'adresse à Istanbul, le téléphone, le numéro MERSIS et le numéro d'immatriculation au registre du commerce, et décrit des services d'hébergement, serveur cloud, domaine, SSL, email et services IT connexes.
• L'affirmation sur l'infrastructure est spécifique mais pas totalement indépendante. Lapage à proposindique que les systèmes daha.net sont gérés depuis Istanbul 4. Levent et hébergés dans l'ICS centres de données d'Istanbul, avec des affirmations concernant le Tier III, PCI/DSS, une capacité Internet redondante, une fibre indépendante de l'opérateur, un UPS, une alimentation A+B, une sécurité physique et un refroidissement. Les lecteurs doivent considérer ces affirmations comme des allégations de l'entreprise sauf si elles sont confirmées par des contrats clients ou des certificats d'installation.
• L'empreinte de routage public 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 fin-juin-à-12-juillet-2026. Lescomptes de préfixes RISmontrent un préfixe d'origine IPv4, aucun préfixe de transit et aucun préfixe d'origine IPv6.
• La principale question client n'est pas de savoir si daha.net existe. Il s'agit de savoir dans quelle mesure le site web, VPS, mail, DNS, sauvegarde et plan de migration d'un client sont liés à une seule installation stambouliote, un petit bloc d'adresses routé, le chemin amont ICS actuellement observé, les fenêtres de réponse du support et les 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 le bureau des impôts de Maslak, donne le numéro de taxe 5470543764, le numéro MERSIS 0547054376400001 et le numéro d'immatriculation au registre du commerce 759033, et précise 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 un téléphone, un fax, un email et des coordonnées KEP.

Cela importe car il ne s'agit pas simplement d'un vendeur de noms de domaine anonyme. Un acheteur peut relier la marque, l'entreprise, l'adresse, l'identité au registre et l'identité réseau publique. Leenregistrement d'organisation de RIPE pour ORG-SBHv1-RIPEliste Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. en Turquie, montre le même numéro d'immatriculation au 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-num de RIPE pour AS202048nomme 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 client. Lapage à proposindique que daha.net opère depuis 2010 et sert des clients individuels et corporatifs 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 comprenant l'hébergement, le serveur cloud, l'hébergement revendeur, le domaine, le SSL et l'email corporatif. Lapage de contactdonne le téléphone public, le fax, les emails de support, l'adresse et les coordonnées KEP, donc les acheteurs ont un chemin visible pour les ventes, le support et les avis formels.

L'entreprise n'opère donc pas derrière une vitrine complètement opaque. Les preuves soutiennent un véritable fournisseur d'hébergement turc, une entreprise légale nommée, un canal de vente au détail de marque, une identité LIR RIPE et un AS annoncé. La restriction commence non pas à l'identité, mais à l'échelle et à la redondance. Les enregistrements publics peuvent prouver l'entreprise et un réseau routé.

Ils ne prouvent pas combien de matériel est déployé, combien de baies sont sous contrôle direct, combien de capacité de réserve est réservée, à quelle fréquence le basculement est testé, ou si une récupération client peut être effectuée sans le site principal d'Istanbul.

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

L'image réseau publique est simple. L'aperçu AS de RIPEstat pour AS202048a montré le détenteur comme CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. et a marqué 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 d'origine IPv4, zéro préfixe de transit IPv4, zéro préfixe d'origine IPv6 et zéro préfixe de transit IPv6 au moment de la requête du 12 juillet.

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

Les mêmes preuves limitent la prétention. Un seul /24 est une petite empreinte d'adresse publique. Il peut porter 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 ce n'est pas une preuve d'une région cloud régionale étendue. 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 devraient demander une disponibilité IPv6 explicite plutôt que de supposer qu'elle existe.

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

C'est une qualité de preuve moyenne, pas négative. Le réseau est visible et actuel, mais il laisse le client demander une preuve privée pour la capacité multisite, la diversité de transit, la capacité d'hôte de réserve et la conception du chemin de récupération.

La frontière du rack est Istanbul, pas un cloud sans emplacement

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

Cela transforme le mot marketing « cloud » en un lieu. Le service du client dépend de baies à Istanbul, d'un opérateur d'installation, de la distribution d'énergie, du refroidissement, du câblage, des interconnexions, des ports de commutateur, 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 de l'ICS centres de données ou des transporteurs en amont.

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

La distinction est importante pour la localisation des données. L'offre de CloudTeknoloji est attractive pour les clients turcs en partie parce qu'elle semble garder la capacité d'hébergement et de serveur en Turquie. Lapage VDSfait la publicité de l'emplacement Istanbul, de la virtualisation VMware ESXi et des packages VDS avec stockage SSD. Lapage Pro Cloudfait à nouveau la publicité de l'emplacement Istanbul, avec des processeurs Xeon Gold 6138, un support géré et un stockage NVMe SSD. Lapage d'hébergementfait la publicité d'un hébergement situé à Istanbul, Linux LiteSpeed, Windows IIS, SSL gratuit et sauvegardes hebdomadaires. Lesdonnées de géolocalisation RIPEstat pour 46.28.232.0/24placent également le préfixe public en Turquie au moment vérifié.

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 d'un client tout en laissant ce client exposé à une panne de site unique. Si le service hébergé principal, la copie de sauvegarde, le portail de support et le DNS client dépendent tous du même campus ou de la même remise de transporteur, le client a un contrôle local mais une indépendance limitée.

Une affirmation de continuité plus forte nommerait un deuxième site, un emplacement de restauration testé, un domaine administratif séparé, 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 qu'une boutique VPS étroite. Lapage d'informations commercialesindique que l'entreprise opère dans l'hébergement web, le serveur cloud, l'enregistrement de domaine, les certificats SSL, l'email et les services IT connexes. La navigation et les pages de produits montrent la même largeur:serveurs cloud VDS standard,serveurs cloud Pro gérés,hébergement web, hébergement WordPress, hébergement revendeur, hébergement corporatif, services de domaine, certificats SSL, licences de panneau de contrôle, Microsoft 365, email en masse et services de maintenance de serveur.

Cette largeur est commercialement utile. Une petite entreprise peut acheter domaine, hébergement, email, certificat, VPS et support auprès d'un seul fournisseur. Une agence peut garder les domaines et sites clients sous un seul compte. Un site e-commerce turc peut choisir une infrastructure hébergée à Istanbul et un support en turc plutôt que 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.

La même largeur rend également la dépendance plus difficile à inspecter. L'enregistrement de domaine dépend des canaux de registre et de registraire. L'email peut dépendre de plates-formes externes ainsi que du DNS local et du support. Le SSL dépend des autorités de certification et du timing de validation. Le 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 tous ces éléments sont un seul service, alors que la chaîne de défaillance traverse encore plusieurs opérateurs.

Les pages publiques de CloudTeknoloji font un travail décent pour nommer certains ingrédients techniques. La page VDS fait la publicité de VMware ESXi, de stockage SSD, d'accès root complet, de processeurs Intel Xeon E5-2695 V4 et de tailles de packages allant de machines à deux cœurs plus petites jusqu'à des niveaux à six cœurs, 8 Go RAM et 80 Go SSD. La page Pro Cloud fait la publicité de Xeon Gold 6138, NVMe SSD, ressources allouées, service géré, mises à jour de sécurité, optimisation et suivi technique. La page d'hébergement fait la publicité de Linux LiteSpeed, Windows IIS, NVMe SSD, cPanel ou Plesk et 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 plans? Quel est le taux de sur-réservation? Combien de nœuds de réserve peuvent absorber la panne d'un hôte? Les systèmes de stockage VDS sont-ils locaux, partagés, répliqués ou sauvegardés par des instantanés? 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 référentiels de sauvegarde sont-ils en dehors de la couche de stockage de production?

Un client peut-il exporter une image VM, ou seulement des fichiers et des sauvegardes de panneau de configuration? Ces questions décident si un plan vendu est confortable uniquement pendant 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 frontière installation/opérateur. L'enregistrement aut-num de RIPE pour AS202048contient 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 échantillonné. Lesdonnées de voisins ASN de RIPEstatont également rapporté un voisin gauche unique, AS214588, pour le dernier temps disponible.

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

Cela ne prouve pas que CloudTeknoloji n'a pas de liaison de sauvegarde privée, de chemin de fibre noire ou 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 de la capacité hébergée, le chemin public actuel est toujours significatif. Si le service Internet public d'AS202048 est actuellement atteint via AS214588, alors la coordination de l'installation et du transporteur avec le côté ICS fait partie de la surface d'exploitation de CloudTeknoloji.

Une erreur de routage, un différend commercial, un défaut d'interconnexion, un problème de mitigation DDoS, un événement d'alimentation, une panne de transporteur ou un handoff mal configuré sur ce chemin peut affecter les clients de CloudTeknoloji même si leur VM est saine.

La question pratique est la diversité de transit. La propre page de l'entreprise de CloudTeknoloji revendique une fibre indépendante de l'opérateur 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 transporteurs tandis que l'AS de CloudTeknoloji utilise actuellement le réseau ICS comme handoff de transit public.

Elles peuvent également coexister si les options de sauvegarde sont réservées à l'utilisation de l'installation, aux circuits privés ou au basculement manuel plutôt que d'être visibles comme des 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 deuxième transporteur si AS214588 est dégradé, 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 AS202048 principale 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 extérieurement concentrée.

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 la configuration rapide et l'augmentation facile des ressources. Elle indique que les serveurs cloud utilisent la virtualisation VMware ESXi, un stockage SSD, un accès root complet et des ressources isolées, et elle vante les mises à niveau de ressources via le panneau client. La page Pro Cloud va plus loin, vendant un service géré, des ressources allouées, des processeurs Xeon Gold et du stockage NVMe SSD pour les sites plus lourds, SaaS, agences, e-commerce et 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 minutes, mais le substrat physique tombe encore en panne en heures. Les disques tombent en panne. Les reconstructions RAID consomment des E/S. Les hôtes nécessitent des mises à jour de firmware. Les ports de commutateur se comportent mal. Les hyperviseurs ont besoin de correctifs. Les sauvegardes manquent leurs fenêtres. Un pool de stockage peut être plein même lorsqu'une page de compte indique que le plan est actif. Un mot cloud public ne supprime pas les pièces détachées.

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 être activés 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 le courrier en masse - peuvent prendre jusqu'à huit heures pour être installés ou livrés en dehors des heures de bureau. 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 personnel, 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 devrait pas supposer que chaque changement de ressource, ajout de licence ou exception de bande passante est automatique.

Il devrait 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 un renumérotage IP est nécessaire 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 devient souvent visible seulement lorsqu'un site est attaqué, qu'une restauration de sauvegarde s'exécute, qu'une campagne e-commerce commence ou qu'un fichier média doit être distribué. Un pool partagé de 10 Mbit peut être suffisant pour des sites d'entreprise calmes, mais ce n'est pas un substitut à un chemin de récupération à haut débit testé.

Si un client s'attend à restaurer rapidement des centaines de gigaoctets ou à servir de grandes rafales de trafic, la règle de débit réseau appartient à 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 sélectivement. 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, 24 heures, avec une garantie de réponse de 60 minutes. Plus tard 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 bureau et dans les huit heures en dehors des heures de bureau. 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 identifiants ou dire qu'un fournisseur a été contacté. La réparation peut dépendre du personnel de l'installation, des ingénieurs en amont, du stock de matériel, d'une licence de fournisseur, du propre administrateur du client ou d'un registre de domaine. Pour un support d'hébergement de routine, une réponse de 60 minutes peut être suffisante.

Pour un paiement e-commerce 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 termes d'escalade, pas seulement de termes de première réponse.

L'histoire de support de CloudTeknoloji est plus solide qu'un hôte économique sans contact car elle publie des numéros de téléphone, des emails de support, un chemin de tickets, une adresse professionnelle, une adresse KEP et des conditions écrites. Le risque est que les 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 bureau, et le délai de réponse en dehors des heures est décrit de deux manières.

Un acheteur devrait demander quelle clause contrôle son produit spécifique, si Pro Cloud géré bénéficie d'une escalade différente de 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 sévérité nommé avec des objectifs de temps de réparation.

Le personnel intersecte également avec la migration. La page VDS vante 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. C'est précieux si c'est vrai dans le cas d'un client, mais cela devrait être cadré. Déplacer un site 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 devraient 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 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

La clause de maintenance est l'un des signes les plus clairs que le cloud de CloudTeknoloji est toujours 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 bureau sauf si nécessaire. Elle exclut également la responsabilité en cas de force majeure pour une exécution tardive, incomplète ou non exécution.

Quatre-vingt-seize heures par an n'est pas un objectif de panne; c'est un plafond de maintenance tel qu'écrit dans la politique. Néanmoins, c'est un nombre de planification client significatif. Une entreprise qui lit uniquement 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 significatif d'heures sur 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.

Ce n'est pas suffisant pour un client dont les prises de commandes, le centre d'appels, les flux de paiement ou les systèmes de clinique doivent fonctionner à travers chaque nuit de maintenance.

La question importante est de savoir comment la maintenance est isolée. Un hôte peut-il être vidé tandis que les charges de travail continuent ailleurs? Les clients VDS sont-ils migrés en direct entre hôtes? La maintenance du stockage nécessite-t-elle un temps d'arrêt? Les événements de maintenance 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 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 à toute maintenance ou seulement aux temps d'arrêt attendus? La politique fournit le modèle d'alerte public, mais le client a besoin de détails d'architecture.

Cela affecte également les clients agence et revendeur. Si un revendeur héberge des douzaines de sites clients sur daha.net, un événement de maintenance peut devenir des douzaines 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 e-commerce 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 produits d'hébergement et VDS vantent des sauvegardes hebdomadaires ou des fonctionnalités de sauvegarde périodique. Lapolitique de servicedonne la règle plus dure: les serveurs d'hébergement sont sauvegardés hebdomadairement et mensuellement, 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 de compte est la responsabilité du client. Elle indique également que lorsqu'un client a besoin d'une sauvegarde prise 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 en cas de suppression accidentelle ou de panne de site, mais la politique décline la garantie de récupération. Pour les services VDS et serveur, la politique indique que la sauvegarde n'est pas incluse sauf si elle est achetée.

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

La différence entre « la sauvegarde existe » et « la restauration fonctionne » est centrale pour cette entreprise. CloudTeknoloji vend de la capacité hébergée, mais le client peut toujours 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 prendre un instantané vers une région séparée. Une base de données peut diffuser des réplicas ou des vidages vers un deuxième fournisseur. Le DNS peut être hébergé avec un opérateur séparé.

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

Le client devrait 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 hébergé ICS principal? 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 taux de réseau par défaut?

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

La facturation, l'annulation et la suppression de 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 depuis 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 de service supprime le compte ainsi que les sauvegardes. Elle restreint également l'éligibilité au remboursement pour certains modules complémentaires, licences, domaines, SSL et autres services, et indique que l'éligibilité 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 routinières. Pour une charge de travail professionnelle, elles sont une dépendance. Un échec 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 qui quitte daha.net doit exporter les fichiers, bases de données, DNS, boîtes aux lettres, certificats, clés, licences et images serveur avant l'annulation ou le non-renouvellement.

Un client qui compte sur les sauvegardes pour le retour 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 sur le client: la discipline de renouvellement, les sauvegardes, la préparation à la migration, le stockage des identifiants, la gestion du verrouillage de domaine, les TTL DNS et les copies de restauration hors fournisseur. Le client devrait 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. Gardez l'accès au registraire indépendant si possible. Gardez les exports DNS. Gardez les sauvegardes hors plateforme. Sachez quelles adresses IP sont liées aux listes blanches. Gardez une liste à jour des certificats SSL et des dates de renouvellement. Testez la restauration d'un site vers un autre fournisseur. Gardez la continuité de la messagerie en dehors d'un seul compte d'hébergement web si le courrier 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 pour les utilisateurs domestiques, simplifier le support linguistique et fiscal, garder les contrats sous une juridiction familière et soutenir les préférences de localisation des données. Les pages officielles de CloudTeknoloji s'appuient sur ce profil local: bureaux à Istanbul, installation à Istanbul, support en 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 l'email professionnel. Lavue de géolocalisation pour 46.28.232.0/24aligne également le préfixe public visible avec la Turquie.

La localité, cependant, peut concentrer le risque si elle n'est pas associée à une récupération indépendante. Un client qui doit garder des données en Turquie peut encore avoir besoin d'un deuxième site turc, d'un deuxième fournisseur, d'un deuxième compte de sauvegarde ou au moins d'un DNS séparé et d'un arrangement de restauration. Un client qui peut utiliser une copie de récupération à l'étranger peut obtenir une séparation géographique plus facile mais doit considérer les limites légales, 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 multisite 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 séparés. Le premier demande où les données vivent et quelle loi s'applique. Le second demande si un client peut continuer après une panne 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.

C'est particulièrement vrai pour les clients avec des charges de travail réglementées, réputationnelles ou sensibles aux revenus. Une école, une clinique, une agence, une boutique e-commerce ou un bureau professionnel peut choisir daha.net parce que le bureau de support parle la même langue, l'entité légale est joignable et le serveur se trouve à Istanbul. C'est rationnel. Mais si le même service est aussi le seul hôte DNS, le seul hôte de messagerie, le seul emplacement de sauvegarde et la seule route vers le support, alors un avantage local devient un point 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é quand ce système tombe en panne

Le premier groupe affecté est les 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 elle. Une panne d'hébergement partagé peut mettre hors ligne les sites web, les boîtes aux lettres, les bases de données, les panneaux de contrôle et les chemins de renouvellement SSL en même temps. Le client peut ne pas avoir d'accès root ou de contrôle direct de sauvegarde. Les clauses de non-responsabilité de sauvegarde de la politique de service importent donc le plus pour les clients les moins techniques.

Le deuxième groupe est les clients VDS et Pro Cloud. Ils ont plus de contrôle, mais ils héritent également de plus de responsabilité. 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 base de données et la planification de restauration peuvent incomber au client. Un client Pro Cloud géré peut obtenir plus d'aide, mais devrait encore confirmer exactement quelles couches sont gérées, lesquelles sont un support au mieux et lesquelles restent la propriété du client.

Le troisième groupe est les agences et les revendeurs. Ils transforment un fournisseur en 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 les clients domaine et email. L'expiration de domaine, les limitations de transfert, les erreurs DNS et les échecs de routage de courrier 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 domaine, DNS, hébergement et courrier sous un seul compte obtiennent de la commodité. Ils mettent également le renouvellement, les identifiants et l'escalade de support en un seul endroit.

Séparer l'accès de propriété du contrôle d'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 suffisant 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 frontière d'installation et de propriété: quels services fonctionnent dans l'ICS centres de données, lesquels sont du matériel appartenant à CloudTeknoloji, lesquels sont de la capacité louée, et lesquels reposent sur des fournisseurs tiers. Deuxièmement, il pourrait publier des 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, il pourrait énoncer la conception de transit pour AS202048: transporteurs 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 historiques. Quatrièmement, il pourrait fournir des engagements de maintenance et d'urgence par niveau de produit, en distinguant la réponse de la réparation.

Cinquièmement, il pourrait documenter les droits de sortie: exports VM, sauvegardes de panneau de configuration, export de zone DNS, support de transfert de domaine, limites de portabilité IP et délai de suppression de compte.

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

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

Conclusion

CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. ne mérite ni rejet ni confiance aveugle. L'entreprise derrière daha.net est identifiable, a opéré sous une identité commerciale turque visible, publie des coordonnées et des informations légales, 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 est que l'empreinte publique est étroite. Un IPv4 /24 visible, aucune origine IPv6 visible, aucun profil PeeringDB public et un 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 de la capacité hébergée qui peut être précieuse pour les entreprises turques, mais cette capacité dépend encore de baies, de transit, d'électricité, de remplacement matériel, de réponse du personnel et de la propre discipline de sauvegarde et de migration du client.

La posture d'acheteur appropriée est pratique: utilisez le fournisseur local lorsque son hébergement à Istanbul, son support en turc et ses services groupés correspondent à la charge de travail, mais faites 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, combien de temps une restauration complète peut prendre, ce qui se passe après le non-renouvellement et comment le client quitte proprement.

Jusqu'à ce que ces réponses soient écrites et testées, les preuves publiques soutiennent un profil d'infrastructure à confiance moyenne: opération réelle, profondeur de réseau public limitée et questions de récupération qui importent plus que le mot « cloud ».