Proč uptime monitoring nestačí: web běží, ale nákup nefunguje
Monitoring svítí zeleně. Dostupnost za poslední měsíc je téměř stoprocentní. Server odpovídá, stránka se načte, vše je v pořádku.
A přitom se už od pátečního releasu nedá dokončit objednávka. Platební brána vrací chybu. Nebo se po aktualizaci šablony ztratilo tlačítko v košíku a zákazník se nemá kam posunout. Bez kontroly celé cesty se o problému můžete dozvědět až ze stížnosti nebo z poklesu objednávek.
Mezitím jste platili za reklamu, která přiváděla lidi na web, kde se nedalo nakoupit.
Běžný problém: server odpovídá, ale zákazník cíle nedosáhne
Běžný monitoring sleduje, zda server odpovídá. Zavolá adresu, dostane odpověď a zaznamená, že je vše v pořádku. Je to legitimní kontrola – odpovídá však jen na otázku, zda běží stroj. Ne na otázku, zda funguje byznys.
Server totiž může bez problémů odpovídat, a přesto nelze nákup dokončit:
- Platební brána vrací chybu. Váš systém je v pořádku, jen partner na druhé straně ne. Pro zákazníka je to jedno – objednávka neprojde a zákazník může nákup přerušit nebo zvolit jinou možnost.
- Po aktualizaci zmizelo tlačítko v košíku. Stránka se načte, vrátí stavový kód 200 a monitoring je spokojený. Chybí na ní však to jediné, na co zákazník přišel kliknout.
- Přihlášení přestalo fungovat. Formulář se zobrazí, odešle se, a nic. Server odpověděl.
- Doprava nenabízí žádné možnosti. Košík funguje, platba funguje, ale zákazník se nedostane přes třetí krok objednávky.
Společné je, že samotná kontrola dostupnosti nemusí tato funkční selhání zachytit. Rozdíl mezi „server odpovídá“ a „zákazník dosáhne cíle“ má přímý obchodní význam.
Samotný zelený výsledek regresních testů před releasem nestačí. Testy mohly běžet v prostředí s jinou konfigurací, testovacím režimem platební brány a kontrolovanými daty. V produkci se může problém projevit až po releasu nebo po změně na straně partnera.
Jak sledovat výsledek pro zákazníka
Místo toho, abychom se serveru ptali, zda odpovídá, projdeme celou cestu jako zákazník.
V pravidelném intervalu projde prohlížeč přímo v produkci domluvenou cestu – například přihlášení, vyhledání produktu, vložení do košíku nebo bezpečně připravený platební krok. Pokud se scénář zastaví, čas upozornění závisí na intervalu a potvrzovacích bězích.
Scénáře připravujeme tak, aby snižovaly riziko zásahu do produkce: používají oddělené účty, podle možností testovací režim platební brány a kontrolované čištění dat. Před spuštěním je třeba ověřit, co konkrétní produkční integrace bezpečně umožňuje.
Když scénář selže, upozornění přijde kanálem, který tým skutečně sleduje – e-mailem nebo přes Slack či Teams. Nastavíme ho tak, aby nevytvářelo šum, kterého si tým po týdnu přestane všímat.
Co vám monitoring klíčové cesty přinese
Můžete reagovat dříve. Upozornění v domluveném intervalu snižuje závislost na stížnosti zákazníka nebo pozdním pohledu na tržby.
Dostanete použitelnější podklad. Podle nástroje a konfigurace může záznam o selhání obsahovat snímek obrazovky, video nebo záznam síťové komunikace. Tyto údaje mohou zkrátit hledání příčiny, i když ne vždy nahradí reprodukci.
Hlídají se také externí systémy. Platební brána, doprava, přihlášení přes třetí stranu. Výpadek partnera pocítíte stejně, jako by byl váš – proto o něm chcete vědět stejně rychle, i když za něj nemůžete.
Vidíte, jak se odezvy mění v čase. Postupné zpomalování po nasazeních lze prověřit, i když ještě nejde o výpadek.
Další krok
Stačí říci, které cesty nesmějí přestat fungovat – typicky nákup, přihlášení, platba. Ozvěte se nám a domluvíme, co budeme sledovat a jak často.