Inżynieria chaosu - czyli jak wprowadzanie kontrolowanych błędów może pomóc w projektowaniu systemów komputerowych

Chaos… kojarzy się przede wszystkim z nieładem i brakiem porządku. Skąd więc pomysł, żeby użyć założeń związanych z tą ideą i połączyć je z rozwiązaniami w chmurze obliczeniowej?

W dzisiejszym wpisie postaramy się nakreślić koncepcję “chmurowego armagedonu”, który z powodzeniem jest używany przez inżynierów Netflixa w codziennej pracy.

Inżynieria chaosu to podejście “badające” zachowania systemu w ekstremalnych i krańcowych sytuacjach, poprzez wykorzystanie koncepcji empirycznej. Koncepcja pozwala na swego rodzaju “przeprowadzenie eksperymentu”, który przyrównywany jest do czynności wykonywanych przez naukowców podczas badania zjawisk fizycznych czy społecznych.

Pozwala  na budowanie stabilnych i odpornych na awarię systemów. Daje możliwość wczesnego wykrycia problemów i usterek różnego typu, dzięki czemu ujawnionym błędom można zapobiec wcześniej i stworzyć takie rozwiązanie, które będzie na nie odporne w przyszłości. Polega na celowym wywoływaniu “zaburzeń” w funkcjonującym systemie, aby w rezultacie stworzyć jego najlepszą możliwą wersję. Dodatkowo podejście to pozwala na zgłębienie takich zdarzeń jak np. zwiększony ruch na stronie, który może stać się doskonałym przypadkiem “eksperymentalnym”.

Zatem, w czym owa technika jest lepsza od innych?

Zasadnicza różnica, jaka istnieje pomiędzy podejściami chaos testingu i rutynowymi testami systemu czy aplikacji, polega na czynniku empirycznym, który pozwala na zdobycie nowej wiedzy na temat danego systemu.

Wynik standardowego testu jest wartością binarną, która jednoznacznie określa czy testowana aplikacja zadziała prawidłowo czy też nie. Chaos testing umożliwia podjęcie nowych działań wpływających na rozwój i ulepszanie istniejącej wersji systemu. Dzięki wprowadzeniu nieoczekiwanych problemów i błędów, zmiennych empirycznych, takich jak wcześniej wspomniany zwiększony ruch na stronie, możemy sprawdzić i w konsekwencji przewidzieć działanie systemu oraz wykluczyć problemy, które będą powodowały awarie.

Źródło: Business vector created by Vectorpocket – Freepik.com

Na bazie licznych doświadczeń z testowaniem zgodnym z prezentowanym tu nurtem, w celu usprawnienia procesu chaos testingu, w 2011 roku inżynierowie pracujący w Netflixie, stworzyli narzędzie o nazwie Chaos Monkey. Jego działanie jest oparte na celowym wyłączaniu serwerów w sieci produkcyjnej serialowego giganta. Pozwala to na sprawdzenie zachowania pozostałych systemów podczas takiej kontrolowanej awarii, czyli wpływ braku lub częściowego braku działania usługi na całość systemu.

Narzędzie Netflixa początkowo było elementem zestawu narzędzi funkcjonującego pod nazwą Simian Army, które wykorzystywane było do sprawdzania niezawodności, bezpieczeństwa oraz odporności infrastruktury opartej na AWS. Aktualnie projekt został zakończony a Chaos Monkey jest rozwijany jako niezależny projekt, zgodny z założeniami metodyki DevOps. Spełnia on potrzebę ciągłego testowania, zapewniając wystarczający poziom zaufania i bezpieczeństwa systemów komputerowych. Jest jednocześnie częścią wzorca Design for failure, który ma na celu sprawdzenie odporności każdego bazowego elementu systemu (czy to oprogramowania czy sprzętu) na awarię. W 2015 r. do narzędzi chaosu dołączył Chaos Kong, który symuluje niedostępność całego regionu AWS, a w 2017 r. ich rodzina powiększyła się o Chaos Automation Platform, w skrócie ChAP, pozwalającą na wychwycenie luk w zabezpieczeniach podczas “wstrzykiwania” awarii do mikro serwisów.

Posiadając już pewną wiedzę na temat założeń i narzędzi inżynierii chaosu, możemy przejść do Reguł Chaosu. Są one wytycznymi, które pozwalają na wdrożenie tytułowego podejścia w praktyce:

1. Buduj hipotezy wokół stałego stanu rzeczy – skup się na miarodajnym wyniku systemu, a nie jego właściwościach. Ta reguła pozwala na sprawdzenie czy system faktycznie działa, a nie jak działa.
2. Zmieniaj rzeczywiste wydarzenia – nadaj priorytety zdarzeniom, mającym potencjalny wpływ na działanie systemu lub biorąc pod uwagę częstotliwość ich wystąpienia. Wydarzenia należy rozumieć jako “zmienne chaosu”, którymi są np. nagłe skoki w ruchu czy skalowanie. Nie należy z nimi łączyć takich sytuacji jak np. utrata serwerów i inne.
3. Uruchom eksperymenty na produkcji – warto eksperymentować na produkcji, aby zachować autentyczność jak i aktualność tworzonego systemu.
4. Zautomatyzuj proces eksperymentów – automatyzacja pozwala  na zachowanie ciągłości podczas eksperymentowania, jednocześnie sterując orkiestracją i analizą.
5. Minimalizuj promień wybuchu – istnieje granica tolerancji dla chwilowych negatywnych skutków eksperymentów. To one pozwalają na minimalizowanie i ograniczenie tych potencjalnych, w dużej skali.

Inżynieria chaosu, choć jest stosunkowo młodym podejściem, jest niezwykle potężną praktyką. Całkowicie zmienia sposób w jaki oprogramowanie i całe systemy są projektowane i konstruowane. W momencie kiedy reszta świata pracuje nad szybkością i elastycznością systemów, inżynieria chaosu bada sferę niepewności systemowej. Reguły Chaosu tym samym, pozwalają na szybkie wdrażanie innowacji na dużą skalę, z zapewnieniem wysokiej jakości doświadczeń dla odbiorcy.