Z pamiętnika Inżyniera Wydajności

Czy zastanawiałeś się kiedyś, jak wyglądałby świat, w którym nikt nie przejmowałby się wydajnością?

Wyobrażacie sobie na przykład, że Wasza poranna kawa nie wypływa z ekspresu zaraz po naciśnięciu przycisku, a dopiero po godzinie? Co byście czuli, gdyby ulubione lody w lodziarni trzeba było zamówić kilka dni wcześniej?

Potraficie zrozumieć, jak żyli ludzie w czasach, gdy podróżowało się pieszo albo konno, a przebycie kilkunastu czy kilkudziesięciu kilometrów zajmowało wiele godzin lub nawet dni?

Dlaczego wybrałem tę ścieżkę?

Zajmuję się wydajnością w informatyce od 15 lat, ale zanim jeszcze zorientowałem się, że informatyka to coś więcej niż składanie komputerów z podzespołów kupionych w sklepie, już wiedziałem, że tamte czasy nie są dla mnie. Od zawsze dostrzegałem detale, które nie pasowały do całości i oczekiwałem więcej od rzeczy, których używałem. Dlatego moja ścieżka kariery od samego początku skierowała się na tory testowania i to w trybie ekspresowym!

Rozsiądźcie się wygodnie i pozwólcie, że zabiorę Was w podróż w czasie. Opowiem, jak wyglądała moja przygoda, podczas której dbałem o to, żeby nasze systemy spełniały oczekiwania użytkowników.

Czasy Starożytne ­i pierwszy błąd wydajnościowy

Wspomniałem już, że wydajnością zajmuję się od naprawdę długiego czasu. Ledwie odkryłem, że jest wiele języków programowania, a kod potrafi więcej niż tylko wydrukować na ekranie „Hello World”, a już wylądowałem w wydziale, który dumnie nazywał się Quality Assurance.

Stałem się tym samym strażnikiem jakości. Mając doświadczenie zdobyte przez cztery lata na studiach, czułem się przygotowany do tego, aby wytykać błędy innym. Już po trzech miesiącach pracy i ze statystyką na poziomie 95% odrzuconych defektów zrozumiałem, że testy funkcjonalne nie są i raczej nie staną się moją dziedziną na całe życie. Wymagałem bowiem od testowanych systemów znacznie więcej niż opisująca je dokumentacja.

Do tego nic mnie tak nie wyprowadzało z równowagi, jak powtarzanie tych samych scenariuszy testowych w kółko, udowadniając, że te pozostałe 5% błędów nadal występuje, mimo, że system został zrestartowany, a u programisty wszystko działa. Gdy moje zdrowie psychiczne było już na skraju wytrzymałości, zacząłem automatyzować swoje testy.

Dziś, patrząc na to co wydarzyło się chwilę później, nie mogę uwierzyć w taki zbieg okoliczności. System, za testy którego byłem wówczas odpowiedzialny, nie wytrzymał intensywności moich testów automatycznych.

Wolę nawet nie myśleć, na czyjej kozetce dziś opowiadałbym o swoich doświadczeniach z młodości, gdybym wówczas, zaintrygowany awarią, jaką wywołałem, nie zaczął dociekać, co się stało, dlaczego system zachował się tak, a nie inaczej i co to znaczy, że doszło do wycieku pamięci… Tak oto znalazłem swój pierwszy błąd wydajnościowy i stałem się pierwszym testerem wydajności w organizacji.

Średniowiecze, czyli za długi czas odpowiedzi i „potencjalnie wąskie gardło”

Z błogosławieństwem swoich zwierzchników, zacząłem testy wydajności. Ten okres jest najtrudniejszy do opisania. Z jednej strony pamiętam, jak bardzo cieszyłem się wówczas, że sam sobie byłem sterem, statkiem i okrętem. Z drugiej jednak w Internecie nie było wielu informacji o testach wydajnościowych, nie było setek filmików i instrukcji o tym, jak testować daną technologię. Jeśli pamięć mnie nie myli, do dyspozycji były wówczas trzy narzędzia, z czego tylko jedno umiałem uruchomić.

Małymi krokami odkrywałem, jak tworzyć testy wydajnościowe i uczyłem się na własnych błędach. Do dziś wstydzę się, jak mocno upierałem się wtedy przy tym, że testy wydajnościowe należy wykonywać tylko na skończonym systemie i tylko na produkcji. Kosztowało to mnie i administratorów wiele zarwanych nocy, podczas których zmuszeni byli wspierać moje fanaberie na temat testów nocnych.

Szczególnie, że wówczas moje testy opierałem wyłącznie na czasach odpowiedzi i ciągłych pytaniach np. „Dlaczego w 53 minucie testu system nagle zaczął odpowiadać znacznie dłużej?”. Po jakimś czasie testy robiłem już sam, a rano dostawałem w arkuszach zestaw danych, które zbierane były z serwerów. W moich raportach poza czasami odpowiedzi pojawiły się jeszcze statystyki z obciążenia procesora, zużycia pamięci, utylizacji dysków czy sieci. Zacząłem również nadużywać zdania: „Potencjalne wąskie gardło”.

Wówczas myślałem, że osiągnąłem już szczyt diagnostyki wydajności. Przez wiele lat wykonywałem testy wydajnościowe coraz to nowszych technologii, które pojawiały się jak grzyby po deszczu, a każda z nich była coraz trudniejsza w testowaniu. Wciąż jednak wysyłałem wyniki, opisując „potencjalne wąskie gardła”. Pękałem z dumy, gdy udało mi się tak uzasadnić moje przypuszczenia, że wdrożenia były opóźniane o kolejne miesiące, podczas których ja wykonywałem kolejne iteracje tych samych testów i produkując setki stron raportów, przygotowując i analizując każdy wykres, statystykę i miarę ręcznie.

Nowożytność i wywrócenie przekonań do góry nogami

Systemy zaczynają rozwijać się zwinnie, znika podział między ich rozwojem a utrzymaniem. Na pierwszą linię walki z wydajnością i stabilnością systemów wychodzą różne narzędzia wspierające ich monitoring. Z dotychczas zbieranych kilku metryk i przekonania, że Garbage Collector to tylko mityczny stwór nawiedzający aplikacje napisane w Javie, wyrywają mnie narzędzia typu Application Performance Management.

Setki statystyk i metryk zbieranych przez cały czas, nie tylko w trakcie testów, wykresy i dashboardy gotowe do tego, aby na nie patrzeć, zupełnie wywracają mój światopogląd. Z moich raportów znikają wspomniane już wcześniej legendarne słowa „Potencjalne wąskie gardło”. W codziennej pracy znajduję więcej czasu na rozwój i optymalizację. Dzięki graficznej prezentacji metryk zbieranych z różnych warstw testowanego systemu często nie muszę pisać raportu albo tworzę tylko jeden na koniec testów. Błędy znajdowane są i poprawiane nawet w trakcie testów.

W bardzo krótkim czasie zupełnie zrewidowałem podejście do testów. Przestałem dzielić testy na fazy:

• przygotowanie skryptów,
• uruchomienie testów,
• raport.

Zostają one zastąpione samym uruchomieniem testów. Wykonywane są na tyle często, że już nie trzeba co chwilę wracać do poprawy albo ponownego nagrywania skryptów. Brak raportów na każdym kroku sprawia, że mogę testy te uruchamiać znacznie częściej.

Błyskawicznie dochodzę do wniosku, że znów wróciłem do punktu wyjścia i robię cały czas to samo – uruchamiam testy. A ponieważ historia lubi zataczać koło, znów przechodzę do automatyzacji, tym razem jednak automatyzuję uruchamianie testów i zbieranie wyników.

W tym miejscu również pojawia się pierwsza myśl o włączeniu sztucznej inteligencji w testy wydajnościowe. Pierwsze idee krążą wokół nauki uruchamiania testów, dobierania danych testowych czy analizowania zależności w wynikach kolejnych testów.

Współczesność i „shift left”

W moich testach pojawia się najnowsza wersja Dynatrace – najlepszego narzędzia do monitorowania aplikacji na każdym jej poziomie. Od dnia, w którym po raz pierwszy go uruchomiłem, miałem dostęp do wszystkich danych zbieranych z systemów, a poznawanie nowych technologii nie wymagało już szukania informacji jak i co monitorować. Te dane po prostu miałem dostępne od ręki.

Wciąż jednak czułem, że nie mogę stwierdzić, iż umiem robić testy wydajnościowe. Przez te 15 lat mojej podróży poznałem dziesiątki różnych aplikacji wspierających testy wydajnościowe – od generatorów obciążenia, narzędzi do monitorowania, przez aplikacje do automatyzacji testów. A ja nadal tworzyłem i wykonywałem testy na ostatniej prostej wytwarzania oprogramowania, sporadycznie testując poszczególne elementy systemu, gdy nie był on jeszcze skończony.

Oczywiście, w ten sposób dostarczałem wyniki testów późno, wstrzymując wdrożenia. Teraz jednak wiedziałem już, że nikt w organizacji nie jest z tego powodu zadowolony, a koszty moich testów i poprawy ich wyników są bardzo wysokie.

Przyszedł więc czas na „Shift left”, czyli przesuwanie testów jak najbardziej w lewo w procesie wytwórczym – w kierunku jego początku. Oznaczało to dla mnie przyznanie się do wieloletniego błędu, jakim było twierdzenie, że testy tylko na końcowym produkcie, jak najbliżej produkcji.

Etap zaślepek i Ciągłe testy wydajnościowe

Miałem jednak ogromne problemy z wymyśleniem, w jaki sposób wykonywać testy wydajnościowe wcześniej, kiedy system nie działa wcale albo tylko częściowo, gdy nie ma GUI, albo środowisko testowe postawione jest na ułamku tego, czym system będzie dysponował na produkcji…

Z czasem zrozumiałem, że nie ma znaczenia na jakim środowisku robimy testy. Ważne jest, aby testy były powtarzalne. Z tym założeniem dopuściłem do siebie myśl, że zaślepki mogą być wręcz pomocne w testach, bo zachowują się deterministycznie.

Zatem testując na zaślepkach i wykonując bardzo często testy bardzo małych kawałków aplikacji, mogłem śledzić zmiany w wydajności już na wczesnym etapie wytwarzania aplikacji.

Pozostało jedynie znaleźć odpowiednie narzędzie, które pozwoli mi na tworzenie testów w małych kawałkach, uruchamianie ich automatycznie, a potem, na koniec, wspólne zbiorcze testy na gotowej na wdrożenie aplikacji. Wszystkie te potrzeby zaadresowało narzędzie do generowania obciążenia – NeoLoad. Tak oto powstały Continious Performance Tests (Ciągłe testy wydajnościowe).

Niedaleka przyszłość i złoty wiek inżynierów wydajności

Dziś jestem Inżynierem Wydajności i spokojnie mogę powiedzieć, że znajduję się jedną nogą w przyszłości testów wydajnościowych. Dzięki doświadczeniu, które zdobyłem oraz selekcji narzędzi dostępnych na rynku, dla klientów Sii przygotowuję rozwiązania, które nie tylko potrafią przeprowadzać testy wydajnościowe, ale robią to automatycznie – zarówno w zakresie uruchamiania, jak i analizy wyników i raportowania. Zastosowanie inżynierii poskutkowało tym, że wydajność systemów jest precyzyjnie mierzona, a wszelkie anomalie błyskawicznie wyłapywane i poprawiane już na wczesnym etapie wytwarzania oprogramowania.

W niedalekiej przyszłości każdy inżynier wydajności przestanie w kółko wykonywać te same czynności, jak przygotowanie skryptu, jego uruchomienie i pisanie raportów. Nadchodzą czasy, w których każdy pasjonat wydajności będzie mógł skupić się na analizie konkretnych miar, wykresów i skupi się na rozwiązywania poważnych problemów wydajnościowych.

Tego Wam wszystkim życzę!

***

A jeśli chcesz dowiedzieć się, co o swoich zadaniach piszą inni specjaliści, polecamy: zapiski Team Leadera, przemyślenia Resource Managera i wyzwania rekruterów technicznych.