Czy jesteś w stanie powiedzieć, co to znaczy „dużo”? A może wiesz ile to „za dużo”? Czy „trochę” jest „za mało”, a może „wystarczająco”? Jeśli nic Ci to nie mówi, to nie martw się bo zapewne nikt nie potrafi na te pytania konkretnie odpowiedzieć.
Jedną z najważniejszych rzeczy, jaką trzeba brać pod uwagę przy uruchamianiu jakiejkolwiek usługi jest to, czego doświadczy użytkownik końcowy czyli po prostu klient. Koniec końców, to właśnie on zapłaci za tę usługę (albo i nie!). Zawsze należy tak o niego zadbać, aby powracał jak najczęściej, a doświadczenie usługi musi być miłe i przyjemne.
Czy kiedykolwiek irytowała Cię wolno ładująca się strona? Zapewne tak. Dlatego też nie chcesz, aby Twoja strona działała wolno bo to zmusza użytkownika do czekania. Badania pokazują, że klient jest w stanie poczekać maksymalnie trzy sekundy na załadowanie się strony, a potem zamyka ją. Trzy sekundy, to naprawdę mało czasu…
Jeśli monitorujesz swoją stronę, to warto by badać właśnie czas ładowania. Jeśli system monitorujący stwierdzi, że strona otwiera się w tym czasie, będzie to znaczyło, że wszystko działa. Warto wspomnieć, że dodatkowe dane mogą być zaciągane w tle, ale to już odbywa się bez wiedzy użytkownika. Zazwyczaj też uznaje się, że jeśli jakaś strona ładuje się dłużej niż powyższy czas, to jest to traktowane jako ostrzeżenie i należy mieć swój system na uwadze. Taki czas jednak też nie jest bardzo długi, a bo to dosłownie kilkanaście sekund. Jeśli strona ładuje się dłużej, to zostaje uznana za niedziałającą. Oczywiście istnieją odstępstwa jak chociażby kupno biletów na koncerty czy wydarzenia sportowe. Nie ma co się oszukiwać, rzadko który system podołałby obsłudze 50 000 osób chcących zarezerwować sobie bilet dokładnie w tym samym czasie. Jednak wówczas stosuje się kolejkowanie, ale tu już użytkownik nastawia się na czas oczekiwania mogący być rzędu dziesiątek minut czy nawet godzin.
Jak zatem monitorować swoją usługę? Można to robić własnoręcznie, klikając przycisk „Odśwież” w przeglądarce, ale nikt nie będzie w stanie tego robić częściej niż co kilka sekund, a już na pewno nie będzie tego robić 7 dni w tygodniu. To jest ten moment, w którym zaprzęgamy do działania systemy monitorujące.
Pierwszą rzeczą, o jaką należy zadbać jest skwantyfikowanie swoich potrzeb. Oznacza to po prostu przypisanie do określeń „mało” czy „dużo” konkretnych liczb. Przykładowo, może to być właśnie wcześniej wspomniany czas ładowania strony. Ustawiamy monitoring do sprawdzania tegoż czasu i zakładamy, że ma wynosić mniej niż trzy sekundy. W taki sposób określiliśmy jeden z KPI (Key Performance Indicators). Jeśli wyznaczyliśmy je wszystkie, to możemy przejść do implementacji monitoringu.
System monitoringu powinien być skonfigurowany w taki sposób, aby był w stanie zidentyfikować incydent, gdy ten wystąpi. Mianem incydentu najczęściej określa się moment, gdy użytkownik końcowy jest w stanie dostrzec, że coś jest nie tak (np. dodawanie do koszyka w sklepie internetowym nie działa, albo cała strona nie odpowiada). Idealnie by było aby system wpierw próbował sam naprawić zaistniały problem. Dzięki temu reakcja może być praktycznie natychmiastowa. Jeśli jednak nie podoła zadaniu, to może incydent wyeskalować do człowieka. Przyjmuje się, że na pierwszej linii w tzw. Network Operations Center („NOC”) systemy monitorują młodsi inżynierowie tak DevOps jak i inżynierowie monitoringu. Dopiero, gdy „młodsza” obsada nie jest w stanie poradzić sobie z problemem eskaluje go wyżej. Warto zachowywać taką strukturę, gdyż pomaga to młodym się rozwijać oraz obserwować działanie środowiska produkcyjnego oraz starszych kolegów.
Czasem jednak zdarza się, że incydent jest tak złożony, że do naprawy koniecznym staje się zaangażowanie programistów oraz innych osób. Wówczas naprawia się system tak szybko jak to jest możliwe, bez skupiania się na wydajności czy też elegancji rozwiązania. System po prostu musi wrócić do życia. Po uporaniu się z incydentem warto zbadać, dlaczego w ogóle on się wydarzył. Do dobrych praktyk należy przeprowadzenie śledztwa i zadanie kilku ważnych pytań: Co poszło nie tak? Która część systemu była niedostępna i dlaczego? oraz Co należy zrobić aby incydent nie pojawił się ponownie? Rzadko kiedy jedna osoba jest w stanie odpowiedzieć na te wszystkie pytania. Częściej działa cały zespół (albo nawet zespoły) i najpierw bada zdarzenie, a następnie implementuje poprawki. Ale to już temat na inny post.
