Proszę o krótkie podsumowanie wydarzenia AWS jako kilka działań SRE w AIGC Startup, mam nadzieję, że to pomoże wszystkim. Od momentu zatrudnienia zauważyłem, że nasze główne klastry znajdują się w USE1, więc zacząłem robić pewne przygotowania. Oto kilka rzeczy, które zrobiłem: 1. Wykonałem wieloletnie kopie zapasowe naszych kluczowych baz danych, tworząc kopie w USE1, Tokio i SG. W ten sposób, w ekstremalnych sytuacjach, stracimy część danych, ale będziemy mogli zapewnić ciągłość usług. 2. Przekształciłem nasz klaster testowy w SG, który wcześniej był prostym K3S na EC2, w standardowy klaster AWS EKS. Dzięki temu w przypadku katastrofy możemy szybko uruchomić klaster, ponownie wykorzystując istniejące komponenty AWS. Zmiana manifestu została zminimalizowana. 3. Przygotowałem prostą SOP, która zawiera ogłoszenia dla użytkowników, przełączanie DNS, zamknięcie wersji itp. Wracając do dzisiaj, około 10 minut po wystąpieniu incydentu AWS, zauważyłem, że w naszych kontenerach są nowe Pod, które nie mogą się skonfigurować. Po potwierdzeniu z pomocą AWS, że to problem z USE1, zdałem sobie sprawę, że zdarzenie ECR musi być powiązane z innymi zdarzeniami, więc zdecydowanie zacząłem działać zgodnie z moim planem na poziomie incydentu Tier1 (dla SRE takie sytuacje lepiej pomylić, niż przegapić). T+0 min, ogłosiłem wszystkim, że wchodzimy w tryb awaryjny. Ustawiłem publiczne spotkanie dla wszystkich. Wszyscy mogą dołączyć w dowolnym momencie. T+2 min, potwierdziłem, że incydent rozwija się zgodnie z moimi przewidywaniami, więc wydałem dwa polecenia: 1. Całkowity zakaz wprowadzania jakiegokolwiek kodu/commitów (głównie aby uniknąć tworzenia nowych zasobów, co mogłoby spowodować rotację Podów i wpłynąć na ruch), 2. Proszę zespół operacyjny o przygotowanie ogłoszenia. T+3 min, zaczynam działać zgodnie z SOP, rozpoczynam przywracanie bazy danych w regionie SG oraz tworzenie zależności, takich jak OpenSearch / Redis itp. T+5 min, zaczynamy formalnie potwierdzać konkretne problemy z zależnościami w górę i w dół, potwierdzając, że nowo uruchomiona kluczowa usługa została dotknięta. T+10 min, ogłoszenie o zatrzymaniu usług oraz ogłoszenie o wpływie na inne usługi zostały wydane. T+10 min, proszę dwóch innych współpracowników o pomoc w skonfigurowaniu nowego ECR oraz oczyszczeniu istniejących zasobów w środowisku testowym, a także informuję CTO, że w ekstremalnych przypadkach możemy podjąć decyzję o zachowaniu doświadczenia kosztem utraty danych. T+15 min, ostatecznie potwierdzamy, że obecnie utworzone zasoby oraz kierunek ruchu nie będą miały dużego wpływu. Plan przełączenia wstrzymany, ale kontynuujemy przygotowania odpowiednich zasobów. T+30 min, nasza pierwsza baza danych została przywrócona. T+40 min, nasza druga baza danych została przywrócona. T+1h, wszystkie nasze powiązane kluczowe infrastruktury, RDS/ES/Redis są w trybie gotowości, a także ustawiamy opcje optymalizacji, takie jak główny i podrzędny. Równocześnie zaczynamy uruchamiać nowe usługi w nowym klastrze. Na szczęście, ostatecznie awaria AWS nie wpłynęła na wszystkie nasze usługi. Nie musimy stawiać czoła skomplikowanej pracy naprawczej po przełączeniu ruchu. Około T+2h do T+3h, oficjalnie informuję wszystkich, że stan awaryjny został zniesiony. Dla bezpieczeństwa, dzisiaj nadal zamykamy wersje funkcji. Podsumowując całe zdarzenie, mogłem zrobić więcej: 1. Upublicznić SOP dla ekstremalnych przypadków, które wcześniej przygotowałem dla siebie. W ten sposób zapewniam, że nawet jeśli nie jestem online, ktoś może mnie zastąpić. 2. Możemy przeprowadzić pewne wcześniejsze ćwiczenia. 3. Polecenia mogą być wydawane bardziej zdecydowanie. To mniej więcej wszystko, kilka uwag, mam nadzieję, że to pomoże wszystkim.