it diagnoosimine

IT lahendusi saab olla kas töötavaid, õnne kombel töötavaid või mitte töötavaid.

Tihti lahendused töötavad nn.vaikimisi sätetega, teisalt on see ka sama tihti puhtalt õnnelik juhus – tihti ei kasutata seadmete võimsusi või võimalusi piisavalt ära, raisatakse erinevaid ressurse või on seadmete pakutud teenus ebakvaliteetne. Erinevate põhjuste ja tagajärgede välja selgitamine nõuab seadmete konfiguratsioonide ja nende vaheliste seosete mõistmist. Teinekord isegi paremini mõistmist kui lihtsalt pealiskaudset teadmist erinevatest funktsioonidest või võimalustest.

IT diagnoosimine puhul mõtleme kolmele asjale. Tihti võib probleemiks olla mitte seadmete kvaliteet, vaid süsteemi mitte mõistmine. St.seadmete ja nende funktsioonide taha tuleb ka osata vaadata. Tuleb aru saada erinevatest seosetest ning mitte leppida olukorraga kus seade hakkab “lihtsalt tööle”.

Esimese asjana soovitan ikkagi kasutada oma pead.

Mitte niivõrd loota foorumite abile või ka sõbra abile. Nüansse on tihti palju ning kõikide vaatenurkadega on abi palumisel raske lähtuda. Tihti aitab talupojamõistus.

Teise asjana soovitan lugeda seadme logifaile,

Ka nn.event viewerit – missugune viga, millal tekkis ning mida see siis ikkagi täpsemalt tähendab. Silmas tuleb pidada, et üks viga võib teist põhjustada ning ka veateade ei pruugi alati olla eriti kasuks.

Kolmandaks – kolm on kohtu seadus – tuleks lugeda seadme manuali.

Kui sa vaatad seadme kasutajaliidest siis kas sa ikka mõistad kõikvõimalikke valikuid. Mida üks või teine mõiste tähendab? Kuidas selle muutmine muudab teisi asjasse puutuvaid asju? Üldiselt on manuale suhteliselt lihtne lugeda – väga kasulik on endale selgeks teha, et miks mingi seadistus on. Hullem on pimesi kobada ja püstitada erinevaid hüpoteese, mis tihti põhinevad mitte millelgi. Lisaks manualile tasub uurida ka erinevat kirjandust sarnastel teemadel – kuidas siis üks või teine featuur töötab ja miks see üldse mõeldud on.

Tõsi, nn.vaikeseadistustega töötavad ka paljud asjad – seisukoht, et muuta võimalikult vähe seadistusi võib ka aidata – mida rohkem võimalusi seda rohkem võib olla eksimise kohti. Siiski aga peaks need võimalused endale selgeks tegema. Praktiline küsimus – mida miski teeb!?

Kas sul on võimalik pääseda ligi infole kuidas teised sarnast probleemi on lahendanud? Kas sul on ligipääs teatud teadmistebaasile? Räägin millestki muust kui suvalisest foorumist. Näiteks: http://www.experts-exchange.com, http://technet.microsoft.com/en-US/, http://support2.microsoft.com/fixit/ vms.

Kui nüüd ükski lähenemine nendest ei aita siis tuleks probleem kirja panna – võimalikult täpselt.

Mis viga, millal, mida oled teinud, mida ei ole teinud. Missugused hüpoteesid või propositsioonid oled püsitatnud, kuidas neid testinud jne – tihti just kirjutamise käigus märkad oma mitte-märkamist. Kui aga tõesti lahendus veel ei paista siis võiks ehk pöörduda Interneti foorumite poole – kas sealt saab ideid – tähtis on aga otsida võimalikult sarnast probleemi. Huupi seadistuste muutmine on aja raiskamine – võib juhtuda, et leiad sealt lahenduse – tõenäoliselt aga midagi väga asjalikku ei leia. Siiski on lihtne Google abiga erinevad variandid “läbi kammida”. Otsida tuleb osata.

Mida nüüd edasi teha? Pöörduda tootja foorumisse, kirjutada vastava eriala foorumisse või võtta ühendust tootjaga? Üks või teine lähenemine nendest peaks su probleemi juurele lähemale juhatama – tõsi on see, et korralikult formuleeritud probleem annab tootjalt sulle ka suhteliselt advekvaatse vastuse –  foorumist seeeest võid saada vastuse ka natuekene segasemale küsimusele – kuigi endiselt meeldib spetsialistidele vastata korralikult sõnastatud probleemipüstitusele. Võib-olla selgub, et tegemist on seadme firmware või koguni riistvara probleemiga – võib-olla aga on tegemist ikkagi oma lollusega…

Asjad ei juhtu iseenesest – midagi põhjustab midagi.

Põhjus-tagajärg loogika. Kogu arutluskäik võiks olla võimalikult pragmaatiline ja verifitseeritav. Peaksid suutma oma väiteid, seisukohti, lahendusi vms tõestada katsetuste ja vastava täiendava informatsiooni alusel – kõik muu ei ole diagnoosimine vaid on pigem prognoosimine! :) Mitte midagi ei lähe ise korda ning ei lähe ise puruks – Sa lihtsalt ei tea seda põhjust! Okei, on erandeid aga…

Oletame, et leidsid lahenduse. Arvatavasti oled juba kirjeldanud probleemi, sümptomeid, jne – viimane soovitus aga on tihti eriti kasulik – pane oma lahendus kirja.

Võimalikult palju infot aga mitte liiga palju. Kas teist korda tahad uuesti sama protsessi läbi käia või toetuda juba tehtule? Lisaks kirja panemise ajal mõtled kogu nüansid veel korra läbi – äkki jäi veel midagi kahe silma vahele …

it diagnoosimine

Mis dokumentatsioon? Miks? Kellelt? Kuidas?

Kas te olete mõelnud stsenaariumile, kus Teie IT ühel päeval otsustab töölt lahkuda, temaga juhtub õnnetus või on vajalik süsteemi üle andmine kolmandatele isikutele? Oletame, et Teie infosüsteemis on 100 arvutit, 10 serverit ning hunnik erinevaid võrguseadmeid. Kõik need seadmed on kuidagi konfigureeritud, ühenduses üksteisega, need pakuvad teatud teenuseid ning nendesse saab autentida läbi teatud kasutajanime või parooli. Loomulikult on võimalik infosüsteemi administreerida ka ilma paroolideta, ilma dokumentatsioonita jne – tegelikult on see aga lisavaev. Palju kulub näiteks aega näiteks printeri parooli resetmisele? 5-10 minutit. Arvuti parooli resetimisele? Umbes sama aeg. Mida tähendab IT süsteemi edasi ehitamine ilma dokumentatsioonita? Üks näide siit. Võimalikke konflikte, vigu, täiendavat aega ehitamiseks jne.

Peamine kaotus on aga see, et tekkinud intsidente ei ole võimalik niivõrd kiiresti lahendada, eriti kui on spetsialist vahetunud. Seeläbi võib kahju juba osutuda tuntavaks või isegi oluliseks.

Dokumentatsioonile esitatavad elementaarsed nõuded:

• dokumentatsioon peab olema asjakohane
• peab olema arusaadav kolmandale osapoolele
• dokumentatsiooni kirjutades tuleb silmas pidada lugeja eeldusi ja oskusi
• peaks sisaldama varundamisjuhendit ja taastamise juhendit
• soovitused teenuste monitoorimiseks
• turvapoliitika
• infrastruktuur peab olema kaardistatud
• konfiguratsiooniklassid ja seal sees olevad konfiguratsiooniüksused peavad olema kirejldatud (arvutid, võrguseadmed, lisaseadmed, tarkvara, asukohad).
• lisatud peab olema kaabeldusse puutuv dokumentatsioon
• dokumentatsioon peab olema ühtlustatud konfiguratsiooniüksuste lõikes
• konfiguratsiooniüksused peavad olema üksteisele viidatud
• hea oleks ka asjasse puutunud seadmetega seoses intsidentide/probleemide ning lahenduste nimekiri

Kokkuvõtvalt. Dokumentatsioon peab olema koostatud selliselt, et selle järgi on võimalik IT süsteemi hallata, hooldada, täiendada või uuesti ülesse ehitada.

Ülalkirjeldatu peaks olema jõukohane kõikidele spetsialistidele – keerulisemates süsteemides aga tuleks juhinduda ITIL’i, ISO 20 000, COBIT, jne dokumentides kirjeldatud headest praktikastest.

Kaetud võiksid olla sellised teemad:

• IT pikaajaline plaan – 3-5 aasta plaan. Kirjeldatud IT ja äri seosed.
• IT aasta plaan – eelarve. Aasta plaanid ja eesmärgid.
• IT organisatsiooni plaan – tööülesannete jaotused, teadmiste kirjeldamine, koolitused, jne
• Äri jätkusuutlikuse plaan – disaster recovery plan. Tarkvarade taastamise plaan. Varuplaan IT vea puhul. Kontaktisikud. Tegutsemisjuhendid.
• Infrastruktuuri manual/dokumentatsioon – IT arhitektuuri diagramm, riistvara nimekiri, tarkvara nimekiri, süsteemitarkvara nimekiri, äritarkvara nimekiri
• Arendusmeetodite kirjeldus – arenduse põhimõtted, tehnilised soovitused, konkreetsed meetodid
• Operatsioonide ja protsesside manual – milliseid operatsioone ja protsesse organisatsioonis erinevatele äripooltele on vajalikud
• IT turvalisuse dokumentatsioon – mis alustal on turvalisus tagatud, põhimõtted, tegevusplaanid, reeglid ja juhised
• IT süsteemi hinnangut ja pakkumist saab küsida siit: http://www.visioline.ee/it-hooldus/