O2Cloud O2 Cloud, LLC vend de la capacité hébergée qui dépend encore des baies, du transit et des fenêtres de réparation

Résumé

• O2 Cloud LLC dispose de preuves opérationnelles actuelles plus solides que ne le suggérait l'hypothèse d'attribution. RBC Companies répertorie la société russe comme active au 12 juillet 2026, avec le numéro d'enregistrement 1187746216437, le numéro fiscal 9710050732, une date d'enregistrement de 2018, 22 employés en moyenne, un chiffre d'affaires 2025 de 1,418 milliard de roubles et un bénéfice 2025 de 372,9 millions de roubles. RIPE enregistre également O2 Cloud LLC en tant que LIR russe, et l'AS208349 est actuellement annoncé.
• La surface de service public est large: OXYGEN commercialise du cloud public VMware, du cloud privé, du matériel serveur loué, de la sauvegarde, de la reprise après sinistre, du stockage de type S3, des bases de données managées, des produits de sécurité et un support smart remote-hands. Ces pages décrivent des composants utiles, mais ne prouvent pas en elles-mêmes la capacité excédentaire, le basculement testé, le temps de reprise spécifique au client ou la frontière juridique exacte entre O2Cloud LLC, la marque OXYGEN et les installations du centre de données Business System Telehouse.
• Les preuves réseau sont solides au niveau du routage. RIPE et Hurricane Electric montrent AS208349, AS-O2CLOUD, des préfixes IPv4 et IPv6 annoncés, une présence MSK-IX et des amonts nommés incluant RETN, Rascom, Rostelecom, MegaFon et StormWall. C'est de véritables preuves de connectivité, pas simplement du marketing, mais cela ne constitue pas pour autant une continuité applicative prouvée en cas de défaillance d'une baie, d'une installation, d'un compte de support, d'un canal de paiement ou d'un chemin fournisseur lié aux sanctions.
• La dégradation opérationnelle de l'article n'est donc pas « entreprise faible »; elle correspond à une « frontière de reprise non vérifiée ». Les acheteurs doivent exiger des réponses écrites sur la propriété des installations, l'emplacement MSK East/MSK West, les chemins d'alimentation et de baies, l'indépendance du transit, l'emplacement de la sauvegarde, les tests de restauration, le stock de matériel, la portabilité des données, l'exposition aux sanctions et la personne pouvant agir lorsque le client ne peut pas attendre la file d'attente normale des tickets.

Le registre public prouve l'existence d'une entreprise réelle, pas une histoire de résilience complète

La première question avec un petit fournisseur cloud ou spécifique à une région est de savoir si l'empreinte opérationnelle existe réellement. Pour O2Cloud O2 Cloud, LLC, la réponse est plus solide que ce qu'une mise en garde sur l'absence de présence web ne laisserait supposer. Le profil d'entreprise russe surRBC Companiesrépertorie la société à responsabilité limitée O2 Cloud comme active, enregistrée le 28 février 2018, avec le numéro d'enregistrement 1187746216437, le numéro fiscal 9710050732, une adresse légale à Moscou, 22 employés en moyenne et un code d'activité principale pour les travaux informatiques et de technologie de l'information. RBC fait également état d'un chiffre d'affaires 2025 de 1,418 milliard de roubles et d'un bénéfice 2025 de 372,9 millions de roubles, d'après les états comptables, tout en notant que son profil d'entreprise est une information de référence issue de données ouvertes.

RIPE fournit une deuxième couche d'identité. L'objet organisation RIPE pour ORG-OCL29-RIPEnomme O2 Cloud LLC, pays RU, numéro d'enregistrement 1187746216437 et statut LIR. Son adresse est rue Tverskaya à Moscou, tandis que lerôle NOC RIPEindique un NOC O2 Cloud, une adresse Volgogradsky prospekt, un numéro de téléphone et une boîte aux lettres[email protected]. Il ne s'agit pas de témoignages de clients, mais de traces opérationnelles dans le système de registre que les opérateurs réseau utilisent pour coordonner le routage, les abus et la responsabilité administrative.

Le registre réglementaire des télécoms va dans le même sens. Le registre des licences de communications de Roskomnadzor répertorie O2 Cloud sous une licence de services de communications télématiques. RBC et Roskomnadzor utilisent la même identité juridique et le même numéro fiscal russes, tandis que le site web OXYGEN présente la marque d'infrastructure orientée client. Dans l'ensemble, l'entreprise est visible en tant qu'entité corporative, fournisseur de communications agréé et détenteur de numéros Internet.

Cela ne répond pas à la question la plus importante pour le client. Le client n'a pas seulement besoin d'un numéro d'entreprise. Il a besoin de savoir où sa charge de travail s'exécute, qui possède ou contrôle les baies, qui peut entrer dans la salle, quels amonts transportent le trafic, quelle copie de sauvegarde peut être restaurée sans le cloud primaire, et que se passe-t-il si un fournisseur, une autorité de sanctions ou un litige de facturation bloque l'accès normal au support. Une entreprise peut être active, rentable et visible au niveau du routage tout en donnant aux clients des preuves faibles de reprise.

Il existe également une couche de risque juridique qui ne peut être dissociée de l'approvisionnement. LaRecherche dans la liste des sanctions de l'OFAC pour O2 KLAUDrépertorie une entité SDN avec le numéro d'enregistrement 1187746216437 et le numéro fiscal 9710050732, correspondant à l'identité RBC et RIPE. Lecommuniqué de presse du Trésor du 23 février 2024décrit O2 Klaud comme exploitant un centre de données et fournissant des produits de sécurité d'infrastructure et de réseau, et précise qu'il a été désigné dans le cadre du programme Russie. Ceci n'est pas une preuve d'une panne de service. C'est la preuve que certains clients, fournisseurs, processeurs de paiement, assureurs, fournisseurs de matériel et concédants de licence logicielle doivent traiter la relation comme un problème de conformité aux sanctions avant de la traiter comme un contrat cloud normal.

Le résultat est un jugement partagé. O2Cloud ne doit pas être rejeté comme un opérateur sans preuve. Les éléments visibles indiquent une véritable entreprise russe de cloud et de réseau. Mais l'article ne doit pas convertir l'existence corporative et les pages marketing en une garantie de récupération pour le client. La norme correcte est plus étroite: le client peut-il prouver le chemin de défaillance exact pour ses propres machines virtuelles, données, adresses, licences et droits de support?

Ce qu'OXYGEN dit vendre, c'est de l'infrastructure, même lorsqu'elle est vendue comme un cloud

Le site OXYGEN présente un large catalogue d'infrastructure d'entreprise. La page d'accueil indique que l'infrastructure cloud fournit des services allant de la location de matériel et de machines virtuelles à la gestion de bases de données, la sauvegarde et les produits de sécurité. Lapage cloud public VMwaredécrit le cloud public sur VMware, les centres de données virtuels, les machines virtuelles, le CPU, la mémoire et le stockage configurables, la mise en réseau définie par logiciel, les modules complémentaires de sauvegarde et le support. Lapage cloud privédécrit le cloud privé pour les clients nécessitant un environnement dédié et un contrôle accru de la sécurité et des performances. Lapage location de serveurspropose du matériel dédié plutôt qu'une simple capacité virtuelle. Lapage de sauvegardevend de la sauvegarde cloud, et lapage de reprise après sinistrevend de la capacité de reprise pour les sites défaillants.

Ces pages sont importantes car elles situent la catégorie de service. O2Cloud ne se contente pas de vendre un tableau de bord logiciel ou un site de contenu. Il vend de la capacité de calcul, du stockage, de la mise en réseau, de la sauvegarde, de la reprise et du support hébergés. Ces services sont des abstractions reposant sur des systèmes physiques: serveurs, baies de stockage, commutateurs, routeurs, pare-feux, interconnexions, distribution électrique, refroidissement, personnel opérationnel et contrats avec les opérateurs amont et les exploitants d'installations.

La façon la plus utile de lire le catalogue de services est de séparer le produit visible de la dépendance invisible. Une machine virtuelle de cloud public ressemble à un paramètre de compte. Dans le parc du fournisseur, c'est une décision d'emplacement sur un cluster avec des cœurs CPU, de la RAM, des E/S de stockage, une bande passante de sauvegarde et une capacité réseau finies. Un serveur loué semble dédié, mais cette dédicace augmente la dépendance vis-à-vis du stock exact de matériel et du processus de maintenance.

Un produit de sauvegarde ressemble à une assurance, mais seulement si la sauvegarde est cohérente, conservée, protégée des mêmes identifiants que la production et restaurable dans un emplacement indépendant. Un produit de reprise après sinistre ressemble à de la continuité, mais seulement si le site de reprise dispose d'une capacité réservée, d'une capacité de routage, de licences et d'un guide opérationnel testé.

Les pages OXYGEN fournissent des revendications de service utiles. Elles ne divulguent pas toute l'architecture nécessaire pour évaluer le risque. Elles ne publient pas de politique de sursouscription client par client, de carte d'emplacement, d'historique des tests de basculement, de conception de réplication de stockage, de limites exactes des clusters d'hyperviseurs, d'inventaire de pièces de rechange ou des circonstances dans lesquelles un client peut récupérer des données sans le portail normal du fournisseur.

C'est normal dans la vente commerciale de cloud, mais cela signifie que l'acheteur doit demander des preuves plutôt que de se fier au mot « cloud ».

La frontière de propriété est particulièrement importante ici. RIPE identifie O2 Cloud LLC comme le détenteur du réseau derrière AS208349. Uptime Institute identifieBusiness System Telehousecomme le client pour Oxygen Data Processing Center, Data Halls 2 et 3, à Moscou. Les marques OXYGEN et O2DC sont présentées ensemble dans le matériel public, et la politique de routage RIPE d'O2 Cloud inclut Business System Telehouse AS47440 dans un contexte de routage client ou adjacent. Cela indique une association opérationnelle dans le registre public, mais cela ne constitue pas un contrat client précisant quelle personne morale est responsable de l'alimentation, de l'espace, des interventions à distance, du cloud hébergé, de la sécurité, des sauvegardes et de la restitution des données. Un acheteur ne doit pas laisser la continuité de la marque se substituer à la clarté contractuelle.

L'histoire des installations de Moscou exige une preuve au niveau du site

Les pages cloud d'OXYGEN pointent vers des emplacements d'installations à Moscou et utilisent le langage des centres de données. Les pages publiques font référence aux emplacements MSK East et MSK West, tandis que le matériel O2DC décrit un réseau de centres de données à Moscou et promeut des caractéristiques Tier III. La liste des prix Uptime Institute montre Business System Telehouse à Moscou avec Oxygen Data Processing Center, Data Halls 2 et 3, portant la certification Tier III des documents de conception. Il s'agit d'une véritable validation de conception par un tiers, mais la portée est importante.

C'est une certification des documents de conception pour des salles de données nommées, pas un certificat universel pour chaque service, chaque baie, chaque cluster cloud ou chaque processus de continuité vendu sous la marque OXYGEN.

Cette distinction n'est pas tatillonne. La fiabilité d'un centre de données repose sur des domaines de défaillance indépendants. Une salle peut avoir une topologie d'alimentation bien conçue tandis qu'un déploiement client ne dispose que d'un seul système de stockage, d'un seul cluster de pare-feu, d'un seul plan de gestion, d'un seul compte de sauvegarde ou d'une seule chaîne contractuelle.

Deux emplacements à Moscou peuvent réduire certains risques tout en en laissant d'autres en commun: la même région métropolitaine, la même administration du fournisseur, les mêmes contraintes de sanctions, la même pile logicielle, la même équipe de support, le même système de facturation, et parfois les mêmes dépendances interurbaines ou d'échange.

La liste physique à régler pour l'acheteur commence par l'emplacement. Quelle salle est primaire? Y a-t-il une deuxième salle? Les deux sont-elles utilisées ou l'une n'est-elle disponible qu'après une commande de reprise? Le client dispose-t-il d'une anti-affinité entre les clusters, les baies, les alimentations électriques et les baies de stockage, ou seulement entre les noms de machines virtuelles? La copie de sauvegarde se trouve-t-elle dans l'autre site de Moscou, dans la même installation, dans un stockage objet ou sur des supports nécessitant l'intervention du fournisseur pour être restaurée?

Le client peut-il choisir ou vérifier la localité des données et des logs?

Les revendications d'alimentation et de refroidissement nécessitent également une interprétation au niveau du client. Une conception Tier III vise une infrastructure pouvant être maintenue de manière concurrente, mais un environnement client peut toujours tomber en panne si les deux cordons d'alimentation aboutissent sur la même unité de distribution de baie, si les contrôleurs de stockage partagent une dépendance, si un incident de refroidissement force un arrêt contrôlé des nœuds à haute densité, ou si une maintenance planifiée vide le seul cluster avec une capacité de réserve.

L'expression « Tier III » précise la question de l'installation; elle ne répond pas à la question de la plateforme cloud.

La capacité installée est un autre point où les pages de service et la résilience divergent. OXYGEN peut commercialiser des options de vCPU, de RAM, de stockage et de réseau tout en se réservant le droit de placer les charges de travail dans des clusters finis. Un client qui achète suffisamment de capacité pour un fonctionnement normal n'a pas nécessairement acheté suffisamment de capacité pour fonctionner pendant une panne d'hôte, de baie de stockage, de baie, de salle ou de compte fournisseur.

La capacité pouvant être récupérée nécessite une capacité de réserve sur le lieu de reprise, des licences permettant à la charge de travail d'y démarrer et un chemin testé pour le trafic utilisateur.

La lecture la plus sûre est donc positive mais conditionnelle. Le dossier des installations de Moscou est plus solide qu'une revendication générique « hébergé quelque part ». Il comprend des emplacements nommés, une marque de centre de données publique et des preuves de documents de conception Uptime Institute pour les salles Oxygen de Business System Telehouse. La question non résolue est de savoir comment une charge de travail client O2 Cloud correspond à ces salles, combien de domaines de défaillance indépendants sont réellement achetés et qui supporte le coût et l'autorité pour les activer.

La visibilité réseau est réelle, mais la diversité des routes n'est pas une reprise applicative

Les preuves réseau d'O2 Cloud sont l'une des parties les plus claires du dossier. L'objet aut-num RIPE pour AS208349nomme AS208349 comme O2CLOUDRU et le lie à ORG-OCL29-RIPE. Le même objet répertorie la politique de liaison montante IPv4 et IPv6 pour RETN, Rascom, MSK-IX, Rostelecom, MegaFon et StormWall. Il enregistre également des relations client ou aval dans AS-O2CLOUD, incluant AS211933, AS47429, AS41667, AS47440, AS206904, AS206301 et AS47763.

Lavue des préfixes annoncésde RIPEstat pour le 12 juillet 2026 montrait des annonces actives d'AS208349 incluant 45.134.124.0/22, 5.35.120.0/23, plusieurs routes /24, 185.31.133.0/24 et le bloc IPv6 2a0e:7e40::/29. Savue de l'état du routagemontrait AS208349 comme annoncé, avec une visibilité IPv4 complète sur 325 pairs RIS sur 325 et une visibilité IPv6 sur 321 pairs RIS sur 322 au moment de la requête. Lapage BGP Toolkitde Hurricane Electric montrait de même un pays d'origine russe, des préfixes IPv4 et IPv6 annoncés, un point d'échange Internet, aucun invalide RPKI annoncé, des pairs BGP observés et des adresses MSK-IX Moscou.

C'est des preuves opérationnelles significatives. Cela montre qu'O2 Cloud n'est pas simplement un nom de revendeur sans ressources de numéros visibles. Il annonce de l'espace, maintient des objets de route et apparaît dans les mesures BGP mondiales. Cela montre également une conception réseau avec plusieurs chemins amont et d'échange nommés. Pour les clients, cela réduit une catégorie de risque: une défaillance d'un seul opérateur ne doit pas automatiquement être supposée isoler l'ensemble du parc.

Mais la diversité de routage a des limites. Deux noms d'amont ne prouvent pas deux fibres physiquement diverses depuis la baie exacte. Une session de peering à MSK-IX ne prouve pas que le trafic client peut contourner une panne dans le périphérique de bordure du fournisseur, le pare-feu, le réflecteur de route ou le chemin de nettoyage DDoS. Une route par défaut StormWall peut améliorer les options d'atténuation tout en ajoutant une dépendance vis-à-vis de la politique de filtrage, de la redirection et de la coordination des incidents.

Un préfixe IPv6 visible prouve la prise en charge de la famille d'adresses; il ne prouve pas que les applications, pare-feux, la surveillance, le DNS et les processus de support des clients sont également prêts pour un basculement IPv6.

Le client doit également distinguer l'accessibilité de production de l'accessibilité du plan de contrôle. Une machine virtuelle peut rester allumée tandis que le portail, le compte de facturation, le DNS, le compte de certificat ou le système de ticket de support est indisponible. Inversement, un portail peut être accessible tandis que le réseau de stockage, la politique de pare-feu ou l'annonce de routage du client est incorrect. Le dossier BGP public ne peut pas régler ces dépendances internes.

Le chemin de défaillance concret à tester n'est pas « est-ce que AS208349 a des routes? » Il en a. Le test est de savoir si une application client reste accessible lorsqu'un amont, un échange, un périphérique de bordure, un chemin DDoS, un fournisseur DNS, un compte portail et une dépendance d'installation à Moscou sont indisponibles. Si la réponse dépend d'une action manuelle du fournisseur, le client a besoin du contact d'escalade, du temps de réponse contractuel et de la preuve que le fournisseur a effectué l'opération récemment.

Les fenêtres de réparation sont définies par les personnes, les pièces et l'autorité

La capacité cloud semble élastique jusqu'à ce qu'un disque, une carte de ligne, une alimentation, un ventilateur, une carte mère de serveur ou un contrôleur de stockage défaillant ramène l'abstraction à un événement de réparation. Lapage smart remote-handsd'OXYGEN est donc une partie importante des preuves. Elle décrit un support d'ingénierie pour le matériel client et les tâches de centre de données plutôt qu'une simple capacité virtuelle en libre-service. C'est le vocabulaire opérationnel correct pour l'infrastructure: quelqu'un doit recevoir le matériel, étiqueter les actifs, connecter les ports, remplacer les composants, vérifier le câblage et coordonner l'accès physique.

Les interventions à distance sont précieuses, mais elles ne constituent pas une garantie de réparation complète. Un technicien d'installation peut être en mesure de remplacer un câble sans être autorisé à se connecter à un hyperviseur. Un ingénieur cloud peut être en mesure de redémarrer une machine virtuelle sans être autorisé à toucher à un appareil dédié du client. Un disque de rechange peut être disponible alors que le contrôleur RAID exact, le HBA, la carte réseau, le module optique ou la carte mère ne l'est pas.

Un ingénieur d'astreinte peut acquitter un ticket rapidement tandis que la pièce du fournisseur, la licence logicielle ou l'approbation de sécurité arrivent plus tard.

C'est là que le contrat de capacité hébergée devient économique. Le matériel de rechange coûte de l'argent. La capacité de calcul réservée coûte de l'argent. Les chemins double opérateur coûtent de l'argent. Un site de reprise chaud coûte de l'argent. Garder des ingénieurs seniors d'astreinte coûte de l'argent. Un fournisseur cloud qui propose des prix attractifs doit décider combien de capacité inutilisée et de disponibilité humaine il conserve pour les défaillances. Les clients ne peuvent pas voir cette réserve à partir d'une table de prix VM.

Le statut de sanctions d'O2 Cloud fait de la question de réparation plus qu'un simple exercice logistique pour certaines contreparties. La désignation OFAC ne dit pas qu'un serveur tombera en panne. Cela signifie que certains fournisseurs liés aux États-Unis, canaux de paiement, éditeurs de logiciels, prestataires de services à distance et assureurs peuvent être restreints ou peu disposés à soutenir des transactions directes. Pour un acheteur en dehors de la Russie, cela peut affecter l'approvisionnement, l'applicabilité du contrat, le paiement, le remplacement de matériel, les mises à jour logicielles et l'assistance d'urgence.

Pour un acheteur en Russie, cela peut encore affecter les pièces importées, la maintenance logicielle tierce et le support transfrontalier.

Les bonnes preuves sont pratiques. Les clients doivent demander la matrice de sévérité du support, le modèle de dotation sur site, la portée des interventions à distance, l'approche des pièces de rechange, les fenêtres de maintenance, des exemples d'incidents récents, l'état de la maintenance des fournisseurs et la personne ou le rôle autorisé à agir lorsqu'une file d'attente de tickets normale est trop lente. Pour le matériel dédié, ils doivent demander qui possède le matériel, où les numéros de série sont suivis, si des pièces de rechange compatibles sont en stock et comment les supports contenant des données sont traités.

Pour le cloud virtuel, ils doivent demander si la panne d'hôte est automatique, si la panne de stockage est protégée et si une capacité de réserve suffisante existe pendant la maintenance ou un incident au niveau de la salle.

Le point clé n'est pas qu'O2 Cloud manque de capacité de réparation. Les preuves publiques ne le démontrent pas. Le point clé est que la réparation n'est pas incluse simplement parce qu'un service est appelé cloud. La réparation est une chaîne de pièces, d'accès, de contrats et de personnes. Un client qui ne peut pas voir cette chaîne doit supposer une fenêtre de reprise plus longue que ne le suggère la page marketing.

Les parties affectées sont plus larges que le titulaire du compte

Une panne de capacité hébergée s'arrête rarement à la personne qui paie la facture. Si O2 Cloud héberge une vitrine de détail, le groupe affecté comprend les acheteurs, les processeurs de paiement, les partenaires de livraison, les systèmes d'inventaire et le personnel qui doit rapprocher les transactions après le retour du service. S'il héberge une base de données ou une application privée pour une entreprise russe, le groupe affecté peut inclure les employés, les sous-traitants, les clients, les auditeurs et les régulateurs.

S'il transporte les réseaux clients derrière AS208349 ou les membres en aval d'AS-O2CLOUD, une erreur de route ou de filtrage peut affecter des organisations dont les utilisateurs peuvent même ne pas connaître le nom d'O2 Cloud.

C'est pourquoi la frontière de propriété importe. L'utilisateur professionnel peut avoir souscrit un contrat pour « cloud » ou « sauvegarde » tandis que la tâche de reprise réelle couvre un exploitant d'installation, une équipe cloud, une équipe d'exploitation réseau, un chemin d'atténuation DDoS, un fournisseur de stockage, un concédant de licence logicielle, un compte de facturation et peut-être un intégrateur client. Pendant un mois calme, ces couches peuvent ressembler à un seul service. Pendant une panne, elles deviennent des files d'attente séparées avec des autorités distinctes.

Si le contrat du client ne nomme que le vendeur de première ligne, le client peut ne pas avoir qualité pour appeler l'installation, commander des interventions à distance, payer un amont, renouveler une licence ou récupérer des disques.

Les preuves de routage en aval rendent cela plus concret. La politique AS208349 n'annonce pas seulement les propres préfixes d'O2 Cloud; elle décrit également des routes pour d'autres numéros AS via AS-O2CLOUD. L'article ne traite pas ces noms comme une liste de clients vérifiée, mais la structure de routage montre toujours que le réseau peut se trouver en amont d'autres organisations. Lorsqu'un fournisseur d'infrastructure devient une dépendance de transit ou d'hébergement pour une autre entreprise, sa propre fenêtre de réparation devient une partie de la fiabilité publique de cette entreprise.

Un redémarrage de routeur ou un changement de filtrage peut donc créer un problème de service client ailleurs.

La facturation est un autre chemin de partie affectée. Une plateforme cloud peut être techniquement saine tandis qu'un compte suspendu, un blocage de paiement, un gel de contrôle des sanctions ou une erreur administrative en retire l'accès. Il ne s'agit pas d'une accusation spéciale contre O2 Cloud. C'est un mode de défaillance cloud général qui importe davantage lorsque le fournisseur est sous sanctions et travaille avec des clients dont les banques, fournisseurs ou assureurs peuvent interpréter les obligations différemment.

Le client doit savoir qui peut maintenir l'accès si un canal de paiement ordinaire échoue, et quelle documentation est nécessaire pour préserver le service pendant la résolution d'un examen de conformité.

La même logique s'applique à la restitution des données. Si la charge de travail hébergée contient des données personnelles, des dossiers financiers, des informations médicales, des registres logistiques ou des preuves nécessaires pour un litige, une panne du fournisseur peut devenir un problème de droit d'accès. Les utilisateurs peuvent ne pas se soucier de savoir si la panne était due à une PDU de baie, une fuite de route, un problème de snapshot de stockage ou un paiement bloqué. Ils s'inquiètent de savoir si le propriétaire du service peut produire l'enregistrement.

Ce propriétaire de service a besoin d'un chemin vers les données qui ne repose pas sur le même portail défaillant.

Pour un acheteur, cela change la discussion sur le niveau de service. Un pourcentage de disponibilité est utile mais incomplet. L'acheteur a besoin d'une liste des fonctions métier qui doivent continuer: la prise de commandes, la capture des paiements, l'authentification interne, le reporting, la messagerie, la récupération des sauvegardes, la notification d'incident, les preuves réglementaires et le support client. Chaque fonction doit être mise en correspondance avec le composant O2 Cloud dont elle dépend et avec le chemin alternatif qui fonctionne si ce composant est indisponible.

Cette carte est le seul moyen de voir si le fournisseur est une dépendance ou plusieurs dépendances partageant une seule marque.

Les clients les plus exposés sont ceux qui utilisent la plateforme à la fois pour la production et la reprise. Si les machines virtuelles primaires, les sauvegardes, la surveillance, le DNS, le filtrage de sécurité et le support d'urgence sont tous hébergés au sein d'une seule relation fournisseur, alors le client a acheté la commodité mais n'a peut-être pas acheté l'indépendance. Le catalogue OXYGEN comprend des produits qui peuvent être combinés dans une conception résiliente, mais la combinaison importe.

Une sauvegarde dans le stockage objet OXYGEN, un cluster de reprise dans une autre salle OXYGEN et un pare-feu géré par la même équipe OXYGEN peuvent encore constituer une conception solide pour certaines charges de travail russes. Cela ne constitue pas un chemin de sortie indépendant du fournisseur.

L'avertissement de l'article est donc pratique. Chaque organisation utilisant O2 Cloud doit décider quelles parties sont lésées en premier, quelles parties ont des obligations de notification légale, quels systèmes doivent reprendre en premier et quelles preuves sont nécessaires pour prouver la restauration. Ensuite, elle doit demander à O2 Cloud les contrôles qui correspondent à cet impact. Un petit environnement de test peut tolérer une reprise manuelle et une réponse au mieux. Un système de production réglementé ne le devrait pas.

La sauvegarde et la reprise après sinistre ne comptent qu'après une restauration en dehors du chemin défaillant

Lapage de sauvegarde en tant que serviced'OXYGEN commercialise la sauvegarde cloud, et sapage de reprise après sinistrecommercialise la reprise d'urgence. Ce sont les bons services à rechercher dans un parc de capacité hébergée. Ils créent également un piège utile pour la diligence raisonnable: l'existence d'un produit de sauvegarde ne prouve pas qu'un client spécifique a une copie restaurable, indépendante et contractuellement portable.

La première question est l'indépendance de la copie. Un snapshot sur la même baie de stockage protège mieux contre une suppression de fichier erronée que contre une panne du système de stockage. Une sauvegarde dans la même salle protège mieux contre la corruption applicative que contre la perte d'alimentation, de refroidissement, d'accès incendie, de compte fournisseur ou de panne de fournisseur liée aux sanctions.

Une réplique dans un autre site OXYGEN peut réduire le risque lié aux installations, mais peut encore dépendre du même plan de contrôle du fournisseur, des mêmes identifiants administrateur, de la même relation de facturation et de la même juridiction légale.

La deuxième question est la cohérence. Un snapshot de machine virtuelle n'est pas automatiquement une restauration propre de système métier. Les bases de données, les files de messages, les partages de fichiers, les systèmes d'identité, les certificats, les tâches planifiées, les clés de chiffrement, les secrets d'application et les intégrations doivent être alignés. Pour un client utilisant une infrastructure hébergée pour l'ERP, la logistique, la vente au détail, les interfaces bancaires ou les données personnelles réglementées, une VM démarrée n'est pas synonyme d'opérations récupérées.

La troisième question est le temps. Leguide de planification d'urgencedu NIST traite l'analyse d'impact métier, les stratégies de reprise, les tests et la maintenance du plan comme des contrôles centraux. Leguide de sécurité du stockagedu NIST distingue les sauvegardes, la réplication, les snapshots et l'assurance de restauration. Les directives du cloud public disent la même chose en langage opérationnel: lesoptions de reprise après sinistred'AWS vont de la sauvegarde et restauration à la veille chaude en passant par les conceptions actif-actif, et leguide de planification de reprise après sinistrede Google Cloud demande aux équipes de confirmer la bande passante, les installations, le support, l'alimentation, l'infrastructure réseau et la reprise testée plutôt que la simple existence d'une copie.

Pour les clients O2 Cloud, la preuve pratique est un rapport de restauration. Il doit nommer le système de production, la source de sauvegarde, l'emplacement de reprise, le point de perte de données, le temps de restauration écoulé, les personnes impliquées, les modifications réseau requises, les applications testées et le propriétaire métier qui a accepté le résultat. Si la sauvegarde est un service managé, le rapport doit également montrer si le client peut récupérer une copie de manière indépendante, y compris les clés de chiffrement et la documentation, si la relation fournisseur est interrompue.

La reprise après sinistre n'est pas un accessoire à acheter après la panne. C'est une réservation de capacité et une procédure. Si un acheteur veut qu'une charge de travail survive à la perte de MSK East en démarrant dans MSK West, alors MSK West doit disposer de suffisamment de calcul, de stockage, de licences, de routage, de politique de pare-feu et d'autorité de support avant l'incident. Si l'acheteur veut quitter complètement OXYGEN, alors la sauvegarde doit être exportable vers un format indépendant du fournisseur et testée sur une infrastructure que le client contrôle.

La localisation des données n'est un avantage que lorsque la frontière est explicite

La catégorie d'attribution inclut la souveraineté et la localisation des données, et O2 Cloud est un cas utile car sa proposition de valeur est probablement la plus forte pour les clients russes ou proches de la Russie qui souhaitent un hébergement national, un support russe, une connectivité locale et un alignement avec la loi 152-FZ sur les données personnelles. OXYGEN commercialise des services liés à la sécurité de l'information et aux besoins en données personnelles russes. Le registre Roskomnadzor et le profil RBC situent également l'entreprise et son identité juridique en Russie.

Pour un client russe, la localisation peut être un véritable avantage opérationnel. Les chemins de trafic peuvent être plus courts. Le placement des données personnelles russes peut être plus facile à documenter. Le support peut être local. Le paiement et la contractualisation peuvent s'aligner sur l'approvisionnement national. Certaines charges de travail peuvent être plus confortables chez un fournisseur russe que dans une région hyperscale étrangère, en particulier là où l'exportation de données, l'accès du régulateur, la langue et le support logiciel local importent.

Mais la localisation n'est pas un contrôle de résilience complet. Si toutes les copies primaires et de reprise se trouvent dans une seule zone métropolitaine, un problème régional d'installation ou de connectivité peut encore avoir un impact. Si le même fournisseur contrôle le portail, les sauvegardes, le DNS, les certificats et l'environnement de reprise, le client a toujours un risque de concentration sur le fournisseur. Si les sanctions compliquent les flux de logiciels, de matériel ou de paiement étrangers, l'hébergement local peut réduire certains problèmes juridiques tout en en créant d'autres pour les clients internationaux.

Lesconseils de Microsoft sur la fiabilité et la souverainetéformulent bien le compromis: la redondance entre régions peut améliorer la continuité tout en modifiant les questions de juridiction, de placement des clés et d'accès de l'opérateur. La même logique s'applique en dehors d'Azure. Un deuxième emplacement n'a de valeur que s'il est acceptable selon les règles de localisation des données du client, et un déploiement uniquement national n'est acceptable que s'il présente encore une séparation suffisante pour répondre à la tolérance de panne et de perte de données du client.

Les clients O2 Cloud doivent donc documenter quatre emplacements, pas un seul: où résident les données de production; où résident les réplicas; où résident les sauvegardes, les logs et les données de surveillance; et d'où l'accès au support peut provenir. Ils doivent également enregistrer qui peut accéder aux données dans le cadre d'opérations normales, de support d'urgence et de demandes légales. C'est à ce niveau que « RU » devient plus qu'une étiquette de région.

La couche des sanctions modifie la population d'acheteurs. Un client russe peut principalement évaluer la réglementation locale, la disponibilité, le prix et le support. Une multinationale, une personne américaine, une banque ayant une exposition aux États-Unis, un fournisseur utilisant une technologie américaine ou une entreprise ayant besoin d'une assurance transfrontalière doit évaluer le risque OFAC avant même d'aborder les mérites techniques. Ce n'est pas une enluminure morale sur l'infrastructure. C'est un fait pratique concernant le paiement, le support, l'application des contrats et l'approvisionnement d'urgence.

La migration est la dernière ligne de redondance

Tout acheteur cloud veut un basculement. Dans de nombreuses pannes réelles, le seul basculement durable est la capacité de partir. Le propre catalogue d'O2 Cloud comprend des services autour de la migration et de l'infrastructure managée, ce qui rappelle que le mouvement fait partie de la surface produit. Un client doit traiter les droits de sortie comme une fonctionnalité de reprise, pas comme une annexe juridique.

Le problème de migration commence par l'inventaire. Une machine virtuelle VMware peut contenir des systèmes d'exploitation sous licence, des bases de données, des intergiciels, des services d'arrière-plan propriétaires, des intégrations d'identité, des clients de sauvegarde, des règles de pare-feu et des crochets de surveillance. Un serveur dédié peut inclure le firmware, les configurations RAID, les disques locaux et les garanties du fournisseur. Une base de données managée peut cacher les paramètres de réplication, les versions d'extension et les formats de sauvegarde.

Un produit de sécurité peut se trouver sur le chemin du trafic de production. Aucun de ces composants ne se déplace automatiquement simplement parce que le client possède les données métier.

Le client a besoin de preuves portables avant un incident. Cela signifie des exports de configuration actuels, des images de VM ou des scripts de reconstruction, des sauvegardes de bases de données, des clés de chiffrement, des enregistrements de licence, le contrôle du DNS et des certificats, des diagrammes réseau, des politiques de pare-feu, des contacts de support et une liste des intégrations tierces. Cela signifie également une capacité de test au niveau de la destination. Un extrait de base de données n'est pas portable s'il ne peut pas être restauré dans la fenêtre de maintenance.

Une image de VM n'est pas portable si l'hyperviseur, le contrôleur de stockage, le mode réseau ou la politique de licence de destination la rejette.

Lesynopsis et recommandations sur le clouddu NIST traite les accords de service, le transfert de données, les performances, la fiabilité, la sécurité et la portabilité comme des questions d'achat connectées. C'est le bon cadre pour O2 Cloud. L'acheteur ne doit pas seulement demander « puis-je récupérer mes données? » Il doit demander dans quel format, avec quelles clés, dans combien d'heures, à quelle bande passante, dans quel état contractuel et avec quel personnel du fournisseur disponible.

Les preuves publiques de routage et de service d'O2 Cloud rendent plausible que de nombreux clients puissent y exécuter des charges de travail de production ordinaires. La plausibilité n'est pas suffisante pour les systèmes critiques. Le test de sortie doit être effectué pendant que la relation est saine: restaurer une sauvegarde représentative en dehors du fournisseur, mettre en place une copie de l'application, diriger un groupe de test par le chemin alternatif, rapprocher les données et confirmer que le fournisseur peut supprimer ou conserver les anciennes copies conformément au devoir légal du client.

Plus la charge de travail est réglementée, plus la migration doit inclure des enregistrements et des preuves. Les systèmes de données personnelles nécessitent des logs de localisation et d'accès. Les systèmes financiers nécessitent un rapprochement et des pistes d'audit. Les systèmes de vente au détail et de logistique nécessitent une continuité des interfaces. Les systèmes de sécurité nécessitent la preuve que les politiques et les logs survivent. Un client qui attend qu'un litige de facturation, de sanctions, d'installation ou de support commence peut découvrir que la migration technique n'était que la moitié du problème.

Le verdict: de solides preuves réseau, une confiance opérationnelle conditionnelle

O2Cloud O2 Cloud, LLC doit être traité comme un fournisseur d'infrastructure russe actif avec de solides preuves de routage et une marque de service substantielle. L'entreprise est visible dans les registres d'entreprises, dans les licences de communications, dans RIPE en tant que LIR, dans le routage AS208349, dans les pages de service OXYGEN et dans les enregistrements de certification de centres de données tiers liés aux salles Oxygen de Business System Telehouse. C'est bien plus qu'une entrée d'annuaire dormante.

La dégradation concerne les preuves de reprise, pas l'existence.

Les pages publiques décrivent des services de cloud, de sauvegarde, de reprise, de sécurité, de location de matériel et de support, mais elles ne publient pas les faits spécifiques au client qui convertissent ces services en résilience: l'emplacement exact des installations, la séparation de l'alimentation et des baies, les limites des clusters, la capacité de réserve, la réplication du stockage, l'indépendance des routes, l'autorité d'escalade, l'indépendance de la sauvegarde, les tests de restauration, les droits d'exportation et les chemins de fournisseurs à l'épreuve des sanctions.

Pour les charges de travail russes ordinaires qui ont besoin de capacité cloud locale et acceptent l'environnement juridique du fournisseur, O2 Cloud peut être un candidat rationnel si le contrat et les tests correspondent à la charge de travail. Pour les charges de travail avec des contreparties internationales, des données personnelles réglementées, des objectifs de reprise stricts, des dépendances matérielles importées ou une exposition aux règles de sanctions américaines, la barre de diligence est plus élevée. Le fournisseur peut être réel et pourtant constituer une mauvaise frontière de reprise pour un client donné.

La réponse pratique est d'acheter des preuves, pas des adjectifs. Demander la carte du site, le chemin AS, l'architecture de sauvegarde, la dernière restauration, la politique de stock de pièces de rechange, la matrice de support, le calendrier de localisation des données, la réponse de conformité aux sanctions et le package de sortie. Ensuite, tester une panne qui supprime l'installation primaire, la route primaire, le chemin de support normal et le portail en libre-service du fournisseur. Si la charge de travail survit à cet exercice dans la tolérance métier, la capacité hébergée d'O2 Cloud fait ce pour quoi les acheteurs cloud paient.

Si ce n'est pas le cas, la redondance réelle du client se trouve toujours en dehors du fournisseur.