event log

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.

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 või nn. event log 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 …

event log

Retrospektiivne diagnoosimine

Spetsialistide töös on logifailid tihti määrava tähtsusega. Tavaliselt inimesed loevad dokumentatsiooni või manuali alles siis kui oma mõistus küsimusele peale ei hakka. Sama lugu on logifailidega. Kui enam ise aru ei saa siis tasub alati logifaile vaadata. St.logifailide kättesaadavus ja tõlgendamine on määrava tähtsusega.

Nii mõnegi probleemi põhjus selgub logifailidest kiiremini.

Logisid kirjutavad peaaegu kõik seadmed. Ruuter, switchid, arvutid, printerid, võrguseadmed, rakendustarkvarad, teenused, jpm. Logifaile on võimalik kirjutada erineva täpsusastmega – näiteks: vead, hoiatused ja teadaanded. Iga logi grupp on erineva iseloomuga ning erineva tähtsusastmega. Reaalses elu on logisid tohutult. Tähtis on eraldada terad sõkaldest. Tähtis on kas see, et logifailid oleks loetavad ka siis kui konkreetne seade või teenus ei ole enam kättesaadav. Mida see tähendab? See tähendab seda, et logifailid võiksid olla kirjutatud eraldiseisvale salvestusseadmele või spetsiaalsele teenusele. Toon konkreetsest elust näite: ühel heal päeval ruuteri parool on justkui muutunud. Kas süsteemi on sisse häkitud? Kas see parool muudeti kogemata? Kas tegemist on riistvara veaga? Või mõni muu põhjus? Arvatavasti tahetakse nendele küsimustele vastust. Probleem on aga selles, et peale seadme nn.tehase seadmete taastamist tihtipeale logifaile ei ole võimalik enam lugeda – seega tagajärg likvideeritakse aga põhjust ikkagi ei teata.

Logifaile kirjutavad ka monitooringuseadmed.

Monitooritakse aktiivselt – st.küsitakse konkreetsel hetkel konkreetselt seadmelt või tarkvaralt teatud andmeid – näiteks protsessori koormatuse, mälu kasutuse, vms kohta – tulemused salvestatakse andmebaasi ning IT spetsialistil on võimalik lisaks logidele uurida ka graafikuid erinevate näitajate trendide kohta.

Teine variant on passiivne monitooring – st.seade saadab ise teatud infot – see on hea juhul kui näiteks osa infrastuktuurist ei tööta – näites: süsteemi keskne võrgujaotusseade on katki – sellest võiks teha aktiivne monitooring järelduse, et ka selle külge ühendatud süsteemid ei tööta – tegelikult aga töötasid ja neid andmeid võib olla vaja hilisemaks diagnoosimiseks. passiivne monitooring saadab andmed ka taganjärgi ühenduse taastumisel, antud juhul võrgujaotusseadme vahetusel. Mis siis ikkagi toimus see hetk kui antud seade maas oli? See info võib olla vajalik.

Kolmas variant on võrgu pidev skänneerimine. St.võrgus on seade või tarkvara, mis pidevalt jalutab kogu süsteemi läbi. Kaardistab võrgus olevad seadmed ja teenused ning mõõdab erinevaid parameetreid.

Sealt on võimalik saada info selle kohta, et mis kell milline arvuti käis võrgus – mis tarkvaraga see oli, milline kasutaja seda kasutas vms – ühesõnaga sellega leiab ülesse võrgust need seadmed, mida ei otsita. St.need seadmed, mis pole määratud passiivsesse või aktiivsesse monitooringusse. Miks seda vaja on? Näiteks selleks, et teada milline võrku ühendatud seade tekitab probleeme, millal see seade oli ühendatud ning kas see seade oli võrgus esimest korda või on ta tihemini olnud ühendatud asutuse võrgku. Nii võib leida süsteemiadministraator võrgust näiteks lubamatu Wifi pääsupunkti mis võib teie andmeid kontorihoones ka konkurentidele vabalt kättesaadavaks teha. Arvate, et sellist olukorda ei juhtu? Meie teenusepakkujana oleme seda tihti näinud. Inimesed heast tahtest teevad kõige suuremaid lollusi.

Konkreetse kontoritöökoha logifailid võivad osutuda samuti kasulikuks – tarkvara vead, seadistamise vead, kasutaja tegevused, teenuste kättesaadavuse vead vms  – arvatavasti paljud arvutikasutajad ei mõtle sellele kui palju tema arvuti tegelikult andmeid sisaldab erinevate tegevuste kohta. See kehtib nii Windowsi, Linuxi kui ka Maci kohta.

Teenuse pakkujal on vajalik probleemide kiireks lahenduseks logifaile, tähtis on logi info tõlgendamine ning seostamine konkreetsete küsimustega. St.lisaks logide olemasolule on oluline näha ka varasemaid intsidente või probleeme IT töös seotuna konkreetste inimeste, konkreetste arvutite või IT teenustega. Terviklik lähenemine annab vastuse kiiremini kui lihtsalt erinevate probleemilahenuste katsetamine.