Provozujete e-shop. Někdo právě teď dokončuje objednávku. Pokladna je rozbitá. Zákazník dostane chybu. Zákazník odejde. Právě jste přišli o prodej.
Bez provozního přehledu byste chybu našli až zítra, když si projdete denní report.
S provozním přehledem provozní tým chybu zpozoruje během vteřin. Okamžitě ji opraví. Zákazník to zkusí znovu. Prodej proběhne.
Cena pomalého odhalení: stovky dolarů za hodinu na každou chybu.
Provozní přehledy zachytí problémy v reálném čase, ne o hodiny nebo dny později.
Úkol provozních přehledů
Provozní přehledy sledují zdraví systémů a probíhající provoz.
Funguje web. Fungují postupy v pokladně. Odpovídají platební brány. Odesílá se e-mail. Úspěšně probíhají volání API.
Provozní přehled není o tržbách ani obchodních metrikách. Je o zdraví systémů.
Požadavek na data v reálném čase
Provozní přehled se musí aktualizovat v reálném čase nebo téměř v reálném čase (do jedné minuty).
Zpožděná data jsou k ničemu. Pokud se přehled aktualizuje jednou za hodinu, přijdete o výpadky, které nastanou mezi aktualizacemi.
Požadavek na reálný čas znamená: provozní přehled je drahý na vytvoření i údržbu. Používejte ho jen pro kritické systémy.
Co sledovat v provozním přehledu
Dostupnost systému
Odpovídá web. Zelená, pokud funguje, červená, pokud je mimo provoz.
Doba odezvy
Jak rychlý je web. Zelená do dvou sekund, žlutá dvě až pět sekund, červená přes pět sekund.
Míra chyb
Jaké procento požadavků vrací chyby. Zelená do 0.1 %, žlutá 0.1 % až 0.5 %, červená nad 0.5 %.
Aktivní transakce
Kolik transakcí právě probíhá. Pro orientaci. Samo o sobě není dobré ani špatné.
Probíhající konverzní trychtýř
Kolik návštěvníků je právě teď v každém kroku pokladny. Odpad v kterémkoli kroku spustí prošetření.
Výkon API
Doby odezvy externích integrací. Platební brána, e-mailová služba, API dopravy.
Výkon databáze
Doby odezvy dotazů, zdraví fronty připojení.
Skutečný příklad: provozní přehled e-shopu
Horní část (zdraví systému)
Stav webu: FUNGUJE (zelená). Doba odezvy: 1.2 sekundy (zelená). Míra chyb: 0.08 % (zelená). Aktivní uživatelé: 423. Probíhající transakce: 17.
Střední část (trychtýř pokladny)
Zobrazení košíku: 127 uživatelů. Zahájení pokladny: 89 uživatelů (70 % konverze z košíku). Údaje o dopravě: 72 uživatelů (81 % konverze). Platební údaje: 68 uživatelů (94 % konverze). Potvrzení objednávky: 64 uživatelů (94 % konverze). Odpad u údajů o dopravě: 17 uživatelů (počkat, je to víc než obvykle, prošetřit).
Spodní část (integrace)
Platební brána: odpovídá za 800 ms (zelená). E-mailová služba: 99.8 % doručení (zelená). Kalkulačka dopravy: odpovídá za 1200 ms (žlutá, mírně pomalá).
Okamžitá akce
Odpad u údajů o dopravě je vyšší než obvykle. Prošetřete, zda pomalost kalkulačky dopravy nezpůsobuje opuštění objednávky.
Systém upozornění
Provozní přehled by měl spustit upozornění, když metriky zčervenají.
Upozornění provoznímu týmu okamžitě. Ne e-mail, který může zapadnout. SMS, zpráva v chatu nebo pager, který vyruší.
Prahové hodnoty by měly být přísné. Nechcete falešné poplachy. Je ale lepší mít jeden falešný poplach a zachytit jeden skutečný problém, než problémy přehlédnout.
Příklady prahových hodnot: web nefunguje 30 sekund = upozornění. Míra chyb nad 1 % po dobu 5 minut = upozornění. Doba odezvy nad 5 sekund po dobu 10 minut = upozornění. Platební brána neodpovídá = upozornění okamžitě.
Pohotovostní služba na střídačku
U systémů dost kritických na to, aby potřebovaly provozní přehled, potřebujete pohotovostní službu na střídačku.
Někdo odpovídá za sledování 24/7. Pokud se upozornění spustí ve 3 ráno, pohotovostní osoba se probudí a problém opraví.
Pohotovost je drahá. Cena výpadku je ale dražší.
Do provozního přehledu s pohotovostí dávejte jen kritické systémy.
Co NESLEDOVAT
V provozním přehledu nesledujte obchodní metriky. Tržby, konverze a trendy návštěvnosti patří do obchodních přehledů, ne provozních.
Míchání obchodních a provozních metrik mate účel. Provozní přehled je o zdraví systémů. Obchodní o zdraví podnikání.
Samostatné přehledy pro samostatné účely.
Přehled, nebo upozornění
Provozní přehled vám umožňuje sledovat proaktivně. Podívejte se na přehled dřív, než se problém stane kritickým.
Upozornění vám umožňují reagovat. Problém nastane, upozornění se spustí, vy ho opravíte.
Potřebujete obojí. Přehled pro proaktivní sledování. Upozornění pro reakci, když se na přehled nikdo nedívá.
Postupy pro reakci na incidenty
Když se upozornění spustí, co se stane potom. Provozní tým by měl mít postup pro každý typ upozornění.
Upozornění, že web nefunguje: restartovat webový server. Pokud stále nefunguje, přepnout na záložní. Pokud stále nefunguje, eskalovat na zkušeného inženýra. Upozornění, že platební brána nefunguje: přepnout na záložní bránu. Informovat zákazníky o možném zpoždění. Sledovat, dokud se hlavní brána neobnoví. Upozornění na pomalou databázi: zkontrolovat frontu připojení. Pokud je plná, zvětšit. Zkontrolovat log dotazů. Ukončit pomalé dotazy. Sledovat.
Postupy brání panice. Jasné kroky brání chybám.
Často kladené otázky
Jak často bychom měli provozní přehled kontrolovat?
Nepřetržitě v pracovní době. Jedna osoba sleduje stále. Mimo pracovní dobu sleduje pohotovostní osoba. U nekritických systémů kontrolujte každou hodinu. U kritických systémů (zpracování plateb, pokladna) nepřetržité sledování. Určete, které systémy jsou kritické: systémy, u nichž hodina výpadku stojí značné tržby. Vše ostatní lze kontrolovat každou hodinu. S Tvůrcem webů WEMASY to můžete nastavit přímo na svém webu.
Jaká doba odezvy je přijatelná?
U pokladny e-shopu: do dvou sekund. U marketingového webu: do tří sekund. U interních administračních nástrojů: do pěti sekund. Při horších hodnotách trpí konverze nebo zkušenost uživatele. Měřte z pohledu uživatele, ne serveru. Pokud uživatel vnímá zpoždění, je to příliš pomalé.
Jak se vyhnout únavě z upozornění?
Přísné prahové hodnoty. Upozorňujte jen při skutečném problému. Pokud dostáváte deset upozornění denně a devět je falešných poplachů, lidé přestanou věnovat pozornost. Lepší jsou dvě upozornění denně, která jsou všechna skutečná. Prahové hodnoty ladíte důsledně. Pokud se upozornění spustí a není naléhavé, zvyšte prahovou hodnotu. Únava z upozornění zabíjí pohotovost reakce.
Má být provozní přehled dostupný na mobilu?
Ano. Pohotovostní osoba se musí na přehled podívat odkudkoli. Zajistěte, aby fungoval na telefonu. Pohotovostní osoba může být mimo stůl. Optimalizujte pro mobil. Velké dotykové plochy. Jednoduché rozložení. Rychlé načítání i na 4G.
Jak sledujeme provozní zdraví v čase?
Zaznamenávejte všechny metriky. I když je provozní přehled v reálném čase, uchovávejte historii. Týdně vyhodnocujte: jak často jsme byli mimo provoz, jak pomalí jsme byli, jaké byly nejčastější chyby. Z historie poznáte systémové problémy. Příklad: pokud máte tři vypršení časového limitu platební brány týdně, prošetřete platební bránu. Neupravujte jen prahovou hodnotu upozornění.
Co když pohotovostní osoba neví, jak problém opravit?
Mějte eskalační postup. Pohotovostní osoba je první, kdo reaguje. Pokud to do pěti minut neopraví, eskaluje na zkušeného inženýra. Zkušený inženýr je druhá úroveň. Pokud to nedokážou ani oba, eskalujte na podporu dodavatele nebo na ředitele. Postupy by měly pro každý typ upozornění určit eskalační cestu.