Egyik legjobb barátom szerint amivel én foglalkozom arra a legjobb elnevezés a "Management bullshit". Ezzel azt akarja mondani, hogy földi halandó által érthetetlen kifejezéseket használunk és olyan dolgokkal (IT Szolgáltatás Menedzsment) töltünk egy csomó időt, illetve ügyfeleink olyasmiért fizetnek a munkaidőnkért (adott esetben az enyémért) nem csekély összegeket, ami földi halandót valójában soha nem érint. Így aztán azt gondoltam, hogy a magyarorszag.hu körüli utóbbi időben jelentkező hűhóra egy kicsit ránézek szakmai szemmel, hátha valakit érdekel, hogy mégis miért hasznos ez az egész dolog amit csinálunk.

Előre bocsátom, hogy nincs időm részletes és tartalmas elemzést csinálni (akár azt is mondhatnám, hogy mint konzulens cég megkereshetőek vagyunk, de egyszerűen csak arról van szó, hogy a dolog hosszabb elemzést és több információt igényelne). Így aztán inkább csak szemezgetek és felvetek pár dolgot gondolatébresztőként.

A dolog hátteréül, ha valaki nem hallott volna, érdemes elolvasni a kormányzati portál összeomálásról szóló híradásokat. A portál egyébként az utóbbi időben többször is rendetlenkedett, de most csak ezt az egy esetet fogom megnézni. A leállással kapcsolatban több elemzés is napvilágot látott, bár az elemzések és a hozzájuk kapcsolódó megjegyzések nagy része a technológia körül zajlik, ezzel túl sokat nem szeretnék foglalkozni. Bár kétségtelenül az architektúra, technológia fontos (és ez is része a Szolgáltatásmenedzsment körébe tartozó dolgoknak), ezzel nagyon sokan foglalkoznak, nagy mennyiségű szakember (és szakbarbár) is van az országban.

Ezzel szemben az üzemeltetési módszertan jóval kevésbé ismert. Márpedig a leállásról szóló hivatalos jelentés elsősorban üzemeltetési eljárásrendbeli hiányosságokat talált, ezek (pontosabban az eljárásrend be nem tartása) voltak a fő okozói a leállásnak. Akkor innentől következzék pár dolog, ami az eset kapcsán eszembe jutott, és konkrétan a fenti jelentés elemzése, kifejezetten IT Szoláltatás Menedzsment szemüveggel.

Ami a technológia választást illeti, sokan tudjátok, hogy én technológia semleges vagyok. Egyetlen dolgot utálok: amikor valaki logikátlanul védi vagy ellenzi egyik, vagy másik (vagy harmadik) platformot. Így aztán üzemeltetési szempontból édes mindegy, hogy ki milyen platformra fejleszt. Ami viszont üzemeltetési szempontból mérlegelendő, az egy szolgáltatással (jelen esetben a kormányzati ügyfélkapu, már ha ez egyetlen szolgáltatásnak minősül) szemben támasztott teljes követelményrendszer. ITIL v3 terminológia szerint a követelmények egy szolgáltatással szemben két csoportra oszthatóak: a szolgáltatás hasznosság (utility), amely kb. azt takarja, hogy a szolgáltatás mit "csinál", és a szavatosság (warranty) keretébe tartozó követelmények. Az utóbbira, durva megközelítéssel fogalmazva a Szolgáltatásmenedzsment eszköztárában a Szolgáltatási szint menedzsment (Service Level Management) fog megfelelő mérhető vállalásokat tenni, azaz az SLA-ban (Service Level Agreement) lesz dokumentálva az, hogy az informatikai szolgáltató milyen paraméterekkel vállalja a szolgáltatás üzemeltetését. Ez persze nem minden - egy papír önmagában csak a papírt magát éri. Aki tisztességesen végzi a szolgáltatás menedzsmentet, az az SLA egyeztetés és megkötés közben gondoskodik arról, hogy az abban foglalt összes vállalás teljesíthető is legyen. Magyarul minden, a szolgáltatást összetevő komponenset végignézve biztosítja, hogy az összes láncszem együtt működve kiadja a megfelelő működést. Itt jön be a képbe a technológia kiválasztása. Egészen konkrétan a jelentés azon megállapítása, miszerint:

A hasonló hibajelenségek internetes keresése során sikerült olyan leírást találni, amely a bekövetkezett hibára jelentős mértékben hasonlít. Az interneten fellelt információk csak a hiba lehetséges okát nevezik meg, teljes bizonyossággal egyik leírás sem szolgál. A jelenséget egy nyílt forráskódú alkalmazás igen ritka – eddig pontosan nem behatárolt – körülmények között bekövetkező hibája okozta.

A lényeg, szolgáltatás menedzsment szemszögből NEM a szerző által kiemelt, hanem az azt megelőző mondatban keresendő. A nyílt forráskódú, pontosabban a közösségi programok Achilles-ina ugyanis éppen az, hogy nem elérhető hozzájuk meghatározott válaszidőkkel, garanciákkal rendelkező támogatás. Természetesen a nyílt forráskódot végig lehet tanulmányozni, de senki nem fogja tudni garantálni, hogy a hibát a szolgáltatás üzemeltetési paraméterein belül meg is fogjuk találni (ha egyáltalán). Ez a tényező pedig sokkal de sokkal fontosabb érv egy komoly elvárásoknak megfelelni kívánó szolgáltatás esetében a platform és a felépítő komponensek kiválasztásához, mint az, hogy mondjuk szeretjük-e a gyártót. A helyzet az, hogy az SLA-t megfelelően támogató háttérmegállapodások (Operational Level Agreement, Underpinning Contract) csak létező, megfogható szervezetekkel köthetők, ráadásul olyanokkal, amelyek elég stabilak és elég nagy kiépített bázissal rendelkeznek ahhoz, hogy ne jelentsenek önmagukban rizikót. Egy ország eKormányzati portálja mögé teljes joggal szerződik az állam egy akkora céggel, mint a Kopint-Datorg, és nem adja a fejlesztést és üzemeltetést kisvállalatok kezébe, nem azért, mert nem bízna az ottani szakembergárdában, hanem azért, mert egy nagy és megalapozott cég általában véve megbízhatóbb, kiszámíthatóbb, jobban számon lehet kérni, és nagyobb eséllyel fogja tejesíteni a komoly elvárásokat. (Persze mint láthatjuk, ez önmagában nem garantálja a zökkenőmentes működést, de mindenesetre nagyobb rá az esély.)

Beszéljünk egy picit magáról a jelentésről. A jelentés maga eléggé széles körben elemzi a kiesést, annak okait és körülményeit. Informatikai menedzsment szempontból a jelentés közepesen jónak mondható. Az elsődleges problémám vele, hogy nem egyértelmű, a jelentésnek ki a címzettje. Így azután a felépítésével is nehéz vitatkozni, hiszen - és ez alapelv - egy jelentés szükséges tartalmát az határozza meg, hogy kinek szól, vagyis mi a célja. Ezt egy szakszerű jelentés amúgy első bekezdésében szokta tartalmazni. 

Ránézésre egyébként a jelentés (megint csak Informatikai menedzsment szemszögből) leginkább egy Major Incident Report (magyarul Súlyos Incidens Jelentés) és egy Security Incident Report (Biztonsági Incidens Jelentés) keverékének tűnik. Előbbi esetében elvárható az incidens leírása, időpontok megjelölésével (ez megtörténik, bár már itt keveredik az események leírása az elvárt tevékenységek leírásával), az érintettség (impact) részletezésével (ez az "Első megállapítások" címszó alatt szerepel lényegében), a kiváltó ok jelenlegi státusza (ismert-e, vagy nem, ha nem, akkor milyen akciók léptek életbe a feltárás érdekében és mik a következő lépések - ez szintén szerepel a jelentésben). A kiváltó ok részletezése ugyanakkor nem feltétlenül szükséges, hogy részleteiben szerepeljen egy MIR-ben, és itt hoznám fel ismételten azt, hogy kinek szól a jelentés. Egy MIR tipikusan menedzsment, azaz az irányítók számára készül, abból a célból, hogy meggyőzödhessenek róla, az eset kézben van tartva, és az intézkedők megkaphassák a szükséges vezetői támogatást (például pénzt) annak érdekében, hogy az eset újbóli előfordulása meg legyen akadályozva. Mivel a menedzsment jellemzően nem technikusokból áll, ennek a közönségnek teljesen felesleges az adott jelentésben szereplő mélységig elmenni (DoS támadás emlegetése, a gyorsítótárazás működésének elemzése stb). Természetesen ezeket az elemzéseket el kell végezni, azonban ezeket nem itt, egy ilyen jelentésben kell részletezni - az eset dokumentálására szolgáló Probléma jegy adataiban kell ezeket dokumentálni (amely kifejezetten szakmai), illetve a biztonsági incidens adataiban, amennyiben a biztonsági elemzés részleteiről beszélünk. Szakmai szempontból ezen részletek publikálása bár nem hatalmas hiba, de mindenesetre a jelentés így tartalmaz jó néhány technikai részletet, amelyek publikálása akár valamennyire segítheti egy esetleges rosszindulatú betörést tervező hacker dolgát. Túlságosan azért persze nem vészes a publikált infomráció mélysége, de 1-2 plusz kör futását megspórolhatja.

A jelentés ugyancsak tartalmaz egy részt, és ez itt számunkra a leglényegesebb, amely az eljárásrend és jogszabályok esetre értelmezését boncolgatja. Mind egy MIR illetve SIR esetén fontos része a jelentésnek az, amelyben megvizsgáljuk, vajon 1.) Mindenki az érvényes szabályok szerint járt-e el és 2.) Az érvényes szabályok megfelelők-e, vagy azok javítása szükséges.

A jelentés mindkettőt boncolgatja, és ennek keretében elég sok részlet megtudható az üzemeltetési eljárásokról. Az idézett eljárások alapján látszik, hogy az üzemeltetéssel szemben támasztott elvárások (az azok íróinak tudtával vagy azon kívül, de) nagymértékben a szolgáltatásmenedzsment elvek mentén készültek. Ezek nagy része helyesnek tűnik (részletes ismeret és kontextus hiányában biztosat nem lehet mondani se pro, se kontra).

Megemlíteném, hogy jelentés egyben kezeli a felelősség, az eljárásrend betartása/megfelelése és a szolgáltatási szint vállalásokra vonatkozó megállapításokat. Bár látszik, hogy az egyes témakörök nincsenek összekavarodva, azzal, hogy nem választja szét ezeket, megint csak azt mutatja, hogy nem tiszta, mi is a jelentés célja valójában:

1. Az eljárásrend megfelelőségét azért kell megállapítani, hogy ha szükséges, lehessen javítani azokon. Ennek a céltábora tehát az üzemeltetést felügyelő menedzsment/megrendelő. Ilyen jellegű megállapítás, elemzés a jelentésben egyáltalán nem szerepel. A vonatkozó szabályok ugyan szerepelnek, de arra vonatkozó elemzés, hogy a szabályok/eljárások maguk megfelelőek lettek volna (ha betartják őket), vagy sem, nincsen. Ezzel a mulasztással a megrendelő, szabályozó szervezet elmulasztja azt a lehetőséget, hogy egy éles eset kapcsán javítson magán a szabályozáson. (Ismétlem, itt nem felelősségről van szó, hanem annak a Szolgáltatás Menedzsment Folyamatos Szolgáltatás Fejlesztés (Continual Service Improvement, CSI) nem teljes körű figyelembe vételéről).
2. Az eljárásrend betartását azért kell megállapítani, hogy az üzemeltetésért felelős vezetők és beosztottak munkáját meg lehessen ítélni, illetve a szükséges lépéseket meg lehessen tenni annak érdekében, hogy a későbbiekben a folyamatok be legyenek tartva (ha itt nem voltak). Előfordulhat, hogy nem egyszerű trehányságról van szó, hanem pl. megfelelő oktatás hiányáról, információhiányról, az adott folyamattámogató eszközök hiányosságáról. Ez a rész tehát azért fontos, hogy a következő lépéseket meg lehessen tenni, és a megállapítások elsősorban az üzemeltető szervezetre vonatkozó visszajelzés, az ottani vezetőkhöz szól. A jelentés bőségesen tartalmaz ilyen jellegű megállapításokat (pl. "tekintettel arra, hogy a változás a Működtető (kapcsolattartó) által nem lett jóváhagyva, megsértették a Változáskezelési Szabályzat 7.§ (1) pontját", de lehetne még sorolni), sajnos azonban tovább nem megy. Természetesen az elkövetkezendő lépések megtétele az üzemeltető feladata, így nem biztos, hogy ezek felsorolása éppen egy ilyen dokumentumtól (amely ráadásul nyilvánosságra kerül) várható. Bár nem tudhatjuk, hogy az Üzemeltető mi módon tervezi (ha tervezi) az eljárások kijavítását, mindenesetre ebből a jelentésből még nem következik, hogy ez meg fog történni (Esetleg, ha a jelentés célja meg lenne fogalmazva, erről többet lehetne következtetni).
3. A szolgáltatási szintnek való megfelelés ezzel szemben ismét külön témakör kell, hogy legyen. Egy kicsit boncolgassuk, miért is zavar ezzel a jelentéssel kapcsolatban a szolgáltatási szint félreértése. Egy SLA jellemzően mérhető paraméterek vállalását tartalmazza, amelyek egy időszakra vonatkoznak. Ez pl. olyan vállalásokat jelent, mint amilyen a jelentésben is idézett havi rendelkezési állás: "a kormányzati portál üzemeltetője biztosítja az elektronikus szolgáltatás folyamatos, havi szinten legalább 99,5%-os szintű elérhetőségét a kormányzati portálon". Emellett az SLA tartalmazhat (bár ritkán teszi) esetlegesen egyedi esetre vonatkozóan minden esetben teljesítendő vállalásokat (például hogy katasztrofális incidens esetében minden esetben X percen belül helyreállít bizonyos funkciót). A gond ez esetben az, hogy egy MIR vagy SIR szükségképpen egyetlen incidenst vizsgál, míg az SLA-ban szereplő vállalások általában egy időszakra vonatkoznak. A fent idézett havi rendelkezésre állás idézése ebben a jelentésben teljesen felesleges - a havi rendelkezésre állást csak a hónap végén, az összegzett adatok alapján lehet megállapítani. Az utóbbi, azaz minden egyes kiesésre vonatkozó mérőszámot a jelentés nem említ (könnyen elképzelhető, hogy nem is létezik, nagyon ritkán szerepel olyan vállalás egy tisztességesen letárgyalt SLA-ban amely ilyen jellegű, hiszen 100%-os teljesítés nem garantálható, mindig vannak előre nem látható események. Maximum akkor vállal be egy ilyet egy cég, ha bevállalja a szerinte minimális rizikót, hogy bekövetkezik egy ilyen esemény). A jelentés ugyan lebegtet néhány dolgot ezzel kapcsolatban (pl. "Az Üzemeltető nem teljesítette a (...) kötelezettségét, miszerint 20 percen belül mindenkit tájékoztatnia kellett volna a hibáról" ), de nem világos, hogy itt eljárásbeli hibáról van-e szó (lásd előző pont), vagy konkrét szolgáltatási szint sértésről.
   Ez a kérdés megint csak azért fontos, hogy a következő lépéseket ki tudjuk deríteni. SLA nem teljesítés esetén ugyanis a szerződés rendelkezik (normál esetben) arról, hogy mi a teendő - milyen büntetést kell fizetnie a szolgáltatónak, például. SLA keretein BELÜL megtörtént szolgáltatáskiesésért pedig nem érdemes zsörtölődni, hiszen azt a kiesést a megrendelő "bevállalta", azaz nem érte meg neki a plusz rendelkezésre állás költségeit megfizetni. Ez rendben is van, hiszen felesleges arra pénzt költeni, amire nem szükséges, a minőséget és a költségeket egyensúlyozni kell (lásd még a blog címét).
   Summa summarum, a Szolgáltatási szintre ugyan kitér a jelentés, de szerintem rossz helyen, feleslegesen és értelmetlenül kavarja bele a témakört. Ha mindenáron szolgáltatási szint vállalást kér számon, akkor ezt más mérőszám szerint tehette volna meg (ha van ilyen), azt viszont nem teszi.
4. Végezetül nézzük a felelősség kérdését. A jelentésből egyértelműen ez a legjobban kidolgozott rész. Érezhetően a jelentés célja leginkább az (bár ezt nem jelenti ki), hogy a felelőst megtalálja és megnevezze. Ezzel önmagában nem érdemes vitatkozni, csak az a probléma, hogy Szolgáltatás Menedzsment szempontból a felelősség megállapítása a legkevésbé érdekes. A felelős megtalálása ugyanis önmagában nem fogja jobbá tenni a szolgáltatást. Politikai szempontból persze tökéletesen érthető, hogy miért ezen a részen van a hangsúly a jelentésben. Ezt a szempontot a jelentés majdnem tökéletesen ellátja, s politikai kommunikáció szempontjából a jelentésnek az eredménye is meglett, hiszen a fő felelősséget viselő cég üzemeltetési igazgatójának távoznia kellett. Egy ilyen lépés a magyar üzemeltetési gyakorlatban eddig viszonylag ritka, és jelen esetben is valószínűleg elsősorban az ügy politikai vetülete miatt történt meg. Mindenesetre "nyugaton" ez egyáltalán nem ritka következmény, és talán fontos tanulság lehet általában az üzemeltető szervezeteknek azzal kapcsolatban, hogy az üzemeltetési folyamatok betartása (s nem utolsó sorban, betarthatósága) miért kell, hogy a csúcsvezetők számára fontos téma legyen. A személyes érintettség csodákat tud művelni (ezen a felismerésen alapul egyébként a sokak által mélyen utált USA-beli SOX szabályozási rendszer is, ami a pénzügyi átláthatóság érdekében személyesen büntethetővé teszi a vezetőséget, amennyiben a pénzügyi kontroll folyamataik nem felelnek meg a szabályozásoknak).
   A felelősség megállapítása egyébként valóban fontos olyan értelemben, hogy a szolgáltatási szerződésben (amely tartalmilag NEM egyezik meg az annak általában csatolmányaként kezelt SLA-val - az egyik jogi szakszöveg, a másik inkább technikai jellegű) szabályozott lépéseket meg lehessen tenni. Más szóval, egy felelősséget megállapító jelentés (amely viszont tipikusan NEM MIR vagy SIR, hanem annak alapján készülő KÜLÖN anyag, mivel a címzettje is más, ráadásul a MIR/SIR hamarabb kell, hogy elkészüljön, hogy a megfelelő szolgáltatásjavító lépéseket mielőbb meg tudjuk tenni) célja, hogy a szolgáltatási szerződésben remélhetőleg szereplő szankciókat be lehessen azonosítani. Itt számíthat az, hogy pl. milyen eljárásrendi hibák voltak - amennyiben a szerződés rendelkezik ezek szankcionálásáról. (Ha nem, úgy egy ilyen felelősség megállapítás önmagában nem előre mutató lépés).
   A jelentés azonban megáll a felelős megállapításánál, és nem említi, hogy milyen szankciókat lehet ennek következtében kiróni a szerződés alapján. Ez arra utal, hogy ilyen szankció nincsen a szerződésben megállapítva (természetesen ez nem biztos, elképzelhető, hogy politikailag nem akart ebbe belemenni a jelentés készítője)

A fenti 4 cél ill. a köréjük csoportosított megállapítások keveredésének az az eredménye, hogy összességében a jelentés bár korrekt, valószínűleg sokkal kevesebb konkrét szolgáltatás fejlődést fog eredményezni, mint abban az esetben, ha a célok tisztázottak és az adott folyamatokhoz kapcsolódóan külön készültek volna jelentések, jól azonosított célcsoportnak. Ez ráadásul sokkal konstruktívabb is lett volna. (Persze nincs kizárva, hogy ilyenek is készülnek valahol a háttérben).

Már látom, a jelentés kritizálásában elég mélyre mentem, pedig a jelentés által feltárt eljárásbeli hiányosságok nagyságrendekkel (igen... nagyságrendekkel) komolyabbak, mint a jelentés kevésbé tökéletes volta. Ezért elnézést kérek a jelentés készítőitől így ismeretlenül, hiszen láthatóan nem kevés munkájuk fekszik benne, és alapvető probléma nincs is vele - csak ugye, folyamatos szolgáltatásfejlesztés alapelvei mentén, mindent lehet fejleszteni... :)

Azért még lenne 1-2 megjegyzésem konkrétan az üzemeltetési szabályozáshoz, pontosabban ahhoz, ami belőle látszik a jelentés alapján.

- A legfontosabb, hogy rengeteg időt tudott volna spórolni az összes, szabályozást dokumentáló szervezet, ha egyszerűen előírták volna (ahogyan azt pl. az Egyesült Királyságbeli kormányzati üzemeltetési pályázatok egyre nagyobb százaléka teszi) az ISO20000 és ISO 27000 szabványok szerinti minősítését az üzemeltetőnek. (vagy akár lehetett volna annak magyar megfelelőjére is hivatkozni). Ez a szabályzat legtöbb kívánalmát lefedi, igaz, nem az összeset, de nem biztos, hogy az üzemeltetési kritériumrendszert pl. nehezen megváltoztatható kormányrendelet formájában kell rögzíteni, mert ez a javítást célzó változtatásokat is nehezíti.

- A hivatkozott Tesztelési és Változáskezelési szabályzat utal arra, hogy mind Teszt, mint Változáskezelési folyamatok futnak. A hivatkozott struktúra azonban jól mutatja, hogy miért nem alkalmas egy szabályzat helyettesíteni a szolgáltatás menedzsment folyamatok megfelelő dokumentálását. Többek között keverednek a felelősségi körök (Roles and Responsibilities), a tevékenység/munkafolyamat előírások, valamint a kontroll pontok/célok. ("Új szoftver komponens bevezetése esetén az igénybe vett funkcionalitásra, új verzió bevezetése esetén a változó funkcionalitásra tekintettel kell kidolgoznia a tesztelési tervet. E feladat felelőse az IT1 Osztály" - hogy kerül ide az IT1 osztály ami sehol máshol nem volt említve? És mi történik, ha átszervezik az üzemeltetési feladatokat? Meg kell változtatni az egész szabályzatot?)

- Pontatlan definíciók. Például: "Minden jóváhagyott szoftverváltoztatásról – függetlenül a jóváhagyó személyétől – haladéktalanul értesíteni kell a Működtetőt." Mit jelent a "haladéktalanul"? Mi számít értesítésnek? Konkrétan kit a "Működtető"-nél? Azt is megkérdezhetném, hogy a szofterváltoztatásra vonatkozó értesítés miért a Tesztelési Szabályzatban szerepel, miért nem a Változáskezelésre vonatkozóban? Ez nem pusztán zabhegyezés - minél több helyen és bonyolultabban szerepelnek az üzemeltetési elvárások, annál nehezebb azoknak megfelelni, annál könnyebb elsiklani valami felett.
Másik helyen a jelentés arra hivatkozik, hogy "20 percen belül mindenkit tájékoztatnia kellett volna a hibáról" - ki az a mindenki? A Föld összes lakosa?

- Megkérdőjelezhető alapállások. Például: "A teszt tervnek elkülönítetten kell meghatároznia a KR teszt és éles környezetben végrehajtandó tesztelési tevékenységeket. A KR éles környezetben végrehajtandó tesztelésnek tükröznie kell a két környezet különbségeiből adódó eltéréseket." Ez azt feltételezi, hogy az éles és a teszt környezet egymástól különbözik. Bár ez nagyon sokszor előfordul, a kormányzati portálra költött összeg ismeretében legalábbis kérdéses, hogy nem lehetett-e volna egy pontosan azonos felépítésű pre-production környezetet felépíteni (ahogy azt sok nagy cég teszi), kifejezetten az éles tesztelés céljára. (Ne mondjátok, hogy valami különbség mindíg van - persze, például az adattartalom, de az tesztelési szempontból lényegtelen, hiszen megfelelő környezet (environment) menedzsment esetén készíthető az éles környezetből egy attól max. néhány órai eltéréssel különböző tükörkép. Igen, pénzbe kerül.)

- A rendszer üzemeltetési eljárásai minden bizonnyal biztonsági szempontból nem megfelelőek. Erre a következő állítások együtteséből következtetek: "Az érvényes eljárásrend szerint a KÜK abban az esetben értesíti hibabejelentésről a Központi Rendszer Helpdeskjét, ha a bejelentések száma 5 percen belül meghaladja a 10-et",  valamint "A Központi Rendszer Helpdeskjéhez 12:06-kor érkezett bejelentés a Kormányzati Ügyféltájékoztató Központtól (KÜK) (...). A hibáról az első (...) feljegyzés 10:32 (...) kb. ettől az időponttól kezdődtek (...) a bejelentések a hibáról."  és "az ügyeletben levő munkatársak a hibabejelentés fogadásától annak elhárításáig a szakmai tevékenységük során az üzemeltetési szabályzat szerint jártak el". Lefordítom. Ez azt jelenti, hogy a szabályozás szerint egy biztonsági hiányosság esetén simán előfordulhat, hogy szórványos bejelentések vannak "csak", és erről a biztonsági hibáról a Helpdesk nem értesül. Jelen esetben kb. 1,5 órán keresztül olyan ember nem tudott a hibáról, aki tudott volna tenni valamit rendszerszinten. És ez, a jelentés szerint legalábbis, rendben van. Itt jelezném ismét, amit már feljebb egy bekezdésben említettem, hogy a jelentés nem elemzi az eljárások megfelelőségét. Adott esetben valószínűleg az értesítési kritérium kiegészítendő lenne egy biztonsági incidensekre vonatkozó külön eszkalációs úttal (hacsak nem rendelkeznek erről valahol máshol, amit a jelentés azonban nem említ).

Miért érdekes mindez? Nos csak azért, mert kb.a fentihez hasonló elvok, gondolatmenetek alapján állítunk össze vagy javítunk egy-egy szervezet informatikai menedzsmentjén. És egy ilyen gondolatmenet eredménye jó esetben az, hogy a szolgáltatás alanyai, azaz a felhasználók, rövidebb ideig érzékelnek kieséseket (vagy egyáltalán nem), és nem kell aggódni amiatt, hogypéldául betekinthetett-e valamely idegen az adóbevallásunkba.

Ha pedig informatikai vezetők vagyunk, akkor biztosíthatjuk, hogy ne járjunk úgy, ahogy a Kopint-Datorg üzemeltetési vezetője.