Czym jest inżynieria chaosu i dlaczego jest ważna?

Dlaczego inżynieria chaosu jest ważna? Przyjrzyjmy się najpierw temu, dlaczego w ogóle istnieje zapewnienie jakości (QA). 

Najprościej mówiąc, QA istnieje, ponieważ niezależnie od tego, jak bardzo staramy się tworzyć doskonałe oprogramowanie, które zawsze działa tak, jak zostało zaprojektowane i powinno działać, rzeczywisty świat zdaje się na to nie pozwalać. 

Wkradają się błędy. Maszyny interpretują nasz kod inaczej, niż zamierzaliśmy. Różne rzeczy się zdarzają. Inżynieria jakości ma na celu wykrywanie tych niezamierzonych problemów, zanim zrobią to nasi klienci. 

Czym jest inżynieria chaosu?

Inżynieria chaosu to metodyczne podejście do identyfikowania potencjalnych awarii, zanim doprowadzą one do przestojów. W ramach inżynierii chaosu projektuje się eksperymenty polegające na celowym wprowadzaniu awarii, a następnie porównuje się przewidywany przebieg zdarzeń z tym, co faktycznie dzieje się w systemach. Dosłownie „celowo psuje się różne rzeczy”, aby nauczyć się budować bardziej odporne systemy.

Dlaczego inżynieria chaosu jest ważna?

Ponieważ systemy się zmieniają. Tradycyjnie QA przeprowadza różnorodne testy i korzysta z różnych typów testów, aby proaktywnie wyszukiwać te problemy na długo przed tym, zanim kod trafi na środowisko produkcyjne. Testy te są przeprowadzane pod koniec procesu budowania i przed publicznym wdrożeniem kodu, zazwyczaj na środowisku etapowym lub testowym, a nie poprzez testowanie na produkcji. 

Jak dotąd wszystko działa dobrze, jeśli działamy w ramach tradycyjnego modelu tworzenia oprogramowania i modelu wdrażania. Monolityczne projekty i wdrożenia na maszynach należących do firmy zapewniają dużą kontrolę. Ta kontrola wiąże się ze stabilnością. Dzięki temu środowiska etapowe i testowe są podobne do środowisk produkcyjnych, co pozwala skutecznie przeprowadzać na nich testy.

Systemy rozproszone są inne. Chmura jest inna. Nie kontrolujemy infrastruktury. Nieustannie się zmienia. Infrastruktura zmienia się zgodnie z naszym projektem: poszczególne usługi i mikrousługi uruchamiają dodatkowe węzły obliczeniowe lub usuwają je w zależności od potrzeb, a równoważenie obciążenia dostosowuje się do tych zmian. Systemy przełączania awaryjnego dostosowują się, aby zapewnić zarządzanie ryzykiem. Ciągłe zmiany powodują nieoczekiwane, wyłaniające się zachowania. Są to zachowania, których nie zawsze potrafimy przewidzieć, ale które możemy odtworzyć i wywołać za pomocą formy testowania nazywanej inżynierią chaosu.

Testowanie musi dostosowywać się do zmian systemów

Nie jesteśmy w stanie skutecznie przetestować wszystkiego, z czym zetknie się nasz kod produkcyjny i środowisko, testując w jakimkolwiek innym środowisku. Możemy przetestować wiele rzeczy — kwestie, z którymi tradycyjne QA radzi sobie bardzo dobrze i powinno nadal sobie radzić — choć być może część z nich można teraz testować automatycznie w ramach potoku budowania. Jednak sposób, w jaki dotychczas przeprowadzaliśmy QA, nie pozwala sprawdzić, jak nasz system rozproszony zareaguje na przykład wtedy, gdy komunikacja sieciowa między magazynem danych a wieloma węzłami obliczeniowymi zostanie przeciążona, a opóźnienia wzrosną.

Nasze testy automatyczne i prowadzone przez ludzi nie uwzględniają szybko zmieniającego się środowiska produkcyjnego, w którym usługi są uruchamiane i wyłączane w zależności od zapotrzebowania. Jedynym sposobem sprawdzenia, czy system rozproszony pozostanie niezawodny w obliczu wyłaniających się zachowań powodowanych przez zmieniające się warunki produkcyjne, jest zrobienie tego, co robi się w ramach wszystkich paradygmatów testowania: wypróbowanie tego i sprawdzenie rezultatu.

Jak działa inżynieria chaosu: testowanie i nauka na podstawie awarii

Wszyscy mamy cele dotyczące dostępności. Wszyscy chcemy poprawiać wydajność. Aby to osiągnąć, musimy korzystać z każdego dostępnego zasobu, by dowiedzieć się jak najwięcej o tym, jak nasze systemy radzą sobie z awariami — niezależnie od tego, czy chodzi o niepowodzenie użytkownika przy wprowadzaniu odpowiednich danych w polu formularza, czy o awarię komponentu systemu w chmurze, który nie działa zgodnie z oczekiwaniami.

 „Co się stanie, gdy…?” to pytanie, które wszyscy uwielbiamy zadawać. Następnie próbujemy i sprawdzamy rezultat.

Ponieważ nasze systemy i projekty systemów ewoluowały w tak bezprecedensowy sposób, musimy również rozwijać nasze metody testowania, aby lepiej rozumieć, jak nasze systemy rozproszone poradzą sobie z awariami oraz jak awarie komponentów i zależności wpływają na cały system. Testowanie całościowe tego rodzaju jest tym, do czego służy inżynieria chaosu, ponieważ umożliwia testowanie całego systemu w takiej postaci, w jakiej istnieje on na środowisku produkcyjnym.

Program inżynierii chaosu zaczyna się od małych kroków — testowania rzeczy, które już znamy lub sądzimy, że znamy:

• Czy nasz system monitorowania aktywnie wykryje opóźnienia sieciowe przekraczające określony próg? 
• Czy spowoduje to wysłanie powiadomienia do inżyniera pełniącego dyżur lub uruchomienie automatycznego ograniczania skutków awarii? 
• Czy nasza konfiguracja z czasem uległa rozbieżności, czy nadal uruchamiamy węzły obliczeniowe zgodnie ze specyfikacją?

Jak każda instancja usługi radzi sobie podczas lekkich testów? A podczas średniego obciążenia? Dużego? Wszystkie powinny działać tak samo, a nasze równoważenie obciążenia powinno odpowiednio rozdzielać obciążenie między nimi. Co się stanie, jeśli jedna instancja zacznie otrzymywać znacznie większe obciążenie niż pozostałe, ponieważ nasza usługa równoważenia obciążenia ma problemy?

Systematyczne testowanie chaotycznych systemów przynosi kluczowe korzyści

Testujemy, korzystając z metody naukowej, zaczynając od małych kroków i działając celowo. Projektujemy wczesne eksperymenty tak, aby zminimalizować promień rażenia — zestaw usług i komponentów, na które naszym zdaniem może mieć wpływ eksperyment — oraz ograniczyć zakres parametrów eksperymentu. 

Gdy odniesiemy tutaj sukces, możemy zdecydować się na budowanie krok po kroku, zwiększając nasze zaufanie do systemu lub rozbudowując uporządkowaną listę usprawnień, które wprowadzimy. Kiedy wprowadzimy te usprawnienia i ponownie przeprowadzimy test z użyciem tego samego eksperymentu chaosu i tych samych parametrów, system przejdzie test, a my będziemy wiedzieć, że jest bardziej niezawodny niż wcześniej.

To jedyny sposób, aby dowiedzieć się, jak nasze systemy rzeczywiście radzą sobie z awariami w środowisku produkcyjnym, gdzie ostatecznie ich skutki odczują nasi klienci. Jeśli uda nam się znaleźć małe problemy teraz, zanim będą miały szansę przerodzić się w duże problemy, możemy zadbać o to, aby występowało coraz mniej awarii całego systemu.

To sprawia, że inżynieria chaosu jest niezwykle skutecznym narzędziem zapewniania niezawodności. Jest to dyscyplina, która pomaga nam osiągać w chmurze i na dużą skalę to, co wcześniej mogliśmy realizować w mniejszych, kontrolowanych środowiskach za pomocą tradycyjnego zapewniania jakości.

Ostatecznie oznacza to mniej awarii i przestojów na dużą skalę w środowisku produkcyjnym. W rzeczywistości, gdy inżynieria chaosu jest wdrażana i stosowana konsekwentnie, awarie usług i komponentów, których można spodziewać się w chaosie chmury, nie będą miały żadnego wpływu na naszych klientów. W rzeczywistości nigdy nawet nie dowiedzą się, że doszło do awarii — i to jest prawdziwy cel.

Co dalej?

Omówiłem inżynierię chaosu bardziej szczegółowo w odcinku podcastu The QA Lead z Jonathonem Wrightem.

Nota redakcyjna:

Możesz być na bieżąco z innymi podcastami i artykułami The QA Lead, zapisując się do newslettera.

Możesz także zostać członkiem, aby uzyskać dostęp do forum społeczności The QA Lead, na którym możesz dzielić się najlepszymi praktykami z innymi specjalistami QA i inżynierami jakości. Mamy nadzieję, że się tam zobaczymy!

Powiązany artykuł: 10 NAJLEPSZYCH NARZĘDZI PROGRAMOWYCH DO ZAPEWNIANIA JAKOŚCI: KOMPLETNY PRZEWODNIK