Provoz a podpora: co se děje s aplikací po tom, co ji spustíte

Aplikace, kterou nevidíte, není nasazená — je opuštěná. Rozdíl mezi těmi dvěma stavy není v kódu, ale v tom, jestli se o problému dozvíte vy, nebo zákazník.

Projekt se předá, faktura se vystaví a tím to pro většinu dodavatelů končí. Aplikace přitom žije dál: roste jí databáze, mění se závislosti, vyprší certifikáty a někdo jednou udělá změnu, která něco pokazí. Provoz je to, co rozhoduje, jestli se to řeší v klidu, nebo v panice.

Monitoring je o otázce, ne o grafech

Smyslem monitoringu není mít hezkou nástěnku. Je to umět odpovědět na jednu otázku: funguje to teď pro uživatele?

Stačí na to překvapivě jednoduché věci, které se ale musí sledovat doopravdy:

• Chybovost a rychlost na klíčových místech. A ne průměr — ten schová i to, že desetině lidí se stránka načítá osm sekund. Zajímá nás, jak je na tom ta nejpomalejší část návštěv.
• Běží ještě to, co má? Nejen webserver, ale i fronty a naplánované úlohy. Spadlý worker se navenek neprojeví hned — projeví se o den později tím, že nikomu neodešel e-mail.
• Dochází něco? Místo na disku, připojení do databáze, platnost certifikátu. To jsou výpadky, které jdou vidět týdny dopředu.

A platí jedno pravidlo: alert, na který se nedá reagovat, je potřeba smazat. Tři upozornění denně, která nikdo neřeší, spolehlivě naučí tým ignorovat i to čtvrté, které bylo důležité.

Záloha, která nebyla obnovena, není záloha

Tohle je nejčastější tichá díra v provozu. Zálohy běží, v logu je „OK", a v den, kdy jsou potřeba, se zjistí, že se roky zálohovala prázdná databáze nebo že obnova trvá dvanáct hodin.

Proto k zálohování patří pravidelná zkušební obnova — ne kontrola, že soubor existuje, ale reálné obnovení do odděleného prostředí a ověření, že data v něm dávají smysl. Zároveň je potřeba mít řečená dvě čísla: kolik dat si můžeme dovolit ztratit a jak dlouho smí trvat návrat do provozu. Z nich plyne, jak často se zálohuje a co to stojí.

Dostupnost: co se dá slíbit a co ne

Domluvená dostupnost je užitečná věc, ale jen tehdy, když se k ní řekne zbytek. Samotné procento neříká nic, dokud není jasné, co se počítá jako výpadek, v jakém čase se měří a co se stane, když se nedodrží.

Stejně důležité je, co nemůže slíbit nikdo: dostupnost služeb třetích stran. Když vypadne platební brána nebo API dopravce, aplikace to má přežít se srozumitelnou hláškou — ale nemůže za to ručit.

Proto se s klienty bavíme o domluvené dostupnosti a reakčních časech podle závažnosti, ne o jednom čísle do smlouvy.

Nasazování změn je součást provozu

Většina výpadků nevzniká z ničeho nic. Vzniká při změně. Proto se provoz a způsob nasazování nedají oddělit:

• Nasazuje se automaticky a stejně pokaždé, ne ručně a ne podle toho, kdo má službu.
• Změny databáze musí být zpětně kompatibilní, jinak se nedá vrátit zpět bez ztráty dat.
• Návrat na předchozí verzi musí být vyzkoušený, ne jen popsaný. Rollback, který se poprvé zkouší během incidentu, obvykle nefunguje.

Co děláme my

Aplikace nasazujeme v kontejnerech, takže běží stejně u nás, u vás nebo u jiného poskytovatele — a případné stěhování je nasazení, ne přepisování. K provozu patří monitoring s alerty, zálohování s ověřenou obnovou, domluvená dostupnost a reakční časy, a změny nasazované automatizovaně.

Provozovat umíme i řešení, které jsme nestavěli — tehdy se začíná auditem, abychom věděli, co přebíráme. Pokud vás zajímá, co by to znamenalo pro vaši aplikaci, ozvěte se.