Хайтек→ original

« Yandex » ne garantit pas la restauration complète des serveurs après l'attaque contre le data center de Sasovo

Yandex n'a pas voulu garantir que le matériel serveur du site de Sasovo (oblast de Riazan) pourra être entièrement restauré. En cause : un important incendie sur un site clé de l'infrastructure de l'entreprise. Dans son titre, Hi-Tech, qui cite Forbes.ru, attribue l'incendie à un raid de drones. Ce compte rendu ne donne aucune donnée publique sur le nombre de baies touchées, la capacité perdue ni le montant des dégâts. Pour l'instant, l'entreprise parle d'évaluation des conséquences, mais ne promet pas un retour à l'état antérieur. • La restauration complète du matériel n'est pas garantie. • Les chiffres des dégâts n'ont pas été communiqués. • Les clients ont intérêt à vérifier où se trouvent leurs données et leurs sauvegardes.

Traité par IA depuis Хайтек ; édité par Hamidun News
« Yandex » ne garantit pas la restauration complète des serveurs après l'attaque contre le data center de Sasovo
Source : Хайтек. Collage: Hamidun News.
◐ Écouter l'article

Yandex a refusé de garantir que le matériel serveur du data center de Sasovo, dans l'oblast de Riazan, sera entièrement restauré. En cause : un important incendie sur l'un des sites clés de l'infrastructure de l'entreprise. Hi-Tech, qui cite Forbes.ru, évoque une attaque de drones. Ce compte rendu ne contient aucune donnée chiffrée : on ignore combien de baies ont été touchées, quelle puissance de calcul a été perdue et à combien l'entreprise estime les dégâts. La formule « nous ne pouvons pas garantir » en dit long : une partie du matériel est vraisemblablement perdue de façon irrémédiable.

Ce que l'on sait à ce jour

Le tableau disponible est maigre ; séparons donc ce qui est confirmé de ce qui ne l'est pas.

  • Site : le data center de Yandex à Sasovo, dans l'oblast de Riazan, est décrit comme clé pour l'infrastructure.
  • Événement : un important incendie ; selon le titre du média, survenu après une attaque de drones.
  • Position de l'entreprise : la restauration complète du matériel serveur n'est pas garantie.
  • Source : Forbes.ru, cité via Hi-Tech, c'est-à-dire un compte rendu de seconde main.
  • Non communiqués : l'étendue des dégâts, le nombre de serveurs et de baies, la part de la capacité du site, les délais, l'estimation financière.

Tant qu'il n'existe pas de rapport officiel, tout chiffre de pertes relèvera de la conjecture. Il faudra l'attendre de l'entreprise elle-même ou de ses publications financières.

Ce que l'on perd réellement lors d'un incendie de data center

Les baies calcinées ne représentent qu'une partie des dégâts. La fumée, les produits de combustion, les agents d'extinction et l'eau endommagent aussi le matériel qui semble intact : les cartes s'oxydent, et les disques et blocs d'alimentation tombent en panne plus tard, après la remise en service. La décision de « restaurer ou remplacer » se prend donc à l'issue d'un diagnostic, qui prend des semaines. Cette incertitude explique vraisemblablement la prudence de la formulation de l'entreprise.

Il y a aussi le volet approvisionnement. En Russie, serveurs, équipements réseau et accélérateurs doivent être achetés sous sanctions et avec de longues chaînes d'approvisionnement. Remplacer la capacité perdue peut prendre nettement plus de temps que dans une région ordinaire du monde. Le compte rendu ne précise pas quelle charge était hébergée à Sasovo (recherche, cloud, services d'IA), et nous ne disposons d'aucune donnée confirmée sur des défaillances de produits précis.

Les grands opérateurs construisent leur infrastructure avec de la marge : la charge peut être répartie entre plusieurs sites et zones de disponibilité. Mais cette marge est calculée pour la défaillance d'une seule zone, pas pour la perte de plusieurs grands sites. Si les dégâts s'avèrent sérieux, il faudra choisir quels services reçoivent en priorité les ressources restantes. Pour préserver la stabilité des produits principaux, ce sont généralement les charges expérimentales et gourmandes en ressources qui en pâtissent, y compris l'entraînement et le réentraînement de modèles.

Que faire pour les clients et les équipes d'ingénierie

Pour ceux qui construisent des produits sur le cloud de Yandex ou d'autres fournisseurs russes, une courte liste de vérifications s'impose :

  • Vérifiez dans quelles zones de disponibilité se trouvent vos machines virtuelles, vos bases de données et vos stockages, et assurez-vous de ne pas avoir de point de défaillance unique dans une seule zone.
  • Précisez vos RPO et RTO cibles et comparez-les aux valeurs réelles : quand avez-vous restauré une sauvegarde pour la dernière fois ?
  • Conservez vos sauvegardes hors du site de la charge principale, et de préférence chez un autre fournisseur.
  • Pour l'inférence d'IA, gardez une image et une configuration prêtes à l'emploi afin de déplacer le modèle vers une autre zone sans assemblage manuel. Placez les points de contrôle d'entraînement dans un stockage séparé.
  • Relisez le SLA : quels incidents il couvre, comment l'indemnisation est calculée et si la force majeure en est exclue.
  • Suivez les communications officielles du fournisseur, pas les comptes rendus de seconde main. Pour l'instant, seule la position prudente de l'entreprise est publique.

La grande question des prochaines semaines : à quelle vitesse Yandex annoncera l'ampleur des pertes et les délais de remplacement des capacités. La réponse déterminera si l'incident reste un problème local à un seul site ou s'il affecte la disponibilité des services et les plans de développement de l'infrastructure d'IA.

ZK
Hamidun News
Actualités IA sans bruit. Sélection éditoriale quotidienne de plus de 50 sources. Produit de Zhemal Khamidun, Head of AI chez Alpina Digital.
✦ Unified AI Workspace

Access Frontier LLMs & Multimodal AI in One Workspace

Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.

Try NomadNet AI →Launch NomadNet Agent
Qu'en pensez-vous ?
Chargement des commentaires…