Résumé

  • DigitalOcean a signalé des erreurs lors de la création de clusters Managed Databases, d’abord sous un composant Global et dans plusieurs régions, puis a nommé NYC1 et NYC3 au moment des correctifs.
  • Les lignes de composants des deux régions sont restées operational dans les dernières mises à jour, preuve qu’un voyant global ne suffit pas à décrire la santé d’une transaction du plan de contrôle.

Un tableau d’état peut être vert sans que l’action dont dépend une équipe fonctionne. L’incident « Managed Databases Creation » de DigitalOcean l’a montré le 23 août : le fournisseur décrivait des erreurs lors de la création de nouveaux clusters, tandis que les lignes finales pour NYC1 et NYC3 indiquaient un passage d’operational à operational.

Il ne s’agit pas d’une contradiction qu’il faudrait résoudre en choisissant une seule ligne. Le composant agrège un état de service ; le texte de l’incident décrit une transaction précise. Pour une équipe qui devait créer une base, la seconde information était la plus directement exploitable.

DigitalOcean a ouvert l’incident à 05:11:37 UTC. La première mise à jour indiquait que des utilisateurs pouvaient rencontrer des erreurs en créant des clusters depuis le Cloud Control Panel ou au moyen de requêtes API. Le composant général Managed Databases - Global est alors passé d’opérationnel à performances dégradées.

À 07:06:56, le fournisseur a étendu sa description à plusieurs régions. Ses ingénieurs appliquaient une mesure d’atténuation pour rétablir un provisionnement normal. Aucune cause technique n’était publiée, et le message ne disait ni combien de requêtes avaient échoué, ni si les deux interfaces échouaient de la même manière.

À 11:30:34, la géographie publique s’est précisée. DigitalOcean a annoncé avoir déployé les correctifs nécessaires pour la création de clusters dans NYC3 et NYC1. Les utilisateurs devaient désormais pouvoir créer de nouveaux clusters, et l’incident est passé en phase de surveillance. À 14:33:31, le fournisseur l’a déclaré résolu.

Entre l’ouverture et la surveillance, il s’est écoulé 6 heures, 18 minutes et 57,959 secondes. La surveillance a duré 3 heures, 2 minutes et 56,760 secondes. Le temps total enregistré jusqu’à la résolution atteint 9 heures, 21 minutes et 54,719 secondes. Ce sont des intervalles du journal public, pas la durée prouvée d’une erreur continue pour chaque client.

La succession des périmètres doit également rester visible. Le premier composant était Global, le message suivant parlait de plusieurs régions, puis les deux dernières mises à jour ont nommé NYC1 et NYC3. Rien ne précise si l’enquête a réduit le périmètre, si d’autres régions ont récupéré avant elles ou si le composant initial n’était qu’une catégorie large.

La documentation DigitalOcean permet de comprendre ce que recouvre la création. Un client peut demander un cluster depuis le panneau de contrôle, avec doctl ou par l’API. L’interface documentée utilise POST /v2/databases et demande notamment un moteur, une région et une taille. Ces éléments décrivent le contrat public, pas l’origine de l’incident.

Le provisionnement ne se termine pas au premier succès HTTP. La réponse à une demande acceptée contient une ressource de base de données qui commence dans l’état creating. Elle passe ensuite à online lorsqu’elle est prête à recevoir du trafic. Pour PostgreSQL, DigitalOcean indique que le provisionnement prend généralement au moins cinq minutes.

Il faut donc observer plusieurs frontières : la demande est-elle acceptée, la ressource est-elle créée, quitte-t-elle l’état creating, devient-elle online, puis accepte-t-elle réellement la connexion prévue ? La disponibilité d’un cluster existant constitue encore une autre mesure. Le récit public portait sur la première action et n’autorise pas à conclure que toutes les autres ont échoué.

Cette séparation évite deux erreurs symétriques. Qualifier l’événement de panne générale des bases exagérerait ce qui est établi : DigitalOcean n’a pas signalé de perte de données, d’échec des requêtes SQL, des sauvegardes ou de la réplication. Affirmer que tous les clusters existants sont restés intacts irait aussi au-delà des preuves, car le fournisseur ne l’a pas certifié pour chaque client.

Le signal le plus concret reste l’impossibilité potentielle de créer ce qui n’existait pas encore. Une application peut continuer à servir ses utilisateurs alors qu’une nouvelle région, une capacité supplémentaire, une base d’isolement ou une cible de reprise ne peut pas être provisionnée. Le plan de données visible est sain, mais la marge de manœuvre opérationnelle se réduit.

C’est précisément pourquoi le vert du composant ne doit pas être assimilé à la réussite de chaque parcours. Dans les dernières entrées du fichier d’incident, NYC1 et NYC3 sont notés opérationnels avant et après la mise à jour narrative. Seul le texte indique que la création avait été empêchée puis réparée.

DigitalOcean n’a pas publié le point de défaillance. Le dossier ne nomme ni validation de requête, ni ordonnanceur, ni capacité, ni réseau, ni stockage, ni moteur de base, ni passerelle API, ni orchestrateur. Les pages produit ne permettent pas de remonter de la forme générique du parcours à une cause locale le 23 août.

La bonne unité d’observation est ainsi la transaction du client. Conserver le corps de la demande, la région, le code de réponse, l’identifiant reçu, les changements d’état et le premier instant où la base devient joignable donne une chronologie vérifiable. Regarder seulement la couleur du composant peut masquer le problème ; regarder seulement l’erreur de création peut masquer le retour progressif du service.

L’incident est clos dans le registre public. Sa portée demeure plus précise qu’une « panne de bases » : DigitalOcean a perturbé la capacité à créer de nouveaux clusters, dans un périmètre d’abord large puis associé à NYC1 et NYC3, sans publier de cause. Cette précision est indispensable pour transformer un statut en décision d’exploitation.

Sources