Az alkalmazásrendszer indítása előtt a hibák és rejtett veszélyek jelentősen csökkenthetők intenzív teszteléssel, de mivel a teszt szimulációs környezete nem lehet pontosan ugyanaz, mint a rendszer indítása utáni valós környezet, a tesztmunka nem képes lefedni az IT alkalmazásrendszer gyártásának és üzemeltetésének minden forgatókönyvét, és nehéz elkerülni az IT alkalmazásrendszer hibáinak előfordulását egy adott helyzetben.
Mivel a rejtett kudarc veszélye elkerülhetetlen, nagyon fontos, hogy nyugodtan kezeld a hibát! A legjobb előre tudni, előre jelezni az IT alkalmazási rendszer lehetséges problémáit, és intézkedéseket tenni, ha a probléma nem fordul elő, hogy a hiba már kezdetben megszűnjük. Bármilyen súlyos is a helyzet, minél előbb tudnunk kell, milyen problémák történtek a rendszerben, és hol jelentek meg, és időben kezelni kell őket, mielőtt terjednének, hogy elkerüljük a helyzet eszkalálását. Valójában azért, mert ezek a két pont még mindig nehéz, a működés és karbantartás nyomása példátlan!
Ha a jelenlegi vállalatokat nézzük, amelyek magas szintű információs konstrukcióval rendelkeznek, és amelyeket a bankok képviselnek, az üzleti fejlesztés egyre inkább az IT-től függ, az IT alkalmazásaik összetettsége egyre nagyobb lesz, és a kontrollálhatóság egyre rosszabb. De ami fejfájás, hogy egy ilyen nagy intenzitású üldözés és elfogás helyzetben rendszerhibák is előfordulnak, a kockázatok újra és újra felvillannak, és sokszor apró problémák végül nagy hibákká alakulnak – mi az oka? Miért van mindig késés a felfedezésben? Miért nem tudják különböző monitorozási módszerek először észlelni az rendellenességeket? Ezt meg kell boncolni.
Főbb szempontokat tekintve a számítógépterem két kategóriába sorolható: alapvető erőforrásokra és IT alkalmazásrendszerekre. Hosszú ideje nagy jelentőséget tulajdonítottunk az alapvető erőforrásoknak, mint például a hálózat, a gazdaház, a tároló, a hőmérséklet és a számítógépterem páratartalom, és a monitorozási módszereket "fogig felfegyverzettnek" nevezzük.
Az IT alkalmazásrendszerek monitorozásához jelenleg a hazai és külföldi gyártók és szolgáltatók számos terméket vagy megoldást kínálnak, a monitoring tartalma saját fókuszt és átfogó elemzést igényel, gyakorlatuk főként az IT alkalmazásrendszer teljesítményének megfigyelése az alapvető erőforrás-rétegen, hálózati forgalom, rendszer teljesítménye, CPU forgalmazása, memóriafoglalás, adatbázis-hozzáférés, közműszoftver állapota és egyéb mutatók révén, valamint naplóelemzéssel, szondafeltárással, szimulációs hozzáféréssel és proxy kinyeréssel és egyéb módszerekkel, hogy megszerezzék a rendszer működésének bizonyos időpont-információit. Nagyjából a rendszer működési állapotát nagyjából megítéljük, ezek a termékek vagy megoldások nem követik és figyelik a rendszerműködési részleteket, így nem tudják felfogni az egyes modulok működési állapotát az IT alkalmazásrendszerben, sőt a modul alatti funkcionális pontokat sem, ezek a részletek a következők: Milyen tranzakciókat dolgoznak fel a rendszer? Melyik sikerült? Melyik problémás? Ki kezdeményezi az ügyletet? Mikor indul? Milyen üzlettel foglalkozol? Melyik rendszer modulja vesz részt benne? Melyik függvénypont felelős a feldolgozásért? Mikor tér vissza a válasz? Vannak teljesítménybeli anomáliák? Ha nem sikerül, mi a hibás? Nagyon fontosak egy IT alkalmazásrendszer működési állapotának megítélésében.
A gyakorlatban, az IT alkalmazásrendszer hibájának kezdetén, amikor a hibapont kevés hatással van az alapvető erőforrásokra, vagy még nem került továbbításra az alap erőforrás rétegbe, vagy a hiba a naplók, szondák, proxyk és egyéb eszközök használata közötti rés között történik, bár a rendszer kockázata "aluláramú" volt, de gyakran a meglévő megfigyelési módszerek nem játszanak szerepet, és a külső megjelenítés is "nincs rendellenesség". Ez az alapvető oka is, hogy a hibafelismerés lemarad és nehéz kezelni! Látható, hogy a rendszerhibák időben történő észlelése "első alkalommal" az IT üzemeltetési és karbantartási munkák hiányossága, és ez nagy jelentőséggel bír az IT üzemeltetés és karbantartás pótlására.
Mi az a "első alkalom"? Vagyis egy IT alkalmazásrendszer folyamatában, amely hozzáférési kérelmekre reagál, abban a pillanatban, amikor egy tranzakció meghibásodik vagy rendellenesen történik, pontosan rögzíteni kell! Mindenki tudja, hogy a korai észlelés időben kezelhető, és ahhoz, hogy megfordítsák az IT működésének jelenlegi passzív helyzetét, valamint pótolják az IT működésének és karbantartásának hiányosságait, technikailag meg kell oldani a rendszerhibák "első alkalommal" észlelésének problémáját. Számos IT alkalmazási rendszer működésének összehasonlító kutatása és gyakorlata révén ez az elképzelés technikailag megvalósítható, de az iroda munkatársait érintheti az inerciális gondolkodás, nem tudnak kiugrani az eredeti gondolkodásmódból, sőt, akár azt is gondolják, hogy ez szubjektív tudatosságban nem megvalósítható, így ebben a munkaterületben nem jár jelentős áttörés, és az IT alkalmazások működési kockázatai mindig passzív, darabonkénti válaszhelyzetben vannak.
Az első alkalommal történő rendszerhiba felismerésének kulcsa az, hogy "figyelmesen kezeljük" az IT alkalmazásrendszert, elsajátítsuk minden lépését, különösen az IT alkalmazásrendszer működési részleteinek mélyreható megfigyelése, és minden modul és funkcionális pont működését szigorú figyelem alá helyezzük, miközben ennek a monitorozásnak folyamatos és megszakítás nélküli kell lennie, csak így nem hagyjuk ki semmilyen rendszeri tranzakciós rendellenességet, így az IT alkalmazásrendszer működése irányítható állapotban legyen.
Mivel ez a folyamat részletes rendszerműködési állapot információkat tud szerezni és felhalmozni, egy nagyon értékes rendszerműveleti fájlt létrehozni annak elemzésével és felhasználásával, nemcsak referenciaként szolgálhat az egyes modulok és a funkcionális pontok minőségének megítéléséhez, hanem alapot is nyújthat a rendszer működési állapotának fejlődésének és változásának elemzéséhez, lehetővé téve az IT alkalmazásrendszer állapotának állapotának előrejelzését.
|
Közzétéve 2014. 10. 13. 10:36:01
|
|
|
