Résumé

  • L’incident critique de la région MKC1 a couru publiquement de 11 h 10 à 19 h 34 UTC le 19 août, avec des effets successifs sur des baies, des nœuds, DOKS, l’inférence et des services régionaux.
  • DigitalOcean l’a déclaré résolu après le retour du plan de contrôle et des services CPU généraux, tout en maintenant que les GPU Droplets restaient touchés et que la restauration de tous les nœuds continuait.

Deux horloges ont rythmé l’incident de Kansas City. La première mesurait le retour du socle régional : commandes de gestion, plan de contrôle Kubernetes, calcul CPU, bases de données, stockage et équilibrage. La seconde suivait les nœuds accélérés et les services qui en dépendaient. Le 19 août, DigitalOcean a arrêté la première horloge publique alors que la seconde tournait encore.

L’alerte a été ouverte à 11 h 10 min 06 s UTC pour un problème touchant plusieurs baies et plusieurs nœuds de MKC1. Le fournisseur évoquait des perturbations possibles des charges GPU et des nœuds de travail DOKS susceptibles de passer à l’état NotReady. L’impact global était classé critique.

À 12 h 22, DigitalOcean annonçait avoir identifié la cause racine et engagé des mesures correctives. La cause elle-même n’a pas été publiée. À ce stade, la liste des effets possibles comprenait les charges GPU, Serverless Inference, les nœuds DOKS, l’accès aux API Kubernetes et les opérations de gestion des clusters affectés. À 15 h 28, les équipes travaillaient encore au rétablissement de la connectivité et à la remise en ligne des nœuds. Aucun nombre de baies, de clusters ou de clients n’était fourni.

Le découpage des couches est devenu explicite à 18 h 59. Le plan de contrôle régional était, selon DigitalOcean, entièrement sain. Les CPU Droplets, Managed Databases, Load Balancers, Block Storage et Spaces fonctionnaient normalement. La création et le redimensionnement de Droplets avaient repris, tout comme les autres commandes de gestion, et les plans de contrôle DOKS étaient joignables.

Cette même note disait cependant que les GPU Droplets de MKC1 demeuraient hors ligne ou injoignables. Des nœuds de travail GPU de DOKS pouvaient encore afficher NotReady, tandis que les points d’accès d’inférence adossés aux GPU pouvaient rester indisponibles. DigitalOcean prévoyait de surveiller brièvement le plan de contrôle, puis de fermer l’incident régional. Les informations suivantes destinées aux clients GPU seraient personnalisées et envoyées par Slack et courriel plutôt que sur la page publique.

À 19 h 34 min 54 s, le statut est effectivement passé à resolved. La note finale confirmait le retour des services partagés nommés, mais répétait que les GPU Droplets restaient touchés et que la restauration de tous les nœuds se poursuivait. Les 8 h 24 min 48 s entre l’ouverture et la clôture décrivent donc une fenêtre de gestion d’incident dont le périmètre a évolué. Elles ne représentent ni une panne uniforme de tous les produits ni la durée exacte d’indisponibilité de chaque client.

La région n’avait que quinze jours. DigitalOcean avait annoncé MKC1 le 4 août comme un nouveau centre de données entièrement refroidi par liquide, équipé de GPU NVIDIA B300. Le catalogue lancé ensemble comprenait calcul, DOKS, bases de données, stockage, réseau, App Platform et Functions. Rien dans le dossier public ne relie le refroidissement liquide ou les B300 à la panne. En revanche, cette proximité entre lancement et incident transforme le rétablissement en test précoce de mise en service d’une région GPU.

DOKS montre pourquoi le mot « régional » ne suffit pas. DigitalOcean administre le plan de contrôle Kubernetes ; les applications s’exécutent sur des nœuds de travail. Un plan de contrôle accessible rend le cluster observable et administrable, mais ne rend pas disponible un accélérateur attaché à un nœud encore NotReady. La documentation propose bien un remplacement automatique des nœuds, mais ce mécanisme est en aperçu public, doit être activé volontairement et dépend de conditions, délais, actions et budgets configurés. Aucune source ne prouve qu’il était actif chez les clients touchés.

Le dossier comporte enfin des absences importantes. Le fournisseur n’a pas rendu publique la mécanique de la cause racine, malgré son identification annoncée. La mention d’un travail avec « l’installation » ne permet pas de conclure à un défaut électrique, de refroidissement ou de réseau. Il manque aussi le nombre de clients, l’heure exacte du retour de tous les GPU, un constat sur l’intégrité des charges et un plan détaillé de prévention. Un voyant de composant redevenu vert plus tard ne reconstitue pas ces faits.

Pour un exploitant, la bonne lecture consiste donc à séparer les preuves : le plan de contrôle répond-il, les nœuds sont-ils Ready, les accélérateurs sont-ils attribuables, les points d’inférence répondent-ils et l’application respecte-t-elle son objectif de service ? Le 19 août, DigitalOcean a rétabli plusieurs de ces couches, mais pas toutes au même instant. C’est cette chronologie, davantage que le seul mot resolved, qui décrit la réalité opérationnelle.

Sources