Să trecem în revistă pe scurt câteva dintre operațiunile AWS ca AIGC Startup SRE, sper că poate ajuta pe toată lumea De la începutul onboarding-ului pentru a descoperi că clusterul nostru principal era USE1, am început să fac câteva pregătiri. Acestea sunt principalele lucruri pe care le fac 1. Mai multe dintre bazele noastre de date de bază au fost salvate în mai multe locuri, formând copii de rezervă USE1, Tokyo și SG. În acest fel, în cazuri extreme, pierdem o parte din date, dar putem asigura și continuarea serviciului 2. Reconstruiți clusterul nostru de testare SG de la EC2 original K3S la un cluster AWS EKS standard. Acest lucru vă permite să încălziți rapid un cluster în caz de dezastru și să reutilizați componentele AWS existente. Minimizați costul modificărilor manifeste 3. Sortați pe scurt un SOP, inclusiv anunțurile utilizatorilor, comutarea DNS, blocarea versiunilor etc Astăzi, la aproximativ 10 minute după incidentul AWS, am descoperit că existau capsule noi în containerele noastre care nu puteau fi configurate. După ce am confirmat cu AWS Support că este o problemă USE1, mi-am dat seama că evenimentele ECR trebuie să fie legate de restul evenimentelor, așa că am decis să încep să gestionez evenimentele de nivel 1 conform propriului meu plan (pentru SRE, este mai bine să greșești decât să ratezi) T+0 min, am emis un anunț pentru tot personalul și am început să intru în modul de urgență. Am stabilit o întâlnire publică generală. Toți oamenii se pot alătura oricând T+2 min, am confirmat că evenimentul se extinde treptat așa cum mă așteptam și am dat două instrucțiuni, 1. Interzicerea oricărei fuziuni/comiteri de cod pe toată linia (în principal pentru a preveni resursele nou create să provoace rotația podurilor pentru a afecta traficul), 2. Vă rugăm să pregătiți un anunț pentru studenții operați T+3 min, am început să urmăresc SOP, am început recuperarea bazei de date în regiunea SG și am făcut cascadă pentru a crea dependențe precum OpenSearch/Redis etc T+5 min, am început să confirmăm oficial problemele specifice ale dependențelor din amonte și din aval și am confirmat că un serviciu de bază nou lansat a fost afectat T+10min, vor fi emise anunțul nostru de suspendare a serviciului și anunțul afectat pentru restul serviciilor T+10min, am rugat alte două persoane să ajute la configurarea noului ECR și la curățarea resurselor existente în mediul de testare în același timp, și la sincronizarea CTO-ului, în cazuri extreme, putem avea decizia de a păstra experiența și de a pierde date. T+15min, am confirmat în sfârșit că resursele create până acum și direcția de intrare a traficului nu vor fi afectate foarte mult. Trecerea este în așteptare, dar continuăm să pregătim resursele relevante T+30min, prima noastră bază de date este restaurată T+40min, a doua noastră bază de date este restaurată T+1h, toate infrastructurile noastre de bază asociate, RDS/ES/Redis sunt în stand-by, iar opțiunile de optimizare, cum ar fi master-slave, sunt setate în funcție de arhitectura de producție. În același timp, începem să lansăm noi servicii în noi clustere Din fericire, în cele din urmă, blocarea AWS nu a afectat toate serviciile noastre. Nu trebuie să ne ocupăm de lucrări complexe de reparare a datelor după comutarea traficului După aproximativ T+2h până la T+3h, am anunțat oficial tot personalul și starea de urgență a fost ridicată. Pentru a fi în siguranță, vom fi în continuare închise pentru a juca în această seară. Privind înapoi la întregul incident, aș fi putut face mai mult 1. Dezvăluiți tuturor angajaților SOP-ul cazului extrem pe care l-am pregătit pentru mine. Acest lucru asigură că, chiar dacă nu sunt online, cineva îmi poate lua locul 2. Putem face niște exerciții avansate 3. Comenzile pot fi mai decisive Aproape atât, un pic de împărtășire, sper că poate ajuta pe toată lumea