Dr. Morcz elkövetett egy kintűnő posztot a magyar egészségügy (és úgy általában az állami szervek és szolgáltatások) egyik komoly problémájáról, azaz az információ áramlás és rögzítés hiányosságairól.

A kommentek között felmerült, hogy ennek az esetleges professzionális megoldása miért kerülne pusztán üzemeltetésileg is havi több száz millió forintba, éves szinten akár 2-3 milliárdba? (és erre rakódna rá a tárgyi eszközök beszerzése és az infrastruktúra kialakítása előzményként, amiknek a költségeit még megbecsülni sem merem)

Az ár kérdése - mint mindig - attól függ, hogy mik az elvárások. A klasszikus elvárások egy informatikai rendszerrel kapcsolatban a következők: nagy rendelkezésre állás, maximális adatbiztonság, alacsony válaszidő, bővíthetőség és átadhatóság. Hogyan lehet ezeket mind megvalósítani, és az miért ilyen drága?

Kezdjük az elején. Milyen formában kívánjuk ezt megvalósítani? A 100%-os kiszervezést ilyen kényes és érzékeny adatoknál én magam se támogatom, hiszen hiába tulajdonosa az állam az adatoknak, ha a szolgáltatóban nincs tulajdonrésze, úgy csak körülményesen tudja azok biztonságát és az egyéb folyamatok betartását felügyelni. Teljesen állami tulajdonban üzemeltetve a költségeket és a hatékonyságot képtelenség kézben tartani, hiszen ha az állam saját magával szerződik, az azt jelenti, hogy pártalkuk kérdésévé degradálnánk, és teletömnénk káderekkel, majd az egészet megfejelnénk közbeszerzéssel és a költségvetés - így a szolgáltatásra szánt összeg - percenkénti újraszabásával, vagyis tömören tervezhetetlen és felügyelhetetlen lenne.

Maradna egy vegyesvállalat, ami természetesen azt is magában hordozza, hogy egyrészt a privát partnernek az állam nem csupán működési költséget, hanem hasznot is fizet, továbbá a szerződéses tételek az államháztartás pillanatnyi állapotától és a tényleges működési költségektől függetlenek lennének, viszont mind az állam, mind a privát partner osztoznának a kockázaton is.

A kockázatvállalást és a szolgáltatást az úgynevezett szolgáltatási szint szerződés (SLA) szabályozza. Fő eleme - sok egyéb paraméter, így a már említett válaszidő és biztonság mellett - a rendelkezésre állás: ennek a kitételnek a teljesülése határozza meg az üzemeltetés költségeinek a fő számait. A rendelkezésre állás pusztán egy 0 és 100 közötti százalék, mondjuk 99.96%. Ez azt jelenti, hogy a szolgáltatás adott paraméterekkel és egyéb feltételek nem sérülésével a szerződésben meghatározott időtartam 99.96%-ban elérhető, nem számítva a tulajdonos kéréseiből és az esetleges rendszeres karbantartásból és egyéb, szintén szerződött rendszeres tevékenységekből származó kieséseket vagy lassulásokat.

Egy országos egészségügyi nyilvántartó rendszernél, amiben nem csupán a társadalombiztosítási jogállást és egyéb alapadatokat tartanánk nyílván, hanem valamennyi beteg teljes kórtörténetét, a szerződéses időtartam napi 0-24 óra, évi 365 nap - vagyis non-stop szolgáltatás. Ebben az esetben a 99.96%-os rendelkezésre állás azt jelenti, hogy az év 8760 órájából a szolgáltatás kiesés 3.5 óra lehet - a cél ugyanis az, hogy az egészségügyi szolgáltatás NEM ÁLLHAT MEG! Amennyiben ez nem teljesül, úgy a szolgáltató súlyos kötbért fizet, rosszul megtervezett szolgáltatásnál akár veszteséges is lehet (előfordul a nagyokkal is).

Hogyan lehetséges egy ilyen első látásra irreálisnak tűnő feltételt teljesíteni? Redundanciával.

Telephely (site)
A szolgáltató cégnek négy telephellyel kell rendelkeznie: két szerverközponttal, egy felügyeleti központtal, és egy tartalék felügyeleti központtal. A két szerverközpont teljesen azonosan van felszerelve, azaz minden eszközt és beszállítói szolgáltatást duplán kell kalkulálni. Az elsődleges felügyeleti központ és a tartalék felügyeleti központ felszereltsége eltérhet az elsődleges javára.
Miért kell a telephelyet duplázni?

Csinálunk egy szerverközpontot Budapestre, egyet meg mondjuk Debrecenbe. Amennyiben a budapestivel bármi történne - elvágják az áramot, a hálózati kapcsolatot, elárasztja a víz, tűz üt ki, elfoglalja az alkotmányozó nemzetgyűlés - úgy a szolgáltatást fél órán belül vissza kell állítani, ez pedig csak úgy lehetséges, ha van tartalékban egy ikre, aminek az üzembe helyezéséhez elég az interneten elfordítani néhány kapcsolót, és máris oda érkeznek a bitek - ez persze azt is jelenti, hogy a debreceni központ is folyamatosan teljes árammal üzemel, és várja, hogy történik-e bármi baj a budapestivel. A távolság az olyan események miatt indokolt, amik tartósan ellehetetlenítik akár egy egész város működését is: földrengés, árvíz, lázongások - mindaz, amit egy biztosítás kötésekor a vis major apró betűs magyarázata alatt találnánk. Vagyis a továbbiakban minden olyan költséget, ami a szerverközponttal kapcsolatos, tessék fejben megszorozni kettővel.

A felügyeleti központ duplázása is ugyanezen okokból indokolt. A hatékony üzemeltetés megoldásához komoly felügyeleti infrastruktúra tartozik, ellenkező esetben az üzemeltetéshez szükséges információk hatékony feldolgozása sérül, és az esetleges problémákra adott korrektív válaszreakciók késnek. A másodlagos felügyeleti központ szükségmegoldásként van tartalékban, vagyis a szerverközponttal ellentétben használaton kívül nem üzemel. A felügyeletet ellátók képzése és az információk kényes volta miatt a személyzetet nem lehet duplázni, így a két felügyeleti központ szükségszerűen ugyanabban a régióban, egymástól maximum fél órányira található. Végszükség esetén megoldható az elosztott felügyelet is, amikor a felügyeletet ellátók az erre a célra kiosztott eszközökkel akár otthonról is képesek minimális szolgáltatást nyújtani, ám ha a helyzet eddig fajul, könnyen meglehet, hogy már nincs is szükség egészségügyre.

Mit kell még duplázni?

Induljunk az alapoktól. Duplázni kell a telephely áramellátását és hálózati kapcsolatát, külön szolgáltatókkal: ezekre azért van szükség, hogy ha bármilyen gond történne a fizikai infrastruktúrával, a szolgáltatás folytonossága ne sérüljön, továbbá, ha bármely szolgáltatóval kötött szerződéssel gondok lennének az alvállalkozó váltás is zökkenőmentes legyen. Minimum duplázni kell minden egyes szervert, amit funkciótól és a várható terheléstől függően lehet többszörözni is, így a terhelés a felhasználó számára láthatatlanul oszlik meg az azonos funkciójú gépek között. Az egyes szervereknek duplázni kell szintén az áramellátását, a hálózati hozzáférését, a belső tárhelyét paritással konfigurálni, valamint nem árt a belső hálózati eszközöket is redundánssá tenni.

Itt viszont már érintettük is az alacsony válaszidőt, a bővíthetőséget, és az adatbiztonságot - folytassuk a továbbiakban az utóbbival.

Adatbiztonság

A adatbiztonság egyrészt a szerverközpontok védettsége minden külső behatástól és behatolástól - akár fizikai, akár hálózati támadás -, másrészt annak a biztosítása, hogy bármely adatvesztés vagy sérülés esetén az adatokat vissza tudjuk állítani.

A fizikai védelem tulajdonképpen egy föld alatti bunkert jelent, ami véd akár egy rázuhanó repülőgéptől is, valamint védett az elektromágneses impulzusoktól. Maga az objektum nemzetbiztonsági szempontból a legmagasabb kategóriába kell, hogy tartozzon - csak gondoljunk bele, mivel járhat az itt tárolt adatok illetéktelen eltulajdonítása, így mind a védelemnek, mind a beléptető rendszernek és protokolloknak ezt kell tükrözniük. (ez mondjuk egy meghibásodott hardver eszköz cseréjekor, amikor a gyártó a garanciális szerződés alapján kiküldi saját technikusát a csereeszközzel, elég pikáns tud lenni - gyakorlatilag ott kell állnia mellette két embernek, akik nézik, amit a csavarhúzós ember csinál)

Szintén a fizikai védelemhez tartozik a több évtizedekre eltárolt biztonsági mentések védelme: bunker a bunkeren belül, hatalmas, bankokat megszégyenítő páncélajtóval, automata CO2 oltórendszerrel. (jártam már olyanban, ami azt is túlélné, ha egy atombomba robbanna az épület fölött - több tíz kilométeres körzetben mindenki meghalna, de az ott tárolt biztonsági mentésekből vissza lehetne állítani az adatokat, és ez most nem nagyzolás, ezt tényleg így csinálják, pedig azok nem egy állam összes állampolgáráról szóló nyilvántartások)

A biztonsági mentésnek három fajtáját tudjuk használni: image (bocs, nem tudok rá megfelelő magyar szót), naplózás és külső mentés.

Az image pillanatfelvétel az adott gépen található adatokról, operációs rendszertől kezdve az összes telepített programon át a beállításaikig mindenről. Kitűnően alkalmas olyan szerverek mentésére, amik nem üzemeltetnek adatbázisokat, rajtuk a felhasználók által kezdeményezett adatváltozás minimális: ilyenek az alkalmazás szerverek, terminál szerverek, stb. Helyigényük az adatok kis mennyisége miatt kicsi, és szinte percek alatt helyreállítható (újrahúzható) egy szerver belőlük bármilyen adatsérülés vagy olyan változtatás után, aminek a kimenetele kedvezőtlenül hat a rendszer működésére. (tipikus példa a programjavítások telepítése: a program forgalmazója nem tud minden csatolt termékkel kompatibilitási tesztet végezni, így minden egyes program minden egyes változtatása igazából lutri - ezért kell minden egyes változtatás előtt egy működőképes állapotot lementeni, amit bármikor, akár a változatás után hónapokkal később is, amikor a hibák a felszínre jönnek, visszaállíthatunk)

A naplózás a legjobb módja az adatbázisok mentésének: minden egyes adatváltoztatáskor lementésre kerül az adat kiinduló változata, a változtató parancs és az új adat a naplóba (journal, nem pedig log, az más), míg magában az adatbázisban csak az adat legutolsó verziója marad. Helyigénye óriási, mivel mérete a szintén óriási adatbázisnak gyakorlatilag a háromszorosa, viszont megkapjuk vele azt a lehetőséget, hogy nem csak egy adott nap vagy óra (attól függ, hogy milyen gyakoriságra van beállítva) végi adatbázis állapotot tudunk visszaállítani, hanem akár egy tetszőlegesen kiválasztott adatmódosításig vissza tudjuk pörgetni az eseményeket, javítani, és az összes utána következő módosítást újra megejteni, automatizálva persze.

A naplófájlokat évekig megtartani a szerveken fizikai képtelenség, egész egyszerűen nem lenne az a számítási kapacitás, ami megérné. Itt jön be a képbe a külső adathordozókra történő mentés, ami általában még mindig mágnesszalagot jelent, bár a tíz évvel ezelőttiekkel összevetve rájuk se ismernénk. A naplófájlok bejegyzéseit előre beállított időintervallum szerint avultatnánk, mondjuk a szervereken található naplófájlok csak az elmúlt egy hónap adatmódosításait tartalmaznák (ezek lennének on-line elérhetők), és minden ennél idősebb módosítást naponta, óránként, két óránként (ahogy tetszik) lementjük külső adathordozóra (ezek lesznek szükség szerint elérhetők, de nem igazán off-line), valamint ez egy évnél vagy két-három hónapnál (megint csak ahogy tetszik) idősebb külső adathordozókat visszük a páncélba. Ezeken a rendszeres mentéseken kívül készítünk teljes külső mentést az adatbázisainkról heti ill. havi (vagy akár napi) rendszerességgel, amit a mentés befejeztével szintén elzárunk. A külső mentéssel helyet szabadítunk fel a naplófájlokban, illetve abszolút biztonságos körülmények közé helyezzük az adatbázisaink pillanatfelvételeit, hogy egy igazán nagy katasztrófa vagy adatvesztés után se kelljen mindent a nulláról kezdeni.

Az adatbiztonsággal átlapolva meg kell említenünk a hálózati biztonságot (itt a különböző technikákat nem fogom se felsorolni, se részletezni, egyrészt mert ehhez a részhez annyira nem értek, másrészt ez még az informatikán belül is gyakorlatilag egy külön világ - egy profi hálózatbiztonsági szakember megkapja a súlyát aranyban, és ez megint nem túlzás). Ott van ugye az iker szerverközpontunk, ugrásra készen - de az adataink a pillanatnyilag működő szerverközpontban keletkeznek, így azokat át kell "vinnünk" a tartalék helyre. Ez nem megoldható a külső biztonsági mentések szállításával, egyrészt a plusz biztonsági kockázatok, másrészt az időigénye miatt - maradna a hálózati szinkronizálás, amihez olyan vonal kell, aminek az éves bérleti díja egy kistelepülés éves költségvetésével vetekszik.

A válaszidő a rendelkezésre állás mellett a másik olyan mérhető paraméter, ami a szolgáltató tényleges díjazását meghatározza. Kényes kérdés, mivel a szolgáltató – ahogy az egy lakossági internet szolgáltatónál is gyakorlat, tessék megnézni a szerződését, ott vannak benne a rendelkezésre állás és a minimális szolgáltatási paraméterek abban is – ez esetben csak a központi infrastruktúrára vállal kötelezettségeket, így a távoli eléréseket mérni csak úgy lehetne, ha a központi infrastruktúra üzemeltetője (aki ugyanúgy vásárolná a szükséges hálózati hozzáféréseket, csak a szerződések központosítva és valamennyire hangolva lennének) leszerződnénk legalább a nagyobb intézetek (kórházak például) összekötésére. A kisebb, magánúton járó intézetek esetében a válaszidő a központi infrastruktúra válaszidejére vonatkozna csak, így a hálózati szolgáltató rendszerében keletkezett problémák esetén a központi infrastruktúra üzemeltetője széttárná a kezét.

Ezen is lehetne segíteni két módon: az egyik a redundancia bevezetése a kis intézeteknél is (vezetékes mellé mobilinternet például), valamint a terminál technológia kiajánlása. Ez utóbbi esetén a kisebb intézeteknek – de akár a nagyobbaknak is, ha úgy döntenek – semmiféle központi infrastruktúrát nem kellene fenntartaniuk helyileg, hiszen minden adatrögzítés és kérés egy terminál ablakban történne, ami azt tudja, hogy egy távoli gép képernyőjének a képét jeleníti meg, így az adatbeviteli program maga a központi infrastruktúrában futna, érzetre viszont majdnem olyan lenne, mintha helyben. A hálózati adatforgalom így a töredékére csökkenthető, hiszen még egy kliens-szerver felépítésű adatbázisprogram esetében is egy lekérdezés eredményét teljes egészében át kell küldeni mondjuk Debrecenből Karakószörcsögre (ami igazából Karakószörcsök), míg a terminálnál csak a lekérdezés eredményének a képét, amit a felhasználó a képernyőjén látna, hogy ha a program helyben nála futna (sőt, igaziból csak a képernyő változásait küldik át a kliens fele, a szerver fele pedig csak az egérkattintások pozícióját és a billentyűlenyomásokat, és abból számolja ki a szerver, hogy az adott koordinátán egy kattintás mögött ikon, gomb vagy beviteli mező van-e – spórol a hálózattal, na). Ja, és very-very secure. Persze mindezek a megoldások (plusz mobilinternet, plusz adminisztráció a központi szolgáltató részéről) jelentősen megdobják a szolgáltatás árát.

Most pedig jöjjön a bővíthetőség. Bővítésre illetve változtatásra szükség van. A terhelés és az igények folyamatosan változnak: vágyálmaim között szerepel, hogy előbb-utóbb az informatika eléri a magyar államigazgatást is legalább egy közepes bank szintjén, és a különböző szervek és szervezetek, hatóságok is hasonló konstrukciókat valósítanak meg, és a rendszereket egymással összekötik és egymás számára átjárhatóvá teszik. Változtatásra ezen kívül szükség van még a különböző eszközök elhasználódása, a programok frissítése, illetve az adattulajdonos igényeinek változása miatt (huhú, ott aztán vannak csúnya dolgok). Itt csatolunk vissza a redundanciához: ahhoz, hogy a bővítések illetve a változtatások kivitelezhetőek legyenek, szükség van a redundanciára minden szinten. (és akkor még nem említettem a különbséget a produktív, a teszt és a fejlesztői rendszerek között)

Meg kell említenünk még egy nagyon fontos dolgot: az átadhatóságot. A teljes rendszert úgy kell kiépíteni, az üzemeltetést, a folyamatokat, a dokumentálást úgy megvalósítani, hogy az másfél-két hónap alatt átvihető legyen egy másik szolgáltatóhoz szolgáltatás fennakadás vagy minőségromlás nélkül (good luck - ilyenről még csak nem is hallottam, hogy ez valaha valahol sikerült volna, pedig 8 éve csinálom, de meg kell próbálni, hátha). Tulajdonosként elemi érdekünk a tulajdonunk védelme, és - mint már mondtam - az egészségügyi ellátás NEM ÁLLHAT MEG!

Így visszagondolva a poszt elején említett havi több száz millió forintra úgy érzem, igen szerényen számoltam: igazgatótól a fejlesztőkön és üzemeltetőkön át a biztonsági személyzetig és a takarítókig ez úgy lazán 150 fő, akiknek pusztán a fizetési vonzata havi 150-200 millió forint. És akkor nem számoltuk a vásárolt szolgáltatásokat és a fenntartási költségeket, mint bérleti díjak, áram, hálózati kapcsolat, stb., stb.

Legyen évi 6 milliárd alsó hangon. Plusz a tiszteledíjam, persze, ami majdnem ugyanennyi, de az csak egyszeri kiadás.