Låt oss kort granska några av AWS operationer som en AIGC Startup SRE, jag hoppas att det kan hjälpa alla Från början av introduktionen för att upptäcka att vårt huvudkluster var USE1 började jag göra några förberedelser. Det här är de viktigaste sakerna jag gör 1. Flera av våra kärndatabaser har säkerhetskopierats på flera ställen och bildat USE1-, Tokyo- och SG-säkerhetskopior. På så sätt förlorar vi i extrema fall en del av datan, men vi kan också säkerställa att tjänsten fortsätter 2. Rekonstruera vårt SG-testkluster från den ursprungliga EC2 själv K3S till ett standard AWS EKS-kluster. På så sätt kan du snabbt värma upp ett kluster i händelse av en katastrof och återanvända befintliga AWS-komponenter. Minimera kostnaden för manifeständringar 3. Ordna kortfattat en SOP, inklusive användarmeddelanden, DNS-växling, versionsblockering, etc Tillbaka idag, ungefär 10 minuter efter AWS-incidenten, upptäckte jag att det fanns nya poddar i våra containrar som inte kunde ställas in. Efter att ha bekräftat med AWS Support att det var ett USE1-problem insåg jag att ECR-händelser måste vara relaterade till resten av händelserna, så jag bestämde mig för att börja hantera händelser på Tier1-nivå enligt min egen plan (för SRE:er är det bättre att ha fel än att missa) T+0 min, jag utfärdade ett meddelande för all personal och började gå in i nödläge. Jag ordnade ett offentligt möte för alla. Alla personer kan gå med när som helst T+2 min, jag bekräftade att evenemanget gradvis expanderade som jag förväntade mig, och jag gav två instruktioner, 1. Förbjud all kod som sammanfogas/checkas in över hela linjen (främst för att förhindra att nyligen skapade resurser orsakar poddrotation för att påverka trafiken), 2. Förbered gärna en annons till verksamheten studenter T+3 min, jag började följa SOP, startade databasåterställningen i SG-regionen och kaskad för att skapa beroenden som OpenSearch/Redis, etc T+5 minuter började vi officiellt bekräfta de specifika problemen med uppströms- och nedströmsberoenden och bekräftade att en nyligen lanserad kärntjänst påverkades T+10min, vårt meddelande om avstängning av tjänsten och det berörda meddelandet för resten av tjänsterna kommer att utfärdas T+10min, jag bad två andra personer att hjälpa till med att sätta upp den nya ECR och städa upp de befintliga resurserna i testmiljön samtidigt, och synkronisera CTO, i extrema fall kan vi ha beslutet att bevara upplevelsen och förlora data. T+15min bekräftade vi äntligen att de resurser som skapats hittills och riktningen på inkommande trafik inte kommer att påverkas nämnvärt. Övergången väntar, men vi fortsätter att förbereda de relevanta resurserna T+30min, vår första databas är återställd T+40min, vår andra databas är återställd T+1h, alla våra associerade kärninfrastrukturer, RDS/ES/Redis är standby, och optimeringsalternativ som master-slave ställs in enligt produktionsarkitekturen. Samtidigt börjar vi också lansera nya tjänster i nya kluster Tack och lov påverkade AWS-kraschen i slutändan inte alla våra tjänster. Vi behöver inte ta itu med komplext datareparationsarbete efter att ha bytt trafik Efter ungefär T+2h till T+3h meddelade jag officiellt all personal och undantagstillståndet hävdes. För att vara på den säkra sidan kommer vi fortfarande att vara stängda för att presentera ikväll. När jag ser tillbaka på hela händelsen kunde jag ha gjort mer 1. Avslöja det extrema fallet SOP som jag har förberett för mig själv för alla anställda. Detta säkerställer att även om jag inte är online kan någon ta min plats 2. Vi kan göra några avancerade övningar 3. Beställningar kan vara mer avgörande Det är nästan det, lite delning, jag hoppas att det kan hjälpa alla