Základní registry byly 4 hodiny mimo provoz
Toto úterý měly základní registry čtyřhodinový výpadek, zapříčiněný blíže nespecifikovaným problémem v jednom ze dvou používaných datových centrech. Muselo dojít k přechodu do záložní lokality.
Základní registry jsou sice páteří (a tzv. backoffice) českého eGovernmentu, ale o jejich skutečné implementaci a spolehlivosti fungování se ví jen málo. Známy jsou pouze základní obrysy jejich architektury, a ze skutečně provozních statistik prakticky nic (ani v pravidelných zprávách o provozu ZR). O případných incidentech se ví ještě méně.
K určité výjimce došlo toto úterý, 25. března 2014, kdy samo Ministerstvo vnitra – někdy v poledních hodinách - zveřejnilo na svém webu informaci o „krátkodobém přerušení provozu základních registrů“. Na následujícím obrázku vidíte tuto zprávu z Google cache, protože na původním místě na webu MV ČR již k dispozici není.
Současně o této skutečnosti informovalo vnitro i na svém twitterovém účtu:
Správa základních registrů na svých stránkách příslušnou informaci (původně) zveřejnila také, byť méně viditelně – viz následující obrázek (zdroj) a na dalším obrázku pak proklik na samostatnou stránku:
Všechny tyto informace zmiňovaly, že k obnovení provozu mělo dojít do 15:30 téhož dne (úterý 25.3.2014). Minutu před 16. hodinou pak vnitro na svém twitterovém účtu informovalo o obnovení provozu základních registrů:
Pár minut předtím ale základní registry ještě nefungovaly úplně tak, jak měly: když jsem si jejich funkčnost testoval na žádosti o výpis (o využití údajů z registru osob), požadované údaje o mé osobě nebyly v registru ještě nalezeny. O den později již ano.
Co se stalo?
Co bylo příčinou onoho „krátkodobého přerušení provozu základních registrů“?
Server Novinky.cz se zeptal na vnitru:
Podle mluvčího resortu vnitra Pavla Nováka byl příčinou výpadku problém v datovém centru provozovaném Státní tiskárnou cenin.
Já jsem se dotázal přímo Správy základních registrů, a dostal následující odpověď:
Dne 25. 3. 2014 v 11:41 hodin vzniknul výpadek v datovém centru.
Správa základních registrů okamžitě provedla analýzu incidentu a byl vydán pokyn k přechodu zpracování služeb základních registrů do sekundární lokality.
Do 4 hodin, jak stanoví architektura základních registrů, byla obnovena dostupnost služeb základních registrů v plném rozsahu.
Nechme stranou to, že podle mého zjištění (viz výše) základní registry ještě plně nefungovaly ani v 15:52, a tedy více jak 4 hodiny po vzniku výpadku. Podstatnější je důvod výpadku – ale o tom oficiální zdroje bohužel mlčí.
Proč přechod do záložní lokality?
Další podstatnou věcí je to, jak mohl problém v jednom datovém centru (ať už byl jeho důvod jakýkoli), znamenat okamžitý výpadek celého systému základních registrů. Znamená to snad, že takto životně důležitý systém, který by měl být skutečně trvale dostupný, naopak má klasický „single point of failure“? Proč vnitro i Správa základních registrů hovoří o „přechodu do náhradní lokality“?
Připomeňme si v této souvislosti, že základní registry využívají dvou datových center: tzv. Národního datového centra v areálu Státní tiskárny cenin (obrázky z exkurze), a dále datového centra České pošty. Stejně tak si ocitujme následující informaci ze zprávy o provozu základních registrů za první půlrok:
Od října minulého roku je provoz základních registrů zajištěn ve dvou státních datových centrech, Státní tiskárně cenin a České poště, čímž se podařilo dosáhnout kýžené mety nepřetržitého 24hodinového provozu a zajistit plnou redundanci provozu, neboli zastupitelnost jedné lokality druhou.
Znamená to tedy, že základní registry sice využívají dvou lokalit (dvou datových center ve dvou různých lokalitách), ale nikoli takovým způsobem, aby to tvořilo skutečný „cloud“, resp. tzv. HA (High Availability) cluster, v rámci kterého ani výpadek jedné lokality ještě neohrozí celkové fungování systému?
Asi ano, viz následující vyjádření Správy základních registrů:
V roce 2012 byla Správě základních registrů k provozování předána architektura základních registrů dle detailního návrhu implementace tak, aby v případě výpadku jedné lokality Správa základních registrů obnovila služby do 4 hodin v záložní lokalitě. Současná technologie základních registrů není koncipována na plynulý přechod z jednoho do druhého datového centra, toto lze zajistit změnou koncepce zpracování služeb v informačních systémech základních registrů.
Nebyl to jediný problém
Jak jsem již psal výše, informace o provozní spolehlivosti a případných problémech základních registrů nejsou moc dostupné. A když už se nějaké objeví, tak zase rychle zmizí – viz výše, kdy informace o popisovaném úterním výpadku zase rychle zmizely jak z webu MV ČR, tak i z webu Správy základních registrů.
Obávám se, že takovýto přístup „na schovávanou“ rozhodně neprospívá pozitivnímu vnímání eGovernmentu a jeho jednotlivých součástí. Již jen proto, že dává vzniknout otázkám na to, co dalšího se stalo, ale neví se o tom.
Shodou okolností zrovna nedávno mne jeden čtenář (z oblasti veřejné správy) upozornil na zvláštní problém v rámci základních registrů: projevuje se tím, že když úředník při zcela standardním úkonu zadá správnou adresu (vybranou z číselníků), následný úkon se provede s chybnou (starší, neaktualizovanou) adresou, kterou také obsahuje příslušný výstup.
Podstata problému je zřejmě v tom, že nedochází ke správné aktualizaci a replikaci dat v rámci základních registrů. Kvůli tomu pak některé agendové informační systémy dostávají nesprávné referenční údaje, které ale musí považovat za správné a jako s takovými s nimi nakládat. Ale ani úředníci nejsou upozorněni na to, že by aktuálně byl kolem základních registrů nějaký problém.
Když jsem zjišťoval souvislosti, dozvěděl jsem se z neoficiálních zdrojů, že od pátku 14.3. měly být zastaveny replikace z ISUI a ISKN do RUIAN, a celý problém (prý dost závažný a „na delší dobu“) má být řešen s dodavatelem. Ve středu 19.3. pak mělo být nasazeno dočasné řešení, spočívající v přechodu na asynchronní způsob komunikace.
No a oficiální vyjádření Správy základních registrů ze 20.3., v odpovědi na můj dotaz, bylo následující:
Výpadek, o kterém se zmiňujete, byl řešen standardní cestou (prostřednictvím založeného requestu a incidentu v Service Desku SZR). Problém byl vyřešen v zákonné lhůtě. Provoz zajišťující zpracování služeb ISZR poskytovaných RÚIAN byl obnoven v plném rozsahu.
Jenže podle čtenáře, který mne na celý problém upozornil, se ani poté nic nezměnilo a chybný stav přetrvával i nadále.