Podívejme se stručně na některé operace AWS jako AIGC Startup SRE, doufám, že to může pomoci všem Od začátku onboardingu, kdy jsem zjistil, že náš hlavní cluster je USE1, jsem začal dělat nějaké přípravy. To jsou hlavní věci, které dělám 1. Několik našich klíčových databází bylo zálohováno na více místech, čímž vznikly zálohy USE1, Tokyo a SG. Tímto způsobem v extrémních případech přijdeme o část dat, ale zároveň můžeme zajistit pokračování služby 2. Rekonstruovat náš testovací cluster SG z původního EC2 samotného K3S na standardní AWS EKS cluster. To vám umožní rychle zahřát cluster v případě havárie a znovu použít stávající komponenty AWS. Minimalizace nákladů na změny manifestu 3. Stručně vyřešte SOP, včetně uživatelských hlášení, přepínání DNS, blokování verzí atd Dnes, asi 10 minut po incidentu s AWS, jsem zjistil, že v našich kontejnerech jsou nové pody, které nelze nastavit. Poté, co jsem si u podpory AWS ověřil, že se jednalo o problém USE1, jsem si uvědomil, že události ECR musí souviset se zbytkem událostí, a tak jsem se rozhodl začít zpracovávat události na úrovni Tier1 podle svého vlastního plánu (u SRE je lepší takové věci špatně než přehlédnout) T+0 min jsem vydal hlášení pro všechny zaměstnance a začal jsem přecházet do nouzového režimu. Zorganizoval jsem veřejné setkání všech rukou. Všichni lidé se mohou kdykoli připojit T+2 min jsem si potvrdil, že se akce postupně rozšiřuje podle mých očekávání, a vydal jsem dva pokyny, 1. Zakažte jakékoli slučování/odevzdávání kódu plošně (zejména proto, aby se zabránilo tomu, že nově vytvořené zdroje způsobí, že rotace podů ovlivní provoz), 2. Připravte si prosím hlášení pro provoz studentů T+3 min jsem začal sledovat SOP, zahájil obnovu databáze v oblasti SG a kaskádovitě jsem vytvořil závislosti, jako je OpenSearch/Redis atd. T+5 min jsme začali oficiálně potvrzovat konkrétní problémy upstream a downstream závislostí a potvrdili, že byla ovlivněna nově spuštěná core služba T+10min, bude vydáno naše oznámení o pozastavení služeb a dotčené oznámení pro ostatní služby T+10min, požádal jsem další dva lidi, aby mi pomohli s nastavením nového ECR a zároveň s vyčištěním stávajících zdrojů v testovacím prostředí a synchronizací CTO, v extrémních případech můžeme mít rozhodnutí o zachování zkušeností a ztrátě dat. T+15min, jsme konečně potvrdili, že dosud vytvořené zdroje a směr příchozí dopravy nebudou příliš ovlivněny. Na přechod se čeká, ale nadále připravujeme příslušné zdroje T+30min, naše první databáze je obnovena T+40min, naše druhá databáze je obnovena T+1h, všechny naše přidružené core infras, RDS/ES/Redis jsou v pohotovostním režimu a možnosti optimalizace, jako je master-slave, jsou nastaveny podle produkční architektury. Zároveň také začínáme spouštět nové služby v nových clusterech Naštěstí nakonec pád AWS neovlivnil všechny naše služby. Nemusíme řešit složité opravy dat po přepnutí provozu Asi po T+2h až T+3h jsem oficiálně informoval všechny zaměstnance a nouzový stav byl zrušen. Pro jistotu budeme mít dnes večer stále zavřeno. Když se na celý incident dívám zpětně, mohl jsem udělat víc 1. Sdělit extrémní případ, který jsem si pro sebe připravil, všem zaměstnancům. Tím je zajištěno, že i když nejsem online, někdo může zaujmout mé místo 2. Můžeme udělat několik předběžných cvičení 3. Objednávky mohou být rozhodující To je skoro vše, trocha sdílení, doufám, že to může pomoci všem

Promluvme si o tom násilně S příchodem éry umělé inteligence se budou kódové základny a architektury i nadále ničit bezprecedentním tempem. To bude znamenat, že stabilita bude stále obtížnější. Mnoho detailů stability a osvědčených postupů, které byly dříve přehlíženy, bude v éře umělé inteligence zesíleno. Stále více startupů se setkává s vlastními architektonickými překážkami dříve, než se očekávalo, nebo když je čas splatit technický dluh Dalším významem toho, že stabilita se stává stále obtížnější, je to, že je stále méně lidí, kteří mohou stabilitu vykonávat. V případě vibe kódování je stále méně lidí, kteří se dokážou uklidnit a udělat stabilitu