Tarkastellaan lyhyesti joitain AWS:n toimintoja AIGC Startup SRE:nä, toivottavasti se voi auttaa kaikkia Perehdytyksen alusta lähtien huomasin, että pääklusterimme oli USE1, aloin tehdä valmisteluja. Nämä ovat tärkeimmät asiat, joita teen 1. Useat ydintietokannoistamme on varmuuskopioitu useisiin paikkoihin, ja ne muodostavat USE1-, Tokio- ja SG-varmuuskopiot. Näin äärimmäisissä tapauksissa menetämme osan tiedoista, mutta voimme myös varmistaa palvelun jatkuvuuden 2. Rekonstruoi SG-testiklusterimme alkuperäisestä EC2 K3S:stä tavalliseksi AWS EKS -klusteriksi. Näin voit lämmittää klusterin nopeasti katastrofin sattuessa ja käyttää olemassa olevia AWS-komponentteja uudelleen. Manifestimuutosten kustannusten minimoiminen 3. Selvitä lyhyesti SOP, mukaan lukien käyttäjäilmoitukset, DNS-vaihto, version esto jne Tänään, noin 10 minuuttia AWS-tapauksen jälkeen, huomasin, että konteissamme oli uusia kapseleita, joita ei voitu asentaa. Varmistettuani AWS-tuen kanssa, että kyseessä oli USE1-ongelma, tajusin, että ECR-tapahtumien on liityttävä muihin tapahtumiin, joten päätin alkaa käsitellä Tier1-tason tapahtumia oman suunnitelmani mukaan (SRE:ille tällainen asia on parempi olla väärässä kuin jättää väliin) T+0 min, annoin koko henkilökunnalle ilmoituksen ja aloin siirtyä hätätilaan. Järjestin julkisen kokouksen. Kaikki ihmiset voivat liittyä milloin tahansa T+2 min, vahvistin, että tapahtuma laajeni vähitellen odotetulla tavalla, ja annoin kaksi ohjetta, 1. Estä koodin yhdistäminen/sitouttaminen kautta linjan (lähinnä estämään äskettäin luotuja resursseja aiheuttamasta podin kiertoa liikenteeseen), 2. Laadi ilmoitus operaation opiskelijoille T+3 min, aloin seurata SOP:ta, aloitin tietokannan palautuksen SG-alueella ja loin riippuvuuksia, kuten OpenSearch/Redis jne T+5 min, aloimme virallisesti vahvistaa tuotantoketjun alku- ja loppupään riippuvuuksien erityisongelmia ja vahvistimme, että tämä vaikutti äskettäin lanseerattuun ydinpalveluun T+10min, ilmoituksemme palvelun keskeytyksestä ja muiden palveluiden ilmoitus T+10min, pyysin kahta muuta henkilöä auttamaan uuden ECR:n asennuksessa ja testiympäristön olemassa olevien resurssien puhdistamisessa samanaikaisesti ja CTO:n synkronoinnissa, äärimmäisissä tapauksissa saatamme joutua päättämään säilyttää kokemuksen ja menettää tietoja. T+15min, vahvistimme vihdoin, että tähän mennessä luotuihin resursseihin ja liikenteen suuntaan ei juurikaan vaikuteta. Siirtyminen on kesken, mutta jatkamme asiaankuuluvien resurssien valmistelua T+30min, ensimmäinen tietokantamme palautetaan T+40min, toinen tietokantamme palautetaan T+1h, kaikki niihin liittyvät ydininfrat, RDS/ES/Redis, ovat valmiustilassa ja optimointivaihtoehdot, kuten master-slave, asetetaan tuotantoarkkitehtuurin mukaan. Samalla aloitamme myös uusien palveluiden lanseerauksen uusissa klustereissa Onneksi AWS:n kaatuminen ei lopulta vaikuttanut kaikkiin palveluihimme. Meidän ei tarvitse käsitellä monimutkaisia tietojen korjaustöitä liikenteen vaihtamisen jälkeen Noin T+2h ja T+3h jälkeen ilmoitin virallisesti koko henkilökunnalle ja hätätila kumottiin. Varmuuden vuoksi olemme edelleen kiinni esiintyäksemme tänä iltana. Kun katson taaksepäin koko tapausta, olisin voinut tehdä enemmän 1. Paljasta itselleni laatimani äärimmäisen tapauksen SOP kaikille työntekijöille. Tämä varmistaa, että vaikka en olisikaan verkossa, joku voi ottaa paikkani 2. Voimme tehdä joitain ennakkoharjoituksia 3. Tilaukset voivat olla ratkaisevampia Siinä melkein se, pieni jakaminen, toivottavasti se voi auttaa kaikkia