Laten we kort terugblikken op deze AWS-incident en enkele acties die ik als AIGC Startup SRE heb ondernomen, hopelijk helpt het iedereen. Vanaf het moment dat ik begon, ontdekte ik dat onze belangrijkste clusters zich in USE1 bevonden, dus begon ik met enkele voorbereidingen. De belangrijkste dingen die ik heb gedaan zijn de volgende: 1. Ik heb meerdere back-ups gemaakt van onze kern-databases, met back-ups in USE1, Tokyo en SG. Op deze manier, in extreme gevallen, verliezen we een deel van de data, maar kunnen we de service blijven garanderen. 2. Ik heb onze testcluster in SG, die oorspronkelijk eenvoudig was opgezet met EC2 en K3S, opnieuw opgebouwd naar een standaard AWS EKS-cluster. Dit maakt het mogelijk om in geval van een ramp snel een cluster op te warmen en gebruik te maken van bestaande AWS-componenten. De kosten van manifestwijzigingen zijn tot een minimum beperkt. 3. Ik heb een eenvoudige SOP opgesteld, inclusief gebruikersaankondigingen, DNS-wijzigingen, en versiebeheer. Terug naar vandaag, ongeveer 10 minuten na het incident bij AWS, ontdekte ik dat er nieuwe Pods in onze containers waren die niet konden worden opgezet. Na bevestiging met AWS-ondersteuning dat het een probleem in USE1 was, realiseerde ik me dat het ECR-incident ongetwijfeld verband hield met andere incidenten, dus begon ik resoluut te handelen volgens mijn eigen geplande Tier1-incidentprotocol (voor SRE's is het beter om een fout te maken dan iets te missen). T+0 min, ik publiceerde een aankondiging voor iedereen en schakelde over naar noodmodus. Ik zette een openbare vergadering op waar iedereen op elk moment kon deelnemen. T+2 min, ik bevestigde dat het incident zich zoals verwacht aan het uitbreiden was, en gaf twee instructies: 1. Verbod op het samenvoegen/indienen van enige code (voornamelijk om te voorkomen dat nieuwe resources Pod-rotaties veroorzaken, wat de verkeersstroom zou beïnvloeden), 2. Vraag de operationele collega's om een aankondiging voor te bereiden. T+3 min, begon ik volgens de SOP met het herstellen van de databases in de SG-regio en het cascade creëren van afhankelijkheden zoals OpenSearch / Redis. T+5 min, we begonnen officieel de specifieke problemen van upstream en downstream afhankelijkheden te bevestigen en bevestigden dat een nieuw gelanceerde kernservice werd beïnvloed. T+10 min, we publiceerden de aankondiging van de stopzetting van de service en de aankondiging van de andere getroffen diensten. T+10 min, vroeg ik twee andere collega's om te helpen met het opzetten van een nieuwe ECR en het opruimen van bestaande testresources, en synchroniseerde met de CTO. In extreme gevallen kunnen we beslissingen nemen om de ervaring te behouden, zelfs als we data verliezen. T+15 min, bevestigden we uiteindelijk dat de momenteel gemaakte resources en de verkeersinvoer niet al te veel beïnvloed zouden worden. De switch-plannen werden opgeschort, maar we bleven relevante resources voorbereiden. T+30 min, we voltooiden de eerste databaseherstel. T+40 min, we voltooiden de tweede databaseherstel. T+1h, al onze gerelateerde kern-infrastructuur, RDS/ES/Redis, stond standby en we stelden ook de master-slave en andere optimalisatie-opties in volgens de productiearchitectuur. Tegelijkertijd begonnen we met het opstarten van nieuwe diensten in een nieuw cluster. Gelukkig had de crash van AWS uiteindelijk geen invloed op al onze diensten. We hoefden niet te worstelen met complexe databasereparaties na de verkeersoverschakeling. Ongeveer T+2h tot T+3h later, informeerde ik officieel iedereen dat de noodtoestand was opgeheven. Voor de zekerheid blijven we vanavond de functies vergrendelen. Terugkijkend op het hele incident, had ik nog meer kunnen doen: 1. De extreme case SOP die ik eerder voor mezelf had voorbereid, openbaar maken voor iedereen. Dit zorgt ervoor dat, zelfs als ik niet online ben, iemand anders mijn taken kan overnemen. 2. We kunnen enkele voorafgaande oefeningen doen. 3. De instructies kunnen iets resoluter worden gegeven. Dat is het zo'n beetje, een kleine bijdrage, hopelijk helpt het iedereen.