La oss kort gjennomgå noen av operasjonene til AWS som en AIGC Startup SRE, jeg håper det kan hjelpe alle Fra begynnelsen av onboardingen for å oppdage at hovedklyngen vår var USE1, begynte jeg å gjøre noen forberedelser. Dette er de viktigste tingene jeg gjør 1. Flere av kjernedatabasene våre har blitt sikkerhetskopiert flere steder, og danner USE1-, Tokyo- og SG-sikkerhetskopier. På denne måten mister vi i ekstreme tilfeller en del av dataene, men vi kan også sikre videreføringen av tjenesten 2. Rekonstruer vår SG-testklynge fra den originale EC2 K3S til en standard AWS EKS-klynge. Dette lar deg raskt varme opp en klynge i tilfelle en katastrofe og gjenbruke eksisterende AWS-komponenter. Minimere kostnadene ved manifestendringer 3. Sorter kort ut en SOP, inkludert brukerkunngjøringer, DNS-bytte, versjonsblokkering, etc Tilbake i dag, omtrent 10 minutter etter AWS-hendelsen, oppdaget jeg at det var nye pods i containerne våre som ikke kunne settes opp. Etter å ha bekreftet med AWS Support at det var et USE1-problem, innså jeg at ECR-hendelser må være relatert til resten av hendelsene, så jeg bestemte meg for å begynne å håndtere hendelser på nivå 1 i henhold til min egen plan (for SRE-er er denne typen ting bedre å ta feil enn å gå glipp av) T+0 min, jeg sendte ut en kunngjøring for alle ansatte og begynte å gå inn i nødmodus. Jeg satte opp et offentlig møte med alle hender. Alle personer kan bli med når som helst T+2 min, bekreftet jeg at arrangementet gradvis utvidet seg som jeg forventet, og jeg ga to instruksjoner, 1. Forby at kode slås sammen/forpliktes over hele linja (hovedsakelig for å forhindre at nyopprettede ressurser får pod-rotasjon til å påvirke trafikken), 2. Vennligst utarbeide en kunngjøring for operasjonsstudentene T+3 min, jeg begynte å følge SOP, startet databasegjenopprettingen i SG-regionen og kaskade for å lage avhengigheter som OpenSearch/Redis osv T+5 min begynte vi offisielt å bekrefte de spesifikke problemene med oppstrøms- og nedstrømsavhengigheter, og bekreftet at en nylig lansert kjernetjeneste var berørt T+10min, vår kunngjøring om tjenestesuspensjon og den berørte kunngjøringen for resten av tjenestene vil bli utstedt T+10min, jeg ba to andre personer om å hjelpe til med å sette opp den nye ECR og rydde opp i de eksisterende ressursene i testmiljøet samtidig, og synkronisere CTO, i ekstreme tilfeller kan vi ha beslutningen om å bevare opplevelsen og miste data. T+15min, bekreftet vi endelig at ressursene som er opprettet så langt og retningen på trafikken innover ikke vil bli mye påvirket. Overgangen venter, men vi fortsetter å forberede de relevante ressursene T+30min, vår første database er gjenopprettet T+40min, vår andre database er gjenopprettet T+1h, alle våre tilknyttede kjerneinfraer, RDS/ES/Redis er standby, og optimaliseringsalternativer som master-slave er satt i henhold til produksjonsarkitekturen. Samtidig begynner vi også å lansere nye tjenester i nye klynger Heldigvis, til slutt, påvirket ikke AWS-krasjet alle tjenestene våre. Vi trenger ikke å forholde oss til komplekst datareparasjonsarbeid etter å ha byttet trafikk Etter omtrent T+2 timer til T+3 timer varslet jeg offisielt alle ansatte og unntakstilstanden ble opphevet. For å være på den sikre siden vil vi fortsatt være stengt for å være med i kveld. Når jeg ser tilbake på hele hendelsen, kunne jeg ha gjort mer 1. Avslør den ekstreme SOP jeg forberedte for meg selv til alle ansatte. Dette sikrer at selv om jeg ikke er online, kan noen ta min plass 2. Vi kan gjøre noen forhåndsøvelser 3. Bestillinger kan være mer avgjørende Det er nesten det, litt deling, jeg håper det kan hjelpe alle

La oss snakke voldsomt om det Med fremveksten av AI-æraen vil kodebaser og arkitekturer fortsette å korrumpere i en enestående hastighet. Dette vil bety at stabilitet blir vanskeligere og vanskeligere å gjøre. Mange stabilitetsdetaljer og beste praksis som tidligere ble oversett, vil bli forsterket i AI-æraen. Flere og flere startups møter sine egne arkitektoniske flaskehalser raskere enn forventet eller når det er på tide å betale tilbake teknisk gjeld En annen betydning av at stabilitet blir vanskeligere og vanskeligere er at det er færre og færre mennesker som kan gjøre stabilitet. Når det gjelder vibe-koding, er det færre og færre mennesker som kan roe seg ned og gjøre stabilitet