Syntetický monitoring: testy, které běží i po releasu
Regresní testy v pipeline obvykle ověřují aplikaci před releasem. Zelený výsledek však sám o sobě neříká, co se s klíčovou cestou děje později v produkci, kde se může změnit konfigurace nebo selhat externí služba.
Syntetický monitoring může znovu využít část regresních scénářů upravenou pro bezpečný produkční běh. Takové kontroly se spouštějí v pravidelném intervalu i tehdy, když se právě nic nenasazuje.
Běžný problém: po releasu chybí kontrola celé cesty
Server může odpovídat, i když zákazník nedokončí přihlášení, nákup nebo platbu. Příčinou může být vlastní změna, testovací data i externí služba. Samotný monitoring dostupnosti proto neposkytuje stejnou informaci jako průchod klíčovým scénářem.
Jak to řeší syntetický monitoring
Ve zvoleném intervalu prochází skutečný prohlížeč klíčové cesty vašeho systému – registraci, přihlášení, vyhledání produktu, vložení do košíku i bezpečně připravený platební krok. Nejde jen o volání adresy a kontrolu, zda přišla odpověď. Prohlížeč klikne na tlačítko, vyplní formulář a ověří domluvený výsledek podobně jako uživatel, ale s oddělenými produkčními účty a daty.
Scénáře připravujeme na bezpečný běh: používají oddělené účty, podle možností testovací režim platební brány a kontrolované čištění vytvořených dat. Interval kontroly domluvíme podle toho, jak rychle se o problému potřebujete dozvědět.
Jaké podklady dostanete při selhání
Právě zde se syntetický monitoring od běžného monitoringu liší nejvíce.
Klasické upozornění zní „HTTP 500“. S tím se nedá dělat téměř nic – vývojář začne hledat v logách a zkouší chybu reprodukovat ručně.
Podle zvoleného nástroje a konfigurace může záznam o selhání obsahovat snímek obrazovky, video průběhu nebo záznam síťové komunikace. Tým tak snáze určí krok, na kterém se scénář zastavil, a najde související odpověď serveru.
Upozornění přijde tam, kde ho tým skutečně uvidí – e-mailem, do Slacku nebo Teams. Nastavíme ho tak, aby se neozývalo při jediném náhodném selhání a nestal se z něj šum, kterého si nikdo nevšímá.
Součástí může být také přehled dostupnosti a odezev v čase. Můžete tak vidět, že se košík po pátečním releasu zpomalil, i když scénář zatím neselhává, a změnu prověřit dříve.
Jak využít existující testovací scénáře
Syntetický monitoring může znovu využít část regresních scénářů upravenou pro bezpečný produkční běh. Produkční běh potřebuje zvláštní účty, data, čištění a bezpečnostní pravidla. Rozdíl tedy nespočívá jen v prostředí a intervalu.
Pokud už máte automatizované testy webové aplikace, existující scénáře mohou zmenšit rozsah úvodní práce. Stále je však třeba připravit je pro bezpečný produkční běh, naplánovat a napojit na upozornění.
Funguje to i opačně. Pokud automatizaci zatím nemáte a začnete monitoringem, mohou vhodné scénáře posloužit jako základ regresní sady. Část práce tak lze využít také v regresní sadě.
Co vám pravidelná kontrola přinese
O selhání nákupní cesty se můžete dozvědět v rámci domluveného intervalu a potvrzovacích běhů. Podle konfigurace získáte podklady, se kterými lze problém prověřit. Hlídání se přitom nemusí týkat jen vašeho kódu: pokud bezpečný scénář zahrnuje platební bránu, dopravu či přihlášení přes třetí stranu, může zachytit také selhání této závislosti.
Když se web změní, scénáře lze podle dohody upravit. Skripty mohou běžet ve vašem prostředí a v rámci domluveného předání zůstanou uloženy ve vašem repozitáři.
Další krok
Na nezávazné konzultaci projdeme klíčové cesty a prověříme, zda pro ně existuje bezpečný produkční účet, vhodná data, podporované integrace a přijatelné provozní limity. Potom navrhneme rozsah, interval a pravidla upozornění.