Facciamo un breve riepilogo dell'incidente AWS come alcune operazioni di un AIGC Startup SRE, spero possa essere utile a tutti. Dall'inizio del mio lavoro, ho scoperto che i nostri cluster principali si trovano in USE1, quindi ho iniziato a fare alcune preparazioni. Le cose principali che ho fatto sono state queste: 1. Ho effettuato backup multi-sito dei nostri principali database, creando backup in USE1, Tokyo e SG. In questo modo, in situazioni estreme, potremmo perdere una parte dei dati, ma possiamo garantire la continuità del servizio. 2. Ho ricostruito il nostro cluster di test SG, che inizialmente era un K3S semplice su EC2, in un cluster AWS EKS standard. In questo modo, in caso di disastro, possiamo avviare rapidamente un cluster riutilizzando i componenti già esistenti di AWS. Ho ridotto al minimo il costo delle modifiche al manifest. 3. Ho redatto un semplice SOP, che include annunci agli utenti, cambio DNS, chiusura delle versioni, ecc. Tornando a oggi, circa 10 minuti dopo l'incidente AWS, ho scoperto che nel nostro container c'erano nuovi Pod che non riuscivano a configurarsi. Dopo aver confermato con il supporto AWS che si trattava di un problema di USE1, ho realizzato che l'evento ECR era sicuramente correlato ad altri eventi, quindi ho iniziato a gestire la situazione secondo il piano che avevo stabilito per gli eventi di livello Tier1 (per un SRE, è meglio sbagliarsi che perdere un evento). T+0 min, ho pubblicato un annuncio a tutti, entrando in modalità emergenza. Ho impostato una riunione pubblica per tutti. Tutti possono unirsi in qualsiasi momento. T+2 min, ho confermato che l'evento si stava espandendo come previsto, ho emesso due ordini: 1. Vietare qualsiasi integrazione o commit di codice (principalmente per evitare che la creazione di nuove risorse porti a un rotazione dei Pod, influenzando così il traffico), 2. Chiedere ai colleghi delle operazioni di preparare un annuncio. T+3 min, ho iniziato a seguire il SOP, avviando il ripristino del database nella regione SG e creando in cascata dipendenze come OpenSearch / Redis, ecc. T+5 min, abbiamo iniziato a confermare i problemi specifici delle dipendenze a monte e a valle, confermando che un nuovo servizio core lanciato era stato influenzato. T+10 min, abbiamo emesso l'annuncio di interruzione del servizio e l'annuncio degli altri servizi influenzati. T+10 min, ho chiesto ad altre due persone di aiutare a configurare un nuovo ECR e a pulire le risorse esistenti nell'ambiente di test, e ho informato il CTO che, in situazioni estreme, potremmo dover prendere decisioni per mantenere l'esperienza a scapito della perdita di dati. T+15 min, abbiamo confermato che le risorse già create e la direzione del traffico non sarebbero state troppo influenzate. Il piano di switch è stato sospeso, ma abbiamo continuato a preparare le risorse correlate. T+30 min, il nostro primo database è stato ripristinato. T+40 min, il nostro secondo database è stato ripristinato. T+1h, tutte le nostre infrastrutture core correlate, RDS/ES/Redis, sono state messe in standby e abbiamo impostato opzioni di ottimizzazione come master/slave secondo l'architettura di produzione. Allo stesso tempo, abbiamo iniziato a lanciare nuovi servizi in un nuovo cluster. Per fortuna, alla fine il crash di AWS non ha influenzato tutti i nostri servizi. Non abbiamo dovuto affrontare il complesso lavoro di riparazione dei dati dopo il cambio di traffico. Circa tra T+2h e T+3h, ho ufficialmente informato tutti che lo stato di emergenza era stato revocato. Per sicurezza, questa sera rimaniamo in chiusura delle versioni delle funzionalità. Ripensando all'intero incidente, avrei potuto fare di più: 1. Rendere pubblico a tutti il SOP per i casi estremi che avevo preparato per me stesso. In questo modo, anche se non fossi stato online, qualcuno avrebbe potuto sostituirmi. 2. Possiamo fare alcune esercitazioni preventive in anticipo. 3. Gli ordini possono essere dati in modo più deciso. Ecco, è tutto. Spero che questa condivisione possa essere utile a tutti.