Rubriques tendance
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Faisons un petit retour sur cet incident AWS en tant que SRE d'une startup AIGC, j'espère que cela pourra aider tout le monde.
Dès mon arrivée, j'ai constaté que nos principaux clusters se trouvaient dans USE1, alors j'ai commencé à faire quelques préparatifs.
Voici les principales actions que j'ai entreprises :
1. J'ai effectué des sauvegardes multi-sites de nos principales bases de données, créant des sauvegardes à USE1, Tokyo et SG. Ainsi, dans des situations extrêmes, nous perdons une partie des données, mais nous pouvons garantir la continuité du service.
2. J'ai reconstruit notre cluster de test SG, qui était à l'origine un K3S simple sur EC2, en un cluster AWS EKS standard. Cela permet de réchauffer rapidement un cluster en cas de catastrophe, en réutilisant les composants existants d'AWS. J'ai minimisé le coût des modifications de manifest.
3. J'ai élaboré un SOP simple, incluant des annonces aux utilisateurs, des changements de DNS, des mises hors ligne, etc.
Revenons à aujourd'hui, environ 10 minutes après l'incident AWS, j'ai découvert que de nouveaux Pods dans notre conteneur ne pouvaient pas être configurés.
Après avoir confirmé avec le support AWS qu'il s'agissait d'un problème USE1, j'ai réalisé que l'incident ECR était nécessairement lié aux autres incidents, alors j'ai commencé à traiter l'incident selon le niveau de gravité Tier1 que j'avais planifié (pour un SRE, ce genre de situation peut être une erreur, mais il ne faut pas manquer l'occasion).
T+0 min, j'ai publié une annonce à tous, et nous sommes entrés en mode d'urgence. J'ai mis en place une réunion publique pour tout le monde. Tous les membres du personnel pouvaient rejoindre à tout moment.
T+2 min, j'ai confirmé que l'incident se développait comme je l'avais prévu, j'ai émis deux instructions : 1. Interdiction de toute intégration ou soumission de code (principalement pour éviter que la création de nouvelles ressources ne provoque une rotation des Pods, ce qui affecterait le trafic), 2. Demander à l'équipe opérationnelle de préparer une annonce.
T+3 min, j'ai commencé à suivre le SOP pour restaurer la base de données dans la région SG, et à créer en cascade des dépendances telles qu'OpenSearch / Redis, etc.
T+5 min, nous avons commencé à confirmer les problèmes spécifiques des dépendances en amont et en aval, confirmant qu'un nouveau service central mis en ligne était affecté.
T+10 min, nous avons publié l'annonce d'arrêt de service et l'annonce des autres services affectés.
T+10 min, j'ai demandé à deux autres personnes de m'aider à configurer un nouvel ECR et à nettoyer les ressources existantes dans l'environnement de test, tout en synchronisant avec le CTO. Dans des situations extrêmes, nous pourrions avoir à prendre des décisions sur la préservation de l'expérience utilisateur tout en perdant des données.
T+15 min, nous avons finalement confirmé que les ressources créées et le sens du trafic ne seraient pas trop affectés. Le plan de basculement a été suspendu, mais nous avons continué à préparer les ressources connexes.
T+30 min, notre première base de données a été restaurée.
T+40 min, notre deuxième base de données a été restaurée.
T+1h, toutes nos infrastructures centrales associées, RDS/ES/Redis, étaient en attente, et nous avons configuré les options d'optimisation telles que la mise en place de maîtres et d'esclaves selon l'architecture de production. Nous avons également commencé à démarrer de nouveaux services dans un nouveau cluster.
Heureusement, l'incident AWS n'a pas affecté tous nos services. Nous n'avons pas eu à faire face à des travaux complexes de réparation des données après le basculement du trafic.
Environ T+2h à T+3h après, j'ai officiellement informé tout le monde que l'état d'urgence était levé. Par précaution, nous avons toujours mis en pause les nouvelles fonctionnalités ce soir.
En rétrospective sur l'incident, je pense que j'aurais pu faire encore plus :
1. Rendre public le SOP des cas extrêmes que j'avais préparé pour moi-même, afin de garantir que même si je ne suis pas en ligne, quelqu'un puisse me remplacer.
2. Nous pourrions effectuer des exercices de simulation à l'avance.
3. Les instructions pourraient être données de manière plus décisive.
Voilà, c'est tout, un petit partage, j'espère que cela pourra aider tout le monde.
Meilleurs
Classement
Favoris

