Intsidendi loomine
Loo intsident, kasutades olemasolevat infot intsidendi kohta. Kasuta kliendilt saadud infot, määra intsidendile klient, arusaadav ja asjakohane pealkiri ning kirjelda intsidendi olemust. Oluline on kirja saada võimalikult palju infot, siiski mitte
Igasugune komponent, mida on IT teenuse osutamiseks vaja hallata. Iga CI kohta on info talletatud konfiguratsiooni kirjesse (mis paikneb konfiguratsioonihalduse süsteemis) ja CI-d haldab läbi kogu elutsükli konfiguratsioonihaldus, CI-d on muudatusehalduse kontrolli all. CI-deks on tavaliselt IT teenused, riistvara,
* Backup – on tegevus, kus kopeeritakse failid või andmebaasid selliselt, et need oleks kättesaadavad riist-või tarkvara rikete puhul.
* Full Backup – täies mahus varukoopia. Varundatakse kõik andmed täies mahus. See varunduse liik võtab kõige rohkem ruumi. Reeglina tehakse üks kord nädalas.
* Incremental Backup – varundatakse vaid muudatused,
Loo intsident, kasutades olemasolevat infot intsidendi kohta. Kasuta kliendilt saadud infot, määra intsidendile klient,
arusaadav ja asjakohane pealkiri ning kirjelda intsidendi olemust.
Oluline on kirja saada võimalikult palju infot, siiski mitte liiga palju infot. Kui hiljem tekkib intsidendile täiendavat infot siis
lisa see märkusena.
Võimalusel kasuta ekraanipilte, lisa juurde linke, vms
Intsidendi tüübi kirjeldamiseks tuleb valida antud intsidenti kõige paremini iseloomustav tüüp. Intsidendi tüüpi võib lisainfo juurde tekkimisel muuta. Enne intsidendi sulgemist tuleb kontrollida, kas intsidendi tüüp oli õige. IT intsidendi klassifitseerimine tuleb teha võimalikult täpselt.
Intsidendi tüübid:
Vaata üle intsident ja selle artiklid. Uuri sellega seotud config item’eid. Kasuta kõiki võimalikke vise info hankimiseks. Alates intsidentidest, CI’dest, seostest, sarnastest intsidentidest, Googlest, kliendivestlusest, meeskonnaliikmetega vestlusest, jne. Kogu kokku võimalikult palju infot intsidendi lahendamiseks – see võib
Kliendi peamine roll on intsidentide, probleemide ja informatsiooni edastamine teenuse pakkujale.
Teenuspäringud, intsidendid või probleemid võivad tekkida teistest intsidentidest, probleemidest või teenuspäringutest, muudatuste soovist, monitooringusüsteemist või mõnest muust allikast. Kui konkreetset klienti ei ole teada siis informeeritakse sellest vastava teenuse juhti ning
Mis põhimõtteid võiks jälgida IT kasutajatoe ostutamisel?
Config item on igasugune komponent, mida on IT teenuse osutamiseks vaja hallata. Iga CI kohta on info talletatud konfiguratsiooni kirjesse (mis paikneb konfiguratsioonihalduse süsteemis) ja CI-d haldab läbi kogu elutsükli konfiguratsioonihaldus, CI-d on muudatusehalduse kontrolli all. IT Config Item on tavaliselt IT teenused, riistvara, tarkvara, ehitused,
OTRS teenus
OTRS presentatatsioon lae alla siit: Klienditeenindus- ja äriprotsesside haldussüsteem OTRS.
OTRS OnDemand on võimas, paindlik ja pilvepõhine teenustehalduse lahendus. Tõestatud headuses ja avatud lähtekoodiga OTRS tarkvaral rajanev OTRS OnDemand võimaldab teil tõhusalt juhtida ja optimeerida nii sise- kui ka välisklientidele teenuseid pakkuvat mis tahes organisatsiooni. (Vaata lähemalt: www.otrs.com
it hange
Toon mõned mõtted IT hankimisest. Üle maksmisest, valesti küsimisest, lohakuse mõjust, jne.
Korraliku pakkumise koostamiseks on vaja anda pakkujale võimalikult palju dokumentatsiooni ning samas mitte avaldada detaile, mis võivad kuidagi IT süsteemi turvalisust mõjutada. Kust tõmmata piir? Siiski on võimalik tõmmata mõistlik piir. Näiteks serveripargi ja
Kas te olete mõelnud stsenaariumile, kus Teie IT ühel päeval otsustab töölt lahkuda, temaga juhtub õnnetus või on vajalik süsteemi üle andmine kolmandatele isikutele? Oletame, et Teie infosüsteemis on 100 arvutit, 10 serverit ning hunnik erinevaid võrguseadmeid. Kõik need seadmed on kuidagi konfigureeritud, ühenduses üksteisega, need