Keď štátne e-služby padnú: Architektonické princípy pre spoľahlivé verejné systémy

Spoľahlivosť verejnej e-služby sa ukáže pri výpadku závislosti aj pri obnove dát. Samotné oznámenie nedostupnosti nestačí na určenie technickej príčiny. Nasledujúce odporúčania vychádzajú z princípov spoľahlivosti AWS, nejde o technický rozbor konkrétneho incidentu ESKN.

Kde hľadať riziká

Pri audite overte závislosti, podporované verzie a možnosti obnovy. Monolit sám osebe neznamená nespoľahlivý systém. Riziko vzniká napríklad vtedy, keď zlyhanie jednej závislosti zastaví celý proces a neexistuje overená záložná cesta.

Architektonické princípy pre spoľahlivé e-služby

Design for Failure

Každý komponent raz zlyhá a systém s tým musí rátať. Circuit breaker odreže zaseknutú závislosť, aby jedna pomalá služba nestiahla so sebou zvyšok. Graceful degradation nechá použiteľné aspoň to, čo funguje, namiesto bielej obrazovky. A automatický failover prehodí prevádzku na záložnú inštanciu, kým všetci spia.

Observability od prvého dňa

Nemôžete opraviť to, čo nevidíte. Moderný systém potrebuje štyri veci naraz:

• všetky logy na jednom mieste a prehľadávateľné
• metriky v reálnom čase, teda CPU, pamäť, response time a error rate
• distribuované trasovanie, aby sa dala požiadavka sledovať naprieč komponentmi
• alerting, ktorý sa ozve skôr, ako problém nahlási prvý používateľ

Bez nich je ladenie výpadku hádanie.

Škálovateľnosť a redundancia

Počet prostredí a spôsob replikácie určite podľa prípustného výpadku a straty dát. Redundantné nasadenie môže obmedziť dopad poruchy, ale potrebuje nezávislé závislosti, dostatočnú kapacitu a pravidelne overené prepnutie.

Automatizovaný deployment a rollback

Opakovateľné nasadenie a automatické kontroly znižujú riziko chýb. Blue-green a canary nasadenie pomáhajú overiť novú verziu postupne. Návrat otestujte aj s databázovými zmenami, pri ktorých obyčajné vrátenie aplikácie nemusí stačiť.

Transparentná komunikácia počas výpadku

Počas výpadku zverejnite, ktoré funkcie nefungujú, dostupnú náhradnú cestu a čas ďalšej aktualizácie. Technickú príčinu označte za potvrdenú až po vyšetrení. Po obnove má nasledovať opis dopadu a nápravných opatrení.

Záťažové testy pritom nepatria len pred spustenie. Prevádzka sa v čase mení, takže testovať treba aj počas nej.

Obnovu treba predviesť

Verejná správa aj súkromná firma potrebujú určiť, kto rozhoduje pri incidente a aké služby obnoví ako prvé. Výsledkom skúšky má byť nameraný čas obnovy a overenie úplnosti dát.

Failover pritom nie je dôkazom odolnosti len preto, že je nakreslený v architektúre. Treba ho pravidelne skúšať riadeným prepnutím, merať čas obnovy a overiť, či záložná cesta zvládne reálnu prevádzku.

Ak budujete systém, ktorý musí byť spoľahlivý, porozprávajme sa o tom, ako to dosiahnuť.