C.7. Teenuste tarne ja tugi | EUCIP: IT kutsehariduse õppematerjalid\nC.7. Teenuste tarne ja tugi\nC.7.1 Kliendisuhted ja teenustaseme lepingud\nC.7.1.1 Teenustaseme haldusprotsess\nC.7.1.2 Teenustaseme lepingu elemendid\nC.7.1.3 Erinevad lepingutüübid\nC.7.2 Mahu ja talitluspidevuse planeerimine\nC.7.2.2 Mahuplaani elemendid\nC.7.2.4 Riskide vähendamise meetmed\nC.7.3.1 Käideldavushalduse mõisted\nC.7.3.2 Käideldavuse mõõdikud\nC.7.3.3 Käideldavushalduse meetodid ja tehnikad\n4.4.1 Kasutajatoe eesmärk\nC.7.4.2 Erinevad kasutajatoe liigid\nC.7.4.3 Kasutajatoe elemendid\nC.7.5 Muutuste haldamine\nC.7.5.1 Konfiguratsioonihalduse praktikad\nC.7.5.2 IT muutuste halduse praktikad\nC.7.5.3 Muutuse taotluse eesmärk ja elemendid\n# C.7. Teenuste tarne ja tugi\nMõistma kliendipõhise IT kasutajatoe tähtsust ja osata kohaldada lihtsamaid IT teenuste osutamise põhimõtteid\nAru saama konfiguratsiooni- ja muudatusehalduse põhimõtetest ja muudatuste planeerimise vajadusest.\n# C.7.1 Kliendisuhted ja teenustaseme lepingud\nKirjeldama teenustaseme haldusprotsessi ja selle tulu\nLoetlema ja kirjeldada peamised teenustaseme lepingu SLA elemendid\nVõrdlema teenustaseme lepingu, partnerlepingu ja käitluslepingu kasutusotstarvet.\n# C.7.1.1 Teenustaseme haldusprotsess\nKirjeldada teenustaseme haldusprotsessi ja selle tulu.\nTeenustaseme haldusprotsess SLM / Service Level Management peab tagama, et organisatsioonile vajalikku IT teenust pakutakse piisavas mahus ning selleks vajalike ressursside inimeste, süsteemide kasutamine on efektiivne.\nIT teenus - IT teenuseosutaja poolt ühele või mitmele kliendile osutatav teenus. IT teenus kasutab infotehnoloogiat ning toetab kliendi äriprotsesse. IT teenuse moodustavad inimeste, protsesside ja tehnoloogia kombinatsioon ning see peab olema kirjeldatud teenustaseme lepingus.\nTeenustaseme haldusprotsessi osapooled on:\nTeenuseosutaja IT Service Provider - IT ettevõte, kellel on vastavad teadmised, spetsialistid ja partnerid, et pakkuda IT teenuseid oma sisemistele või välistele klientidele\nKlient Customer – IT teenuse tarbija, kelle põhitegevus ei ole seotud IT teenuste pakkumisega kuid kes vajab IT infrastruktuuri vahendeid oma äritegevuse teostamiseks.\nTeenustaseme haldusprotsess sisaldab järgmisi komponente:\nKvaliteedi parendused IT teenusele.\nOluline eesmärk on jõuda osapoolte läbirääkimistel arusaamisele, et teenuseosutaja poolt pakutud teenuste kvaliteet ja hind vastavad kliendi ootustele. Pakutud teenus peab olema mõõdetav ja mõõdikud kajastuma ka osapoolte vahelistes lepingutes. Oluline teenustaseme haldusprotsessi eesmärk on teha kliendi ja teenuseosutaja vaheline kommunikatsioon võimalikult lihtsaks, et vajadusel korrigeerida teenuseid ja nendega seotud mõõdikuid.\nTeenustaseme haldusprotsessiga seotud peamised dokumendid on:\nIT teenuste kataloog Services Catalogue – kirjeldab kogu teenuseosutaja tootevalikut koos erinevate teenuse tasemetega, mida suudetakse garanteerida\nTeenustaseme nõuded SLR – Service Level Requirements – kliendi nõuete kirjeldus, mis tuleneb kliendi ja teenuseosutaja vahelisest koostööst\nTeenustaseme lepingud SLA – Service Level Agreements – kliendi ja teenuseosutaja vahel sõlmitud lepingud tellitud teenustega ja garanteeritud teenuse tasemega\nKäitluslepped OLA - Operational Level Agreement – IT teenust pakkuva ettevõtte sisemine täpsustatud leping\nPartnerlepingud UC - Underpinning Conracts – teenuseosutaja lepingud kolmanda osapoolega teenuste täitmiseks\nTeenuse kvaliteediplaan Service Quality Plan – plaan tegevustest vastava tasemega teenuse pakkumiseks\nTeenustaseme halduse lisaülesanded:\nMonitooring ja aruandlus\nTeenuse täiustamise plaan SIP - Service Improvement Plan – tegevused, teenuse kvaliteedi parendamiseks\nKliendisuhete haldus CRM - Customer Relationship Management – tegevused, mis seotud kliendiga suhtlemisega\n# C.7.1.2 Teenustaseme lepingu elemendid\nLoetleda ja kirjeldada peamised teenustaseme lepingu SLA elemendid nagu teenuste definitsioon, jõudluse mõõtmine., probleemihaldus, intellektuaalne omandiõigus ja konfidentsiaalne info, garantiid ja lepingu lõpetamine.\nTeenustaseme haldusprotsessi üks peamisi tegevusi on defineerida teenustaseme lepingu sisu. Selles dokumendis peab olema detailselt kirjas läbirääkimiste käigus väljaselgitatud kliendi poolt nõutud teenused koos garanteeritud teenuse tasemega ja mõõdikutega, mille järgi hinnata nõuete täitmist.\nTeenustaseme lepingus kliendi ja teenuseosutaja vahel defineeritud peamised aspektid on:\nTeenuste loetelu, mida klient nõuab teenuseosutajalt\nHindamismõõdikud iga pakutava teenuse jaoks ja soovitatavalt aktsepteeritavad ning mitteaktsepteeritavad teenuse tasemed\nMõlema osapoole kohustused ja vastutus\nTegevused, mis võetakse ette spetsiifiliste olukordade puhul\nHarilikult spetsifitseerib teenustaseme leping järgmist:\nGaranteeritud teenuse tase näiteks reageerimisaeg tõrke korral või garanteeritud käideldavus perioodi jooksul\nKonfidentsiaalsusnõuded, mis seotud kliendi intellektuaalse omandi kaitsega\nNõutud aruandlusdokumentatsioon ja selle esitamissagedus\nTrahvid teenuse lepingule mittevastava täitmise korral\nTeenustaseme lepingu koostamise reeglid:\nLeida aeg, et defineerida vastutused ja jõuda üksmeelele vastutuste jaotamisel\nLepingus pakutavad teenused peavad olema mõõdetavad\nIga lepingus pakutud teenus peab olema äärmisel täpselt spetsifitseeritud\nKõik lepingu täitmisega seotud osapooled peavad olema esindatud läbirääkimistel teenustaseme lepingu loomisel\nLepingu loomise protsess toimub iteratiivselt etappidena. Osapooled loovad lepingu kavandi, mis esitatakse vastavatele töögruppidele muudatuste tegemiseks. Protsess jätkub kuni mõlemad osapooled on tulemusega rahul.\n# C.7.1.3 Erinevad lepingutüübid\nVõrrelda teenustaseme lepingu, partnerlepingu ja käitluslepingu kasutusotstarvet.\nKui teenustaseme leping on ametlik leping kliendi ja teenuseosutaja vahel, siis käitluslepe on tüüpiliselt kasutuses teenuseosutaja IT osakonnas, et teisendada kliendiga kokkulepitud mõõdikud parameetriteks, mida on võimalik lihtsasti hinnata. Käitluslepe on töödokument, milles sisalduvad vajalikud detailid teenustaseme lepingus kirjeldatud teenuste täitmise kohta. Käitluslepe defineerib nõuded aja ja ressursi osas, mis on seotud IT teenuste arendajatega ja hooldusmeeskonnaga.\nKäitlusleppe peamised elemendid on:\nPakutava teenuse definitsioon ja selle seos vastava allüksusega\nTeenindatavate kasutajate hulk\nÄrikahjud teenuse käideldavuse puudumisel\nKriitilised teenindusperioodid ehk tipptunnid või perioodid kuude lõikes\nMitteaktiivsusperioodid hoolduseks kui teenuse käideldavus ei ole kriitiline\nTeenuse katkemise vältus, peale mida läheb käiku taasteplaan\nKäideldavuse hindamismeetodid mõõdetakse minimaalse nõutud sooritusvõimee järgi ja aja järgi, mil teenus ei olnud aktiivne\nPalju IT teenuse pakkujaid kasutab oma partnereid teenuste osutamisel sõlmides nendega partnerlepingud. Need on lepingud, mis sõlmitakse IT ettevõtete vahel ja oma sisult sarnanevad need käitluslepetega. Erinevalt käitluslepetest on partnerlepingud osapooltele ametlikud ja nende kaudu delegeeritakse ka vastutus teatud teenuse täitmise eest alltöövõtjale.\nKogu teenuse pakkumise protsess peab olema monitooritud ja kaetud aruandlusdokumentidega. Teenuse aruanded peavad olema täidetud jooksvalt.\nKliendile tuleb koostada perioodilist aruandlust ja edastada need vastavalt lepingus määratud sagedusele ja enne lepingu ülevaatamist või pikendamist.\nTeenuste täitmise jälgimine on võimalik vaid siis kui teenused on mõõdetavad. Seetõttu on eluliselt tähtis määrata spetsiifilised mõõdikud igale teenustaseme lepingus kirjeldatud teenusele ja kirjeldada need mõõdikud ka teenustaseme lepingus.\nPeale selle peab teenustaseme leping defineerima garanteeritud teenuse kvaliteedi ja rahalised trahvid, mis tulenevad teenuse garanteeritud taseme mittetäitmisest.\nJärgnevalt mõned võimalikud mõõdikud teenuste hindamiseks:\nTeenuse käideldavus perioodi jooksul protsentides\nTeenuseosutaja reageerimisaeg tõrke ilmnemisel\nTeenusega seotud teenindajate hulk\nTeenustaseme lepingu jälgimis- ja aruandlustegevusel on järgmised eesmärgid:\nKokku leppida ja korraldada nõutud teenuse tase\nMõõta ja aru anda teenuse tasemest, vajalikest ressurssidest ja teenuse täitmise maksumusest\nPidevalt parendada pakutavat teenuse taset\nKoordineerida teiste teenuse haldamise protsessidega\nPerioodiliselt vaadata üle teenustaseme leping, et ära hoida lahknevused kliendi muutunud nõuete ja teenuses fikseeritud teenuse taseme vahel\nTeenuse taseme hindamine vastavalt lepingus sätestatud mõõdikutele.\n# C.7.1 Kordamisküsimused\nTeenustaseme haldusprotsessi tegevused on?\nTeenustaseme haldusprotsessi dokument ei ole?\nTeenustaseme lepingus on fikseeritud?\nMuudatuste nõukoja otsused\nTeenustaseme lepingu lisana\nEttevõtte sisese osakonnaga\nIT teenuse delegeerimiseks välisele partnerile X\n# C.7.2 Mahu ja talitluspidevuse planeerimine\nKirjeldama mahuhaldust ja selgitada selle alamprotsesse\nTuvastama mahuplaani otstarve ja peamised elemendid\nMääratlema riski, ohu ja haavatavuse mõisted ja meetmed riskide vähendamiseks\nMääratlema talitluspidevusplaani otstarve ja peamised elemendid.\n# C.7.2.1 Mahuhaldus\nKirjeldada mahuhaldust ja selgitada selle kolem alamprotsessi äri, teenus ja komponent tähtsust.\nMahuhalduse protsessi peaeesmärk on tagada, et IT teenuste ja IT infrastruktuuri mahud oleksid piisavad teenustaseme sihtide saavutamiseks tulusal ja õigeaegsel viisil. Mahuhaldus arvestab kõigi IT teenuste osutamiseks vajalike ressurssidega ja esitab lühi-, kesk- ja pikaajalised ärinõuete plaanid.\nMahuhalduse ülesanded on:\nJälgida IT teenuste sooritusvõimet ja efektiivsust ning selleks vajalikke infrastruktuuri komponente\nKasutada olemasolevaid ressursse efektiivselt\nMõõta äri nõuete täitmiseks olulised ressursid\nKoostada prognoose tulevaste äri nõuete jaoks, et hoida äri toimivana\nSaada kindlus, et pakutud ressursid suudavad garanteerida teenustaseme lepingus defineeritud teenuste kvaliteedi.\nMahuhalduse tegevusi tuleb analüüsida järgmisi seoseid arvestades:\nArvestada maksumuse seost võimekusega, et tagada olemasolevate ressursside efektiivne kasutus\nArvestada pakutud teenuse vastavust nõudlusega, et kliendid oleksid rahul ja ressursid vastaksid nõudlusele.\nIT infrastruktuuride teek ITIL - IT Infrastructure Library on komplekt praktikatest ja põhimõtetest IT teenuste haldamiseks ja osutamiseks ning on kujunenud IT teenuste osutamise hea tava standardiks.\nITIL mudeli järgi jaguneb mahuhaldus kolmeks alamprotsessiks:\nÄri mahuhaldus Business Capacity Management, mille ülesanne on tagada, et tulevaste IT teenuste maht on õieti planeeritud. See kontrollib olemasolevate ressursside kasutust erinevate IT teenuste poolt, et hinnata trendi ja luua vastavad prognoosid tulevaste nõuete täitmiseks.\nTeenuse mahuhalduse Service Capacity Management eesmärk on kontrollida pakutavate teenuste sooritusvõimet ja mahtu. Mahuplaani jaoks kogutakse, salvestatakse ja analüüsitakse IT teenuste ressursside tarbimise ja kasutusstatistika ajalisi graafikuid.\nKomponentide mahuhaldus Component Capacity Management mis vastutab selle eest, et mõista konfiguratsioonielementide mahtu, kasutatust ja sooritusvõimet. Vastavaid andmeid kogutakse, salvestatakse ja analüüsitakse kasutamiseks mahuplaanis.\n# C.7.2.2 Mahuplaani elemendid\nTuvastada mahuplaani otstarve ja peamised elemendid.\nErinevad mahuhalduse alamprotsessid seavad eesmärgiks täiesti erinevad aspektid.\nÄriprotsesside mahuhaldus koondab tähelepanu olemasolevatele ja tulevastele äri vajadustele, teenuse mahuhaldus keskendub olemasolevate teenuste käimashoidmisele ja komponentide mahuhaldus on fokusseerunud tehnoloogiale, mis on kõiki teenuseid toetav infrastruktuur.\nMahuhalduse protsessi poolt läbiviidavad tegevused realiseeritakse jooksvalt, hoolduse käigus ja perioodiliste mahuhaldusinfo andmebaasi ning dokumentide ülevaatamisel.\nInfo erinevate teenuste sooritusvõimeest kogutakse jälgimistegevuste käigus mahuhalduse andmebaasi CDB – Capacity Management Database. Viimane on keskne infohoidla, mida kasutavad kõik kolm mahuhaldusealamprotsessi oma kogutud andmete talletamiseks. Seda infot kasutatakse mahuhalduse planeerimisel ja prognooside koostamisel jälgitavate teenuste jaoks. Peale selle on andmebaasis info teenuste omavahelistest seostest ja teenuste ning ressursside omavahelistest seostest.\nKorrektseks info kogumiseks andmebaasi on vaja jälgitavad subjektid teenused ja nendega seotud ressursid varustada mõõdikutega.\nTeenuste kvaliteeti tuleb mõõta erinevate vaatenurkade alt:\nOlemasolevad äri nõuded\nIga spetsifitseeritud mõõdiku jaoks peab mahuhalduse protsess defineerima soovitud sihid ja garanteerima nende saavutamise.\nPrognoosid ja ressursside kogus, mis on vajalik teenuste käimashoidmiseks ning äri nõuded vormistatakse spetsiifilisse dokumenti, mida nimetatakse mahuplaaniks.\nKõik alamprotsessid annavad oma osa selle dokumendi sisu uuendamisse. Mahuplaan on paindlik dokument, mida võidakse regulaarselt muuta ja parandada. Mahuplaani koostamisel on möödapääsmatu võtta aluseks mahuhalduse andmebaas. Peamine mahuplaani koostamise eesmärk on defineerida täpselt kogu IT infrastruktuur, mida on vaja käimas hoida, selleks, et garanteerida lepingutega määratud teenuste tasemed.\nTüüpiline mahuplaan sisaldab järgmist infot:\nPlaani ulatus ehk põhilised IT infrastruktuuri elemendid, mis on seotud planeerimisega\nKasutatud meetodid – defineerib kuidas ja millal info plaani koostamiseks saadakse\nÄristsenaarium – see kirjeldab kliendi ettevõtte olemasolevat seisu ja võimalikke muutusi tulevikus\nTeenuste aruanne – kokkuvõttev profiil igast kliendile pakutavast teenusest\nTulevased teenuse tasemed – teenuse kasvuprognoos\nRessursside aruanne – erinevate teenustega seotud ressursside kasutusmäär\nTulevane ressursivajadus – ressursid, mis vaja, et täita oodatavaid teenuse tasemeid\nTeenuse parendamise võimalused – tegevused teenuste parendamiseks.\n# C.7.2.3 Riskihindamismeetodid\nMääratleda riski, ohu ja haavatavuse mõisted ja tuua näiteid nagu teenuse tõrge, andmete kadu.\nEnne riskianalüüsi protsessi kirjeldamist on oluline defineerida sellega seotud terminid:\nRisk Risk – tõenäosuslik sündmus, mis võib põhjustada kahju või mõjutada võimet saavutada eesmärke. Riski mõõdetakse ohu tõenäosuse, varade haavatavusega sellele ohule ja mõjuga, mis riski realiseerumisel tekiks.\nOht Threat) – igasugune olukord, sündmus või tegevus, mis võib haavatavuse ära kasutada ja süsteemi kahjustada. Igasugust intsidentide potentsiaalset põhjust tuleb käsitleda ohuna. Näiteks elektrikatkestus on oht, mis võib ära kasutada elektrisüsteemi poolt tekitatud haavatavuse. Iga oht on määratud tasemega, mis näitab võimalikku sündmuse esinemissagedust (statistika baasil. Seda taset kasutatakse riskide hindamisel.\n**Haavatavus *****Vulnerability*** – nõrkus, mida oht võib ära kasutada. Näiteks avatud tulemüüri port või piisava jahutussüsteemita serveriruum. Puuduv meede kvalifitseeritakse samuti haavatavuseks..\n**Vara *****Asset*** – teenuseosutaja varad sisaldavad kõike, mida saab kasutada teenuste osutamiseks nagu juhtimine, organisatsioon, protsess, teadmised, inimesed, informatsioon, rakendused, infrastruktuur ja finantskapital.\nTeine faas IT teeninduse mahuhalduse protsessis on aluseks, et defineerida IT talitluspidevusplaan. See on plaan, mis kirjeldab ühe või mitme IT teenuse taastamiseks vajalikke samme.\nSelles faasis on põhilised tegevused järgmised:\nHinnatakse ohtude ja haavatavuse taseme järgi riskianalüüs\nHinnatakse ja mõõdetakse riskitase riskianalüüs\nDefineeritakse tegevused riskide vähendamiseks aktsepteeritavale tasemele riskihaldus.\nRiskianalüüsi Risk analysis) käigus analüüsitakse varade väärtust ärile, tuvastatakse ohud ja hinnatakse varade haavatavust nende ohtude suhtes. Riskianalüüs võib olla kvantitatiivne (andes arvulise tulemuse või kvalitatiivne.\nRiskianalüüsi käigus arvutatakse riskitasemed järgmiste näitajate alusel:\nErinevate ressursside riskitase arvestades nendega seotud ohtudega\nRiskihaldus Risk Management on protsess, mis vastutab riskide määramise, analüüsi ja juhtimise eest. See sisaldab vajalike vastumeetmete tuvastamist, valimist ja kasutuselevõttu vastavalt ressursside tuvastatud riskitasemele ja riskide piiramist aktsepteeritavale tasemele.\n# C.7.2.4 Riskide vähendamise meetmed\nLoetleda riskipiiramise abinõude näiteid.\nRiskihalduse metoodika tähendab iga riski jaoks mingi valiku tegemist. Valik võib olla üks järgnevatest:\nRiskist hoidumine sellega seotud funktsiooni kasutusest eemaldamisega või nõrga lüli süsteemist kõrvaldamisega\nRiski vähendamine aktsepteeritud tasemele sisaldab sobivate vastumeetmete kasutamist, mis võivad toimida erinevat teed pidi:\nKanda risk üle kolmandale osapoolele näiteks kindlustuse kasutamine\nPiirata ohu esinemise võimalust\nPiirata ohu mõju\nTuvastada tõrke või ohu esinemissagedus\nAktsepteerida riski –klient võib otsustada lubada riski kui selle vastumeetmed osutuvad liialt kulukaks.\nOhtude hindamise meetodid sõltuvad kasutuselvõetud metoodikast.\nNäiteks CRAMM CCTA Risk Analysis and Management Method metoodika järgi on ohutasemete väärtused järgmised:\nVäga madal – üks juhtum iga 10 aasta jooksul\nMadal – üks juhtum iga 3 aasta jooksul\nKeskmine – üks juhtum aastas\nKõrge – üks juhtum 4 kuu jooksul\nVäga kõrge – üks juhtum kuus\nHaavatavuse hindamine CRAMM järgi:\nMadal –juhtumi esinemisel on halvima stsenaariumi tõenäosus alla 33%\nKeskmine – juhtumi esinemisel on halvima stsenaariumi tõenäosus vahemikus 33-66%\nKõrge – halvim stsenaarium juhtub üle 66% tõenäosusega\nOhtude hindamine on seotud riskianalüüsiga, mille käigus ohtude tasemed arvutatakse. Ohud, mida riskianalüüsis arvestada võivad olla näiteks järgmised:\nSeadmete või dokumentide vargused\nRiistvara või tarkvara hooldusega seotud inimlik eksimus\nRiskide mõõtmise aluseks on süsteemile tekitatud potentsiaalne kahju ohusündmuse esinemisel.\nRusikareegel riski hindamisel arvestab ohu poolt tekitatavat kahju ja ohu esinemise tõenäosust:\nR = D × P\nkus R on risk, D on potentsiaalne kahju ja P on ohu esinemise tõenäosus\nÜldine riskihindamise definitsioon infoturbe alal on riski tõenäosus esitatud funktsioonina süsteemi haavatavusest ja ohu tasemest järgmiselt:\nP = f ***V, T***\nkus V on haavatavus, T on oht, P on tõenäosus\nJuhuslike riskide puhul on riski esinemise tõenäosus funktsioon süsteemi haavatavusest ja tõrkejuhtumi eripärasest tõenäosusest näiteks üleujutuse või elektrikatkestuse esinemise tõenäosus\nP = f ***V, p***\nkus V on haavatavus, p on eripärane tõenäosus\nOhusündmuste tõsidus on tavaliselt väljendatav ka rahalises kahjus. Riski tase, mis võtab arvesse riski seose vastava vara kohta on väljendatav:\nkus L on riskitase, V haavatavus, T oht ja A vara väärtus\nKui riski tase on hinnatud on vaja defineerida vastumeetmed ohtudele. Iga vastumeede on spetsiifiline kaitsvale objektile ja sellega seotud ohtudele. Defineeritud vastumeetmed peavad katma kõiki tuvastatud riske. Kui vastumeetmed on tarvitusele võetud tuleb hinnata allesjäänud riskivõimalust. Selle järgi saab teha järeldusi, kas vastumeetmed on piisavad.\nÜldine riskianalüüsi ja riskihalduse põhimõte on esitatav lihtsa diagrammiga, kus riskianalüüs ja riskihaldus on kaks erinevat aga seotud tegevust.\nJoonis 7-1. Riskianalüüsi ja riskihalduse seosed *Allikas: Learning Materials for Information Technology Professionals (EUCIP-Mat)*\nSellel diagrammil on esitatud riskianalüüsi ja riskihalduse põhielemendid ja nendevahelised seosed.\nAvariijärgne taasteplaan Disaster Recovery Plan) on dokument, mis on sageli kaasatud IT teenuse talitluspidevusplaani (Service Continuity Plan. See defineerib protsessid, poliitikad ja protseduurid normaalolukorra taastamiseks piiratud ajaraamides, kriitilised operatsioonid, äritegevuse jätkamiseks peale kahjujuhtumi esinemist. Katkestuse lubatud vältus peab olema valitud vastavalt äri nõuetele.\nSee plaan pakub välja tehnoloogilised ja organisatoorsed lahendused, mis võimaldavad kriitilistel tegevustel edasi toimida avariiolukorras, kuni tavalise tööolukorra taastumiseni. Plaani tegemise oluline alus on välja valida ja defineerida need protsessid ja teenused, mis peavad olema kaitstud avariijärgses taasteplaanis pakutavate lahendustega.\n# C.7.2.5 Talitluspidevusplaan\nMääratleda talitluspidevusplaani ja varutalitluspidevusplaani otstarve ja peamised elemendid nagu rikketaluvus, taaskäivitamise protseduurid, personalitöö, alternatiivsed ressursid, varundus.\nÜks peamisi IT teenuse talitluspidevuse halduse eesmärke on ära hoida või minimiseerida kahjud, mida juhuslikud ebasoovitavad sündmused võivad põhjustada ärile.\nIT halduses tähendab termin "avarii" igasugust sündmust, mis võib põhjustada katkestuse osutatavale IT teenusele, kahjustades vähem või rohkem äriprotsessi.\nIT talitluspidevusplaan Service Continuity Plan defineerib vastumeetmed avariiolukordadega toimetulekuks vastavalt nende kriitilisusele.\nVarutalitluspidevuse plaan Contingency Plan on täiendav plaan milles kirjeldatakse vastumeetmed olukordadele kui IT talitluspidevusplaan ebaõnnestub.\nIT talitluspidevuse halduse protsessi peamine eesmärk on vähendada miinimumini avariiolukorra poolt tekitatud ärikatkestus.\nProtsessi võib jagada nelja faasi:\nAlgfaas. Siin defineeritakse talitluspidevuse plaanide kavandid ühe ärikomponendi suhtes. Need kavandid võivad olla sisendiks kogu protsessile.\nNõuete analüüs ja strateegiate defineerimine. Selles faasis on jõutud kliendi ja teenuseosutaja vahel kokkulepeteni peamiste riskide osas, millele on vaja defineerida vastumeetmed ja sellega seoses ka kulutada raha.\nTalitluspidevus- ja varutalitluspidevusplaani vormistamine\nTaastusmeetodite ja protseduuride väljatöötamine\nTalitluspidevusplaani hooldus ja perioodiline ülevaatus, mille käigus hinnatakse IT teenuste talitluspidevusplaani vastavust äri arengule.\n# C.7.2. Kordamisküsimused\nMahuhalduse eesmärk on?\nHinnata sooritusvõimet X\nTagada serveris piisavalt vaba massmäluseadme salvestusruumi\nKõik mahuhaldusega seotud tegevused peavad alati olema üle vaadatud, et leida tasakaal:\nHinna ja mahu vahel\nPakkumise ja nõudluse vahel X\nÄri ja nõudluse vahel\nTalitluspidevusplaani peamine eesmärk on?\nÄrikahju vähendamine miinimumini X\nRiski kalkuleerimise rusikareegel on R=risk;D=kahju;P=ohu esinemise tõenäosus:\nR = D + P\nR = D / P\nR = D × P X\n# C.7.3 Käideldavushaldus\nMääratlema käideldavushalduse otstarve ja defineerida sellega seotud mõisted ning käideldavusmõõdikud\nMääratlema käideldavushalduse meetodid ja tehnikad.\n# C.7.3.1 Käideldavushalduse mõisted\nMääratleda käideldavushalduse otstarve ja defineerida mõisted: käideldavus, töökindlus, tõrge, taastumine.\nTeenused, mis peavad pidevalt toimima on muutunud tavaliseks IT keskkondades. Ajutine teenuse maasolek võib põhjustada väga halba mõju ettevõtte klientide rahulolule ja kogu ettevõtte mainele. Kuna äriprotsesside komponendid on tihedalt läbipõimunud IT komponentidega on oluline et käideldavushalduse protsess arvestab ärile iseloomulike nõuetega.\nKäideldavuse halduse protsess Availability Management Process vastutab teenuse osutamise alas teenuste käideldavuse halduse eest eesmärgiga garanteerida käideldavuse taseme säilimine, mis rahuldab ärivajadusi.\nKäideldavuse halduse protsessiga seotud terminid:\nKäideldavus Availability – IT komponendi võime täita nõutud funktsionaalsust etteantud ajavahemikus. Käideldavuse määravad töökindlus, hooldatavus, teenindatavus, sooritusvõime ja turvalisus. Tavaliselt väljendatakse käideldavust protsendina. Arvutus põhineb kokkulepitud teenusajal ja maasolekul. Parim praktika soovitab arvutada käideldavust lähtudes IT teenuse ärilisest väljundist.\nTöökindlus Reliability – mõõt iseloomustamaks, kui kaua võib konfiguratsioonielement või IT teenus täita ettenähtud funktsioone ilma katkestuseta. Selleks mõõduks on enamasti MTBF (Mean Time Between Failure) või MTBSI (Mean Time Between Service Incidents_**. Terminit töökindlus saab kasutada ka iseloomustamiseks tõenäosust, et protsess, funktsioon, jne suudab tarnida nõutava tulemuse.\nTõrge Failure - kaotatud võime toimida vastavalt spetsifikatsioonile või tarnida nõutavat tulemit. Terminit tõrge võib kasutada IT teenuste, protsesside, tegevuste, konfiguratsioonielementide, jms kohta. Sageli põhjustab tõrge intsidendi, mis takistab teenuse nõuetele vastavat toimimist.\nTaastatavus Recoverability – teenuse võime taastuda tõrkeolukorrast kiirelt ja korrektselt\nTaastatavuse omadust iseloomustavad järgmised parameetrid:\nHooldatavus Maintainability - mõõt, mis näitab, kui kiiresti ja efektiivselt on võimalik tõrke järel konfiguratsioonielemendi või IT teenuse töövõime taastada. Hooldatavust mõõdetakse ja raporteeritakse tihti näitajaga MTRS / Mean Time to Restore Service. Hooldatavust kasutatakse ka tarkvara või IT teenuse arenduse kontekstis, et iseloomustada selle omadust olla kergesti muudetav või parandatav.\nVastupanuvõime Resilience - konfiguratsioonielemendi või IT teenuse võime panna vastu tõrgete tekkele või taastuda kiiresti tõrke ilmnemist.\nTeenindatavus Serviceability - tarnija, kui kolmanda poole võime täita lepingut. See leping sisaldab konfiguratsioonielemendi töökindluse, hooldatavuse või käideldavuse kokku lepitud tasemeid.\nÜlejäänud mõisted seoses käideldavuse haldusega:\nTurvalisus Security – rakendatavad halduspoliitikad, et tagada teatud spetsiifiliste teenuste hoolduseks turvaparameetrid\nElutähtis ärifunktsioon VBF – Vital Business Function - äriprotsessi funktsioon, mis on äri edukuse suhtes otsustav. Elutähtsad ärifunktsioonid on olulised ärijätkuvuse halduse, IT teenuste talitluspidevuse halduse ja käideldavushalduse seisukohast.\n# C.7.3.2 Käideldavuse mõõdikud\nVõrrelda üldkasutatavaid käideldavusmõõdikuid nagu käideldavusprotsent, tõrkesagedus, keskmine tõrketa tööaeg, tõrke mõju.\nIntsidentide elutsükli saab jagada erinevateks faasideks:\nIntsidendi toimumisaeg Incident Occurrence on aeg kui kasutajal ilmneb probleem\nTuvastamine Detection – aeg, mil IT osakonda informeeritakse intsidendist\nDiagnoos Diagnosis – intsidendi põhjuse tuvastamise aeg\nRemont Repairing – aeg kui võetakse tarvitusele vastumeetmed probleemi lahendamiseks\nTaastumine Recovery – aeg kui probleemiga seotud teenused on täielikult taastunud.\nJoonis 7-2. Intsidendi elutsükkel ajateljel (Allikas: Learning Materials for Information Technology Professionals (EUCIP-Mat))\nVastavalt eelpoolloetletud sündmuste järgnevusele on kasutusel järgmised mõõdikud käideldavuse taseme hindamiseks:\nKeskmine parandusaeg MTTR / Mean Time to Repair - keskmine ajavahemik, mis kulub konfiguratsioonielemendi või IT teenuse parandamiseks peale tõrget ehk keskmine aeg ajavahemik IT osakonna teavitamisest kuni teenuse taastumiseni.\nKeskmine tõrketa tööaeg MTBF / Mean Time Bewteen Failure - töökindluse mõõdik. MTBF on keskmine ajavahemik, millal konfiguratsioonielement või IT teenus toimivad ilma katkestuseta. Seda mõõdetakse IT teenuse taastumise momendist kuni järgmise tõrke tuvastamiseni.\nKeskmine intsidentide vaheline aeg MTBSI / Mean Time Between System Incident - töökindluse mõõdik. MTBSI on keskmine ajavahemik süsteemi või IT teenuse ühe tõrke algusest kuni järgmise tõrke alguseni.\nMTBSI = MTBF + MTTR\nKäideldavuse protsent Availability percentage – mõõdab käideldavust protsentides vastavalt valemile:\nkäideldavus = ((AST – DT) / AST) × 100\nkus AST / Agreed Service Time on kokkulepitud teenusaeg ja DT Downtime on maasolekuaeg\nMittekäideldavuse protsent Unavailability percentage – vastand käideldavuse protsendile\nKestus Duration – käideldavuse protsendi ajaline väljendus\nTõrkesagedus Frequency of Failure – keskmine tõrkesagedus\nTõrkemõju Impact of Failure – tõrke poolt põhjustatud kahju hinnang äri perspektiivis\n# C.7.3.3 Käideldavushalduse meetodid ja tehnikad\nMääratleda käideldavushalduse meetodid ja tehnikad nagu komponendi tõrke mõju analüüs, vigade puu analüüs.\nKäideldavushalduse protsessi väljatöötamiseks on erinevaid metodoloogiaid:\nKomponendi tõrke mõju analüüs CFIA – Component Failure Impact Analysis - tehnika, mis aitab määrata komponendi tõrke puhul selle mõju IT teenustele. Koostatakse mõjude maatriks, mille ühel küljel on IT teenused ja teisel komponendid. See võimaldab tuvastada kriitilised komponendid (mille tõrge mõjub mitmele IT teenusele.\nRiskihalduse metoodika vahend CRAMM – CCTA Risk Analysis and Management Method, http://www.cramm.com\nVigade puu analüüs FTA – Fault Tree Analysis - tehnika mida kasutatakse probleemini viiva sündmuste ahela koostamiseks.\nKomponendi tõrke mõju analüüs – selle metoodika abil saab tuletada info, mille alusel toimib IT teenuse talitluspidevuse haldusprotsess. Analüüsi tulemusena saadakse teada üksteisest sõltuvad IT teenused ja komponendid, mille alusel tuvastatakse:\nKriitilised teenused Critical services, mille toimimine sõltub mitmetest komponentidest\nÜksainus tõrkeallikas SPOF – Single Point of Failure - konfiguratsioonielement, mille tõrge tekitab kohe intsidendi ja mille puhul vastumeetmeid pole veel rakendatud. SPOF võib olla isik, protsessi või tegevuse samm või IT infrastruktuuri komponent.\nTeenused, mille jaoks on defineeritud efektiivne taastumine tõrkeolukorrast.\nVigade puu analüüs – võimaldab luua sündmuste ahela, mis põhjustab IT teenuse tõrke. Ahela loomiseks ühendatakse graafiliselt ja loogiliselt erinevate süsteemikomponentide tõrked.\nAllpool on toodud lihtne vigade puu analüüsi mudel, kus puu juur vastab IT teenuse tõrkele ja oksad kujutavad kombineeritud sündmusi, mis esindavad tõrke põhjust:\nJoonis 7-3. Vigade puu mudel (Allikas: Learning Materials for Information Technology Professionals (EUCIP-Mat))\nSündmused, mida vigade puu analüüs katab on järgmised:\nBaas-sündmus Base event – ühe IT infrastruktuuri komponendi tõrge (kas riistvara tõrge või inimlik eksimus_**.\nSummaarne sündmus Resulting event – üks vahepealne oks vigade puus, mis vastab sõndmuste kombinatsiooni tulemusele\nTingimuslik sündmus Conditional event – ainult teatud tingimustel toimuv sündmus (näiteks kliimaseadme rike võib põhjustada teenuse tõrke kui ruumi temperatuur seetõttu ületab lubatud piiri\nPäästik-sündmus Trigger event – sündmus, mis põhjustab ühe või enam muud sündmust.\nSündmused vigade puus kombineeritakse loogikaoperatsioonidega:\nAND – loogiline ja, mille puhul summaarne sündmus esineb vaid siis kui kõik sisendväärtused on tõesed\nOR – loogiline või, mille puhul summaarne sündmus esineb kui üks baas-sündmustest on tõene\nXOR Exclusive OR – loogiline välistav või, mille puhul summaarne sündmus ilmneb kui üks sisenditest on tõene\nTõke Inhibition – sündmus toimub kui sisendid ei ole tõesed\nVigade puu analüüs on toetav instrument käideldavuse planeerimisel ja parenduste tegemisel käideldavushalduse protsessile.\n# C.7.3 Kordamisküsimused\nMilline kombinatsioon järgnevatest on käideldavuse mõõdikud?\nA. Maasoleku protsent\nB. Tõrke esinemise sagedus\nC. Tõrke mõju\nD. Juhtumite arv aastas\nA, C, D X\nMida saab mõõta MTBF abil?\nKõvaketta vea esinemise keskmist sagedust X\nKeskmist tõrkeolukorra kestust\nKeskmist tõrkeolukorra taastamise aega\nKäideldavushalduse analüüsi tööriist on?\nKomponendi tõrke mõju analüüs X\nMiks ei ole reeglina mõistlik tagada teenuse käideldavus 100% perioodi jooksul?\nHoolduse tegemise vajadus\nSuured kulud X\nElektrikatkestused ei võimalda seda teha\n# C.7.4 Kasutajatugi\nMääratlema kasutajatoe otstarve tugiteenuseid pakkuvas ettevõttes\nTuvastama erinevad kasutajatoe tüübid\nDefineerima intsidendihalduse süsteemi peamised komponendid.\n# 4.4.1 Kasutajatoe eesmärk\nMääratleda kasutajatoe otstarve tugiteenuseid pakkuvas ettevõttes.\nErinevalt teenuse tarne ja teenuse toe protsessidest ei ole kasutajatugi Service Desk defineeritud protsessina, vaid tegemist on funktsiooniga, mis on elulise tähtsusega teenuse halduse protsessi jaoks. Kasutajatugi on üksainus kontaktpunkt teenuseosutaja ja kasutajate vahel. Tüüpiline kasutajatugi haldab intsidente ja kasutaja pöördumisi ja tema ülesandeks on ka igasugune suhtlemine kasutajatega. Kasutades kasutajatoe poolt pakutud funktsioone võivad kasutajad saada ühendust teenuseosutajaga, näiteks teatada tõrkejuhtumist, nõuda muudatust mingile teenusele või saada abi teenuste kasutamiseks.\nKasutajatoe rakendamise eelised:\nÜks kontakt kliendile probleemide lahendamiseks ja edasi suunamiseks\nVõimaldab eristada teeninduse tasemed klienditugi, spetsialist, ekspert\nJuhtumite tsentraalne arhiiv ja haldus\nKulude kokkuhoid teenuseosutajale\nTagada kahesuunaline ühendus süsteemi ja kasutajate vahel (ühelt poolt abi ja treening, soovituste andmebaas, teiselt poolt nõuete ja kaebuste vastuvõtmine), et optimeerida kogu IT infrastruktuuri.\nVõimaldada arvutikasutajatel töötada maksimaalse efektiivsusega, lahendades kiirelt iga kahtluse, mis tavakasutajast klient võib esitada. Teine eesmärk on koguda kokku kõik soovitused teenuse parendamiseks.\nPakkuda operatiivset tehnilist tuge teistele protsessidele teenuse toetuse alal (muutuste haldus ja käideldavushaldus protsessid) ja anomaaliate korrigeerimiseks ning tõrkejuhtumite taastamistegevusteks.\nKui reaktiivne kasutajatugi vaid lahendab probleeme siis proaktiivne lähenemine on kasutajatoe kogutud info põhjal järelduste tegemine, planeerimine ja koostöö, mis aitab lahendada probleemide algpõhjuseid, koordineerida muudatuste sisseviimist ja võita klientide usaldust. Kaasaegsed kasutajatoe teenused on rajatud proaktiivse lähenemise baasil.\n# C.7.4.2 Erinevad kasutajatoe liigid\nTuvastada erinevad kasutajatoe tüübid ja nende rakendamise sobivus vastavalt erinevatele asjaoludele.\nKasutajatoe funktsiooni õige rakendamine on teenuseosutamise edu aluseks ning see tuleb luua ametliku äri parendamise projektina, millel on selgelt defineeritud vastutused, omanik ja ärieesmärgid.\nVõimalikud kasutajatoe mudelid:\nLokaalne kasutajatugi Local Service Desk – üks kasutajatugi iga kliendi ettevõtte füüsilise asukoha kohta. Sellisel juhul on kasutatavate protseduuride standardiseerimine ja teadmiste jagamine fundamentaalse tähtsusega.\nKeskne kasutajatugi Central Service Desk – kõik pöördumised kasutajatoe poole registreeritakse kesksest füüsilisest asukohast. Sellise mudeli puhul on käitluskulud kontrolli all ja ressursside haldamine optimaalne.\nVirtuaalne kasutajatugi Virtual Service Desk – üks tehnilise toe keskus, millele pääsevad juurde kõik lokaalsed kasutajatoed. See lahendus leiab rakendust ettevõtetel, mille kontorid asuvad erinevates maades.\nKasutajatoe sooritusvõime ja efektiivsuse hindamiseks tuleb defineerida mõõdikud, mis aitavad täpsustada kasutajatoe peamisi eesmärke.\nKorrektse kasutajatoe disainimisel tuleb arvestada järgmiste põhitõdedega:\nKokku võtta ja defineerida ärieesmärgid\nLeida ressursid ja finantsid\nKonsulteerida kliendiga ja lõppkasutajatega kasutajatoe funktsioonide defineerimisel\nDefineerida mõõdikud kasutajatoe hindamiseks\nKoolitada kliendid ja lõppkasutajad uut teenust kasutama ja mõistma selle tulu.\nTänapäeval on erinevaid tehnoloogiaid, mida rakendatakse kasutajatoe loomisel:\nErinevad elektroonilise side kanalid: e-post, kiirsuhtlus, veebipäringud, internetifoorumid, VoIP telefonikõned, videokõned, jne.\nVeebipõhised rakendused probleemilahenduste ja utiliitide, diagnostikatööriistade või draiverite otsimiseks\nKaugabi tööriistad, mis võimaldavad klienditoe esindajal võtta üle kontroll kliendi arvutis ja aidata probleemi lahendada või õpetada kasutama mingit teenust. Sellised tööriistad võivad olla riistvarapõhised näiteks Intel’i vPro või tarkvaralised, mis omakorda jagunevad eraldi tööriistadeks, mis võivad olla integreeritud operatsioonisüsteemi (näiteks Windows 7 kaugabi funktsioon) või olla saadaval ka eraldi haldustarkvaradena (näiteks Siteremote või TeamViewer).\nOperatsioonisüsteemipõhised utiliidid probleemi kohta info kogumiseks näiteks Problem Step Recorder, crash dump, sündmuste logid, mida saab kasutajatoele edastada probleemi olemuse selgitamiseks.\nIseteeninduslike kasutajatoe keskkondade puhul on olulised järgmised faktorid:\nKlienti toetavate abiprotsesside kaasatus, mis abistavad probleemi defineerimisel\nKommunikatsioon vastuseks kliendi päringule mille järgi on aru saada, et tema probleem on lahendamisele jõudnud ja lahenduse staatuse jälgimisvõimalus\nKasutajatoe ülesannete ja vastutuse määr on enamasti selgelt defineeritud ja intsidendid, mida ei suudeta kiirelt lahendada, suunatakse edasi tehnilise toe meeskonnale lahendada, kes omakorda on vastutav juhtumi lahendamise eest ja tulemuse edastamise eest kasutajatoele. Kasutajatugi vastutab klientide probleemilahenduse käiguga kursishoidmise eest ja vahendab kliendi ning tehnilise toe meeskonna suhtlust.\nKasutajatoe funktsioonide hulka kuuluvad:\nJuhtumite salvestamine ja jälgimine\nKlientide informeerimine juhtumi staatusest ja arenemisest\nEsimese hinnangu andmine probleemile, püüda leida lahendus ja vajadusel edastama probleemi tehnilisele osakonnale\nHallata päringute elutsüklit\nTeise ja kolmanda astme tehnilise osakonnaga suhtlemine probleemi lahendamiseks\nJagada haldusinfot ja soovitusi teenuste parendamiseks\nKlientide koolitusvajaduste kohta märkuste tegemine\nKlientidele probleemilahenduste edastamine ja juhtumite sulgemine\n# C.7.4.3 Kasutajatoe elemendid\nDefineerida intsidendihalduse süsteemi peamised komponendid.\nKasutajatoe poolt kogutud info intsidentidest on kasutatav, et hinnata kogu IT infrastruktuuri kvaliteeti ja käideldavuse taset. Selle info analüüs on väga kasulik teistele teenuse haldusprotsessidele nagu käideldavuse haldus, teenustaseme haldus ja äri talitluspidevuse haldus protsess ning kõigile protsessidele, mis toimivad teenuste tehnilise toe valdkonnas. Näiteks kui mingi probleem juhtub korduvalt võib olla vajalik uuendada või muuta sellega seotud komponente. Muudatused viib läbi muutuste haldamise protsess.\nKogutud info on kasulik ka kasutajatoele, et planeerida proaktiivseid lahendusi probleemidele.\nTegevused, mis viiakse läbi kasutajatoe poolt probleemide lahendamiseks ja kasutajatega suhtlemiseks on kokku intsidendihaldus Incident Management. See on protsess, mis vastutab intsidentide kogu elutsükli haldamise eest. Intsidendihalduse esmane eesmärk on taastada IT teenus kasutajatele nii kiiresti kui võimalik.\nIntsident on IT teenuse planeerimata katkemine või kvaliteedi langus. Näiteks tarkvara viga, riistvara tõrge, inimlik eksimus. Konfiguratsioonielemendi tõrge, mis pole veel teenusele mõju avaldanud, on samuti intsident. Näiteks ühe kõvaketta tõrge kettamassiivis.\nRiistvara või tarkvara uuendamisnõue ei kvalifitseeru intsidendiks ja seda käsitleb muutuste halduse protsess.\nIntsidendi staatus on tema hetkepositsioon oma elutsüklis intsidendihalduse protsessis.\nMõned näited statuse kategooriatest:\nUus New – kohe peale juhtumi algatamist\nTäitmisele määramise järjekorras Waiting for assignment\nTäitmisele määratud Assigned to specialist\nTäitmisel WIP – Work in Progress\nOluline on klientide informeerimine juhtumi progressist. Selle eest on vastutav kasutajatugi.\nKui klient on saatnud päringu kasutajatoele võtab viimane ette järgmised tegevused:\nInfo salvestamine (kuupäev, aeg, kasutaja, jne.)\nKui tegemist on muudatusettepanekuga lähtud kasutajatugi selle edastamisel vastavatest ettevõtte protseduuridest\nKui tegemist on intsidendiga kogub kasutajatugi ja salvestab info intsidendist ja selle põhjustest\nIntsidendile määratakse prioriteet. See sõltub intsidendi mõjust ärile ja teenuse taastamise pakilisusest\nKasutajatugi otsib lahendus enda eelmiste intsidentide kohta kogutud infobaasist\nKui lahendus leiti siis see rakendatakse ja intsident suletakse\nKui lahendus puudub edastatakse intsident tehnilisele meeskonnale. Kui viimane lahendab probleemi salvestab kasutajatugi lahenduse enda infobaasi\nKasutajatugi informeerib klienti intsidendi sulgemisest.\nPeamised tulud, mida annab intsidendihaldus on järgmised:\nVähendatud intsidendi mõju kiire reageerimisega ja sellest tulenev efektiivsus\nProaktiivne kasulike süsteemitäiustuste tuvastamine\nÄrile suunatud haldusinfo kättesaadavus teenustaseme lepingute jaoks\nParandatud jälgimine, mis võimaldab paremini mõõta teenustaseme lepingutes lubatud sooritusvõimet\nParandatud haldusinfo teenuste kvaliteedi vaatepunktist\nParem meeskonna kasutatus, mis viib suurema efektiivsuse saavutamiseni\nKadunud või ebakorrektsete intsidentide ja teeninduspäringute puudumine\nTäpsem info konfiguratsioonihalduse andmebaasis CMDB / Configuration Management Database\nParandatud lõpptarbijate ja klientide rahulolu\nMõned ITIL’i juhtnöörid intsidendihalduseks:\nÄra planeeri kasutada intsidendihaldust isolatsioonis. Kui võimalik laienda planeerimisulatus kaasates teiste tehniliste protsesside rakendamise, integreerimise ja käitluse. Kui kõiki teenuse toe protsesse ei saa ressursipuudusel korraga rakendada alusta kasutajatoe funktsioonist koos intsidendihaldusega.\nPlaneeri andmebaasi loomine, kus sisaldub info intsidentidest.\nPlaneeri kommunikatsioon kasutajatoe ja tehnilise meeskonna vahel, et kasutajatugi oskaks ära tunda teada probleem ja neid kiirelt lahendada.\n# C.7.4 Kordamisküsimused\nMillised kombinatsioonid järgmistest on kasutajatoe eesmärgid?\nA. Garanteerida vastastikune kommunikatsioon süsteemi ja kasutajate vahel\nB. Võimaldada kasutajatoe operaatoritel töötada maksimaalse efektiivsusega\nC. Pakkuda tugiinfot teistele teenuse toe protsessidele\nD. Kontrollida süsteemi toimimist peale konfiguratsioonimuudatuste sisseviimist\nKasutajatoe erinevad liigid on:\nGlobaalne, lokaalne, keskne\nLokaalne, virtuaalne, keskne X\nKeskne, globaalne, virtuaalne\nTegevused, mis seotud seadme remontimisega\nTegevused, mis seotud juhtumi ennetamisega\nTegevused, mis viiakse läbi kasutajatoe poolt juhtumite lahendamiseks X\n# C.7.5 Muutuste haldamine\nKirjeldama IT infrastruktuuri konfiguratsiooni-, muudatuse- ja versioonihalduse parimad praktikad\nDefineerima muudatuse taotluse otstarve ja selle peamised elemendid.\n# C.7.5.1 Konfiguratsioonihalduse praktikad\nKirjeldada IT infrastruktuuri konfiguratsioonihalduse parimad praktikad.\nKonfiguratsioonihaldus Configuration Management on protsess, mis vastutab IT teenuse osutamiseks vajalike konfiguratsioonielementide ja nende seoste haldamise eest. Seda infot hallatakse läbi konfiguratsioonielementide kogu elutsükli. Konfiguratsioonihaldus on osa laiemast teenuse, vara- ja konfiguratsioonihalduse protsessist.\nKonfiguratsioonielement CI / Configuration Item on igasugune komponent, mida on IT teenuse osutamiseks vaja hallata. Iga konfiguratsioonielemendi kohta on info talletatud konfiguratsioonikirjesse (mis paikneb konfiguratsioonihalduse süsteemis) ja konfiguratsioonielemente haldab läbi kogu elutsükli konfiguratsioonihaldus.\nKonfiguratsioonielementideks on tavaliselt IT teenused, riistvara, tarkvara, ehitused, inimesed ja ametlik dokumentatsioon.\nPõhilised konfiguratsioonihalduse tegevused on:\nInfo kogumine iga konfiguratsioonielemendi kohta\nErinevate konfiguratsioonielementide vaheliste seoste analüüsimine ja defineerimine\nInfo talletamine spetsiaalses konfiguratsioonihalduse andmebaasis CMDB / Configuration Management Database, kus hoitakse konfiguratsiooni kirjeid läbi kogu nende elutsükli.\nSüsteemi terviklikkuse kontroll peale iga konfiguratsioonimuudatust\nPidev IT infrastruktuuri analüüs ja jälgimine\nKonfiguratsioonihalduse protsess annab IT infrastruktuuri ja teenuste loogilise mudeli. See tuvastab, jälgib, hooldab ja kontrollib erinevate konfiguratsioonielementide arengut infrastruktuuris.\nSelle protsessi eesmärgid on:\nSaada toetavat infot IT organisatsioonile\nDefineerida ja dokumenteerida protseduurid, et hallata konfiguratsioonielemente\nSaada liides teiste haldusprotsesside jaoks, mis saavad selle kaudu infot kõigi konfiguratsioonielementide kohta\nSaavutada kõigi konfiguratsioonielementide kohene aruandlus\nKontrollida, et infrastruktuur sisaldab ainult autoriseeritud konfiguratsioonielemente\nKontrollida ja garanteerida konfiguratsioonihalduse andmebaasi terviklikkus\nKonfiguratsioonihalduse protsess on sageli toetatud teise protsessi poolt, mida nimetatakse versioonihalduseks Release Management Process. Viimansega on seotud tegevused, mis kontrollivad versioonide arendamise ja haldamisega seotud tegevusi eesmärgiga kaitsta IT-keskkonda ja IT-teenuseid. Peamised tegevused on versioonide planeerimise, installeerimise ja testimise korraldamine ning koopiate haldamine. See protsess on vastutav kõigi lepinguliste ja juriidiliste kohustuste eest, mis on seotud IT infrastruktuuris aktiivselt kasutusel olevate riistvara- ja tarkvarakomponentidega. Selleks, et turvata tarkvarade originaalkoopiaid, säilitatakse need kaitstud alas, mida nimetatakse tarkvara püsikoguks (DSL - Definitive Software Library). See on andmestu, milles säilitatakse ja kaitstakse tarkvaraliste konfiguratsioonielementide lõplikke, kinnitatud versioone.\nTarkvara püsikogu on füüsiline andmestu või säilituskeskkond, kuhu on paigutatud tarkvara originaalversioonid. Tegelikkuses võib tarkvara püsikogu koosneda ühest või enamast tarkvara-andmestust või failihoidlast. Kohustuslik on eraldada lõplikud versioonid arendus- ning testfailidest, mida võib samuti tarkvara püsikogus hoida. Tarkvara püsikogusse lubatakse paigaldada vaid kinnitatud (autoriseeritud) tarkvara, seda reguleerivad muudatuste halduse ning versioonide halduse protseduurid.\nAnaloogselt tarkvara püsikogule hoitakse riistvara varuosad eraldi turvatud asukohas, mida nimetatakse riistvara laoks DHS / Definitive Hardware Store.\n# C.7.5.2 IT muutuste halduse praktikad\nKirjeldada IT muudatusehalduse ja versioonihalduse parimad praktikad.\nIT keskkonnas, kus toimub tehnoloogia kiire areng, mille baasil pakutakse teenuseid, mis omakorda toetavad ärivajadusi, on vajadus ka pidevateks muudatusteks IT infrastruktuuris.\nPeale selle on enamus intsidentidega seotud probleemilahendusi seotud mingi tõrkuva konfiguratsioonielemendi vahetusega. Iga muudatus, mis rakendatakse IT infrastruktuuris kätkeb endas riski kogu süsteemile. Kõik need faktorid loovad vajaduse planeerida selleks tarbeks eraldi protsess, muudatustehaldus, mis vastutab muutuste haldamise eest IT infrastruktuuris. On eriliselt tähtis, et muudatustehaldus oleks läbipaistev ja omaks avatud kommunikatsioonikanaleid, et tagada sujuv üleminek kui muutus aset leiab.\nMuudatusehaldus Change Management on protsess, mis juhib kõigi muudatuste tervet elutsüklit. Muudatusehalduse esmane eesmärk on võimaldada läbi viia kasulikke muudatusi minimiseerides sealjuures võimalikke IT teenuste katkestusi.\nIT kontekstis võib muudatuse põhjus olla erinev:\nUus kasutuselevõetud IT teenus\nMuudatused, mida haldab muudatustehaldus võivad olla seotud kõigi IT infrastruktuuri komponentidega:\nToetavad protseduurid ja dokumentatsioon\nMärkusena, et rakenduste arendamine ei ole osa muudatustehaldusest. Rakendusi hallatakse projektihalduse protsessiga Project Management Process.\nÄri kontekstis, mida toetab IT infrastruktuur, annavad põhjuse eraldi protsessi loomiseks muudatustehalduse tarbeks, järgmised tegurid:\nVajadus analüüsida ja prognoosida IT muudatuste mõju ärile ja äri muutuste mõju IT infrastruktuuri komponentidele.\nOn vajadus välja tuua probleemid, mis põhjustavad suurimaid muudatusi\nLoomulik äri areng ja uute nõuete esilekerkimine põhjustavad muudatusi IT infrastruktuuris. Sellised muudatused on vaja analüüsida ja ette planeerida kui võimalik.\nMuudatuste haldusega seotud terminoloogia ITIL’i baasil:\nMuudatus Change - igasugune lisamine, modifitseerimine või eemaldamine, mis võib IT teenust mõjutada. Muudatuse alla käivad IT teenused, konfiguratsioonielemendid, protsessid, dokumentatsioon jne.\nMuudatuste nõukoda CAB / Change Advisory Board - inimeste grupp, kes aitab muudatuste halduril muudatusi hinnata, määrata prioriteet ja ajatada. See nõukoda koostatakse tavaliselt IT teenuseosutaja erinevate valdkondade, äripoole ja kolmandate isikute nagu tarnijate esindajatest.\nMuudatuse taotlus RFC / Request for Change - ametlik ettepanek teha muudatus. RFC sisaldab soovitava muudatuse üksikasju ja võib olla paberil või elektrooniline. Mõistet RFC kasutatakse tihti ekslikult muudatuse kirje või muudatuse enda asemel.\nMuudatuste ajakava Change Schedule - dokument, mis sisaldab kinnitatud muudatusi ja nende kavandatud läbiviimise aegu. Muudatuste ajakava kutsutakse ka eelseisvate muudatuste ajakavaks FSC / Forward Schedule of Changes.\nTegevused, mis viiakse läbi muudatuste taotluste haldamisel on järgmised:\nMuudatuse taotluste registreerimine ja filtreerimine RFC logging and filtering – muudatuse taotlused analüüsitakse, klassifitseeritakse ja salvestatakse. Igale muudatuse taotlusele omistatakse prioriteet.\nPlaneerimine Planning – selle käigus luuakse muudatuste ajakava\nMuudatuse taotluste kinnitamine RFC approval - muudatuste nõukoda otsustab, milliseid muudatusi rakendatakse\nEhitamine ja testimine Build and testing – muudatuste rakendamine\nRakendamisejärgne ülevaatus Post implementation review – kõik muutused vaadatakse üle ettemääratud perioodi möödumisel\nMuudatuse taotluse sulgemine RFC closure – muudatused on lõplikult teostatud\nJuhatuse aruandlus Management reporting\nMuudatuste registreerimine on üks peamisi tegevusi muudatustehalduse protsessis. Selle käigus salvestatakse järgmine info:\nMuudatuse taotluse identifitseerimisnumber\nTegevused ja muudatused seoses muudatuse taotlusega\nMuudatusega seotud infrastruktuurikomponendid\nMuudatuse taotluse staatus\nMuudatuse taotluse prioriteet ja klassifitseering.\nMuudatuse taotluse klassifitseerimine lihtsustab märgatavalt taotluse planeerimist ja muid tegevusi, mis viiakse läbi teiste teenuse toe protsesside poolt (konfiguratsioonihaldus ja probleemihaldus).\nMuudatuse taotluse prioritiseerimine aitab samuti kaasa muudatuse taotluse planeerimisel. Prioriteet määratakse vastavalt sellele kui suur on probleemi mõju ärile ja kui tungivalt on muudatust vaja. Allpool on prioriteedi määrad, mida ITIL soovitab:\nOtsekohe Immediate – nõutud on kohene tegutsemine, sest tekkinud probleem põhjustas teenuse toimimast lakkamise või tõsised probleemid teenuse kasutamisel suurele hulgale lõppklientidele või on tegemist missioonikriitilise teenuse tõrkega.\nKõrge High – probleem mõjutab tõsiselt paljusid kasutajaid\nKeskmine Medium – tegemist ei ole kriitilise probleemiga aga selle lahendamist ei saa edasi lükata järgmise korralise versioonimuudatuseni või uuendamiseni\nMadal Low – muudatus on õigustatud ja vajalik aga võib oodata kuni järgmise korralise versioonimuudatuseni või uuendamiseni.\nMuudatuse taotluse kategooriad määratakse, et näidata muudatuse potentsiaalse mõju ja riskifaktor süsteemile:\nStandardne Standard – tavaline muudatus, riski tase on madal. Sellised muudatused võib rakendada ilma muudatuste nõukoja kinnituseta\nEsimene tase First level – lihtsasti rakendatav ja madal riskifaktor. Vajab muudatuste nõukoja kinnitamist\nTeine tase Second level – keskmise riskitaseme ja mõjuga muudatus. Vajab muudatuste nõukoja heakskiitu\nKolmas tase Third level – väga kõrge riskitase ja mõju. Vaja kiirelt kokku kutsuda muudatuste nõukoda, et muudatust kaalud ja heaks kiita või tagasi lükata.\n# C.7.5.3 Muutuse taotluse eesmärk ja elemendid\nDefineerida muudatuse taotluse otstarve ja selle peamised elemendid.\nMuudatuse taotluses peavad olema sees järgmised punktid:\nMuudatuse taotluse number\nMuudetavate konfiguratsioonielementide kirjeldus\nMuudatuse tegematajätmise mõju\nMuudetava konfiguratsioonielemendi versioon\nMuudatuse taotluse esitaja nimi, asukoht ja telefon\nSoovitused muudatuste nõukojale (vastavalt vajadusele)\nPlaneeritud muudatuse toimumise aeg\nEnnistamise plaan ehk ebaõnnestunud muudatuse järel olukorra taastamise sammud\nMõju äri talitluspidevusplaanile\nMuudatuse edukaks läbiviimiseks on vaja hinnata selle mõju ärile ja IT infrastruktuurile. Mõju arvestamisel on aluseks erinevad tegurid, mida peab hindama ja analüüsima:\nMõju IT infrastruktuurile ja kliendi teenusele, nagu see on defineeritud teenustaseme lepingus\nMõju teistele teenustele, mis toimivad samas infrastruktuuris\nMõju teistele struktuurielementidele organisatsioonis nagu turvalisus, kontoriteenused, transport, äri\nMuudatuse mitterakendamise mõju\nIT, äri, ja muud ressursid, mis on vaja muudatuse rakendamiseks\nTäiendavad ressursid, mida on vaja siis kui muudatus rakendatakse.\nSelle analüüsi eesmärk on tuvastada, kas muudatuse poolt saadud tulu õigustab sellega seotud riske. Sellest sõltuvalt teeb muudatuste nõukoda otsuse muudatuse läbiviimise osas.\nSpetsiifiline võit, mida muudatuste haldussüsteem annab sisaldab järgmist:\nIT teenuste parem kohandatus äri nõuetele\nSelge protseduur ja kommunikatsioonikanal muudatuste läbiviimiseks nii äri kui tehnilise toe töötajatele\nVähendatud negatiivne muudatuse mõju teenustaseme lepingule ja teenuste kvaliteedile\nParem hinnaanalüüs välja pakutud muudatuste läbiviimiseks\nParandatud probleemi ja käideldavuse haldus läbi muudatustehalduse protsessi kogutud info\nParem IT meeskonna produktiivsus, kuna muudatused on planeeritud ja ei nõua jooksva töö katkestamist või ebaõnnestunud muudatuste ennistamist\nTäiendatud IT protsesside tunnetus, mille aluseks on teenuste kvaliteet ja pädev lähenemine.\nMuudatusi võib läbi viia ükshaaval aga see ei ole sageli praktiline. Kui võimalik, peab muudatusehaldus ajastama heaskiidetud muudatused järgmiste versiooniuuenduste sees ja soovitama sellele vastava ressursside paigutuse. Muudatusehalduse ja versioonihalduse vahel on selge järgnevus. Versioonihalduse protsess mõjutab muudatusehaldust ja täpsemalt on selle roll arendada ja koondada standardsed muudatused uutesse tarkvara- ja riistvaraversioonidesse, mis võetakse kasutusele IT infrastruktuuris. Kuna versioonid on muudatuse ilmingud, siis muudatuse protsess algatab versioonimuudatused läbi dokumenteeritud versioonihalduse protsessi.\nAutoriseeritud muudatuse taotlused tuleb edastada asjaga seotud tehnilistele gruppidele, et muudatused rakendada. Muudatusehaldus on koordineeriv roll, mis tagab, et need tegevused on kaetud ressurssidega ja korrektselt täidetud vastavalt ajakavale.\nOn oluline, et samad standardid ja meetodid, mida kasutati algse konfiguratsioonielemendi jaoks on kasutusel ka muudatuse läbiviimisel. Ennistamisprotseduurid peavad olema enne muudatust defineeritud, et neid oleks võimalik ebaõnnestumiste korral koheselt rakendada olukorra taastamiseks.\nMuudatuste vastupidise mõju ärahoidmiseks teenuse kvaliteedile on tungivalt soovitatav testida kõiki muudatusi eelnevalt kaasa arvatud ennistamiste protseduur.\n# C.7.5 Kordamisküsimused\nKonfiguratsioonielement ei ole?\nRakenduse viga X\nMilline kombinatsioon järgnevatest on kasutusel muutuse mõju hindamiseks:\nA. Muutuse mitterakendamise mõju\nB. Mõju teistele IT-ga mitte-seotud infrastruktuuridele\nC. Täiendavad ressursid, mis on vajalikud peale muudatuse rakendamist\nMilline kombinatsioon järgmistest on muutuste halduse kasu:\nA. Parendatud riski hindamise tegevused\nB. Vähendatud muutuse negatiivne mõju teenuste kvaliteedile ja SLA-dele\nC. Parem taotletud muudatuste maksumuse hindamine enne nende sisseviimist\nD. Konfiguratsioonielementide piiratud arv, mis on seotud muudatusettepanekutega\nKoosta teenustaseme leping ja vali käideldavuse mõõdikud.\nTuvasta vabalt valitud arvuti kõvaketta mudeli keskmine tõrketa tööaeg spetsifikatsioonist. Kuidas seda tähistatakse?\nMillised on tehnilised vahendid, et tagada teenuse käideldavus ühe komponendi rikke korral? Loetle erinevate süsteemi osade jaoks variante.\nTerminid: http://www.itsmf.ee ITIL®V3 terminite ja määratluste sõnastik\nViimati uuendatud: 12/4/2019, 1:22:17 PM


1-toalised korterid, müük 1 33 1 06.04.19 Võru\n1-toalised korterid, müük 1 28,70 2 08.04.19 Viljandi\nVILJANDI, TALLINNA 49, korter, korteriomand, valmis, katastri nr 89704:001:0200, 2/2, 1 tuba, üldpind 28.7 m², ahjuküte, trepikoda lukus, elekter, vesi, maakler: Anna Volmer Raud; Müüa remonti vajav korter Viljandi kesklinna piirkonnas. Korter asub 2-korruselise palkmaja teisel...\n1-toalised korterid, rendile andmine 1 19,80 2 17.04.19 Tartu\nTARTU, KESK TN 32, vajab kap.remonti, korter, palkmaja, katastri nr 79501:002:0348, 2/2, 1 tuba, üldpind 19.8 m², eterniit, maakler: Sabine Liias; Hinnatud Karlova linnaossa on üürile saabunud renoveeritud ja möbleeritud 1-toaline korter. Korter on sisustatud, fotod on tehtu...\n1-toalised korterid, rendile andmine 1 25 2 23.03.19 Pärnu\nPÄRNU, KARUSSELLI 13, korras, korter, palkmaja, katastri nr 62512:036:1290, 2/2, 1 tuba, 1 magamistuba, üldpind 25 m², sileplekk, TV, Internet, dush, mööbel, pesumasin, boiler, külmik, maakler: Krista Järv; Tasuta parkimine, UUS PAKKUMINE Kas sooviksite tulla elama Pärnu ra...\n1-toalised korterid, müük 1 26,50 2 11.04.19 Tallinn\n1-toalised korterid, müük 1 24,20 3 14.04.19 Tallinn\nTALLINN, KESKLINN, VEERENNI 35, korras, korter, puumaja, katastri nr 78401:110:2570, 3/3, 1 tuba, 1 magamistuba, üldpind 24.2 m², elektriküte, TV, dush, kamin, pesumasin, boiler, maakler: Sandra Vorobjovski; pakettaknad, Tasuta parkimine, Müüki jõudis kaunilt renoveeritud kõrgete lag...\ntreppõhk-vesilääne-nigulalemmiklooma2-toaline korteruueduksed, aknadkauplusaluskii18aeg2wifi4 toalisedaia maja16-11taksoomanikultmõõtja15videovalvesissemakseahjud