Jeśli tutaj jesteś to oznacza, że szukasz informacji o monitoringu w różnych środowiskach. Jesteś w najlepszym miejscu. Dlatego zestawiliśmy takie elementy w formie tabeli gdzie zebraliśmy nasze doświadczenia i rekomendacje.
Z tego tekstu dowiesz się:
W jaki sposób podchodzimy do monitoringu i odtwarzania scenariuszy w zależności od środowiska.
Jak projektować cele, i rozumieć feedback dla środowisk PROD a jakie dla DEV/UAT.
Poniższa tabela zawiera 13 kryteriów. Dla każdego z nich opisaliśmy podejście, które stosujemy w zależności od środowiska.
Poznaj różnice
| Monitoring ciągły wg scenariuszy (PROD) | Testy funkcjonalne / regresji wg scenariuszy (DEV/UAT) | |
|---|---|---|
| CEL | Celem jest wykrycie wszelkich problemów wpływających na możliwość skorzystania z usługi przez klienta, od problemów z serwerem, siecią, dns, elementami serwisu, ssl’em, do możliwości kliknięcia w kluczowy button, wyszukania produktu, dodania go do koszyka, realizacji transakcji itd. | Celem jest potwierdzenie, czy nowa wersja serwisu jest zgodna z ustalonym wzorcem funkcjonalnym. Czy badany scenariusz testowy jest możliwy do przejścia. Nie interesują nas problemy techniczne z infrastrukturą, skupiamy się natomiast na działaniu samej aplikacji |
| CZĘSTOTLIWOŚĆ | Uruchamiane z dużą częstotliwością (co 1 do 60 minut) przez całą dobę – 24/7/365 . Pozwala to w razie awarii na szybką reakcję i naprawienie problemu, zanim zorientują się klienci. | Testy mogą odbywać się rzadziej (np. raz na godzinę) lub bez harmonogramu – wówczas test wykonywany jest na żądanie/ad hoc lub jest automatycznie wywoływany w procesie testowania lub w ramach CI/CD. |
| ŚRODOWISKA | Najczęściej obejmuje systemy produkcyjne (PROD), te z których korzystają klienci przez całą dobę, realizując transakcje i inne funkcje e-usług. Gdy te systemy nie działają, klienci nie mogą korzystać z serwisu/aplikacji. | Weryfikowane są wersje aplikacji/serwisu w środowisku developerskim lub testowym (DEV lub UAT/STAGE). |
| FEEDBACK Z SYSTEMU | Informacje zwracane przez monitoring służą działom utrzymania aplikacji i infrastruktury do rozpoznania problemu i umożliwiają szybką reakcje na wykrytą awarię. Raporty okresowe kierowane do kierownictwa umożliwiają weryfikacje czasu niedostępności danej aplikacji i egzekwowanie odpowiednich Service Level Agreements (SLA). | Informacje zwracane w wyniku testów służą developerom i testerom podczas rozwijania i testowania nowych wersji oprogramowania, informując o potencjalnych niezgodnościach z założeniami/specyfikacją. |
| LOKACJE | Wykonywane z kilku lokalizacji, różnych łącz aby potwierdzić problem z działaniem badanego serwisu. | Wykonywane z jednej lokalizacji. |
| EDYCJA SCENARIUSZY | Aktualizacja scenariuszy następuje stosunkowo rzadko – raz na tydzień, miesiąc nawet kwartał. Zmiany w produkcyjnych systemach są bowiem mniej dynamiczne. | Kilkukrotnie częściej niż w monitoringu ciągłym. W skrajnych przypadkach być wymagana nawet kilka razy dziennie. |
| POWIADOMIENIA ALERTY | Kluczowe jest powiadamianie o znalezionych problemach. Często różnymi kanałami (e-mail, sms, messenger) a także w różny sposób (np. różne osoby/zespoły w zależności od czasu trwania awarii bądź jej rodzaju) | Zazwyczaj wystarcza wgląd w panel administracyjny Monit24 aby po wywołaniu testu zweryfikować czy przeszedł on poprawnie. |
| INTEGRACJA | Wskazana integracja z innymi systemami obsługi incydentów u klienta np. z SIEM, gdzie przesyłane są powiadomienia o wykrytych zdarzeniach. | Integracji najczęściej podlega automatyzacja wywołania testu i sprawdzenia jego rezultatu. W takim przypadku Monit24 zwykle jest dołączany do procesu CI/CD i stanowi jego element |
| ZAKRES SCENARIUSZY | Monitoring zazwyczaj obejmuje kilka kluczowych scenariuszy, każdy w kilku krokach sprawdza działanie najważniejszych procesów biznesowych – np. kupowanie produktu. Ale nie skupia się na „przeklikaniu” całości aplikacji, np. wszystkich zakładek i buttonów dostępnych w serwisie. Najważniejszy jest główny flow wynikający z kluczowej funkcjonalności, np. wyliczenie składki OC po wypełnieniu skomplikowanego formularza i wysłanie zapytania ofertowego. Przeważnie 1 do 3 scenariuszy na jeden serwis/e- usługę/aplikację do 15 kroków każdy. | Testy często pokrywają wiele funkcjonalności, jeden scenariusz testowy może mieć nawet kilkadziesiąt rozbudowanych kroków, sprawdzających działanie jak największej ilości obiektów w aplikacji/serwisie. Scenariuszy zazwyczaj jest więcej niż przy monitoringu, tak aby pokryć wiele przypadków użycia. Przeważnie 1 do 10 scenariuszy po kilkanaście akcji/kroków każdy. |
| WYMAGANIA | Scenariusze mogą wymagać realnych danych, przeprowadzania prawdziwych transakcji i ich wycofywania. Niekiedy potrzebne jest dedykowane środowisko (np. tokeny sprzętowe, certyfikaty). Najczęściej Monit24 odpowiada za to aby dostarczyć takie zasoby. | Dane do scenariuszy testowych dostarczane są najczęściej przez klienta. W środowiskach DEV/UAT łatwiej jest np. o konta testowe dla użytkowników czy też fikcyjne środki do realizacji testowych transakcji. Środowiska mogą być łatwo czyszczone z niepotrzebnych danych/transakcji. |
| AKTUALIZACJA APLIKACJI MOBILNYCH | Przy monitorowaniu aplikacji mobilnych, możliwe jest zautomatyzowanie pobierania i instalacji najnowszej wersji badanej aplikacji z appstore. | Przy testowaniu aplikacji mobilnych może być wymagany dostęp do wersji aplikacji, które nie są jeszcze widoczne w appstore oraz ich częstsza aktualizacja, np. w ramach narzędzia TestFlight. |
| SERVICE LEVEL | Usługa Monit24 musi działać nieprzerwanie z dużym SLA (>99,99%) 24/7/365. | Zazwyczaj nie jest definiowane SLA. Ewentualne przerwy w dostępie do usługi (w szczególności po godzinach pracy developerów/testerów) nie są krytyczne. |
| WSPARCIE | Podczas obsługi klientów często istnieje potrzeba analizy przyczyn awarii; pomocy klientowi w znalezieniu przyczyny problemu. Wymagane ustawianie przerw serwisowych, korekt Service Level. | Wsparcie sprowadza się głównie do aktualizacji scenariuszy i konsultingu w zakresie zakresu testów, wyboru testowanych elementów i aktualizacji. |
Podsumujmy,
Monitoring PROD koncentruje się na ciągłym wykrywaniu problemów wpływających na użytkowników końcowych — działa 24/7, reaguje na awarie i wspiera utrzymanie SLA.
Testy DEV/UAT skupiają się na jakości i zgodności nowych wersji aplikacji z założeniami funkcjonalnymi, wspierając proces CI/CD.
Różne cele i częstotliwość — monitoring dba o dostępność usług, testy natomiast o poprawność funkcjonalną.
Inny feedback i integracje — monitoring raportuje do zespołów utrzymania i systemów SIEM, testy zasilają procesy developerskie.
Zakres i dynamika zmian — w środowiskach PROD scenariusze są stabilne i kluczowe dla biznesu, a w DEV/UAT – rozbudowane i częściej modyfikowane.
Jeśli wszystko jest już jasne i chcesz wdrożyć testy, skorzystaj z formularza na dole tej strony.
