Az elektronikus ingatlan-nyilvántartás (ESKN) 2026 januári leállása ismét rávilágított a szlovák közigazgatás régóta fennálló problémájára. A kritikus e-szolgáltatások törékenyek. Az ingatlanirodák, a közjegyzők és az ügyvédek nem tudtak dolgozni. A polgárok nem tudták ellenőrizni az ingatlanok tulajdonjogát. A Geodéziai Hivatal vonakodva és bizonytalanul kommunikált. Aki meglepődött, emelje fel a kezét. Senki? Pontosan.
Ez nem az első és nem is az utolsó ilyen leállás. De alkalom arra, hogy megnézzük, mit kellene másképp csinálni.
Miért állnak le az állami rendszerek
Szlovákia legtöbb kritikus állami rendszere olyan korban épült, amikor a felhő, a konténerizáció vagy a mikroszolgáltatások még csak álmok voltak. Meg is látszik rajtuk. Monolitok, így egyetlen komponens hibája az egészet magával rántja. Egyetlen szerveren vagy egyetlen adatközpontban futnak, így ha éppen az esik ki, nincs hová átkapcsolni.
Ehhez jön a koruk. Egy részük olyan technológiára épül, amelyet már senki nem támogat, vagyis egy ismert sebezhetőség sosem kap javítást. És ha a kódot csak az eredeti szállító érti, az államnak nincs kivel versenyeztetnie a modernizációt.
Architektúraelvek a megbízható e-szolgáltatásokhoz
Design for Failure
Minden komponens meghibásodik egyszer, és a rendszernek ezzel előre számolnia kell. A circuit breaker levágja a beragadt függőséget, hogy egy lassú szolgáltatás ne rántsa magával a többit. A graceful degradation használhatóan hagyja azt, ami még működik, üres oldal helyett. Az automatikus failover pedig átteszi a forgalmat egy tartalék példányra anélkül, hogy bárkinek éjjel telefont kellene felvennie.
Observability az első naptól
Nem javíthatja meg azt, amit nem lát. Egy modern rendszernek négy dologra van szüksége egyszerre:
- minden log egy helyen, kereshetően
- valós idejű metrikák, vagyis CPU, memória, response time és error rate
- distributed tracing, hogy egyetlen kérés végigkövethető legyen a komponenseken
- alerting, amely megszólal, mielőtt az első felhasználó bejelentené a problémát
Nélkülük a leállás okának keresése találgatássá válik.
Skálázhatóság és redundancia
Egy kritikus szolgáltatásnak legalább két független környezetben kell futnia. A gyakorlatban ez több zónára vagy régióra kiterjedő telepítést jelent, load balancinget a példányok között, és olyan adatbázis-replikációt, amely magától átveszi a replikát. Ha egy helyszín leég, a forgalom máshol megy tovább.
Automatizált deployment és rollback
A manuális telepítés a katasztrófa receptje. Az automatizált teszteket futtató CI/CD pipeline előbb kapja el a hibát, mint a polgárok. A blue-green és a canary stratégia előbb csak a forgalom egy szeletére engedi ki az új verziót. És ha mégis elromlik valami, az előző verzióhoz való visszatérésnek percekbe kell telnie, nem órákba.
Átlátható kommunikáció a leállás alatt
Az ESKN-leállás megmutatta, hogy a kommunikáció ugyanolyan fontos, mint a technikai ellenálló képesség. A valós idejű status page megmondja az embereknek, hányadán állnak. Egy Facebook-poszt három órával később nem. A meghatározott válaszidőkkel bíró SLA súlyt ad ennek az ígéretnek, az incidens lezárása után pedig jelentésnek kell következnie a kiváltó okkal és azzal, mi változik, hogy ne ismétlődjön meg.
A terhelésteszt egyébként nem csak az indítás előttre való. A forgalom idővel változik, tehát a tesztelésnek együtt kell változnia vele.
Mit tanulhatunk a magánszektortól
A bankok, a webáruházak és a SaaS-cégek ugyanezekkel a kihívásokkal néznek szembe, és többségük már meg is oldotta őket. A különbség az ösztönzőben van. A magánszektor közvetlenül fizet a leállás minden percéért. A közszféra sosem kapja meg ezt a számlát.
A megoldás nem az, hogy az állam drágább technológiát vásároljon. Hanem az, hogy alkalmazza a már bevált mérnöki elveket.
A failover pedig nem bizonyítja az ellenálló képességet pusztán attól, hogy szerepel egy architektúradiagramon. Rendszeresen gyakorolni kell kontrollált átkapcsolással, mérni kell egy helyreállítási célhoz képest, és ellenőrizni kell valósághű terhelés alatt.
Amikor rendszert építünk, arra is gondolunk, mi történik, ha valami meghibásodik. Valami mindig meghibásodik. A kérdés csak az, hogy mikor.
Az állami e-szolgáltatások leállásai nem elkerülhetetlenek. Architekturális döntések vagy azok hiányának következményei. Azok az elvek, amelyek a magánszektorban működnek, a közszférában is működnek. Valakinek csak el kell kezdenie alkalmazni őket.
Ha olyan rendszert épít, amelynek megbízhatónak kell lennie, beszéljünk arról, hogyan érheti ezt el.