Notatka. przeł.: Artykuł ten stanowi kontynuację świetnej serii artykułów Adriana Hornsby’ego, ewangelisty technologii AWS, który stara się w prosty i jasny sposób wyjaśnić znaczenie eksperymentów w łagodzeniu konsekwencji awarii w systemach IT.
„Jeśli nie przygotujesz planu, planujesz porażkę”. - Benjamin Franklin
В W tej serii artykułów przedstawiłem koncepcję inżynierii chaosu i wyjaśniłem, w jaki sposób pomaga ona znaleźć i naprawić błędy w systemie, zanim doprowadzą one do awarii produkcyjnej. Omówiono także, w jaki sposób inżynieria chaosu promuje pozytywne zmiany kulturowe w organizacjach.
Na koniec pierwszej części obiecałem porozmawiać o „narzędziach i metodach wprowadzania awarii do systemów”. Niestety, moja głowa miała w tym względzie własne plany i w tym artykule postaram się odpowiedzieć na najpopularniejsze pytanie, które pojawia się wśród osób chcących zająć się inżynierią chaosu: Co najpierw złamać?
Świetne pytanie! Jednak nie wydaje się, żeby ta panda szczególnie go przejmowała...
Nie zadzieraj z pandą chaosu!
Krótka odpowiedź: Kieruj usługi krytyczne na ścieżce żądania.
Dłuższa, ale jaśniejsza odpowiedź: Aby zrozumieć, od czego zacząć eksperymentowanie z chaosem, zwróć uwagę na trzy obszary:
- Obejrzyj historia awarii i identyfikować wzorce;
- Decyzję w sprawie zależności krytyczne;
- Skorzystaj z tzw efekt nadmiernej pewności siebie.
To zabawne, ale tę część można równie dobrze nazwać „Podróż do samopoznania i oświecenia”. W nim zaczniemy „bawić się” kilkoma fajnymi instrumentami.
1. Odpowiedź leży w przeszłości
Jeśli pamiętacie, w pierwszej części przedstawiłem koncepcję korekcji błędów (COE) – metodę, za pomocą której analizujemy nasze błędy – błędy technologiczne, procesowe czy organizacyjne – w celu zrozumienia ich przyczyny i zapobieżenia powtórzenie w przyszłości. Generalnie od tego warto zacząć.
„Aby zrozumieć teraźniejszość, trzeba poznać przeszłość”. — Carla Sagana
Przyjrzyj się historii awarii, oznacz je w COE lub sekcjach zwłok i sklasyfikowaj. Zidentyfikuj typowe wzorce, które często prowadzą do problemów, i w przypadku każdego COE zadaj sobie następujące pytanie:
„Czy można było to przewidzieć i w ten sposób zapobiec temu za pomocą wstrzykiwania usterek?”
Pamiętam jedną porażkę na początku mojej kariery. Można by temu łatwo zapobiec, gdybyśmy przeprowadzili kilka prostych eksperymentów z chaosem:
W normalnych warunkach instancje backendu odpowiadają na kontrole stanu ). ELB używa tych kontroli do przekierowywania żądań do sprawnych instancji. Kiedy okaże się, że instancja jest „niezdrowa”, ELB przestaje wysyłać do niej żądania. Pewnego dnia, po udanej kampanii marketingowej, natężenie ruchu wzrosło, a backendy zaczęły wolniej niż zwykle reagować na kontrole stanu. Należy powiedzieć, że te kontrole stanu zdrowia były , czyli sprawdzono stan zależności.
Jednak przez jakiś czas wszystko było w porządku.
Następnie, już w dość stresujących warunkach, jedna z instancji zaczęła wykonywać niekrytyczne, regularne zadanie cron ETL. Połączenie dużego ruchu i cronjob spowodowało, że wykorzystanie procesora osiągnęło prawie 100%. Przeciążenie procesora jeszcze bardziej spowolniło odpowiedzi na kontrole stanu do tego stopnia, że ELB zdecydował, że w instancji występują problemy z wydajnością. Zgodnie z oczekiwaniami, balanser przestał dystrybuować do niego ruch, co z kolei doprowadziło do wzrostu obciążenia pozostałych instancji w grupie.
Nagle wszystkie inne instancje również zaczęły nie przechodzić kontroli stanu zdrowia.
Uruchomienie nowej instancji wymagało pobrania i zainstalowania pakietów i trwało znacznie dłużej, niż wyłączenie ich - jeden po drugim - w grupie autoskalowania zajęło ELB. Oczywiste jest, że wkrótce cały proces osiągnął punkt krytyczny i aplikacja uległa awarii.
Wtedy na zawsze zrozumieliśmy następujące punkty:
- Instalowanie oprogramowania podczas tworzenia nowej instancji zajmuje dużo czasu; lepiej jest preferować podejście niezmienne i .
- W trudnych sytuacjach priorytetem powinny być odpowiedzi na kontrole stanu i ELB – ostatnią rzeczą, jakiej chcesz, jest komplikowanie życia pozostałym przypadkom.
- Lokalne buforowanie kontroli stanu bardzo pomaga (nawet na kilka sekund).
- W trudnej sytuacji nie uruchamiaj zadań cron i innych niekrytycznych procesów - oszczędzaj zasoby na najważniejsze zadania.
- Podczas automatycznego skalowania używaj mniejszych instancji. Lepsza jest grupa 10 małych okazów niż grupa 4 dużych; w przypadku awarii jednego wystąpienia, w pierwszym przypadku 10% ruchu zostanie rozłożone na 9 punktów, w drugim - 25% ruchu na trzy punkty.
W ten sposób czy można było to przewidzieć i w związku z tym zapobiec temu problemowi?
Taki na kilka sposobów.
Po pierwsze, symulując wysokie użycie procesora za pomocą narzędzi takich jak lub :
❯ stress-ng --matrix 1 -t 60s
stres-ng
Po drugie, przeciążając instancję i inne podobne narzędzia:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperymenty są stosunkowo proste, ale mogą dać dobry materiał do myślenia bez konieczności przechodzenia przez stres związany z prawdziwą porażką.
jednak nie poprzestawaj na tym. Spróbuj odtworzyć awarię w środowisku testowym i sprawdź swoją odpowiedź na pytanie „Czy można było to przewidzieć i w związku z tym zapobiec temu, wprowadzając usterkę?" To mini eksperyment z chaosem w ramach eksperymentu z chaosem, mający na celu sprawdzenie założeń, ale zaczynający się od porażki.
Czy to był sen, czy to wydarzyło się naprawdę?
Dlatego przestudiuj historię niepowodzeń, przeanalizuj EOC, oznacz je i sklasyfikowaj według „promienia trafienia” – a dokładniej liczby klientów, których to dotyczy – a następnie poszukaj wzorców. Zadaj sobie pytanie, czy można było to przewidzieć i zapobiec temu, wprowadzając problem. Sprawdź swoją odpowiedź.
Następnie przejdź do najpopularniejszych wzorów o największym zakresie.
2. Zbuduj mapę zależności
Poświęć chwilę na przemyślenie swojej aplikacji. Czy istnieje przejrzysta mapa jego zależności? Czy wiesz, jaki wpływ będą miały, jeśli wystąpi awaria?
Jeśli nie jesteś zbyt zaznajomiony z kodem aplikacji lub jest on bardzo duży, zrozumienie, co robi kod i jakie są jego zależności, może być trudne. Zrozumienie tych zależności i ich możliwego wpływu na aplikację i użytkowników ma kluczowe znaczenie, aby wiedzieć, od czego zacząć inżynierię chaosu: punktem wyjścia jest komponent o największym promieniu uderzenia.
Identyfikowanie i dokumentowanie zależności nazywa się „budowanie mapy zależności» (mapowanie zależności). Zwykle robi się to w przypadku aplikacji z dużą bazą kodu przy użyciu narzędzi do profilowania kodu. (profilowanie kodu) i oprzyrządowanie (oprzyrządowanie). Mapę można także zbudować, monitorując ruch sieciowy.
Jednak nie wszystkie zależności są takie same (co dodatkowo komplikuje proces). Niektóre krytyczny, Inny - wtórny (przynajmniej teoretycznie, ponieważ awarie często występują z powodu problemów z zależnościami, które uznano za niekrytyczne).
Bez krytycznych zależności usługa nie może działać. Zależności niekrytyczne ”nie powinieneś» aby wpłynąć na obsługę w przypadku upadku. Aby zrozumieć zależności, musisz dobrze rozumieć interfejsy API używane przez aplikację. Może to być o wiele trudniejsze, niż się wydaje – przynajmniej w przypadku dużych zastosowań.
Zacznij od przejrzenia wszystkich interfejsów API. Zaznacz najbardziej istotny i krytyczny. Brać зависимости z repozytorium kodu, sprawdź to logi połączeń, a następnie obejrzyj dokumentacja (oczywiście, jeśli istnieje - w przeciwnym razie nadal maszоwiększe problemy). Skorzystaj z narzędzi, aby profilowanie i śledzenie, odfiltruj połączenia zewnętrzne.
Możesz skorzystać z programów np netstat - narzędzie wiersza poleceń wyświetlające listę wszystkich połączeń sieciowych (aktywnych gniazd) w systemie. Na przykład, aby wyświetlić listę wszystkich bieżących połączeń, wpisz:
❯ netstat -a | more
W AWS możesz używać (logi przepływu) VPC to metoda, która pozwala zbierać informacje o ruchu IP przychodzącym lub wychodzącym z interfejsów sieciowych w VPC. Takie logi mogą pomóc także w innych zadaniach - na przykład w znalezieniu odpowiedzi na pytanie, dlaczego dany ruch nie dociera do instancji.
Możesz także użyć . Rentgen pozwala uzyskać szczegółowe, „ostateczne” (koniec końców) przegląd żądań przechodzących przez aplikację, a także tworzy mapę podstawowych komponentów aplikacji. Bardzo wygodne, jeśli chcesz zidentyfikować zależności.
Konsola rentgenowska AWS
Mapa zależności sieciowych jest tylko rozwiązaniem częściowym. Tak, pokazuje, która aplikacja komunikuje się z którą, ale są też inne zależności.
Wiele aplikacji używa DNS do łączenia się z zależnościami, podczas gdy inne mogą korzystać z wykrywania usług lub nawet zakodowanych na stałe adresów IP w plikach konfiguracyjnych (np. /etc/hosts).
Możesz na przykład stworzyć przez iptables i zobacz co się psuje. Aby to zrobić, wpisz następujące polecenie:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Czarna dziura DNS
Jeśli jest /etc/hosts lub inne pliki konfiguracyjne, znajdziesz adresy IP, o których nic nie wiesz (tak, niestety, to też się zdarza), możesz znów przyjść z pomocą iptables. Powiedzmy, że odkryłeś 8.8.8.8 i nie wiesz, że jest to adres publicznego serwera DNS Google. Używając iptables Możesz zablokować ruch przychodzący i wychodzący na ten adres za pomocą następujących poleceń:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Zamknięcie dostępu
Pierwsza reguła usuwa wszystkie pakiety z publicznego DNS Google: ping działa, ale pakiety nie są zwracane. Druga reguła odrzuca wszystkie pakiety pochodzące z Twojego systemu do publicznego DNS Google – w odpowiedzi na ping dostajemy Operacja nie jest dozwolona.
Uwaga: w tym konkretnym przypadku lepiej byłoby użyć whois 8.8.8.8, ale to tylko przykład.
Możemy zejść jeszcze głębiej do króliczej nory, ponieważ wszystko, co korzysta z protokołów TCP i UDP, w rzeczywistości zależy również od protokołu IP. W większości przypadków IP jest powiązane z ARP. Nie zapomnij o firewallach...
Jeśli weźmiesz czerwoną pigułkę, zostaniesz w Krainie Czarów, a ja pokażę ci, jak głęboka jest królicza nora.
Bardziej radykalne podejście polega na rozłączyć samochody jeden po drugim i zobacz, co jest zepsute... zostań „małpą chaosu”. Oczywiście wiele systemów produkcyjnych nie jest zaprojektowanych do takiego ataku typu brute-force, ale przynajmniej można go wypróbować w środowisku testowym.
Budowa mapy zależności jest często bardzo długotrwałym przedsięwzięciem. Niedawno rozmawiałem z klientem, który spędził prawie 2 lata na opracowaniu narzędzia, które półautomatycznie generuje mapy zależności dla setek mikrousług i poleceń.
Wynik jest jednak niezwykle interesujący i użyteczny. Dowiesz się wiele o swoim systemie, jego zależnościach i operacjach. Jeszcze raz uzbrój się w cierpliwość: najważniejsza jest sama podróż.
3. Uważaj na nadmierną pewność siebie
„Kto o czym marzy, ten w to wierzy.” — Demostenes
Czy kiedykolwiek słyszałeś o efekt nadmiernej pewności siebie?
Według Wikipedii efekt nadmiernej pewności siebie to „błąd poznawczy, polegający na tym, że pewność danej osoby co do swoich działań i decyzji jest znacznie większa niż obiektywna trafność tych ocen, zwłaszcza gdy poziom pewności jest stosunkowo wysoki”.
Oparta na instynkcie i doświadczeniu...
Z mojego doświadczenia mogę powiedzieć, że to zniekształcenie jest świetną wskazówką, od czego zacząć inżynierię chaosu.
Uważaj na zbyt pewnego siebie operatora:
Charlie: „To coś nie upadło od pięciu lat, wszystko jest w porządku!”
Crash: „Czekaj… Zaraz tam będę!”
Uprzedzenie będące konsekwencją nadmiernej pewności siebie jest rzeczą podstępną, a nawet niebezpieczną ze względu na różne czynniki, które na nią wpływają. Jest to szczególnie prawdziwe, gdy członkowie zespołu włożyli całe swoje serce w technologię lub spędzili dużo czasu na jej „naprawianiu”.
Podsumowując
Poszukiwanie punktu wyjścia dla inżynierii chaosu zawsze przynosi więcej rezultatów, niż się spodziewano, a zespoły, które zbyt szybko zaczynają coś psuć, tracą z oczu bardziej globalną i interesującą istotę (chaos-)Inżynieria - kreatywne wykorzystanie metody naukowe и dowody empiryczne do projektowania, rozwoju, obsługi, konserwacji i ulepszania systemów (oprogramowania).
Na tym kończy się druga część. Proszę pisać recenzje, dzielić się opiniami lub po prostu klaskać . W kolejnej części I naprawdę Rozważę narzędzia i metody wprowadzania awarii do systemów. Dopóki!
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com