Après un incident cloud, la question utile n'est pas quel fournisseur a gagné, mais quelles dépendances étaient sur le chemin, quelles preuves existent et quoi changer. Cette revue ne garde que les faits étayés par le fournisseur et l'architecture actuelle.
Chronologie du fournisseur
AWS documente un événement us-east-1 de 23 h 48 PDT le 19 octobre à 14 h 20 PDT le 20, avec erreurs DynamoDB, problèmes de lancement et connectivité EC2, puis erreurs sur certains Network Load Balancers. Lire le bilan officiel d'AWS.
La conclusion étayée
Le runtime principal de ShortURL.bot est documenté sur Microsoft Azure, pas AWS : ce n'était pas une panne directe de l'hôte cloud principal. Cela ne prouve pas que chaque requête, intégration ou destination client était disponible, chaque service amont ayant ses dépendances.
L'architecture documentée
Le backend utilise Node.js Azure Functions, Azure Front Door en périphérie, MSSQL comme stockage principal et Blob Storage ; Cosmos subsiste dans des chemins hérités. Rien n'étaye dix régions actives, un basculement intercontinental en quelques secondes ni Cosmos comme plan principal.
Leçons d'exploitation
- Surveillez tout le parcours : le redirect peut être sain et la destination en panne.
- Gardez une trace : statuts horodatés et communications publiques valent mieux qu’une affirmation rétrospective.
- Testez la reprise : DNS, redirect, identité, stockage et destination séparément.
Vérifier les preuves actuelles
Pour l'état des composants et l'historique publié, consultez la page d'état ShortURL.bot.