“Chaos to najniebezpieczniejsza rzecz na tym świecie… również bardzo potężne narzędzie. Bez kontroli, chaos cię zniszczy.”
Niektórzy z was pewnie rozpoznają powyższy cytat z Wiedźmina. Niestety w mojej prezentacji nie będzie smoków, czy demonów.
Może zaskakiwać jak chaos opisywany w Wiedźminie dobrze wpisuje się w świat wytwarzania oprogramowania. Szczególnie tego rozproszonego.
Pracując nad rozwiązaniami rozproszonymi, skalujący się, aby obsłużyć coraz to większy zapotrzebowanie, można być pewnym jednej rzeczy. Wszystko złego co się może wydarzyć, wydarzy się na pewno, jeżeli nie jest już w trakcie. Mówi nam o tym prawo wielkich liczb.
Nasz system jest w ciągłym stanie awarii. Świadomi rzeczywistości, mamy trzy ścieżki do wyboru.
Najprostsza. Zignorowanie problemu. Akceptujemy ryzyko totalnego przestoju, modląc się by wszechświat był po naszej stronie.
Niepraktyczna. Wpadamy w paraliż decyzyjny. Staramy się zaimplementować nasz system w taki sposób, aby był w stanie poradzić sobie z każdą nieprzewidzianą sytuacją. Gdzie jego zmiana jest praktycznie niemożliwa.
W końcu pragmatyczna. Akceptujemy stan rzeczy i wykorzystujemy go na swoją korzyść. Zaczynamy zagłębiać się w nasz system. Eksplorujemy chaos. Eksperymentujemy, by zaobserwować niepożądaną reakcję. Wyprzedzić realia produkcyjne.
Jak Wiedźmin (ale serio… to już ostatni raz jak o nim wspominam), przeprowadzę was ścieżką pragmatyczną. Wprowadzę w Chaos Engineering. Opowiem czym jest. Jak się w to gra. Jakie typy ćwiczeń możecie przeprowadzić w swoich zespołach, aby uzyskać przewagę nad chaosem i trochę lepiej go kontrolować. Jako, że chaos jest potężny, a nasze systemy skomplikowane, opowiem również o tym jak być przygotowanym na przegraną z żywiołem. Czy jest root cause analysis, jak pomaga failure culture, dostęp do playbook, świadomość you build it you run it.
Obawiasz się, że prezentacja będzie za “mało techniczna”. Nie martw się. Jeżeli ceremonie nie są twoim konikiem, przedstawię też narzędzia oraz typy ataków, do których można je wykorzystać.