1. Zacznij od czynności klienta lub pracownika
Wypisz kilka najważniejszych działań: otwarcie strony, wysłanie zapytania, zalogowanie do aplikacji czy sprawdzenie zamówienia. Przy każdym określ, co oznacza sukces. Samo wyświetlenie strony głównej nie potwierdza jeszcze, że formularz zapisuje zgłoszenia albo system pokazuje aktualne dane.
Dokumentacja Google Cloud opisuje monitoring syntetyczny jako okresowe wykonywanie kontrolnych żądań lub scenariuszy i zapisywanie ich wyniku oraz czasu. Tę zasadę można wykorzystać przy planowaniu kontroli kluczowej czynności. Testy wymagające zapisu powinny mieć uzgodnione dane testowe i ograniczony zakres, aby nie generowały prawdziwych zamówień ani wiadomości do klientów.
2. Wybierz kilka pomiarów zrozumiałych dla firmy
Google SRE wyróżnia cztery podstawowe sygnały: czas odpowiedzi, ruch, błędy i stopień wykorzystania ograniczonych zasobów. Dają wspólny punkt wyjścia do rozmowy z opiekunem IT. Każdy pomiar powinien mieć opis, aby było wiadomo, czy dotyczy całej usługi, pojedynczego serwera, czy tylko jednej kontrolnej próby.
- Czas odpowiedzi: ile czeka użytkownik i czy część odpowiedzi trwa wyraźnie dłużej.
- Ruch: ile żądań obsługuje usługa i czy zmiana odpowiada oczekiwanej aktywności.
- Błędy: jaka część czynności kończy się niepowodzeniem i czego dotyczy problem.
- Zasoby: czy kończy się miejsce, pamięć lub inny zasób potrzebny do działania.
3. Sprawdź miejsce i aktualność pomiaru
Kontrola uruchomiona wewnątrz firmowej sieci opisuje inną drogę dostępu niż próba z internetu. Przy publicznej stronie warto wiedzieć, skąd wykonywany jest test. Google Cloud rozróżnia kontrole publicznych i prywatnych punktów dostępu; publiczne mogą pochodzić z różnych lokalizacji. Dobór miejsca pomiaru powinien odpowiadać temu, skąd korzystają z usługi jej odbiorcy.
Ustal również, co panel pokazuje, gdy przestają napływać dane. Ostatni poprawny wynik sprzed dłuższego czasu nie potwierdza bieżącej dostępności. Przydatne są data ostatniej próby, widoczne przerwy w pomiarach i osobna informacja o braku danych. Dzięki temu właściciel firmy rozumie granice prezentowanego wyniku.
4. Każdemu alarmowi przypisz działanie
Ustal, które zdarzenie wymaga szybkiego kontaktu, które zadania do wykonania w godzinach pracy, a które jedynie obserwacji. Google SRE zwraca uwagę, że nadmiar powiadomień utrudnia zauważanie rzeczywistych problemów. Dla pilnego alarmu zapisz odbiorcę, zastępstwo i pierwszy krok sprawdzenia.
Progi oraz opóźnienie alarmu trzeba dopasować do usługi. Pojedyncza nieudana próba może oznaczać chwilowy problem, ale zbyt długie oczekiwanie opóźni reakcję na awarię. Przetestuj także samo powiadomienie w uzgodnionym terminie. Gotowy wykres nie daje pewności, że wiadomość dotrze do osoby, która może pomóc.
5. Sprawdź zestaw na prostym przykładzie
Hipotetyczny przykład: firma usługowa pozyskuje zapytania przez stronę. Pierwszy zestaw kontroli sprawdza jej dostępność z internetu, czas odpowiedzi i uzgodnioną testową ścieżkę formularza. Opiekun IT otrzymuje alarm o powtarzającej się awarii, a właściciel ma krótki widok stanu usługi i kontakt do osoby prowadzącej sprawę.
Po wykryciu problemu z formularzem zespół porównuje wynik testu z działaniem widocznym w przeglądarce. Jeżeli strona się otwiera, lecz zapis zgłoszenia zawodzi, sam pomiar dostępności strony nie wystarcza. Przykład pokazuje, dlaczego kryterium sukcesu powinno obejmować czynność ważną dla firmy.
Po pierwszym okresie działania przejrzyj alarmy: które wymagały reakcji, których nikt nie odebrał i jakie problemy zgłosili wcześniej użytkownicy. Popraw zakres kontroli na podstawie tych obserwacji. Wraz z nową usługą dopisz jej właściciela, kluczową czynność i sposób wykrycia awarii.
- Czy wiadomo, czego dokładnie dotyczy każdy wynik?
- Czy brak aktualnych danych jest widoczny?
- Czy odbiorca alarmu zna następny krok i ma zastępstwo?