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

Spoľahlivosť verejnej e-služby treba overiť pri výpadku závislosti aj pri obnove dát. Oznámenie o nedostupnosti technickú príčinu neurčí. Odporúčania vychádzajú z princípov spoľahlivosti AWS. Nie sú technickým rozborom konkrétneho incidentu ESKN.

Kde hľadať riziká

Pri audite overte závislosti a podporované verzie. Potom to, či sa dá obnoviť záloha. Monolit sám osebe neznamená nespoľahlivý systém. Riziko vzniká vtedy, keď zlyhanie jednej závislosti zastaví celý proces a záložná cesta existuje len na papieri, nie v prostredí, kde ju niekto naozaj prepol.

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

Design for Failure

Každý komponent raz zlyhá. Circuit breaker odreže zaseknutú závislosť, aby jedna pomalá služba nestiahla so sebou zvyšok, pričom graceful degradation nechá používateľovi aspoň to, čo funguje, namiesto bielej obrazovky. Automatický failover potom 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 len vtedy, keď sú závislosti naozaj nezávislé a kapacita stačí aj v okamihu, keď druhá polovica infraštruktúry nebeží. Prepnutie treba overovať pravidelne.

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, no skutočnou skúškou je až návrat s databázovými zmenami, pri ktorých samotné vrátenie kódu aplikácie nemusí stačiť.

Transparentná komunikácia počas výpadku

Počas výpadku zverejnite dotknuté funkcie a čas ďalšej aktualizácie. Ak existuje náhradná cesta, opíšte ju. Príčinu označte za potvrdenú až po vyšetrení. Po obnove doplňte dopad a nápravné opatrenia.

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ú vedieť, kto rozhoduje pri incidente a v akom poradí sa obnovujú služby, ešte predtým než incident nastane. Výsledkom skúšky má byť nameraný čas obnovy a overenie úplnosti dát.

Záložnú cestu overujte riadeným prepnutím pri dohodnutej záťaži. Zmerajte čas obnovy a porovnajte ho s cieľom. Samotná existencia záložného prostredia tieto výsledky nedokladá.

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