Prieš paleidžiant taikomąją sistemą, intensyvaus testavimo metu defektus ir paslėptus pavojus galima gerokai sumažinti, tačiau kadangi testavimo simuliacinė aplinka negali būti visiškai tokia pati kaip reali aplinka po sistemos paleidimo, testavimo darbas negali apimti visų IT taikomųjų sistemų gamybos ir veikimo scenarijų, o konkrečiu scenarijumi sunku išvengti IT taikomųjų sistemų gedimų.
Kadangi paslėptas gedimo pavojus yra neišvengiamas, labai svarbu mokėti ramiai susidoroti su gedimu! Geriausia žinoti iš anksto, numatyti galimas IT programų sistemos problemas ir imtis priemonių, kai problema neiškyla, kad gedimas būtų pašalintas. Kad ir kaip blogai būtų, turime kuo greičiau žinoti, kokios problemos kilo sistemoje ir kur jos atsirado, ir laiku jas išspręsti, kol jos neišplito, kad išvengtume situacijos eskalavimo. Iš tikrųjų, kadangi šiuos du dalykus vis dar sunku padaryti, eksploatavimo ir priežiūros spaudimas yra beprecedentis!
Žvelgiant į dabartines įmones, turinčias aukštą informacijos konstravimo laipsnį, atstovaujamas bankų, verslo plėtra tampa vis labiau priklausoma nuo IT, jų IT taikomųjų programų sudėtingumas tampa vis didesnis, o valdomumas vis blogėja. Bet kas yra galvos skausmas yra tai, kad tokioje didelio intensyvumo persekiojimo ir perėmimo situacijoje vis tiek pasitaiko sistemos gedimų, rizika mirksi vėl ir vėl, ir daug kartų, mažos problemos galiausiai perauga į didelius gedimus, kokia priežastis? Kodėl atradimai visada atsilieka? Kodėl įvairūs stebėjimo metodai negali aptikti anomalijų pirmą kartą? Būtina tai išskaidyti.
Pagal pagrindinius aspektus kompiuterių kambarys skirstomas į dvi kategorijas: pagrindinius išteklius ir IT taikomąsias sistemas. Ilgą laiką didelę reikšmę teikėme pagrindiniams ištekliams, tokiems kaip tinklas, pagrindinis kompiuteris, saugykla, kompiuterių kambario temperatūra ir drėgmė, o stebėjimo metodus galima apibūdinti kaip "ginkluotus iki dantų".
IT taikomųjų sistemų stebėjimui šiuo metu vidaus ir užsienio gamintojai ir paslaugų teikėjai teikia daug produktų ar sprendimų, stebėsenos turinys turi savo dėmesį, išsamią analizę, jų praktika daugiausia yra stebėti IT taikomosios sistemos veikimą pagrindiniame išteklių lygmenyje, naudojant tinklo srautą, sistemos našumą, procesoriaus užimtumą, atminties užimtumą, prieigą prie duomenų bazės, tarpinės programinės įrangos būseną ir kitus rodiklius, kartu su žurnalo analize, zondo tyrinėjimu, modeliavimo prieiga ir tarpinio serverio ištraukimu bei kitais metodais, kad gautų tam tikrą sistemos veikimo laiko informaciją. Apytiksliai įvertinus bendrą sistemos veikimo būseną, šiems produktams ar sprendimams trūksta nuolatinio sistemos veikimo detalių sekimo ir stebėjimo, todėl jie negali suvokti kiekvieno modulio veikimo būsenos detalių IT taikomojoje sistemoje ir net funkcinių taškų po moduliu, šios detalės apima: Kokias operacijas apdoroja sistema? Kuris pavyko? Kas yra problematiška? Kas inicijuoja sandorį? Kada jis paleidžiamas? Kokiu verslu užsiimate? Kuris sistemos modulis dalyvauja? Kuris funkcinis taškas yra atsakingas už apdorojimą? Kada grįžta atsakymas? Ar yra kokių nors veiklos anomalijų? Jei tai nepavyksta, kokia kaltė? Jie yra labai svarbūs vertinant IT taikomosios sistemos veikimo būseną.
Praktiškai IT taikomosios sistemos gedimo pradžioje, kai gedimo taškas turi mažai įtakos pagrindiniams ištekliams arba dar nebuvo perduotas į pagrindinį išteklių lygmenį, arba gedimas atsiranda tarpe tarp žurnalų, zondų, tarpinių serverių ir kitų priemonių naudojimo, nors sistemos rizika buvo "nepakankama", tačiau dažnai esami stebėjimo metodai negali atlikti vaidmens, o išorinis pateikimas taip pat yra "nėra anomalijos". Tai taip pat yra pagrindinė priežastis, kodėl gedimų aptikimas atsilieka ir su juo sunku susidoroti! Pastebima, kad savalaikis sistemos gedimų aptikimas "pirmą kartą" yra dabartinių IT eksploatavimo ir priežiūros darbų trūkumas, todėl labai svarbu kompensuoti IT veikimą ir priežiūrą.
Kas yra "pirmas kartas"? Tai yra, IT taikomųjų programų sistemai, reaguojant į prieigos užklausas, tuo metu, kai operacija nepavyksta arba įvyksta neįprastai, ji turi būti tiksliai užfiksuota! Visi žino, kad ankstyvą aptikimą galima išspręsti laiku, o norint pakeisti dabartinę pasyvią IT veikimo situaciją ir kompensuoti IT veikimo ir priežiūros trūkumus, būtina techniškai išspręsti sistemos gedimų aptikimo problemą "pirmą kartą". Atliekant lyginamuosius tyrimus ir praktikuojant daugelio IT taikomųjų sistemų veikimą, ši idėja iš tikrųjų yra techniškai įgyvendinama, tačiau biuro žmonės gali būti paveikti inercinio mąstymo, nesugebėti iššokti iš pirminio mąstymo ir netgi manyti, kad tai neįmanoma subjektyvioje sąmonėje, todėl nėra esminio proveržio šiame darbo aspekte, o IT programų operacinė rizika visada yra pasyvioje fragmentiško atsako situacijoje.
Norint "pirmą kartą" aptikti sistemos gedimus, reikia "dėmesingai" vertinti IT taikomąją sistemą, įsisavinti kiekvieną jos žingsnį, tiksliau, nuodugniai stebėti IT taikomosios sistemos veikimo detales ir griežtai stebėti kiekvieno modulio ir funkcinio taško veikimą, tuo pačiu metu šis stebėjimas taip pat turi būti nuolatinis ir nepertraukiamas, tik tokiu būdu nepraleis jokių sistemos operacijų anomalijų, kad IT taikomosios sistemos veikimas būtų kontroliuojamos būsenos.
Kadangi šis procesas gali gauti ir kaupti išsamią sistemos veikimo būsenos informaciją, sukurti labai vertingą sistemos veikimo failą, jį analizuojant ir panaudojant, jis gali ne tik suteikti nuorodą vertinant kiekvieno modulio ir kiekvieno funkcinio taško kokybę, bet ir suteikti pagrindą analizuoti sistemos veikimo būsenos raidą ir pokyčius, leidžiančius numatyti IT taikomosios sistemos sveikatos tendencijas.
|
Paskelbta 2014-10-13 10:36:01
|
|
|
