Zawartość
- Przygotowanie do awarii
- Następne kroki
- Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
- Uczenie się i doskonalenie poprzez ćwiczenia
Źródło: pressureUA / iStockphoto
Na wynos:
Nowoczesne systemy muszą być w stanie poradzić sobie z chaosem, aby uniknąć przestojów. Dlatego ważniejsze niż kiedykolwiek jest dokładne testowanie systemów i zapewnienie ich odporności.
Pomimo naszych największych starań, aby ich uniknąć, incydenty informatyczne są nieuniknioną częścią pracy - a próby wyprzedzania wpływających na biznes przestojów stają się coraz trudniejsze. Dzisiejsze systemy są ściśle ze sobą powiązane i coraz bardziej złożone, a wraz z większą liczbą ruchomych części pojawia się więcej możliwości, aby coś poszło nie tak.
Jest to jeden z powodów, dla których coraz więcej organizacji zwraca się do mikrousług w celu zwiększenia dostępności usług i lepszej odporności na awarie. Ale chociaż są to świetne przesłanki do przełamywania monolitycznych zastosowań, mogą również potencjalnie zwiększać ryzyko awarii - o ile nie zostaną zaprojektowane wyraźnie z myślą o odporności.
Przygotowanie do awarii
Biorąc pod uwagę z natury chaotyczny charakter systemów rozproszonych, usługi powinny być rozwijane nie tylko w celu przewidywania awarii, ale także w celu automatycznego przywrócenia sprawności w przypadku awarii. Oznacza to regularne wywoływanie awarii w celu zapewnienia, że twoje systemy mogą poradzić sobie z chaosem bez zakłócania obsługi klientów końcowych. Aby to osiągnąć, potrzebujesz możliwości symulacji ruchu produkcyjnego w środowiskach testowych.
Oczywiście dobrym pomysłem jest przetestowanie odporności przed wprowadzeniem zmian w produkcji. Jeśli tego nie zrobisz, nie będziesz w stanie zweryfikować, czy Twoje usługi mogą obsługiwać zarówno średnie, jak i szczytowe obciążenia. W rzeczywistości najbezpieczniejszym zakładem jest zapewnienie, że Twój produkt poradzi sobie z dwukrotnością maksymalnej kwoty bez konieczności zwiększania skali.
Jeśli chodzi o testowanie odporności, właściwe narzędzia nie powinny przejmować się sposobem obsługi żądań, tylko że mają one ostatecznie wpływ. Pamiętaj, że pod pewnymi warunkami usługa wprowadzania danych może nie przekazać żądania do reszty systemu, ale nie zgłosić awarii. Nie ryzykuj problemów z lataniem pod radarem monitorowania, upewniając się, że w rzeczywistości ma miejsce kompleksowa walidacja. (Aby uzyskać więcej informacji, zobacz Awarie techniczne: czy możemy z nimi żyć?)
Następne kroki
Po zrozumieniu, jak usługi zachowują się pod obciążeniem, czas zacząć wprowadzać zdarzenia awarii. Podobnie jak w przypadku wszystkich testów oprogramowania, najlepiej mieć zautomatyzowane narzędzia, które umożliwiają łatwe i szybkie odtwarzanie scenariuszy, dzięki czemu można koordynować złożone zdarzenia mające wpływ na różne technologie infrastruktury. Poza możliwością weryfikacji poprawek i zmian w usługach, pozwala to na uruchamianie scenariuszy losowych awarii w dowolnym środowisku i zgodnie z harmonogramem.
Znaczące zdarzenia awarii zależą w dużej mierze od układu usług i można je sformułować, zadając konkretne pytania, które są dla Ciebie istotne. Na przykład jaki wpływ mają osoby korzystające z interfejsu, gdy baza danych staje się niedostępna przez pewien okres czasu? Czy ci użytkownicy mogą nadal poruszać się po interfejsie internetowym? Czy nadal mogą wydawać aktualizacje swoich informacji i czy aktualizacje te będą przetwarzane poprawnie, gdy baza danych będzie ponownie dostępna?
Jeśli uruchomisz wiele mikrousług, możesz zapytać, czy nastąpi awaria globalna w przypadku awarii dowolnej usługi. Lub jeśli masz mechanizm kolejkowania do buforowania komunikacji między usługami, co się stanie, gdy usługa konsumencka (lub usługi) przestaną działać? Czy użytkownicy nadal będą mogli pracować z Twoją aplikacją? Biorąc pod uwagę średnie obciążenie, ile masz czasu, zanim kolejki się przepełnią i zaczniesz tracić s?
Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
Nie możesz poprawić swoich umiejętności programistycznych, gdy nikt nie dba o jakość oprogramowania.
Po zdefiniowaniu kilku kluczowych pytań dotyczących infrastruktury możesz zacząć wymieniać różne sposoby symulowania tych awarii. Może wystarczyć zatrzymanie określonej usługi lub serwera bazy danych. Możesz zablokować główny wątek usługi, aby zasymulować zakleszczenie, podczas gdy jej kontener nadal reaguje i działa. Możesz zdecydować o wprowadzeniu reguł w swojej sieci, aby blokować ruch między określonymi usługami. W środowiskach Linux możesz używać narzędzi takich jak „tc”, aby emulować sytuacje sieciowe, takie jak duże opóźnienia, upuszczone, uszkodzone lub zduplikowane pakiety. (Może być ważne zaangażowanie użytkowników w testowanie. Przeczytaj więcej w 4 Powody, dla których użytkownicy końcowi muszą brać udział w testowaniu przed UAT).
Uczenie się i doskonalenie poprzez ćwiczenia
Jednym z najcenniejszych aspektów tworzenia scenariuszy awarii jest to, że mogą ujawnić wszystkie potencjalne sposoby awarii systemu, tworząc w ten sposób ścieżkę do logiki samoleczenia. Twój zespół wykona kroki, aby ręcznie odzyskać usługi - nawiasem mówiąc, to świetne ćwiczenie, aby potwierdzić, że są w stanie to zrobić w ramach umów SLA. Można pracować nad automatyzacją tego procesu odzyskiwania, ale w międzyczasie możesz odpocząć, wiedząc, że Twój zespół przeszedł proces przywracania usług. Ustawiając losowe i regularne scenariusze awarii i nie ujawniając pełnych szczegółów przebiegu, można także włączyć do wiercenia wykrywanie i diagnozę - która jest przecież kluczową częścią umów SLA.
U podstaw inżynierii chaosu bierze się pod uwagę złożoność systemu, testuje go, symulując nowe i zwariowane warunki, i obserwuje reakcję systemu. To zespoły inżynierii danych muszą przeprojektować i ponownie skonfigurować system, aby osiągnąć wyższą odporność. Jest tak wiele możliwości uczenia się nowych i przydatnych rzeczy. Na przykład możesz znaleźć przypadki, w których usługi nie otrzymują aktualizacji po zmianie usług podrzędnych lub obszary, w których całkowicie brakuje monitorowania. Nie brakuje ekscytujących sposobów na zwiększenie odporności i niezawodności produktu!