„A koncentrált erőforrások kockázatai is koncentráltan jelentkeznek. Az informatikai szolgáltatóknak, felhős cégeknek érdemes lenne körülnézniük a közműszolgáltatóknál, hogyan kezelik ezt a problémát. Gazdag Ferenc (MAVIR) írása.
A számítástechnika kezdeti időszakában, mint annyi más technológia fejlesztésnél, a hadsereg volt az újdonságok gazdája. Az első komolyabb rendszereket minél robusztusabbnak, a személyzetet minél képzettebbnek szerették, akár a költségek és a fejlesztési sebességének rovására is. Ahogy telt az idő, a fejlesztések egyre inkább átszivárogtak a civil életbe, elsőként a tudományos műhelyek kezdték használni ezeket, ahol az idő és a stabilitás nem számított annyira kritikusnak, a szakértelem rendelkezésre állt, és ahol tudtak engedni a megbízhatóságból is. Utána következett a vállalati használat, ahol már szigorúbban figyeltek a költségekre, hiszen egy vállalat működése elsősorban a profitról szól.
Napjainkra nagyon jelentős, akár világméretű szolgáltatói infrastruktúrák alakultak ki – jó néhányat ezek közül felhőnek hívunk –, amelyeknél már a működtetéshez szükséges emberi erőforrás olyan költségű, amit az egyes vállalatok nem tudnának beépíteni a költségeikbe, mert az ügyfelek nagyon nem szeretnék kifizetni. Másrészt ezek már olyan bonyolult rendszerek, hogy emberként nehéz őket átlátni. Így egyre nagyobb teret nyert és nyer az automatizáció, ami jelentősen növeli a beavatkozási sebességet, és csökkenti az emberi hibák számát. Egyre több mindent bízunk a számítógépes programokra, informatikai eszközökre – és egyre jobban bízunk is bennük –, így a fenti, üzleti és működtetési modell nagy valószínűséggel jól és megfelelően működik.
A fenti bekezdések szerint elérkeztünk a legjobb világba, minden nagyon szép, minden nagyon jó. Vagy mégsem?
Nem akar csökkenni a hibák száma
Az egy menedzsment rendszer alatti erőforrások számossága tehát jelentősen megnőtt, így igaz az az állítás, hogy az elemi(bb) emberi hibák száma csökken. Ám az összetettebb hibák számossága mégsem változott jelentősen, ellenben hatásuk egyre súlyosabb. Voltak már kisebb-nagyobb leállások, szolgáltatás-kimaradások, melyek hatására néha a legnagyobb szolgáltatók is kénytelenek a profitjukból beáldozni egy jelentősebb részt az ügyfelek elégedettségének fenntartásáért.Az automatizáció nem tud, nem tudhat többet, mint amit az azt megalkotó mérnökök összessége ki tudott találni, akár a lehetséges feladatokat, akár a probléma lehetséges megoldását nézzük. És ha egy feladat vagy probléma kívül esik az automatizált folyamatok körén, mindenképpen szükség van emberi beavatkozásra. Ezek olyan esetek, amelyekre a gépi forgatókönyv vagy nem érvényes, vagy alkalmazása fokozottabb kockázatot jelent, így emberi felügyelet mellett lehet csak alkalmazni. Persze ilyenkor is felléphet olyan helyzet, ami a szolgáltatás leromlását, sőt akár kiesését is okozhatja, mint például az Amazon 2017. februári esete, amikor egy rosszul kiadott parancs okozott komolyabb galibát.
Vajon van-e erre megoldás? Erősíteni kell tovább az automatizációt vagy csökkenteni, esetleg más megoldások után kell kutatni?
Több forgatókönyv is elképzelhető
A jelenlegi nagy infrastruktúrák rugalmasságát, költséghatékonyságát pont az az emberektől napi szinten független automatizált, központi menedzsment adja, ami képes akár egy teljes rendszert működőképesen tartani a – az előre tervezett korlátokon belüli – változó körülmények között, de amely képes két pillanat alatt romba is dönteni. A két szélső között elég keskeny az a terület, amelyen a nagy szolgáltatók a költséghatékony rugalmasság és a drága megbízhatóság között lavíroznak.Az egyik megoldás erre a problémára a mesterséges intelligencia (MI) alkalmazása lehet az informatikai rendszerek üzemeltetésében. Bár az MI-kutatások ígéretesek, jelenleg azonban ennek a létrehozása és betanítása nem biztos, hogy műszakilag vagy gazdaságosan megoldható. Ha pedig létre is jön egy működőképes változat, felmerülhet: nem történik-e meg az Arthur C. Clark által az Űrodüsszeia 2001-ben leírt szuperszámítógép (HAL 9000) történetére hajazó „meghasonlás”, amikor az MI-nek döntenie kell a rugalmasság és a megbízhatóság között. És lesz-e olyan ember, aki képes a meghibásodott, helyettünk gondolkodó eszköz hibáját átlátja és kijavítani – főleg akkor, amikor a rendszer megalkotója vagy a vele egyenértékű szakértők nem állnak már rendelkezésre? Ugyanakkor ma kétségtelennek tűnik, hogy az MI-vel a hibák előfordulásának a valószínűségét lehetne csökkenteni, és az elhárítási időt is le lehetne faragni.
Egy másik lehetséges megoldás, hogy a jelenlegi erőforrás-szolgáltatók feladják a a további koncentrációt, sőt visszalépnek. Ez a gyakorlatban azt jelentené, hogy a meglévő, nagyméretű erőforrásaikat feldarabolva kontintentális, regionális esetlegesen országos részeket hoznak létre, amelyek azonos, de egymástól független menedzsment rendszer alatt vannak.
Ezzel az automatikák és a szakemberek feladata is egyszerűbbé válik, hiszen kisebb rendszert kell átlátni és ellátni, az esetlegesen előforduló hibák hatása lokális maradna, nem tudnak terjedni. Az már csak hab a tortán, hogy ezzel az államonként esetleg eltérő szabályozásoknak is egyszerűbb lenne megfelelni.
Ez a megoldás persze óhatatlanul emelné a költségeket, hiszen eltűnhet a mérethatékonyság. És ha ez az előny elveszik, az már a kisebb méretű nagyvállalatoknál is megkérdőjelezheti a külső szolgáltatók rendszerébe költözés megtérülését.
Ha a fentiek igazak, akkor nem (csak) műszaki, hanem egy gazdasági megoldást (is) kell keresni a dilemmára. A szolgáltatónak meg kell vizsgálnia, mi az az elfogadható kockázat, amivel még piacon tud maradni, hasznot tud termelni, és a kockázatainak költségét, legalábbis részben, át tudja hárítani az ügyfeleire. Az ügyfeleknek pedig azt kell mérlegelniük – természetesen az Általános Szerződési Feltételeket (ÁSZF) alapos áttanulmányozása után –, hogy megengedhetik-e maguknak a kiesések magasabb kockázatát, vagy hajlandók többet (és pontosan mennyit) fizetni a magasabb biztonságért.
Keresni kell az arany középutat
Az már most is valószínűsíthető, hogy a nagy szolgáltató szervezetek nem tisztán egyik vagy másik forgatókönyvet fogják követni. Az azonban szinte biztos, hogy aránylag rövid időn belül meg kell találniuk az optimális egyensúlyt rendszereik menedzselhetősége, méretgazdaságossága és költséghatékonya között.Hogy hogyan? Erre nehéz általános választ adni. A szolgáltatók rendszerinek automatizáltsági foka ugyanis folyamatosan nő, az igény az emberi beavatkozásra – és ezáltal az ahhoz szükséges ismeretek szintje – stagnál, esetleg csökken. Az ügyfeleiknek pedig meg kell tanulniuk a megfelelő technikákat. A tudás birtokában biztosabb alapokra tudják helyezni a döntést, amelyek a teljes „földre” költözéstől, azaz az informatika újra házon belülre helyezésétől a több szolgáltatós modellen alapuló megoldásokig bármit magukba foglalhatnak. Vagy meg kell tanulni együtt élni az ÁSZF szerint lehetséges kiesésekkel.
De akkor mit is tanulhatunk az áramszolgáltatóktól?
Ha a gondolkodásban eljutottunk eddig, akkor már jól látható az analógia, ami felállítható az informatikai rendszerek és az áramszolgáltató hálózatok között, és amit oly gyakran is hallunk: az informatikai egyre inkább közművé válik.A fenti problémákkal és lehetséges megoldásaikkal a nagy közműszolgáltatók régóta küzdenek, sőt akár kész megoldásaik is vannak. Igaz, kicsit kisebb szolgáltatási változatossággal, de hasonlóan őrlődnek a költséghatékonyság–megbízhatóság tengelyen.
Meglehet, az informatikai szektornak most erősebben körbe kellene nézni a közműszolgáltatóknál, és átvenni tőlük a jó gyakorlatokat. Akár úgy is fogalmazhatnánk, hogy amíg az üzleti életben minden a digitális transzformációról szól, addig magában az informatikai szolgáltatói szektorban „közművesítési transzformációt” kell végrehajtani, lehetőleg önként. Mert már elkezdtek érkezni az állami szabályozások, egyelőre elsősorban adatkezelésre, de előbb-utóbb a rendelkezésre állás, a szolgáltatási kötelezettség is be fog kerülni a hatóságok látókörébe, amikor a társadalmi fejlettség megköveteli.”
Forrás:
Felhőszolgáltató vagy? Tanulj az áramszolgáltatótól!; Gazdag Ferenc; Bitport.hu; 2017. május 11.
