Wstęp
Zacznę od początku, bo na początku projektu jest (mikro)usługa, która komunikuje się z inną/innymi poprzez API. Obecnie modne w web developmencie jest REST API, jak każdy wie działające w oparciu o protokół HTTP (a ten na TCP/IP). W związku z tak niewielką zmianą sposób wymiany danych od kilkunastu lat, błędy jakie mogą się przytrafić podczas działania w takiej typowej architekturze również są powtarzalne.
Mam na myśli fakt, że architekci/programiści/testerzy popełniają te same błędy i stale jest dyskusja dlaczego. Otóż dlatego, że liczy się "metodyka zwinna" wdrażania małymi krokami, a w takich krokach kompleksowe testy wydajnościowe/wysokiej dostępności niekiedy nie mają szansy zostać zrealizowane. Często zespoły mając już na produkcji zmianę mają testy na żywym organizmie. Łatwo dojść może do kolejnego poważnego incydentu, który nie zawsze opatrzony zostanie stosownym komentarzem i wiedza o przyczynie nie zostanie przedstawiona na większym forum. Tzn. inne zespoły nie dowiedzą się wcześniej niżeli przed identycznym incydentem na swoich usługach.
Jeśli nie wiecie, to takie testy prowadzą od dawna w NASA, w wojsku i w systemach medycznych oraz automatyce przemysłowej. Tzn. po wdrożeniu systemu często generuje się tzw. chaos i obserwuje, czy odpowiednie kontrolki w monitoringu zapalają się, informując operatorów o konkretnych problemach. Mogą oni podjąć racjonalne decyzje w kwestii np: przeżycia innych członków zespołu, czyli ocalić czyjeś życie. Bo jak wiemy w wielu profesjach jesteśmy skazani na błędy maszyn i ich oprogramowania. Tak, już od wielu lat oprogramowanie stanowi element naszego życia i warto dbać o jego jakość, bo istotne jest też to, że mniej niepotrzebnych nerwów - np: z powodu wad w sofcie - u człowieka wydłuża jego życie :-) To nie jest mój wymysł, ale obserwacja zachowań kolegów po ok. 20 latach pracy w IT. Jak to niektórzy mawiają, "nie każdy jest na tyle cierpliwy, aby przeżyć awarię i odnosi to dość osobiście". Po części z tym się zgodzę, bo widziałem odejścia z pracy ludzi, którzy nie zgadzali się z bylejakością i zwyczajnie z powodów zdrowotnych rezygnowali z miejsca pracy, bo dusiło ich to, że np: nie mają wpływu na podniesienie jakości.
W obecnych czasach w IT każdy człowiek w zespole, jak również zarząd mają wpływ na jakość produktów, które tworzą lub zlecają do wytworzenia. Idąc tym tropem, pojawia się "chaos", tzn. naturalna kolej rzeczy na produkcji, jeśli nie założymy, że przetestujemy system pod kątem chaotycznego/nietypowego działania. Ba niektóre firmy doszły do takiej wprawy, że testy chaosu potrafią robić na produkcji - tak, nie jest to literówka - i poziom wysokiej dostępności, jaki osiągnęli umożliwia takie działania.
Nieco historii - pewnego pięknego dnia - ok. 10 lat temu - pojawił się arttykuł "5 Lessons We’ve Learned Using AWS" na blogu Netflix, który oświecił cały świat IT w tematyce Chaos engineering.
Od tego momentu wiele firm budujących ze świadomością swoją infrastrukturę zarówno wewnętrzną, jak i hybrydową z użyciem publicznych chmur obliczeniowych, zaczyna inaczej postrzegać jakość i wysoką dostępność. To było epokowe odkrcie, bo świat chaotycznych testów jest dość fascyjnujący :-)
Co ludziom z IT dają testy chaosu
Chaos Monkey wprowadza tutaj w pracy zespołów celowe zamieszanie, które zapewnia w sposób kontrolowany poznanie wad sprzętu / oprogramowania / protokołów a także całego stosu technicznego. Wspomaga zespoły w ich pracy, o ile nie robią same takich testów w ramach kontroli jakości.
Zasada jest prosta: spróbujmy coś wyłączyć, zmienić przepustowość, zmienić jakiś timeout, rozłączać wymagane połączenia pomiędzy serwerami / usługami i mamy "niemalże" gwarantowane problemy, na którejś z warstw naszych usług. A jednak - okazało się, że jest jeszcze jakaś praca do wykonania, aby nazwać nasz system "wysoko dostępnym".
Tak, mam tutaj na myśli automatyczne generowanie "wywrotek" różnych części systemów, aby nauczyć się w praktyce, co jeszcze należy poprawić, aby nasze produkty były odporne na różnego typu błędy. Bo w sumie klienci są zadowoleni z tego, że coś co im oferujemy działa z ich punktu widzenia a naszą rolą jako inżynierów oprogramowania jest zapewnienie im tego komfortu. Tak, pomimo, że wiemy o tym, że połowa usług w jednej serwerowni padła i nie ma szansy na działanie. Ale o tym wiemy my a nie klienci i do tego zmierzają takie testy - wychwycić braki w jakości/ciągłości działania systemów możliwe wcześnie przed awarią postrzeganą przez klientów jako niedogodność. Liczy się uśmiech każdego klienta :-)
Z technicznego punktu widzenia zapewniamy testując chaosem wiedzę o tym jak działa system w kilku ważnych wymiarach:
- dostępności (ang. Availability)
- wydajności (ang. Performance)
- zestaw powiązań (ang. Feature Set)
- integralności komponentów (ang. Components Integrity)
- integralności danych (ang. Data Integrity)
Jakiego rodzaju scenariusze testowe są najczęściej wykorzystywane?
- przełączanie bazy danych (ang. Database Colocation) - kiedy dwie różne bazy działające w trybie np: master-slave lub active-active doznają symulowanej awarii lub niestabailności
- problem z niewydajnymi zrzutami/indeksami/archiwizacją bazy danych (ang. Snapshot Impact) - kiedy wzrasta ilość zrzutów / logów / procesów archiwizacji ew. indeksacji na bazie danych
- aktualizacja klastra / supervisora / urządzenia sieciowego (ang. Rolling Upgrade) - kiedy mamy do czynienia z automatyczną aktualizacją klastra, wirrualnej maszyny, firmware na urządzeniach sieciowych
- wiele, wiele innych "niesamowirtych" zjawisk w IT ...
Jak rozpocząć chaotyczne testy w naszym systemie
Na pewno od razu, po przeczytaniu tego posta ;-)
Jeśli chodzi o testy chaosu, to zakłada się zazwyczaj jakiś plan, który uwzględnia:
- poinformowanie innych zespołów, biznesu, programistów i działu jakości + monitoringu, w jakim przedziale czasu będą odbywały się takie testy i na jakim środowisku. Szanujemy nerwy innych.
- zasymulowanie obciążenia o charakterystyce zbliżonej do PRODukcji i zaplanowanie scenariuszy, które będziemy przeprowadzali. Nie wszystko na raz, bo nie łatwo będzie nam wnioskować.
- przygotujmy sobie dedykowane metryki, KPI i wskaźniki, po których poznamy, że zaszły jakikolwiek anomalie. Tak, w pierwszej fazie nauczymy się działania naszego systemu w warunkach normalnych, aby pod testami chaosu zaobserwować i nazwać anomalie.
- umówmy się w kilka osób.zespołów, że chcemy razem to zrobić, aby innym też dać szansę na odkrycie być może swoich błędów w ich ulubionej/dziedzinowej warstwie.
- przygotować się na starcie na PRODukcji o ile na innych środowiskach jest wszystko w porządku i jak najbardziej w godzinach pracy zaplanować takie testy
- koniecznie jest utworzenie formalnego raportu z testów i podzielić się nim z całą firmą, aby wiedza rozpropagowała się po znakomitej większości ludzi odpowiedzialnych. Świadomość jest cenniejsza, kiedy mamy dla ludzi lekkostrawne dane, które łatwo odczytają/odnajdą. Nie chodzi mi tylko o geeków, ale też o biznes, który może być nieświadomy np: długu technicznego.
- stałe dyskusje, szkolenia. rozwój wiedzy technicznej zespołów i uświadamianie o typach awarii ludzi od biznesu - to jest stały element branży IT
Tak dla pełnej jasności, ten artykuł ma na celu zwrócenie Waszej uwagi na metodologię testów chaosu i wprowadzenie do tematu. Nie zachęcam nikogo do wystartowania takich testów bez porozumienia z liderami technicznymi i bieznesem. Wszelkie działania, jakich dokonacie po przeczytaniu tego artykułu wykonujcie z pełną odpowiedzialnością i świadomością konsekwencji (tzn. prawdopodobnej awarii lub niedostępności biznesu).
Jakie narzędzia mamy do dyspozycji
Temat jest na tyle wartościowy, że celowo nie będę tutaj przeklejał linków a podam dwa źródła, jakie rozwinął Waszą wiedzę z tego obszaru. Oto otwiera się przed wami nieskończony ocean chaosu :-)
Jeśli macie jakiekolwiek doświadczenie z testami chaosu i pozwalacie na takie praktyki piszcie, jak postrzegacie ten art., co odkryliście ciekawego dzięki tej metodzie testowania.
Otwieram dyskusję na ten temat w komentarzach.
Posty
