Když státní e-služby padnou: Architektonické principy pro spolehlivé veřejné systémy

Výpadek elektronického katastru nemovitostí (ESKN) v lednu 2026 opět připomněl dlouhodobý problém slovenské veřejné správy. Kritické e-služby jsou křehké. Realitní kanceláře, notáři a advokáti nemohli pracovat. Občané si nemohli ověřit vlastnictví nemovitostí. Úřad geodézie komunikoval zdrženlivě a neurčitě. Kdo byl překvapený, ať zvedne ruku. Nikdo? Přesně tak.

Není to první ani poslední takový výpadek. Je to ale příležitost podívat se na to, co by se mělo dělat jinak.

Proč státní systémy padají

Většina kritických státních systémů na Slovensku vznikla v éře, kdy se o cloudu, kontejnerizaci nebo mikroslužbách jen snilo. Je to na nich vidět. Jsou monolitické, takže selhání jediné části položí celek. Běží na jednom serveru nebo v jednom datovém centru, takže při jeho výpadku není kam přepnout.

K tomu se přidává věk. Část systémů stojí na technologiích, které už nikdo nepodporuje, takže na známou zranitelnost nepřijde záplata. A když systému rozumí jen původní dodavatel, stát nemá s kým o jeho modernizaci soutěžit.

Architektonické principy pro spolehlivé e-služby

Design for Failure

Každá komponenta jednou selže a systém s tím musí počítat dopředu. Circuit breaker odřízne zaseknutou závislost, aby jedna pomalá služba nestáhla s sebou zbytek. Graceful degradation nechá po výpadku jedné funkce použitelný aspoň zbytek namísto bílé obrazovky. A automatický failover přehodí provoz na záložní instanci, aniž by někdo v noci zvedal telefon.

Observability od prvního dne

Nemůžete opravit to, co nevidíte. Moderní systém potřebuje čtyři věci najednou:

• všechny logy na jednom místě a prohledávatelné
• metriky v reálném čase, tedy CPU, paměť, response time a error rate
• distribuované trasování, aby šlo sledovat jeden požadavek napříč komponentami
• alerting, který se ozve dřív, než problém nahlásí první uživatel

Bez nich se hledání příčiny výpadku mění v hádání.

Škálovatelnost a redundance

Kritická služba musí běžet minimálně ve dvou nezávislých prostředích. Prakticky to znamená nasazení do více zón nebo regionů, load balancing mezi instancemi a databázovou replikaci, která při výpadku přepne na repliku sama. Když vypadne jedno místo, provoz pokračuje jinde.

Automatizovaný deployment a rollback

Manuální nasazování je recept na katastrofu. CI/CD pipeline s automatickými testy zachytí chybu dřív, než se dostane k občanům. Blue-green a canary strategie pouštějí novou verzi nejdřív na malou část provozu. A když se stejně něco pokazí, návrat na předchozí verzi má trvat minuty, ne hodiny.

Transparentní komunikace během výpadku

Výpadek ESKN ukázal, že komunikace je stejně důležitá jako technická odolnost. Status page v reálném čase řekne lidem, na čem jsou. Příspěvek na Facebooku za tři hodiny to nedokáže. SLA s definovanými časy odezvy dává tomu slibu váhu a po skončení incidentu má přijít report s příčinou a s tím, co se změní, aby se incident neopakoval.

Zátěžové testy přitom nepatří jen před spuštění. Provoz se v čase mění, takže testovat je potřeba i během něj.

Co se můžeme naučit ze soukromého sektoru

Banky, e-shopy a SaaS firmy řeší stejné výzvy a většina je už vyřešila. Rozdíl je v motivaci. Soukromý sektor platí za každou minutu výpadku přímo, veřejná správa tuto zpětnou vazbu nemá.

Řešení není v tom, že stát začne nakupovat dražší technologie. Je v tom, že začne uplatňovat ověřené inženýrské principy.

Failover přitom není důkazem odolnosti jen proto, že je nakreslený v architektuře. Je potřeba ho pravidelně zkoušet řízeným přepnutím, měřit čas obnovy a ověřit, jestli záložní cesta zvládne reálný provoz.

Když stavíme systém, myslíme i na to, co se stane, když něco selže. Něco vždycky selže. Otázka je jen kdy.

Výpadky státních e-služeb nejsou nevyhnutelnost. Jsou důsledkem architektonických rozhodnutí nebo jejich absence. Principy, které fungují v soukromém sektoru, fungují i ve veřejném. Stačí je začít uplatňovat.

Pokud stavíte systém, který musí být spolehlivý, promluvme si o tom, jak toho dosáhnout.