Hooldus Sissejuhatus Hooldus on protsess, mis on vajalik teie süsteemi normaalse töö tagamiseks. Hooldustöödeks on näiteks UPS'i akude vahetus, samuti

Väljavõte

1 Hooldus Sissejuhatus Hooldus on protsess, mis on vajalik teie süsteemi normaalse töö tagamiseks. Hooldustöödeks on näiteks UPS'i akude vahetus, samuti logifailide tühjendamine. Mõlemad tegevused on vastavate süsteemi osade tootjate poolt ette nähtud ning vajalikud selleks, et teie süsteem normaalselt töötaks. Seega hooldada on tarvis nii süsteemi riistvara- kui tarkvarakomponente. Hooldustöid võib olla nii regulaarseid, kindla ajagraafiku järgi tehtavaid, kui irregulaarseid, vastavalt vajadusele tehtavaid. Hoolduse planeerimine Nagu iga asi süsteemihalduses, vajab ka tõhusalt tehtav hooldustöö plaanimist. Kindlasti on tarvis teada, mida millal teha. Seetõttu tuleks vastavad protseduurid kirja panna: näiteks ketta täitumise puhul arhiveerida vanad logifailid ning tekitada uued. Protseduurid võiks kirja panna nii, et neid saab läbi viia ka ilma süsteemi süvitsi tundmata. Tavalised hooldusprotseduurid on sageli kirja pandud ka toodete dokumentatsiooni, ning sellisel juhul ei ole oma protseduuride kirjutamisel suurt mõtet. Protseduure dokumenteerides tuleks kirja panna ka see, millal ja mis tingimustel neid protseduure sooritatakse. Nii näiteks tuleks kirja panna see, et logide kustutamisega hakatakse tegelema siis, kui kettamaht on kasutuses 85 %, ning ka see, et kasutajate süsteemi loomine käib personaliosakonna kinnitusel ning uue kasutaja isikut tõestava dokumendi alusel. Regulaarsete hooldustööde jaoks tuleks koostada hooldusgraafik. Hooldusgraafikusse tuleks kirja panna, milliseid hooldustöid millal läbi viiakse, samuti see, kes neid läbi viib. Graafiku loomisel tuleks vaadata nii süsteemi hooldusvajadusi kui ka asutuse töörütmi, viies süsteemi hoolduse sellistele aegadele, kus kasutajate tööd minimaalselt häiritakse. Sellise graafiku pidamise vajalikkust ei maksa alahinnata, sest kuigi võib arvata, et küll meeles seisab ja aega on, siis tegelikkuses kipub ikka nii minema, et vajalikud tööd jäävad kas tegemata või viimasele hetkele. Lisaks protseduuride dokumenteerimisele tuleks pidada ka logiraamatut või hoolduspäevikut, pannes kirja tehtud protseduurid ning nende tulemused. Sellise dokumentatsiooni tekitamist tuleb kindlasti kontrollida, kuna sageli kiputakse oma tegevuste dokumenteerimist alatähtsustama ning seetõttu jäetakse see tegemata või tehakse lohakalt. Hooldusprotseduuride dokumentatsioonis võiks olla ka viide katastroofiplaanidele, kuna just hooldustööde käigus on süsteemi tööd rikkuvate eksimuste tegemine suure tõenäosusega võimalik. Hooldustöödest, mis puudutavad süsteemi toimimist kasutajate jaoks, tuleks kasutajatele kindlasti ette teada anda, isegi siis, kui need tegevused toimuvad väga regulaarselt ning kõik peaks ju teadma. Automatiseerimine Automatiseerimine aitab süsteemi hooldustöid lihtsustada ning sageli ka kiirendada. Automatiseeritud protsessid ei vaja toimimiseks inimesi, ning seetõttu on neid võimalik käivitada ka töövälisel ajal. Automaadid, erinevalt inimestest, ei väsi ega valeta. Automatiseerida tuleks kõike, mida te oskate või saate automatiseerida. Sageli on mingid automaatsed tööd ka süsteemides juba olemas, näiteks regulaarsene ajutiste failide eemaldamine ning logifailide tühjendamine ja säilitamine. Muidugi on ka selliseid protsesse, mida ei saa automatiseerida, kuna vajavad kas

2 inimese otsustamist või tegutsemist: nii näiteks Sertifitseerimiskeskusest tellitud sertifikaatide uuendamine vajab ka inimese sekkumist: vajalik on arvete maksmine. Varundamine, kettaruumi haldus ja monitooring on enamasti automatiseeritud, ent need on vaid üksikud näited. Muidugi ei maksa unustada, et ka automatiseerimisel on oma piirangud: ühest küljest eeldavad automatiseerimised programmeerimist, koos kõige sellest tulenevaga: eelkõige testimise ja vigadega. Teisest küljest ei oska automaadid käsitseda kõikvõimalikke veasituatsioone, ning nende tööd tuleks regulaarselt üle kontrollida. Kindlasti tasub otsida oma automatiseerimisvajaduste koha pealt abi ka internetist. Paljude süsteemide jaoks on seal erinevaid vahendeid. Kasutajate õiguste haldus Kasutajate õiguste haldus on eraldi käsitsemist vääriv probleem, mis kuulub iga süsteemi regulaarse hoolduse juurde. Tegematajätmised kasutajate halduses võivad kaasa tuua mitmesuguseid probleeme, alates asutusesisestest ning lõpetades seaduserikkumisega. Kasutajakontode loomisel ning kasutajate õiguste muutmisel peaks alati teada olema, kes neid protseduure läbi viib ning milliste dokumentide alusel. Vastavad protseduurid peavad kindlasti üheselt kirjas ning kasutajate tekitajatele selged olema. Protseduuride loomisel ei maksa unustada reaalset situatsiooni ja inimeste oskusi: nii näiteks ei pruugi personalitöötaja allkirjaga dokumendist kasutajate loomise alusdokumendina suurt kasu olla, kuna vastavad süsteemispetsialistid ei oska eristada võltsinguid õigetest allkirjadest. Need protseduurid lähtuvad asutuse reeglitest ning vajadustest ning peaks olema kooskõlas asutuse turvapoliitikaga. Mida rohkem on andmed väärt, seda rohkem on nõus ka kurjategijad andmetele ligipääsuks riskima/kulutama. Seetõttu sõltuvad riskid suuresti andmetest. Reeglitest erandeid tohivad teha vaid need, kes teavad oma otsuste mõju ning oskavad hinnata riski. Olenevalt olukorrast võib olla vajalik panna kirja näiteks kasutajanimede loomise kord, samuti see kas ja millal tohib taaskasutada kasutajanimesid või süsteemiidentifikaatoreid. Peale kasutajakontode loomise tuleb samamoodi kindlasti reglementeerida ka õiguste muutmised ning autentimisandmete(eelkõige parooli) muutmised. Erilist tähelepanu tuleb pöörata siin ka kasutajate haldajate koolitusele, kuna just kehva ettevalmistuse tõttu võib langeda nn. social engineering tehnika lõksu ning jääda uskuma jutte kiirest vajadusest ja erakordsest sündmusest. Kindlasti tuleb ka kasutajakontode sulgemise kord reglementeerida, ning siin tuleb väga tähelepanelik olla, kes ja millal selle protsessi algatab, kuna töötajad ei kipu peale vallandamist oma konto sulgemist nõudma tulema. Võimalusel tuleks kasutajate loomist/kustutamist automatiseerida. See on võimalik siis, kui kasutajate isikuandmed ja töösuhted programmiliselt kättesaadavad on. Kasutajate muutmise protseduuride alla kuuluvad ka nimevahetused, mis võivad samuti süsteemi segadust tuua näiteks sellistesse süsteemidesse, kus kasutatakse eesnimi.perenimi e-postialiasi. Tarkvara uuendamine Tarkvarauuendused on regulaarsetest hooldustöödest eraldi väljatoomist vääriv osa. Tarkvara uuendamine on vajalik süsteemi turvalisuse ja töökindluse tagamiseks ning seetõttu tuleks sellega tegeleda erilise hoolega. Tarkvarauuendused reeglina parandavad süsteemi vigu, kuid võivad neid ka juurde tekitada.

3 Kuigi tootja viib tarkvarauuendustel läbi oma kvaliteedi tagamise protseduurid, siis teie konkreetses keskkonnas võib täheldada ikkagi mingite vigade avaldumist. Seetõttu võib praktiliseks osutuda ka tarkvarauuenduste testimine omas keskkonnas. Samuti võib olla olemas ka keskkondi, kus sellised tarkvarauuendused on ebasoovitavad ning viiakse läbi ainult siis, kui tarkvara tõrked hakkavad süsteemi tööd oluliselt segama. Muidugi tuleb sel juhul tagada turvalisus tarkvaraväliste vahenditega. Nii näiteks on väheusutav, et Marsikulguri operatsioonisüsteemile turvaparandusi paigaldatakse, kuid ka meile lähemal on süsteeme, kus eelkõige on oluline käideldavus ning ennustatav toimimine. Edasi tuleb tagada tarkvarauuenduste jõudmine sinna, kuhu vaja, ning tarkvarauuenduste protseduuride korrektne läbiviimine. Tavaliselt on tarkvarauuendustega kaasas ka dokumentatsioon, kus on vajalikud protseduurid kirjas. Et paigaldusprotseduuride ja dokumentatsiooni kvaliteet on reaalsuses väga varieeruv, tuleb kindlasti valmis olla ka selleks, et tarkvarauuendus rikub teie programmid või andmed. See on koht, kus tulevad negatiivse stsenaariumi puhul jällegi mängu katastroofiplaanid. Mitmetel süsteemidel on olemas ka võimalused automaatseks tarkvarauuenduseks. Siin tuleb kindlasti meeles pidada, et kuigi need tarkvarauuendused on testitud, siis teie konkreetne keskkond võib ikkagi avaldada mõne tootja juures avastamata vea ning teie süsteemis olulise tõrke tekitada. Juhul kui selline risk on teile vastuvõetav, võib kasutada automaatseid tarkvarauuendamise vahendeid. Automaatsetest tarkvarauuendamise vahenditest võiks näiteks välja tuua RedHati RHN+up2date, Debiani apt ning Solarise PatchPro, Microsoftil on olemas Automatic Updates ja WSUS. Sõltuvalt tarkvaratootest võib tarkvarauuenduste saamiseks olla vajalik ka tarkvara toelepingu sõlmimine. Riistvarahooldus Lisaks tarkvarale vajab hooldust ka riistvara. Ka riistvara puhul võivad tarvilikuks osutuda tarkvarauuendused nn firmwarele, aga ka palju lihtsamad probleemid: ventilaatorid, kõvakettad ja kõik muu, mis liigub ja kulub. Samuti vajavad regulaarset uuendamist akud ja patareid. Riistvara koha pealt tuleks kindlasti rakendada mingit sorti monitooringut: kas siis käia kohapeal ja kontrollida lambikeste järgi, kas kõik on OK, ja vaadata kas ventilaatorid käivad ringi, või on olemas vastav tarkvara, mis riistvara toimimist jälgib. Igasuguste hooldusprotseduuride läbiviimisel tuleks kindlasti kindel olla, et te teate, mida te teete. Vastasel korral võib hävida hinnaline riistvara ning halvemal juhul ka veel hinnalisemad andmed. Kõige hullemal juhul võib ka protseduure läbi viiv inimene kahjustusi saada, näiteks monitorides aga ka toiteplokkides on tegemist tugevate voolude ja kõrgete pingetega. Juhul kui teil on kõhklusi, tuleks otsida kas tootja hooldustehnik, või keegi teine, kes on võimeline protseduuri korrektselt läbi viima. Outsourcing, allhange Süsteemide hooldusteenuseid on võimalik ka osta, ning seda nii süsteemide osadele kui ka tervetele süsteemidele. Outsourcing võib olla odavam, kui teie vajadused on hooldusmeeskonna töömahu täitmise jaoks liiga väikesed. Võib sisse osta ka ainult osasid hooldusteenuseid, aladel, mida teie oma asutuse inimesed ei valda. Süsteemide hooldusteenuste ostmisel tuleb kindlasti jälgida, et teenusepakkuja täidaks teile vajalikke protseduure: seda näiteks kasutajate haldamisel, aga ka muudes osades. Samuti tuleb

4 kindlasti väga täpselt paika panna pooltevaheline vastutus. Kokkuvõte Hooldusprotseduuride täpne ja süstemaatiline läbiviimine aitab süsteemihaldajatel oma elu lihtsustada, kuna hoolduse õigeaegne läbiviimine aitab probleeme ennetada. Muidugi saab ka hooldusega üle pingutada ning sellega mõttetut raha kulutada süsteemi osadele, millest miski ei sõltu. Kindlasti on ka hooldus tarvis prioretiseerida vastavalt ettevõtte prioriteetidele ja riskianalüüsile. Süsteemide seire ehk monitooring Süsteemide seire on pidev ja süstemaatiline tegevus, mille käigus saadakse korrastatud infot töös oleva süsteemi seisundi (koormus, kasutatud ressursid, sündmused, sh. veasündmused) kohta. Monitooringu ülesanneteks on anda süsteemist operatiivne ülevaade, osutada võimalikele probleemidele enne nende tekkimist, aidata kaasa ressursside planeerimisel ja pakkuda alarmsüsteemi turvaintsidentide puhuks. Tavaliselt on seire automatiseeritud omakirjutatud skriptide või spetsiaaltarkvara abil, kuid erijuhtudel teostatakse seda ka käsitsi. Seire ulatus, täpsus ja skaala Seire skoopi saab kaasata mitmesuguseid erinevaid mõõdetavaid suuruseid, piiriks on administraatori fantaasia ja talle eraldatud vahendid. Väga vajalik on teistest eraldada ja monitooringuga katta süsteemi jaoks tähtsad suurused, vähemtähtsaid tahaplaanile jättes. Tähtsamad suurused peaks meile kätte osutama süsteemi elu algfaasid: planeerimine, riskianalüüs ja testimine, kuid oluline on siin ka kogemus. Enamasti tuleb sõltumata kõigest muust katta nö alusressursid: salvestusruum (nii kettad kui mälu), arvutusjõudlus ja võrgukoormus. Edasi tuleb võtta vaatluse alla mõõdetavad suurused, mis on tähtsad tänu süsteemi spetsiifikale. Kolmanda sammuna võib katta vähemtähtsaid suuruseid, see on kasulik juhuks, kui mõned neist esialgsest hinnangust tähtsamaks osutuvad või süsteemis läbi viidud muutused need tähtsamaks muudavad. Otsuseid tuleb teha ka seire detailsuse kohta. Mitmeid suuruseid saab väljendada ühe kokkuvõtliku suurusena. Kas alamsuuruste eraldi mõõtmine on otstarbekas või mitte, sõltub konkreetsest olukorrast. Vahel paistab üldpildist rohkem kätte kui detailidest eraldi vaadatuna. Samas võib mõni probleem nõuda seirega üksikasjadeni tungimist. Siin saab edukalt kasutada segalähenemist, kus regulaarselt viiakse läbi üldist seiret, kuid vajadusel lühiajaliselt kulukamat, kuid detailsemat seiret. Iga suuruse mõõtmisel peab teadma, milline on mõõtetäpsus. Vastavalt täpsusele saab mõõteandmeid ka tõlgendada ja sealt järeldusi teha. Ebatäpse tulemuse täppisalusel tõlgendamine annab meile ebakorrektseid järeldusi, mis võivad olla esitatud küll põhjalike ja usaldusväärsetena, kuid tegelikult pole seda. Täpsete tulemuste alusel väga üldiste järelduste tegemine aga muudab mõttetuks esialgse mõõtmise heaks tehtud kulutused. Seiretäpsuse teiseks mõõtmeks on mõõteintervall ajavahemik, mille järel mõõtmisi läbi viiakse. Loomulikult oleks põhjalikumate tulemuste saamiseks hea kasutada võimalikult lühikest intervalli, kuid peale selle, et mõningate suuruste mõõtmisel on lühike intervall tarbetu, on intervallile seatud ka muid piiranguid. Suurim neist seisneb selles, et seiretegevus peab muu süsteemi tegevuse kõrval jääma võimalikult märkamatuks ja vähenõudlikuks. Seega ei saa kasutada väga lühikesi intervalle, sest nii suureneks oluliselt töömaht, mis kulub seire tegemiseks, see hakkaks süsteemi mastaapides

5 juba välja paistma ja muud tööd häirima. Seireskaala on vahemik, kus tulemusi kajastatakse, kuhu kuuluvad tulemused meid huvitavad. Mitte alati ei ole kasulik vaadelda suurusi kogu võimalikus mõõtevahemikus. Paljude suurustega on süsteemihalduses nii, et kui need on ülevalpool mingit piiri, siis täpne väärtus pole enam oluline. Samamoodi on osadel suurustel mingi alampiir, kuhu alla jäävad tulemused võib võtta kokku ühte klassi. Selliste väärtuste kogu mõõtevahemiku ulatuses kajastamine tuleb seiretulemuse üldisele loetavusele ja informatiivsusele pigem kahjuks. Seetõttu on otstarbekas kehtestada mõõteskaala, mis kajastab meie jaoks olulist vahemikku, tipud ja põhjad niiöelda lõigatakse. Lühiajaline ja pikaajaline seire Eristatakse lühiajalist ja perioodilist ehk pikaajalist seiret. Lühiajaline seire toimub mingil piiratud ajaperioodil, mõõtmised on täpsemad ja intervall väiksem, seega tehtav töö on suurem. Enamasti toimub lühiajaline seire otsese inimjälgimise all. Pikaajaline seire kasutab pikemaid intervalle ja on ka muus orienteeritud võimalikult väiksele ressursikulule. Selline seire toimub täiesti automaatselt. Lühiajalist ehk operatiivseiret kasutatakse tavaliselt juba ilmnenud probleemide põhjuste tuvastamiseks. Töö toimub tavaliselt vahelduvate tsüklitena, kus esimeses etapis kogutakse seireinfot, teises etapis analüüsitakse seda ning kolmandas etapis tehakse vastavalt saadud järeldustele süsteemis muutusi. Kui probleem kestab, minnakse jälle esimese etapi juurde. Pikaajaline seire peab kajastama süsteemi seisu nii, et probleemide teke oleks võimalikult varajases etapis tuvastatav, enamasti kasutatakse pikaajalist seiret ka süsteemi üldise mahu etteplaanimisel. Pikaajaline seire on pidev ja tema tulemused peavad väljendama süsteemi ja kasutajate vajaduste muutumist: mingid alad kas kasvavad või kahanevad, kasv võib tulla nii välise nõudluse suurenemise tõttu kui mahtude ümberjagamisest teenuste vahel. Monitooringut võib alamosadeks jagada ka selle järgi, mis iseloomuga ressursse või sündmuseid jälgitakse: Jõudlus- ja koormusseire Jõudlus- ja koormusseire huviorbiiti kuuluvad näiteks sellised suurused nagu protsessori koormus, tööaja jaotumine kasutaja ja süsteemi vahel, võrgukoormus, protsessori tööjärjekorra pikkus, kettasüsteemi poolt hetkel kasutatav ribalaius ja teenindusajad, kasutajate hetkearv. Selliseid ressursse iseloomustab see, et nad on kasutuses lühiajaliselt ja kohe pärast kasutamist lähevad nad uuesti taaskasutusse, samuti see, et need ressursid on omavahel üsna tihedates seostes. Veel peab märkima seda, et monitooringuprotsessi ressursinõudlikus mõjutab just ennekõike siia klassi kuuluvaid näitajaid. Seega peab jõudlus- ja koormusseire olema teostatud nii, et intervallid oleksid lühemad, täpsus suurem ja ühise vaatluse all oleks mitmed omavahel seotud suurused. Samuti peab selline monitooringuprotseduur olema koormuse mõttes väga kerge. See muidugi seab piiranguid intervallile ja mõõdetavate suuruste arvule tuleb teha kompromisse. Jõudlus- ja koormusnäitajad võivad olla tihedalt seotud ka väliste mõjutajatega, mida pole alati võimalik jälgida. Seda tasub arvestada, enne kui vastavate näitajate pealt detailseid järeldusi teha. Kipub olema nii, et operatiivseiret viiakse enamasti läbi just jõudlus- ja koormusnäitajate peal, samas kui pikaajaline seire haarab nii jõudlus- ja koormusseiret kui mahuseiret.

6 Jõudlusseire Jõudlusseire on seireliikidest üks keerukamaid, operatiivsemate vajadustega. Teha võib nii süsteemi lõppseiret (kergem) kui ka komponentide (siinid, protsessorid) seiret. Jagatud ressursside juures on probleemiks see, et saame küll lihtsasti iga ressursi kasutaja statistika, kuid sellest pole alati võimalik kogu ressursi statistikat tuletada. Abiks siin on see, kui kogu ressursi kasutamine käib mingil hetkel läbi ühest punktist. Mahuseire Mahuseire abil jälgitakse näiteks selliseid suuruseid nagu ketta- ja mälukasutus, kirjete arv andmebaasis, süsteemi kasutajate koguarv, kirjajärjekorra pikkus. Iseloomulik on neile ressurssidele see, et nende kasutusaeg on pikem (kettamahu puhul mõnikord aastaid) ja seega ei satu juba kasutatud ressurss niipea taaskasutusse. Samuti on need ressursid konkreetsemate piiridega kettamaht on üsna lõplik ja tema lõpp on kindla piiri peal, samas kui protsessori poolt tehtav töö ei ole väga konkreetselt piiratud hetkel võib protsessor olla küll koormatud, kuid mõne aja pärast see vabaneb ja saab teha uusi töid. Seosed selliste ressursside vahel on lõdvemad, kuigi kohati on välja toodavad üsna ühesed seosed (kasutatud mälu ja kasutatud saaleala kettal). Sellest tulenevalt võib mahuseiret tavaliselt teha veidi väiksema täpsusega ja/või pikemate intervallide järel. Suuruseid võib vaadelda üksteisest sõltumatult, süsteemivälised tegurid ei pääse eriti mõjule. Monitooringuprotseduurid peaks muidugi ka siin olema kerged (tavaliselt nad seda ka on), et mitte häirida tundlikumaid jõudlusnäitajaid. Sündmuste seire Sündmuste seire ei tegele niivõrd ressursside kuivõrd muude nähtuste ja sündmuste jälgimisega. Näiteks võib tuua viiruseleiud, ebaõnnestunud autentimised, teenuste peatamised ja (taas)käivitamised. Tavaliselt realiseeritakse sündmuste seire nii, et iga sündmus genereerib mingisuguse logiteate või baasi kirje ning monitooringuprotsess käib teatud intervalli tagant neid kirjeid lugemas ning teeb vastava ülevaate. Tihti esinevate sündmuste korral aitab see seireks minevaid ressursse kokku hoida. samas harvaesinevate sündmuste korral on tegemist ressursiraiskamisega, kuid vastutasuks saame seiresüsteemi mis töötab sarnastel alustel koormus- ja mahuseiresüsteemidega: kindlate intervallide järel teostatakse mõõtmisi. Nii kasutatav täpsus kui intervallid sõltuvad suuremas osas konkreetsetest sündmustest. Näiteks viiruseleidude raport ei pea olema ülemäära tihe, samas kui teenuste peatamisest võiks seiresüsteem informeerida operatiivsemalt. Muud seire liigid Leidub hulk suuruseid, mille jälgimine ei mahu hästi eeltoodud kolme seireliigi alla. Mõned neist on eelnevate hübriidid, mõned aga täiesti eraldiseisvad. Järgnevalt paar näidet: Füüsilise keskkonnamonitooringu eesmärgiks on regulaarselt kindlaks teha, kas riistvara füüsiline keskkond jääb nõutud piiridesse, millised on muutused. Mõõdetakse temperatuuri, õhuniiskust.

7 Seda tehakse tavaliselt mitmetes eri punktides protsessorid, toiteplokid, ruumi temperatuur, akude temperatuur, jahutusseadmete väljundi temperatuur. Sõltuvalt mõõtmiskohast on intervallid vägagi erinevad. Protsessori puhul on olulised ka sekundite jooksul toimuvad muutused, samas vähegi suuremate serveriruumide inerts on piisavalt suur, et leppida ka pooletunnise intervalliga. Levinud seireliigiks on ka nn. kättesaadavuse seire, kus regulaarselt mõõdetakse süsteemi pakutavate teenuste kättesaadavust kas teenus on saadaval, ja kui on, siis millise aja jooksul mingile standardpäringule vastatakse. Kättesaadavuse seire eesmärgiks on anda operatiivinfot süsteemi ja tema teenuste töökorra kohta. Operatiivseirena kasutab kättesaadavuse seire küllaltki lühikesi mõõteintervalle, samas paiknevad vastavad mõõtesüsteemid teistest süsteemidest eraldi ja kasutavad omi ressursse nii ei ole jälgitava süsteemi töö eriti häiritud. Siin kasutatakse ka muutuva intervalli meetodit, kus nn. normaalses olukorras tehakse mõõtmisi harvemini, kriisiolukorras tihemini. Seirevahendid Hetkeseisuga on olemas mitmesuguseid monitooringuvahendeid ja -abivahendeid. Operatsioonisüsteemidega on tavaliselt hulganisti kaasas mitmesuguseid operatiivseire vahendeid. Samas on muidugi nii, et kui seirevajadused soovivad enamat, kui ühe tööarvuti baasressursside seiret, siis tuleb kasutusele võtta kas kolmandate osapoolte poolt loodud monitooringutarkvara või arendada seiresüsteem ise välja. Tihti tehakse mõlemat. Kui on otsustatud isearendamise kasuks, on hea teada, et seda ei pea nullist tegema. On palju erinevaid pooltooteid ja alussüsteeme, mille abil saab monitooringusüsteeme koostada. Paljudel võrguseadmetel on olemas SNMP tugi, mille abil saab üle võrgu pärida erinevaid parameetreid ja suuruseid. Kuna SNMP on ka sellealaseks de facto standardprotokolliks, on vägagi tõenäoline, et SNMP-võimelisi seadeid saab ühendada juba olemasoleva SNMP-teadliku monitooringutarkvaraga. Teisalt jääb isearendatud monitooringusüsteemides vajaka korralikust visuaalsest väljundist. Administraatorid oskavad küll suhteliselt kerge vaevaga süsteemist vajaliku info kätte saada, kuid probleem tekib selle esitamisel. Siin tulevad appi vastavad graafikujoonestamispaketid, näiteks GNUplot. Väga levinud seiresüsteemide osa on MRTG, Multi Router Traffic Grapher, mis algselt oli mõeldud ruutereid läbiva võrguliikluse kajastamiseks, kuid sobib ideaalselt ka paljudeks teisteks monitooringuülesanneteks. MRTG'l on peale SNMP toe ka lihtne skriptide liides, mis tähendab, et vajaliku suuruse jälgimiseks tuleb kirjutada vaid skript, mis seda suurust mõõdab ja kokkuleppelisel kujul väljastab, ülejäänu tehakse juba MRTG abil. Valmiskujul saada olevad monitooringupaketid on enamasti tasulised, enamasti võrguseirele või kättesaadavusseirele orienteeritud ja tootjaspetsiifilised. See tähendab, et näiteks HP ja Cisco toodavad mõlemad võrguseiretarkvara, kuid nende täisfunktsionaalsust saab kasutada ainult sel juhul, kui jälgitavateks seadmeks on samuti vastavate tootjate seadmed. Seiretulemused Eelnevast võis juba aimu saada, millistena esitatakse seiretulemused ja mida seireandmete põhjal ette võetakse. Järgnev kirjeldab kõike seda kokkuvõtlikult. Seire ülesandeks pole niivõrd uue info loomine, kuivõrd olemasoleva korrastamine ja kokkuvõtlik esitamine. Seega on seiretulemuste esitamine tähtis osa kogu seiretööst. Tulemuste hea esituse korral on tehtud mõõtetöödest palju rohkem kasu. See, et tulemused tuleb esitada ühelt poolt kokkuvõtlikena, kuid teiselt poolt võimalikult detailsetena, tingib selle, et seiretulemusi esitatakse ennekõike visuaalsete vahendite abil

8 graafikud, tulpdiagrammid, kaardid. Tihedalt kasutatakse ka tabeleid, kusjuures olulisemate tulemuste tähistamiseks kasutatakse erinevaid rõhutamismeetodeid: värvid, rasvased kirjad, jne. Monitooringutarkvaral on kombeks pakkuda mõõtetulemustele mitmesuguseid erinevaid vaateid: süsteemikeskne, veakeskne, asukohakeskne. See aitab olulist infot selgelt välja tuua, mis omakorda kergendab administraatoril infole adekvaatse hinnangu andmist. Kirjeldatud visuaalvahendid annavad võimaluse üsna väiksel pinnal üsna palju infot edastada, kuid siingi tuleb korraga edastatavasse infohulka suhtuda mõõdutundega. Vahel on mõttekam infohulkasid eraldi graafikutel/tabelites esitada. Liigsesse infohulka kipuvad olulised näidud ära uppuma. Operatiivseire puhul on vajalik ka administraatori teavitamine - ei ole aega oodata, kuni administraator seiretulemusi ise vaatab. Olenevalt operatiivsusvajadusest algavad sellised teavitusvahendid e-postiga, kasutatakse ka SMS'e ja ka heliteateid. Siin tuleb mängu selline mõiste, nagu teatelävi. Teateläved määravad, millise kriitilisusastmega teated millist infokanalit mööda administraatoriteni toimetada. Jällegi- liiga madalale seotud läved pigem segavad kui abistavad. Seire ise on süsteemi suhtes passiivne, kuid seiretulemuste põhjal võetakse süsteemis ette mitmesuguseid aktiivseid tegevusi. Operatiivseire tulemuste põhjal teostatakse põhiliselt probleemilahendust. Kasutatakse kas ülalkirjeldatud etapiviisilist lähenemist või teostatakse seiret ja probleemilahendust paralleelselt. Samuti kasutatakse operatiivseiret detailsemate muudatuste planeerimisel, testimisel ja juurutamisel. Operatiivseire aitab leida ka pudelikaelu, kohti, kus süsteemi jõudlust parandada annaks. Faasid, mis on operatiivseirega lähemalt seotud, on riskihaldus, testimine ja hooldus. Pikaajalise, pideva seire tulemuste põhjal tehakse põhiliselt planeerimistöid ja fundamentaalsemaid süsteemi muutuseid. Seire tulemusi jälgitakse mitmesugustes ajavahemikus, proovitakse nende abil leida mingisuguseid kasutustrende ja saadud teadmisi kasutada muutuste etteplaneerimisel. Faasid, mis on pikaajalise seirega lähemalt seotud, on planeerimine, dokumenteerimine, aga samas ka riskihaldus ja hooldus. Ka tulemuste rakendamise nurga alt näeme, et pikaajalise seire potentsiaalne rakendusmaht on veidi suurem, kui operatiivseirel.