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

Spolehlivost veřejné e-služby se ukáže při výpadku závislosti i obnově dat. Samotné oznámení nedostupnosti neurčuje technickou příčinu. Doporučení vycházejí z principů spolehlivosti AWS, nejde o technický rozbor konkrétního incidentu ESKN.

Kde hledat rizika

Při auditu ověřte závislosti, podporované verze a možnosti obnovy. Monolit sám o sobě neznamená nespolehlivý systém. Rizikem je například závislost, jejíž výpadek zastaví celý proces bez ověřené náhradní cesty.

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

Počet prostředí a způsob replikace určete podle přijatelného výpadku a ztráty dat. Redundance může omezit dopad poruchy, potřebuje však nezávislé závislosti, dostatečnou kapacitu a ověřené přepnutí.

Automatizovaný deployment a rollback

Opakovatelné nasazení a automatické kontroly snižují riziko chyb. Blue-green a canary nasazení umožňují postupné ověření. Návrat otestujte i s databázovými změnami, kdy samotné vrácení aplikace nemusí stačit.

Transparentní komunikace během výpadku

Během výpadku zveřejněte dotčené funkce, náhradní cestu a čas další aktualizace. Příčinu označte za potvrzenou až po vyšetření. Po obnově popište dopad a nápravná opatření.

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.

Obnovu je třeba předvést

Veřejná správa i soukromá firma potřebují určit, kdo rozhoduje při incidentu a co se obnoví jako první. Zkouška má doložit naměřený čas obnovy a úplnost dat.

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.

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