Implementacijom IBM Tivoli Business Service Manager-om (TBSM) dobija se sledeće:

• Modelovanje servisa – grafički prikaz kako se određeni alarm reflektovao na stanje konkretnog servisa
• Vizualizacija Root Cause Analysis-a – prikaz mreže je u TBSM GUI-u dat tako da se od servisa spušta do poslednjeg uređaja od kojeg taj servis zavisi, te se direktno ima uvid u to odakle zaista potiče problem koji se manifestovao kao neraspoloživost servisa
• Online bazičan SLA pregled – dostupno je nekoliko mogućnosti za postavljanje SLA pragova, kao i pregled SLA stanja servisa

Slika 1. TBSM_GUI

Osnovni zahtev koji se postavlja pred IBM Tivoli Bussines Service Manager softver jeste mogućnost proizvoljnog kreiranja servisnih modela, te grafička vizualizacija i online monitoring servisa preko ovih modela. To kao rezultat pruža, osim pregleda alarma u vidu tabela (što je funkcionalnost  prisutna u sistemu nakon implementacije fault management-a), mogućnost uvida u servise na način kako oni zaista zavise od opreme u stvarnosti. Takođe, postići će se mogućnost da se vidi kako koja servisna instanca utiče na servis u celini, te da se lako i brzo može utvrditi šta je osnovni uzrok problema.

Softver je skalabilan i prilagodljiv dinamičnom okruženju service i telco provajdera. Na jednostavan način se mogu dodavati novi servisi i vršiti izmene na postojećim.
IBM Tivoli Business Services Manager modeluje servis upravo na način kako on zaista zavisi od opreme i sistema sve dokle je moguće utvrditi od čega zavisi.

IBM Tivoli Business Services Manager je, naravno, kompatibilan sa sistemom za nadgledanje IP baziranih servisa - IBM Tivoli Netcool rešenjem, što se ogleda u tome da se nakon formiranja servisnih modela, alarmi preuzimaju iz postojećeg centralnog mesta gde se stiču svi alarmi iz cele mreže, a to je IBM Tivoli Netcool Object Server. Takođe, IBM TBSM može podatke da preuzima i iz eksternih izvora podataka, što će detaljnije biti pojašnjeno u nastavku dokumenta. Integracija TBSM softvera za vizualizaciju servisa sa Netcool fault management rešenjem ogleda se i u mogućnosti da TBSM šalje alarme o narušenom stanju servisa i eventualnim SLA prekršajima u centralni IBM Tivoli Netcool Object Server, gde se alarmi iz ponuđenog softvera nalaze ravnopravno u tabeli sa ostalim alarmima iz celog sistema.

IBM Tivoli Services Bussines Manager (TBSM) ima i grafički interfejs GUI (graphical user interface) za kreiranje i pregled servisnih modela. Servisni model operateru daje uvid u realnom vremenu kako se menja stanje servisa. GUI je funkcionalan, pregledan, intuitivan i lak za rukovanje.

Sva podešavanja se rade u okviru GUI-a na najpristupačniji i najbrži način za administrator- a softvera, uz mogućnost podešavanje i konzolnim putem.

SLA u okviru TBSM-a

Service Level Agreement, SLA, u okviru TBSM znači prvenstveno u smislu preventive, jer će se dobijati alarmi upozorenja kada se određeni postavljeni pragovi premaše, a pre nego zaista dođe do narušavanja SLA predefinisane kritične vrednosti, što bi, naravno, povlačilo za sobom penale koje treba isplatiti nezadovoljnom korisniku.

Slika 2. SLA u okviru TBSM

TBSM pruža 3 metoda za računanje SLA-a:

• Duration based SLA: prati vreme od nastanka do kraja trajanja incidenta
• Cumulative Duration SLA: prati kumulativno ukupno vreme koliko je servis neraspoloživ u okviru zadatog dužeg perioda vremena (mesec, dan, sat, minut)
• Number of violations in given time period: za vreme definisanog vremenskog intervala prati broj pojava incidenta, nezavisno od toga koliko je dugo incident trajao.

U narednim pasusima sledi pojašnjenje svakog od metoda SLA:

• Prekršaji zasnovani na vremenskom trajanju 
  Prekršaji zasnovani na vremenskom trajanju, ili engl. duration-based violations, omogućavaju da se definiše vreme koliko servis može biti nedostupan pre nego se generiše alarm ili upozorenje. Na primer, ukoliko je servis nedostupan više od 2 minuta generisaće se alarm upozorenja (marginal status), a ukoliko je nedostupan više od 5 minuta biće prijavljen prekršaj ( critical status).
   
• Cumulative violation calculation
  SLA baziran na prekršaju kumulativnog vremena  omogućava postavljanje ukupnog vremena koliko servis sme biti neraspoloživ u okviru nekog dužeg predefinisanog vremenskog intervala pre nego TBSM pošalje alarm upozorenja ili kritičan alarm u TBSM Object Server.
  Primer bi bio da je u okviru npr. jednog meseca dozvoljeno da servis ukupno bude nedostupan 25 min pre nego se generiše upozorenje, ili 45 minuta, što bi izazvalo SLA prekršaj. Sem u toku jednog meseca, praćenja se mogu vršiti u toku dana, sata ili minuta i to simultano za svaki od ovih intervala. Moguće je i praćenje situacije u toku dostupnosti servisa u toku meseca u procentima.
   
• Prekršaji zasnovani na većem broju kratkih incidentnih situacija u datom vremenskom periodu
  Ovaj način podešavanja SLA omogućava praćenje situacije u mreži na osnovu broja incidenata u određenom vremenskom intervalu. Na ovaj način dobija se uvid u to da li postoji neželjeno veliki broj kratkotrajnih incidenata u predefinisanom periodu vremena. Kumulativno vreme ovakvih prekršaja može biti malo, no frekvencija njihovih pojava može ozbiljno uticati na kvalitet  servisa. Primer za ovakav SLA bio bi da u okviru pola sata sme da se dese max. 2 prekršaja pre nego se izazove alarm upozorenja (marginal), a nakon 5 incidenata javlja se crveni alarm.

Zavisno od prirode servisa i potencijalnih problema definišu se načini za praćenje. Ukoliko korisnik potpiše SLA sa ISP tako da npr. ne sme duže od 5 min u toku dana da bude bez interneta, to je možda, za njega samo prividna garancija kvaliteta usluge. Jer ukoliko servis ima problem flip-flap prirode, onda će korisniku često pucati veza. Number of violations SLA bi u ovom slučaju mogao biti mnogo bolja sigurnost za datog korisnika.

Moguće je definisati veći broj različitih SLA-a, te ih potom samo pridruživati konkretnom servisu. Na primer, SLA koji bi se zvao Standard bi imao uslove da u toku pola sata sme da se dese 2 prekršaja za marginal, 3 za bad, dok bi se mogao definisati i SLA Gold koji bi imao strožije kriterijume: 1 incident za marginal, 2 za bad u toku pola sata.

Naravno, svi alarmi koje generiše TBSM biće zajedno sa svim ostalim alarmima u centralnom Netcool ObjectServeru. Alarmi iz TBSM-a govoriće o statusu servisa, koliko dugo je status servisa bad (prekršen postavljen prag i/ili SLA) ili marginal (upozoravajući), te koliko često je stanje servisa bad ili marginal itd.

TBSM omogućava i da se nekim SLA upozorenjima pridaje veći značaj, te se dobija prioritizacija u slučaju pojave više kritičnih alarma. Podešavanjem "koeficijenta težine" za određeni SLA, znaće se koji od nekoliko prispelih kritičnih alarma zahteva pažnju najpre. 

Značajno je pomenuti još i da se sva podešavanja u TBSM-u rade preko web GUI-a.

Penalties (kazna usled prekršaja SLA)

SLA penalty omogućava postavljanje procene troškova za svaki sat u kome su servisi od interesa neraspoloživi. Kalkulacija je bazirana na JEDINICI CENE PO SATU nedostupnog servisa (od trenutka kada je narušen SLA). Samim tim, penalties se obračunavaju samo uz cumulative duration sla.

Na slici 1. u donjem desnom kraju se vidi otvoren SLA tab za jedan od servisa sa slike. Odmah se preko boje (žuta ili crvena) ima uvid u to koliko je ozbiljno narušen SLA. Takođe, tu su informacije o tome koliko već traje incident i koliko je ostalo do trenutka prekršaja SLA (vreme sa znakom "–" govori o tome koliko je već dugo prekršen SLA), datum, kao i kolona Penalty. (Naravno, alarmi iz ove tabele nalaze se i među "običnim" alarmima na Netcool Webtop.)

SLA Charts

Desnim klikom miša na željeni servis i odabirom potrebne opcije dobija se grafički prikaz stanja željenog servisa. SLA Chart je raport dostupnosti i SLA statusa servisa koji se može koristiti za brzi uvid u stanje servisa. I ovde treba napomenuti da je za ovakav pregled stanja SLA statusa servisa, potreban, naravno, cumulative duration sla.

Ispod grafičkog prikaza (2D ili 3D) nalaze se i dodatne tabele sa informacijama o iznosima kazni za prekršene SLAs (u dolarima $), kao i još jedna tabela sa kolonama gde se navodi kritični element koji je izazvao povredu SLA-a, trenutno stanje kritičnog elementa (npr. still down), ili vreme kada je situacija razrešena (ili nije razrešena te stoji unresolved), kao i ukupno vreme koliko traje "havarija".

Grafički prikaz daje informacije za vremenski interval koji se postavlja zadavanjem početnog i krajnjeg datuma od interesa za dnevni ili pregled iz sata u sat. Takođe, ponuđene su gotove opcije (na klik) Hourly, Daily ili Monthly vremenski raspon prikaza na slici.

Na primer, moguć je prikaz u toku jednog dana iz sata u sat, ili npr. u toku jednog meseca iz dana u dan itd.

Takođe, u svakom trenutku se može sa dnevnog pregleda prebaciti na mesečni pregled jednim klikom.

Maintenance Window

Naravno, postoje trenuci kada Vaša kompanija vrši održavanje svoje opreme, te to vreme nipošto ne sme ući u kalkulaciju SLA prekršaja. TBSM ima mogućnost za podešavanje određenog vremenskog perioda kada prijavljeni incidenti neće uticati na SLA. Moguće je podesiti npr. da se SLA ne računa svakog ponedeljka od 2-4am kada se obavljaju određeni maintenance poslovi na opremi. Moguće je, na primer, tako i regulisati da SLA "radi" samo od ponedeljka do petka, ukoliko se stvori potreba za tako nečim…

Dok je pod maintenance-om status se na GUI-u vidi kao plav (za razliku od uobičajenih zelene, žute (marginal) ili crvene (bad) boje) i uz ikonicu koja reprezentuje servis stoji mali znak kao da su radovi u toku.

Dokle god je servis plav (under maintenance) bilo koji dolazeći event nema uticaj na status dotičnog servisa.

Service Heartbeat

Sem potrebe za informacijom da li je stanje servisa marginal ili bad, postavlja se pitanje šta ako se desi da servis otkaže bez mogućnosti da pošalje bilo kakav alarm?

To što ne stiže crveni alarm nije apsolutno siguran znak da je sa servisom zaista sve u redu. Podešavajući TBSM Service Heartbeat od servisa se zahteva da redovno (npr. na svakih 2 minuta) referiše o svom status čak i ukoliko je status dobar (good). Ukoliko ne dobija nikakve informacije od servisa, njegovo stanje se prikaže kao Unknown, što bi trebalo takođe da alarmira osoblje da provere stanje tog servisa.

Custom Views

Svaki segment service viewer-a se može prilagoditi tako da prikazuje informacije na način koji je prikladan konkretnom servisu. Može se definisati više različitih pregleda koji bi bili dostupni na klik miša u drop-down listi. Moguća je potpuna kontrola koje informacije će na prvi pogled davati ikonica odabrana da reprezentuje određeni servis. Za neke servise biće dovoljni možda samo status (boja) i jedan izabrani podatak, dok će za druge servise biti potrebno više podataka, uključujući i one vezane za SLA tog servisa.

Takođe, moguće je definisati filtere tako da, kada se premaši postavljeni prag, dobije se vizuelni efekat flash-ovanja u cilju privlačenja dodatne pažnje.

Može biti od koristi i mogućnost da se definiše uslov čijim će ispunjenjem ikonica servisa da se pojavi na GUI ekranu. Ukoliko je servis dobrog statusa i nije ga potrebno stalno imati na oku, zgodno je da ne pravi gužvu i ne odvlači pažnju.

Generalno, sve što se vidi na GUI može se menjati i prilagođavati. Može se, na primer, napraviti tako i da se desnim klikom omogući ulazak na određeni link npr. IBM-ov link gde se nalazi dokumentacija o TBSM-u...

Slika 3. Primer ikonica sa različitom količinom iformacija koje prikazuju

User Management

Dozvola pristupa konkretnim stvarima određenim ljudima, ili grupi ljudi, neophodna je  posmatrano sa strane bezbednosti. Samo određeni zaposleni smeju da imaju potpunu kontrolu nad svim aspektima TBSM, dok ostali mogu imati samo pristup uvida u podatke. Kontrola prava pristupa vrši se na nivou kreiranja grupa sa posebnim privilegijama, te smeštanjem korinika TBSM-a u određene grupe. Dodeljivanjem rola moguća je kontrola skoro apsolutno svakog mogućeg slučaja: da se korisniku dozvoli npr. da edituje template, ali ne i da kreira template, ili samo da vidi servise bez dalje mogućnosti uticaja na njih...

Korisna je i mogućnost da se, nevezano za prethodno dodeljena prava konkretnog korisnika, i na nivou samog template-a i servisa mogu definisati ograničenja pristupa konkretnoj instanci.

Eksterni izvori podataka

Važno je napomenuti da IBM Tivoli Business Service Manager podržava i eksterne izvore podataka. Podaci iz eksternih izvora se mogu koristiti da, uobičajeno, određuju pragove za bad, marginal, good status, ali mogu se koristiti i za popunjavanje numeričkih atributa na osnovu kojih se isto može zasnivati status servisa (npr. response time, broj otvorenih tiketa itd.) Ovakvi podaci se mogu, ravnopravno sa defaultim, nalaziti u tabeli u TBSM GUI.
Podaci iz externog izvora se uzimaju bilo jednom dnevno u zadato vreme, bilo tako što se zadaje frekvencija poliranja.

Preciznim pristupom koristeći SQL zahtevaju se iz externog izvora samo podaci za koje je procenjeno da su potrebni - npr. samo open ticket sa severity>4 uređeni opadajući po broju tiketa.

TBSM podržava integraciju sa sledećim eksternim izvorima podataka:

• DB2
• Informix
• MS_SQL
• MySQL
• Oracle
• PostgresSQL
• Sybase