|
|
Objavljeno na 13. 10. 2014 10:36:01
|
|
|
Pred zagonom aplikacijskega sistema je mogoče z intenzivnim testiranjem močno zmanjšati napake in skrite nevarnosti, vendar ker simulacijsko okolje testa po zagonu sistema ne more biti povsem enako dejanskemu okolju, testno delo ne more zajeti vseh scenarijev proizvodnje in delovanja IT aplikacijskega sistema, poleg tega pa je težko preprečiti pojav okvar IT aplikacijskega sistema v določenem scenariju.
Ker je skrita nevarnost neuspeha neizogibna, je zelo pomembno, da se napako rešite mirno! Najbolje je vedeti vnaprej, predvideti možne težave IT aplikacijskega sistema in ukrepati, ko težava ne nastane, da se napaka odpravi v kali. Ne glede na to, kako hudo je, moramo čim prej vedeti, katere težave so se pojavile v sistemu in kje so se pojavile, ter jih pravočasno rešiti, preden se razširijo, da preprečimo eskalacijo situacije. V resnici, ker sta ti dve točki še vedno težko izvedljivi, je pritisk obratovanja in vzdrževanja brez primere!
Če pogledamo trenutna podjetja z visoko stopnjo informacijske strukture, ki jo predstavljajo banke, postaja razvoj poslovanja vse bolj odvisen od IT, kompleksnost njihovih IT aplikacij narašča, nadzorljivost pa se slabša. A težava je, da v tako intenzivnih situacijah zasledovanja in prestrezanja še vedno pride do okvar sistema, tveganja se pojavljajo znova in znova, in velikokrat se majhne težave sčasoma razvijejo v večje okvare – kaj je razlog? Zakaj je vedno zamuda pri odkrivanju? Zakaj različne metode spremljanja ne morejo zaznati nepravilnosti že prvič? To je treba razčleniti.
Glede na glavne vidike je računalniška soba razdeljena v dve kategoriji: osnovni viri in IT aplikacijski sistemi. Dolgo časa smo pripisovali velik pomen osnovnim virom, kot so omrežje, gostitelj, shranjevanje, temperatura in vlažnost računalniške sobe, metode spremljanja pa lahko opišemo kot "oborožene do zob".
Za spremljanje IT aplikacijskih sistemov trenutno domači in tuji proizvajalci ter ponudniki storitev zagotavljajo številne izdelke ali rešitve, vsebina spremljanja pa ima svoj poudarek, celovito analizo, njihova praksa pa je predvsem opazovanje zmogljivosti IT aplikacijskega sistema na osnovni virski plasti, preko omrežnega prometa, zmogljivosti sistema, zasedenosti procesorja, zasedbe pomnilnika, dostopa do baze podatkov, statusa vmesne programske opreme in drugih kazalnikov, v kombinaciji z analizo dnevnikov, raziskovanjem sond, dostopom do simulacij in ekstrakcijo proxyjev ter drugimi metodami za pridobivanje določenih časovnih točk delovanja sistema. Grobo oceno splošnega stanja delovanja sistema ti izdelki ali rešitve nimajo neprekinjenega spremljanja in spremljanja podrobnosti delovanja sistema, zato ne morejo zajeti podrobnosti o stanju delovanja vsakega modula znotraj IT aplikacijskega sistema in celo funkcionalnih točk pod modulom; te podrobnosti vključujejo: Katere transakcije sistem obdeluje? Kateri je uspel? Kaj je problematično? Kdo začne transakcijo? Kdaj bo izšel? S čim se ukvarjaš? Kateri modul sistema je vključen? Katera funkcijska točka je odgovorna za obdelavo? Kdaj se odgovor vrne? Ali obstajajo kakšne nepravilnosti v zmogljivosti? Če ni uspešen, kaj je krivda? So zelo pomembni za ocenjevanje delovnega stanja IT aplikacijskega sistema.
V praksi, na začetku okvare IT aplikacijskega sistema, ko ima točka napake majhen vpliv na osnovne vire ali še ni bila prenesena na osnovni virski sloj, ali pa se napaka pojavi v vrzeli med uporabo dnevnikov, sond, proxyjev in drugih sredstev, čeprav je tveganje sistema "podtočno", vendar pogosto obstoječe metode spremljanja ne morejo igrati vloge, zunanja predstavitev pa je prav tako "brez nepravilnosti". To je tudi temeljni razlog, zakaj zaznavanje napak zaostaja in je težko rešiti! Vidimo lahko, da je pravočasno odkrivanje okvar sistema "prvič" pomanjkljivost trenutnega IT delovanja in vzdrževanja, zato je zelo pomembno nadomestiti delovanje in vzdrževanje IT.
Kaj pomeni "prvič"? To pomeni, da mora biti v procesu IT-aplikacijskega sistema, ki odgovarja na zahteve za dostop, v trenutku, ko transakcija spodleti ali se zgodi nenavadno, ta zajet natančno! Vsi vedo, da je zgodnje odkrivanje mogoče pravočasno odpraviti, in da bi obrnili trenutno pasivno stanje IT delovanja ter nadomestili pomanjkljivosti IT delovanja in vzdrževanja, je tehnično treba rešiti problem zaznavanja okvar sistema "prvič". S primerjalnimi raziskavami in prakso delovanja velikega števila IT aplikacijskih sistemov je ta ideja tehnično izvedljiva, vendar so lahko ljudje v uradu prizadeti zaradi inercialnega razmišljanja, ne skočijo iz prvotnega načina razmišljanja in celo menijo, da to ni izvedljivo v subjektivni zavesti, kar ne vodi do vsebinskega preboja na tem področju dela, operativna tveganja IT aplikacij pa so vedno v pasivni situaciji delnega odziva.
Ključ do uresničitve "prvič" zaznavanja okvar sistema je biti "pozoren" do IT aplikacijskega sistema, obvladati vsak njegov korak, natančneje, izvajati poglobljeno opazovanje podrobnosti delovanja IT aplikacijskega sistema ter strogo nadzorovati delovanje vsakega modula in funkcionalne točke, hkrati pa mora biti to spremljanje neprekinjeno in neprekinjeno, le da se ne spregleda nobena nepravilnost sistemske transakcije, da je delovanje IT aplikacijskega sistema v nadzorovanem stanju.
Ker ta proces lahko pridobi in zbere podrobne informacije o stanju delovanja sistema, vzpostavi zelo dragoceno datoteko za delovanje sistema, lahko s svojo analizo in uporabo ne le služi kot referenca za ocenjevanje kakovosti vsakega modula in vsake funkcionalne točke, temveč tudi kot osnova za analizo razvoja in sprememb stanja delovanja sistema, kar omogoča napovedovanje trenda zdravja IT aplikacijskega sistema.
|
Prejšnji:@天下无双给我们论坛的建议Naslednji:Windows10 je nov, sistem pa še ni dovolj zrel
|
