Mis on config item’id?

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, tarkvara, ehitused, inimesed ja ametlik dokumentatsioon nagu protsesside dokumentatsioon ja TTLd.

Miks on Config Item’id head?

* Tahad näha, kuidas arvuti riistvara konfiguratsioon on muutunud?
* Otsid õiget kiibistiku nime draiverite jaoks?
* Tahad teada, kuidas BIOSi pääsed?
* Mis on windowsi kood? Mis kasutaja parool?
* Tahad teada, mitu mälupesa on emaplaadil?
* Kas arvutil on garantii?
* Kuidas seda arvutit installeerida?
* Mis tarkvara peab sinna olema installeeritud?
* Mis IP aadress arvutil on? Kui suur monitor?
* Missugune printer on installeeritud?
* Kus see arvuti asub? Kes seda arvutit kasutab?
* Proovi viis sarnast küsimust ise mõelda! Oskad? 10?
* Arvutiriistvara on korda tehtud aga kelle arvuti see on?
* Mis see parool siis ikkagi oli?

CI nimi ja asukoht

Kõik olulise tähtsusega seadmed (st va hiired, mikrofonid jne) peavad olema Config Itemina kirjas. CI tüübi ja nime valimiseks on abiks järgnev loetelu:

**Computer**
* CPU – lauaarvutid ja ka serverid (suured kastid)
* LAP – sülearvutid
* RTR – ruuterid
* NAS – võrgukettad
* DVR – videosalvestid

**Hardware**
* UPS – UPSid
* PRN – printerid
* PRJ – projektorid
* PNL – patch paneel
* TEL – telefon
* FAX – faks
* CAM – kaamera
* BCR – ribakoodilugeja
* MON – monitor
* SCN – skänner

**Location**
* Asukoht tuleb märkida vastavalt vajadusele. Kui on väike asutus, kus on 3 arvutit, siis piisab, kui panna ainult asukoha nimi. Nt „Vihula Vallavalitsus“.
* RCK – rack ehk seadmekapp
* Kui on suurem asukoht, siis tuleb lisada üldine asukoht ja selle alla erinevad asukohad. Nt „Vihula Vallavalitsus, serveriruum“
* Asukohaks võib olla hoonetekompleks, hoone, ruum, serverikapp.
* Kui on mitu eri tasandiga asukohta, siis need peavad olema viidatud. Nt „Vihula Vallavalitsus, serveriruum“ on „part of“ Vihula Vallavalitsus.
* Asukoha all peaks olema kirjas aadress, kontakttelefon, lahtioleku aeg ja vajadusel veel infot. Nt Serveriruumi võtme saab sekretäri käest vms.
* Kui kasutada mitmetasandilisi asukohtasid, siis on mõistlik arvuti ära viidata kõigi tasanditega (see ei ole palju lisatööd, ainult 1 või paar linnukest). Niimoodi on teinekord lihtsam asju leida.

**Network**
* MDM – modem
* AP – Access Point
* SWT – switch või hub
* CNV – konverter (VDSL, optika)
* EOP – Ethernet over power seadmed

**Software**
* Litsentsid – klientide tarkvaralitsentsid, võtmed, ligipääsud
* veeb ja post – kliendi kodulehe ja webmaili andmed
* Virtuaalmasinad – virtuaalmasinad, mis asuvad CPU’l

Backup ehk varukoopia

* 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, mis erinevad viimasest koopiast. Võtab vähe ruumi. Reeglina tehakse kord päevas.
* Diferentcial Backup – varundatakse muudatused viimasest full backupist. võtab ruumi rohkem kui incremental, tehakse tavaliselt kord nädalas, nädala lõpus.
* Süsteemi image – varundatakse kogu süsteem. Tehakse “pilt” (image) kogu failisüsteemist.
* Andmebaasi Dump – andmebaasist eksporditakse tekstifailina kogu andmebaasi sisu. Näiteks SQL failina.
* RAID kettasüsteem – Sõltumatute ketaste süsteem. Andmeid salvestatakse mitmele kettale paralleelselt. Andmeid kas peegeldatakse või jaotatakse – lisaks on erinevad variantsioonid peegeldamisest ja jaotamisest.
* Validation – andmete kontrollimine. Kas varukoopia andmed on õiged, st.samad varundatavate andmetega.
* Scheduling – erinevate koopia tööde aegade seadistamine, millal mingit tegevust tehakse.
* Network bandwith – võrgu kiirus, st.arvutivõrgu läbilaske kiirus
* Backup window – aeg, millal on võimalik (või tuleb) varukoopia ära teha.
* RPO ( recover point objective) – seatud eesmärk andmete ajakohasuse kohta. Millises aja punktis peab varukoopia olema taastatav.
* RTO (recover time objective) – seatud eesmärk, et saaks soovitud aja jooksul süsteemi taastada. Aeg probleemi ilmnemise ja ärifunktsiooni taastamise vahel.
* Data security – andmete turvalisus, andmed peavad olema kättesaamatud volitamata isikutele.
* Compression – varukoopia pakitakse kokku, võtab vähem kettaruumi kuid võtab varukoopia tegemisel protsessoriressursi.
* Deduplication – kui mitmete koopiate puhul eksisteerib sarnane ühisosa siis salvestatakse vaid ühisosa ega ei hakata andmeid dubleerima – näiteks mitme kontorimasina full copy.
* Snapshot – varundatakse hetkeseis. Ei sobi niivõrd koopiaks. Näiteks virtualiseerimise puhul snapshot on punkt, kus live süsteem hakkab erinema snapshotist – st.live süsteemi muutumisel snapshoti koopia pidevalt suureneb. Eesmärk on hoida snapshotis selliseid andmeid, et see oleks taastatav täpselt snapshoti ajahetkel. Snapshot ei ise ei saisalda kõiki koopiaks vajalikke andmeid.
* Open file backup – avatud faili või kasutuses oleva andmebaasi varundamine. Tihti vajalik ligipääsu tõkestamine varukoopia tegemise hetkeks.
* Cold backup – andmetest tehakse koopia sellisel hetkel, kus kasutajad ei saa andmetes muudatusi teha
* Hot backup – andmete koopia tehakse töötavast või käigus olevast andmestikust. Näiteks töös olevast andmebaasist.
* System metadata – andmed andmete kohta. Boot sectori kirjeldus, partatsiooni kirjeldus, faili õigused/vms, registri sisu, vms.
* Partition layout – partatsioonide paiguts kettal. Ketas jaotatakse loogilisteks tükkideks andmete hoidmiseks.
* Boot sector – andmete blokk või sektor, mis sisaldab koodi, mida masin oskab lugeda mällu ning käivitada. Eesmärk ongi aidata masinal bootida.
* Master boot sector – spetsiaalne boot sectori tüüp ketta alguses, hoitakse infot loogiliste partatsioonide ning failisüsteemide kohta. Sisaldab nn.loaderit, et saaks käivitada operatsioonisüsteemi.
* On-line backup – varundus, mis on pidevalt kättesaadava. Näiteks väline ketas, NAS või SAN. Puudus on see, et viirus võib kustutada ka selle ketta tühjaks.
* Near-line backup – osaliselt kättesaadav infokandja. Näiteks lindiseade. Hea, kuna ei ole ka viirustele koguaeg kättesaadaval.
* Off-line backup – varundus, kus inimene peab lülitama andmemassiivi töösse. St.peab olema inimese poolt sisse lülitatud või ühendatud, et saaks kasutada.
* Backup site – koht, kuhu koopiaid tehakse. Kas eraldi varundussüsteem, kolmanda osapoole teenus, vms.
* Virtuaalserveri koopia – full copy virtuaalserverist. Tehtud kas operatsioonisüsteemi vahenditega või kolmanda osapoole tarkvaraga.
* Tar koopia – andmed on kokku pakitud tar’iga (sarnane zip, rar, arj, jne)
* Implementation – soovide ja eesmärkidek täitmine olemasolevate võimaluste piires. Implementatsioon.
* Monitored backup – varukoopiate valiidsust monitooritakse ning vajadusel teavitatakse haldureid
* Integrity – andmete vastavasus reaalsusele. Kas koopia on ikka koopia.
* Data wiping (erasing) – andmete hävitamine selliselt, et neid ei ole võimalik taastada. Näiteks spetsiaalse utiliidiga juhusliku korduva andmejada kirjutamine
* Time machine – Apple arvutite varundamise tarkvara
* Shadow Copy – Varundus sisse ehitatud vahenditega. Salvestatakse muudatused. Selliselt on võimalik hoida päris pikaaegselt koopiaid erinevatest versioonidest.

IT intsidendi loomine lahendamisel

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 näitlikustavat materjali.

Need intsidendi täitmiseks vajalikud etapid, mis on esmatähtsad võiksid sisestada ülesse ka checklistina. Sel juhul
meeskonnaliikmed teavad millised etapid peavad olema tehtud.

Sisesta ka tööaeg, mis möödus kliendiga rääkimiseks ning intsidendi kirja panekuks. Soovitavalt tee ka viited config item’ite
vahele. Korralikult koostatud intsident ehk korralikult sõnastatud probleemi olemus on juba pool lahendust

Määra prioriteet
Määra intsidendi prioriteet vastavalt intsidendi tekitavale mõjule ning pakilisusele. Kasuta prioriteedi määramiseks selleks
loodud tabelit! Vajalik võib olla intsidendi probleemi prioriteedi muutmine vastavalt kliendilt tulnud uuele infole või mõnele
muule mõjule.

Kuidas viia lahendust ellu
Pane paika või kasuta olemasolevat plaani intsidendi lahendamiseks. Lihtsama intsidendi jaoks pole plaani vaja, keerulisema
jaoks võiks olla kirjeldatud ka plaan. Plaani täitmist tuleks kontrollida ning vajadusel plaani parandada. Lahendus võib olla ellu
viidud kas meie spetsialistide poolt või ka kliendi enda poolt.

Monitoori(jälgi) muutusi
Jälgi intsidendi käiku alates selle tekitamise hetkest kuni sulgemiseni. Tee selgeks, kas intsidendi staatus on põhjendatud või
mitte

Käi koos kliendiga protsess või lahendus läbi
Edasta kliendile lahendus ja käi kliendiga kogu protsess läbi ning veendu, et lahendus on ellu viidud korretselt.

Määra töö edasisiseks analüüsiks. Eskalleeri teenus!
Määra intsident analüüsimiseks vastavale spetsialistile, kellel on rohkem pädevust ning volitusi küsimuse lahendamisel.
Võimalusel vestle spetsialistiga, et näha kas antud teema on tema pädevuses või mitte.

Määra kindlaks intsidendi mõju
Intsidentide mõju kindlaks tegemine tähendab seda, et selgitatakse milliseid äriprotsesse või teisi Config Itemeid antud
intsident mõjutab. Määra intsidendile mõju. Vajadusel uuenda mõju.

Mitmenda intsidendi tekkimisel ava probleemEnne intsidendi sulgemist proovi veenduda, kas intsident võib veel korduda. Kui tundub, et see võib korduda siis tee uus
intsident tüübiga probleem ning vajadusel määra spetsialistile edasiseks lahenduseks. Esialgne intsident peab olema viidatud
sellele probleemile ning jääma samuti lahtiseks kuni lahenduse korrektse ellu viimiseni.

Uuenda intsidendi informatsiooni
Intsidendi informatsioon võib olla ebapiisav või segadust tekitav. Võimalik, et on vaja kliendilt küsida täiendavat infot.
Ühenduse võtmisel kogu võimalikult palju infot. Eesmärk on koguda infot selliselt, et probleem või intsident muutub
mõistlikuks ja arusaadavaks.

Kategoriseeri intsident
Identifitseeri intsidendi sümptomid ning päritolu. Millest probleem tekkis? Mis hetkel? Peale millist tegevust? Millise
teenusega see seotud on?

Tee kindlaks kui kiiresti on vaja lahendust
Määra kindlaks intsdendi pakilisus. Kui kiiresti peab intsidendi lahendama? Mida see mõjutab?

Pane esialgne diagnoos
Selgita välja intsidendi põhjus ning proovi lahendada intsidenti.Kasuta kogu olemasolevat informatsiooni sarnaste
intsidentide, CI’de, kasutusjuhendite, Google otsingu, KKK teadmistebaasi, jne. Kui lahendust ei õnnestu ellu viia siis mõtle,
kellele see intsidend edasi määrata.

Kontrolli Config Itemi (CI) vastavust
Kontrolli, kas CI infromatsioon OTRSis vastab seotud intsidendile. Vajadusel uuenda informatsiooni või tekita uus intsident
CI info uuendamiseks teise inimese poolt. Config Item’ite kirjeldamisest loe siit.

Sulge intsident
Ametlik intsidendi sulgemine. Intsidendi sulgemiseks küsi kliendilt luba selleks, et veenduda probleemi sobivas lahenduses

Kontrolli topelt intsidente
Topelt intsidentide olemasolul seo intsidendi OTRSis ning sulge need korraga peale lahenduse ellu viimist

Viia lahendus kliendini
Vii ellu konkreetne lahendus. See võib toimuda kliendiga ühenduses olles.

Kontrolli teenuse korrasolekut / probleemi lahendust
Kontrolli, kas lahendus lahendas probleemi või mitte. Kui lahendas siis sulge intsident. Kui ei lahendanud siis saada intsident
uuesti diagnoosimisele. Lihtsamate probleemide puhul on soovitatav kliendilt lahenduse sobivus üle küsida, keerulistemate
küsimuste puhul on see kohustuslik!

Tee kindlaks millise CI’ga on intsident seotud
Tee kindlaks millised CI’d on mõjutatud. Mõjutatud võivad olla nii konrkeetsed probleemsed CI’d kui ka nendega seotud CI’d.
Seo intsident nimetatud CI’dega. Võib ka siduda nende CI’dega mis ei ole niivõrd otseselt seotud!

Anna kiendile tagasisidet
Saada kliendile tagasisidet ning veendu, et klient tagasiside kätte sai.

Algata muutus IT süsteemis
Kui probleemi lahendamiseks on vaja ellu viia suurem muutus siis määra see intsident vastvale spetsialistile!

Vaata üle ja kontrolli intsidendi andmeid
Kasuta kõiki võimalikke andmeid veendumaks, et intsidendi olemusest ja juhtunust on võimalikult selge ülevaade. Intsident
peab olema mõistetav.

Lõpeta ja kontrolli intsidendi andmed
Täida kõik vajalikud andmed intsidendi sulgemiseks. Kontrolli, et lahenduskäik oleks kirjas ning intsident oleks õigesti
klassifitseritud ja priotiseeritud. Veendu, et lahendus oleks kirjeldatud selliselt, et seda saaks jägmise sarnase intsidendi
lahendisel. Kui leiad intsidendist vead siis informeeri sellest vastavaid inimesi ning juhata tähelepanu vigadele. Veendu, kas see
intsident võib põhjustada ka teisi intsidente või kas esksiteerib mingi juurpõhjus sellele intsidendile mis vajab lähemat
uurimist.Kui on siis tekita probleem.

Määra intsident peamiseks intsidendiks’
Määra intsident suureks või peamiseks probleemiks kui see mõjutab paljusid IT ja äriprotsesse ning vajab kiiret lahendamist
ning palju spetsialiste.

Otsi sarnaseid intsidente
Otsi sarnaseid intsidente, et saaks antud intsidenti kiiremini lahendada. Üle võib vaadata ka sarnased intsidendid.

Koosta KKK
Koosta kliendile ja meeskonnale KKK. Kategoriseeri KKK, kirjelda probleemi, sümptomeid ja lahendusi ning vajadusel
kommenteeri asjasse puutuva informatsiooniga. Kasutada võib ka ekraanipilte, vitieid CI’dele või asjasse puutuvatele
intsidentidele. Kliendile kirjutatud KKK peab olema topelt kontrollitud, et kõik oleks keeleliselt korrektne.

Kontrolli tööaja sisestamist
Kontrolli intsidendiga seotud tööaja sisestamist. Töö aja sisestamise juhendi leiad käesolevast dokumendist. S.h.kas on töö
lisatöö või on see väljaspool tööaega töö.

Kliendi identifitseerimine
Klient tuleb kõikidel töötajatel identifitseerida ees- ja perekonna nime järgi. Vajadusel tuleb kontrollida, kas kliendi andmed
OTRSis on värsked (nimi, telefon, ametikoht, e-maili aadress). Identifitseerimine on eriti oluline ligipääsuõguste andmisel.

Ligipääsuõiguste andmine
Ligipääsuõigusi antakse eranditult SMS teel. St.kasutajanimi ja parool edastatakse vaid SMS teel, mitte mingil teisel meetodil.
Selliselt välistatakse ligipääsuõiguste sattumine valede inimeste kätte (social engineering).

Ligipääsu andmine kliendiportaali.
Klienti tuleb informeerida, et tal on võimalus logida sisse kliendiportaali ning sealt näha kõiki temaga seotud intsidente, nende
lahenduskäiku ja lahendusi. Lisaks saab klient sealt ka lugeda korduma kippuvaid küsimusi. Kliendiportaalis ei tohi enne KKK
moodulit aktiveerida kui seal on piisvalt sisu. Kliendiportaali sisu peab teenuse juht kontrollima vahetult konkreetse kasutaja
kasutajanime ja parooliga.

Telefonikõnede suunamine
Teenuse juht vastutab, et kõned oleks alati vastatud või delegeeritud õigele inimesele.

Kaugtoe osutamiseks vajaliku info salvestamine
Vajalik on seadistada igale arvutile TeamVieweri püsi ligipääs. Serverite jt.seadmete puhul vastavalt kas RDP, SSH, vms
ühendus. Teenuse juht hoolitseb, et kõik vajalik info kaugelt haldamiseks ja ligipääsuks on OTRSis kirjas. Soovitav mõelda
selleks mingi teistele ja endale arusaadav süsteem.

Lisada/muuta või kustutada teenus/CI monitooringusse
Vajadusel lisada teenus või config item monitooringusse vastavalt monitooringu teenuse kirjeldusele. Paremaks probleemi
lahendamiseks

Teenuse juht peab töögraafiku arvestust
Teenuse juht on kursis tehnikute töögraafikuga sisestades vastavad parameetrid intsidendi andmetesse.

Rämpsposti filtreerimine
Tõstab rämpsposti “Junk” nimekirja (queue)

Mis on IT config item?

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, inimesed ja ametlik dokumentatsioon nagu protsesside dokumentatsioon ja TTLd.

Miks on IT Config Item hea?

• Tahad näha, kuidas arvuti riistvara konfiguratsioon on muutunud? Vaata IT config item.
• Otsid õiget kiibistiku nime draiverite jaoks? Config item.
• Tahad teada, kuidas BIOSi pääsed
• Mis on windowsi kood
• Mis kasutaja parool?Tahad teada, mitu mälupesa on emaplaadil
• Kas arvutil on garantii
• Kuidas seda arvutit installeerida
• Mis tarkvara peab sinna olema installeeritud
• Mis IP aadress arvutil on
• Kui suur monitor
• Missugune printer on installeeritud
• Kus see arvuti asub? IT config item kirjeldab.
• Kes seda arvutit kasutab
• Mis on veel konfig item kirjas

Config Item andmed

Andmete sisestamisel tuleb olla täpne ja detailne. Ühtepidi on tülikas võib-olla võrgukaardi MACi või arvuti
seerianumbrit kirja panna, aga teinekord säästad sellega kedagi kohalesõitmast.

Seega tuleks kõik vähegi oluline info kirja panna. Eriti olulised on aga võrguparameetrid ja kasutajakontod. Kuid ei saa ka
unustada muud. Nt kui üks jätab märkimata, et arvutis on raamatupidamise andmebaas, siis kui järgmine hakkab sellele
masinale reinstalli tegema, ei pruugi ta seda märgata ja unustab koopia teha.

Oluline on panna andmed kirja ka normaalsel kujul, et need pärast mugavamalt otsitavad oleksid. Nt MAC’i sisestame
väikeste tähtede ja kirjavahemärkideta. Muude asjade sisestamisel võib ka kindluse mõttes mõnd vana CI’d vaadata, kui ei
tea, kuidas sisestada.

CI viited

• Kõik CI’d peavad olema viidatud kõige vajalikuga:
• Asukoha või asukohtadega
• Ühendatud seadmetega (võrguseadmed, printerid, UPS’id jne)St et üldjuhul peaks igas asutuses olema selliseid seoseid: printer>arvuti>switch>ruuter>modem
• Intsidentidega – kui intsident on süsteemi töökindluse hindamisel või konfiguratsiooni taastamisel (reinstall) oluline,siis peab see olema viidatud vastavate CI’ga
  Nt printeri tooneri täitmine ei ole kummagi asja kohapealt oluline, kuid toiteploki vahetus või serveri
  konfiguratsiooni muutus on.
• Kui kõhkled, et kas viidata, siis pigem viita.
• FAQ’ga viitamine – kui seoses mingi konkreetse seadmega sisestad FAQ, siis viita see ka seadmega ära.

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 või videotutvustust Youtubest: https://www.youtube.com/watch?v=QLBIrJMi3KE&list=PLsfu0rI3T3o0G5CLSM5hyRxO2FX8RAdJw )

Alates 2001. aastast on tuhanded organisatsioonid kasutanud OTRS teenuste uuenduskomplekti maailmatasemel kuluefektiivsete klienditoe- ja teeninduslahenduste haldamiseks.

Avatud lähtekoodist tuleneval vabadusel rajanev OTRS on pilvest ligipääsetav OTRS OnDemand lahenduse kaudu, samuti on seda võimalik alla laadida ja tänu meie unikaalsele Pack&Go suutlikkusele kasutada oma tulemüüri taga.

OTRS OnDemand on paindlik teenuste haldussüsteem, mida on võimalik konfigureerida abiliiniks, klienditoesüsteemiks, töövahendite halduspäringute süsteemiks ja mitmel muulgi moel.

Ülevaade

OTRS OnDemand on uus pilvepõhine teenus, mille eesmärk on abistada teid igat laadi klienditeeninduslike tegevuste automatiseerimisel, juhtimisel ja parendamisel.

Kindlustunne

OTRS OnDemand on OTRS teenuste uuenduskomplekti uus, pilvepõhine rakendus. OTRS on maailma juhtivaim avatud lähtekoodiga Klienditeenindus- ja äriprotsesside haldussüsteem, mida alates 2001. aastast kasutavad üle maailma tuhanded organisatsioonid. OTRSi rahulolevate klientide hulka kuuluvad Toshiba, Lufthansa, NASA, Fujitsu, Porsche, Nokia, Boeing ja Philips.

Vabadus

OTRS pakutav vabadus on suurem kui mis tahes teisel täna saadaoleval sarnasel lahendusel. OTRS OnDemand lahenduse abil on võimalik kasutada kõiki OTRS funktsioone ilma, et peaksid arvestama riistvara, tarkvara, installeerimise, käivitusega seonduvate viivituste või mis tahes muude traditsiooniliste tarkvaralahendustega seonduvate piirangutega. Tänu uuele Pack&Go suutlikkusele võite mis tahes ajal alla laadida oma OTRS OnDemand rakenduse koos vastavate andmetega ning installeerida ja kasutada seda oma andmekeskuses ilma, et peaksite muretsema OTRS ees tekkivate täiendavate kohustuste pärast.

Paindlikkus

OTRS OnDemand on enam kui tavapärane abiliinilahendus. Tegemist on lõpmatult paindliku teenuste uuendussüsteemiga, mida võib kasutada mis tahes sellises keskkonnas, milles ekspertidest või teenindajatest koosneval meeskond puutub kokku vajaduste tuvastamise, jälgimise, jagamise, töötlemise ja rahuldamisega. OTRS OnDemand paigaldusviisardi pakutavad mitmed eelnevalt konfigureeritud äristsenaariumid võimaldavad teil süsteemi koheselt kasutada abiliinina, töövahendite haldussüsteemina, koolipiirkonna IT-süsteemina või mitmel muulgi otstarbel.

Tarkvara kui teenus (Software as Service, SaaS)

Pilvepõhise arvutuse populaarsus on tulenevalt kulude ja ajaga seonduvatest eelistest kiiresti kasvamas. Selline lahendus võimaldab kasu lõigata keerulistest tarkvaralahendustest ilma kasutustasude, viivituste ja riist- ning tarkvara omamisega kaasnevate probleemideta.

Selle peamine miinuspool, eriti kasvavate ettevõtete silmis, seisneb asjaolus, et nende äriprotsessid ja andmed on lukustatud omandiõiguslikku vormi ja kellegi teise kontrolli alla.

OTRS OnDemand abil väldite takerdumist põlvepõhistesse ja omandiõigustega kaitstud lahendustesse juba täna.

OTRS teenus on avatud lähtekoodil põhinev tarkvarasüsteem, mille abil on võimalik hallata mitmesuguseid äriprotsesse, abiliinist tehnilise toe või IT teenuste juhtimiseni. „Tõrkelehte“ kasutavatel funktsioonidel rajanev OTRS on mõeldud selleks, et aidata tehnilisel toel, müügil, müügieelsetel tegevustel, arvete esitamisel, ettevõttesisesel IT-l, abiliinil ja teistelgi funktsioonidel võimalikult kiiresti ja tõhusalt reageerida sissetulevatele päringutele. Kas teie postkasti laekub palju elektronkirju, millele soovite vastata koostöös oma agentide meeskonnaga? OTRS hakkab teile kindlasti meeldima!

Selle levitamine toimub vastavalt GNU Affero General Public License (AGPL) litsentsile ja programmi on katsetatud Linux, Solaris, AIX, FreeBSD, OpenBSD, Mac OS 10.x ja Windows platvormidel.

Alusta kohe

OTRS OnDemand võimalusi võite proovida juba loetud minutite möödudes. Täitke ära lisatud ankeet ja kasutage OTRS OnDemand lahendust kolmekümne päeva jooksul ilma täiendavate kohustuste tekkimiseta või krediitkaardi numbri avaldamiseta!

Äristsenaariumid

OTRS OnDemand Business Scenarios on komplekt eelnevalt konfigureeritud näiteid selle kohta, kuidas erinevat liiki organisatsioonid võiksid OTRS OnDemand süsteemi kasutada.

Teie OTRS OnDemand süsteemi ülesehitamise esimene samm on seadistusviisardi ettevalmistamine. Viisard võimaldab teil valida eelnevalt defineeritud stsenaariumide seast ühe, samuti jäetakse teile võimalus ehitada üles päris oma unikaalne OTRS süsteem. Kõiki valitud stsenaariume on võimalik viisardis sammhaaval kohandada, et viia töövahend vastavusse just teie organisatsiooni vajadustele.

Ettevõttesisene IT-tugi

Sisemise IT-toe stsenaarium kujutab endast üldstruktuuri sellistele organisatsioonidele, mis kasutavad OTRS OnDemand lahendust IT-tugiorganisatsioonile suunatud küsimuste üle arvepidamiseks.

Tehasehaldus

Üldstsenaarium arvepidamiseks korraliste ja erakorraliste hooldustööde üle tootmisliinide (montaažiprotsessi) süsteemis. See protsessijaamadel rajanev stsenaarium keskendub seadmetele.

Häirekõnekeskus

Kõnekeskuse stsenaarium, mille eesmärk on hallata infovoogu õnnetusjuhtumi, võimalike ohvrite otsimise ja nende lähedastega kontakteerumise korral.

Koolipiirkonna tugi

IT abiliin, mille peamine klient on koolipiirkonna õpetaja või haridustöötaja.

Töövahendite haldus

Tugistsenaarium töövahendite või kinnisvara haldusosakonnale või korporatiivsele organisatsioonile, milles peamise kliendi rolli täidab näiteks oma ettevõtte töötaja või rendiklient.

Turvanõustaja

Seda stsenaariumi kasutab IT-turvalisuse eest vastutav personal, pidades arvet väliste süsteemi turvalisusega seonduvate probleemiteadete ja siseste süsteemiturvalisuse ohtude ja neile reageerimise üle.

Kodu OTRS

See lõbus stsenaarium on näide OTRS OnDemand süsteemi kasutamisest kodus selleks, et pereliikmetel oleks võimalik end kursis hoida mitmesuguste tegevustega, näiteks laste koduste ülesannete või spordisündmustega, esitada ostusoove poeskäiguks või teavitada aednikku vajadusest sel nädalal hekki pügada.

Klubijuhtimissüsteem

See stsenaarium on mõeldud klubide või pidude, näiteks spordiklubide, poliitiliste gruppide, vabatahtlike organisatsioonide jne juhtimiseks, kommunikatsiooniks ja toeks. Stsenaarium tagab klubis või organisatsioonis organiseerijate ja liikmete/osaliste vahelise pideva ja sujuva infovoo.

Turvalisuse juhtimine – oluliste õnnetusjuhtumite teavitussüsteem

Üldine turvalisuse juhtimise stsenaarium on mõeldud hoonete turvalisuse ja mis tahes objektide juurdepääsukontrolli funktsioonide täitmiseks. Sellest on kasu ka teiste oluliste funktsioonide täitmisel, näiteks ekstreemsest ilmastikust ja tormist tingitud turvalisusküsimuste või reisihoiatuste korral.

Sõltumata sellest, kas teie agendid asuvad kohalikus juuksuritöökojas või vallutavad Mount Everesti, saavad nad nüüd abipalvetele vastata paari hetkega ilma, et peaksid olema pidevalt arvuti taga… Probleemi lahendamise järel võivad nad oma iPhone’i taas taskusse pista ja mägironimist jätkata!

otrs teenus

Mis dokumentatsioon? Miks? Kellelt? Kuidas?

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

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

Dokumentatsioonile esitatavad elementaarsed nõuded:

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

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

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

Kaetud võiksid olla sellised teemad:

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