UNIVERZITET U SARAJEVU ELEKTROTEHNIKI FAKULTET ODSJEK ZA TELEKOMUNIKACIJE

SEMINARSKI RAD
Tema: Service Level Agreements - SLA

Sarajevo, 21.04.2012 god.

orbadi Muharem 517/14927 Malibegovi Alen 444/14676 Bubalo Ajdin 506/14820

Sadraj
1. 2. Uvod ........................................................................................................................................ 3 Ugovor o nivou usluge (eng. Service Level Agremments) - SLA....................................... 4 2.1. 2.2. 2.3. Struktura SLA .................................................................................................................. 4 Elementi SLA okvira........................................................................................................ 6 Dizajniranje SLA okvira .................................................................................................. 6 Korporativni nivo SLA ............................................................................................. 6 Korisniki nivo SLA ................................................................................................. 7 Vienivoski SLA ....................................................................................................... 7

2.3.1. 2.3.2. 2.3.3. 3.

ivotni ciklus SLA ................................................................................................................. 9 3.1. 3.2. 3.3. Arhitektura koja podrava SLA ..................................................................................... 10 Modeliranje sporazuma o nivou usluge ......................................................................... 11 Pregovaranje o SLA ....................................................................................................... 13

4.

Operational Level Aggrement - OLA ................................................................................ 15 4.1. 4.2. 4.3. 4.4. Elementi OLA ................................................................................................................ 15 Aktivnosti, metode i tehnike SLM faze ......................................................................... 16 Praenje ostvarenja razine usluga .................................................................................. 17 Usporedba, mjerenje i poboljanje zadovoljstva klijenta ............................................... 18

5. 6.

Zakljuak.............................................................................................................................. 20 Literatura ............................................................................................................................. 21

1. Uvod
Na prvom mjestu dananjeg uspjeha jedne kompanije se nalazi usluga mrene i informatike tehnologije (IT) koju ona nudi svojim pretplatnicima. S druge strane se nalaze IT usluge koje kompanije nude svojim zaposlenicima. Bilo kakvi padovi u mrei ili IT uslugama mogu prouzrokovati ozbiljne, ak i katastrofalne, tete za posao. To znai da su osoblje brige o kupcima, mreni ininjeri i IT osoblje pod stalnim pritiskom osiguranja traene razine usluge za kupce i korisnike. Uzimajui u obzir sloenost i dinamiku prirodu dananje mree jedne kompanije, postizanje visoke razine usluge za korisnike predstavlja pravi izazov i zahtjev. Stvaranje i primjena uinkovitih ugovora o razini usluge, jame odreenu kvalitetu usluge. Uz Service Level Agremments modul moe se upravljati cijelim opsegom SLA procesa, od definiranja SLA i nadzora uskladivosti, do prikupljanja i analize podataka izvedbe, pronalaenja problematinih podruja i stalnog poboljanja ponuenih usluga. Jednom primjenjen, ugovor o odravanju nivoa usluge (SLA) takoer nudi i real-time, proaktivno SLA upravljanje s gledita zadovoljenja oekivanja. Kao rezultat, moete drati ponuenu IT uslugu u bliskoj vezi s poslovnim zahtjevima, te neprestano raditi na poboljanju kvalitete usluge. Upotrebom SLA modula moete automatizirati korake za upravljanje, konfiguraciju i dokumentiranje svih vrsta ugovora uz podatke i procese koji su specifini za vau organizaciju. Moete odrediti koju vrstu SLA elite postaviti, kao npr. vrijeme odgovora ili rijeenja incidenta, postotak raspoloivosti alata ili usluge, ili maksimalan broj ili vrijeme pojavljivanja ispada usluge. Na primjer, moe se odrediti da svaki incident mora biti rijeen unutar 4 sata, te da tokom jednog mjeseca, 98% incidenata prijavljenih na help desk mora biti rijeeno u tom vremenskom intervalu. Upotrebom SLA modula i radom s poslovnim korisnicima na uspostavljanju obaveza ugovora, moe se pametno povezati usluga s poslovnim ciljevima, postaviti prioritete zasnovani na poslovnom kontekstu, te osigurati odgovarajui nivo IT usluge. Openito, SLA moe biti unaprijed definiran tokom razvojne faze. Modul nudi mogunost ovlatenim korisnicima stvaranje novih SLA i mjerenje postojeih. Vrsta procesa i zahtjeva unutar jednog SLA se odreuje unutar kompanije, u zajednikom radu s kupcima.

2. Ugovor o nivou usluge (eng. Service Level Agremments) - SLA

Postoje razne definicije sporazuma o nivou usluge koje su predloile razliita standardizacijska tijela i organizacije. ITU-T definira SLA kao formalni sporazum izmeu dva ili vie entiteta nastao nakon aktivnosti pregovaranja u svrhu procjene karakteristika usluge, odgovornosti i prioriteta svake strane. TM (eng. Tele Management) forum unutar SLA Management Handbook spominje SLA kao element formalnog, dogovorenog ugovora izmeu dviju strana, tj. izmeu davatelja usluge (eng. Service Provider, SP) i klijenta. Od samog iniciranja usluge do prestanka rada usluge SLA dokumentira zajedniko vienje svih aspekata usluge, uloga i odgovornosti obju strana. IETF definira SLA na slian nain kao i ITU-T, kao sporazum o uslugama izmeu klijenta i davatelja usluga koji odreuje usluge koju treba primit korisnik. SLA treba biti izraena na nain koji je razumljiv korisniku. To obuhvaa osnovna obiljeja usluge i dobro definirane nedvosmislene kriterije za procjenu je li usluga isporuena u skladu s sporazumom. SLA se mora sastojati od pravila odgovornosti za raskidanje sporazuma kako za davatelja usluge, tako i za korisnika. Obino se ukljuuju parametri kao oni definirani u ITU. Jedan od istaknutijih standarda za reprezentaciju i pregovaranje o SLA sporazumu, WS (eng. Web Services) Agreement, razmatra SLA kao sredstvo definiranja dinamiko uspostavljenog i dinamiki upravljanog odnosa izmeu stranaka. Cilj ovog odnos je isporuka usluge jednoj od stranaka u kontekstu sporazuma. Upravljanje isporukom se ostvaruje definiranjem odgovarajuih uloga, prava i obveze stranaka. Sporazum moe odrediti, ne samo funkcionalna svojstva za identifikaciju ili stvaranje same usluge, nego i nefunkcionalna svojstava, kao to su performanse ili raspoloivost.

2.1.

Struktura SLA

SLA moe sadravati stavke o performansama, naplati i dostavi usluga, te takoer pokriva pravnu i ekonomsku prirodu ugovora. Stvarna struktura ovisi o tipu i aktivnostima organizacije. ITU-T je u predloio openitu struktura SLA sporazuma koja je neovisna o tipu usluge ili koritenoj tehnologiji. Takav pristup je posebno koristan u okruenjima s vie davatelja usluga. Kako je prikazano na slici 1, SLA se odnosi na sve usluge razmijenjene izmeu dva entiteta. Struktura SLA se sastoji od jednog zajednikog dijela i od dijelova koji su specifini za pojedinu uslugu. Specifikacija WS-Agreement prua emu za definiranje cijele strukture dokumenta sporazuma.

Slika 1. Generika struktura SLA Na slici 2 prikazana je openita struktura SLA. Neobavezni dio sporazuma ime koristiti se kako bi se dalo ime sporazumu koje je razumljivo ovijeku, dok obavezni dio sporazuma kontekst sadri informacije o sporazumu (npr. tko su ukljuene stranke, oko kojih usluga se dogovara trajanje ugovora itd.). Uvjeti koji se navode unutar SLA za omoguavanje usluge zovu se QoS Ciljevi ili Garantirani uvjeti te pojedinani uvjeti mogu biti vani kako za kupca (Korisniki uvjeti) tako i za davatelja usluge (Uvjeti davatelja usluge). Uvjeti mogu obuhvatati jedan ili vie uvjeta usluge i niti jedan ili vie uvjeta garancije koji specificiraju ciljeve razine usluge i poslovne vrijednosti koje su vezane uz te ciljeve. Svakom uvjetu se moe pridodati vanost (eng. Importance) ili poslovna vrijednost (eng. Business value).

Slika 2. Openita struktura SLA

5

2.2.

Elementi SLA okvira

Veina SLA definiranih prema ITIL-u sadri nekoliko zajednikih elemenata: Opis usluge Djelokrug sporazuma Raspoloivost usluge Pouzdanost Korisniku podrku Kontakt osobe Proces eskalacije Rijenik Pragovi odnosno okidai eskalacije Akcije koje se poduzimaju nakon eskalacije

2.3.

Dizajniranje SLA okvira

Koristei katalog usluga, SLM (eng. Service Level Management) mora dizajnirati najprikladniju SLA strukturu kako bi se osiguralo da su sve IT usluge i klijenti pokriveni na nain koji najbolje odgovara potrebama organizacije. Service level agreement moe biti definiran na nekoliko naina: Korporativni nivo SLA (eng. Corporate level SLA) Korisniki nivo SLA (eng. Customer level SLA) Vienivoski SLA (eng. Multi level SLA)

2.3.1. Korporativni nivo SLA Ugovor pokriva jednu IT uslugu za sve korisnike. Primjerice SLA koji pokriva uslugu osiguranja e-mail pote obuhvaa sve klijente te usluge. Potekoe nastaju ako razliiti klijenti koji koriste istu uslugu imaju specifine zahtjeve ili pak ako su zbog infrastrukture razliite razine usluga neizbjene. U takvim sluajevima definiraju se razliiti ciljevi unutar istog ugovora.

Gdje je mogua zajednika razina IT usluge koja se prua svim podrujima poslovnog sistema (npr. osiguranje e-mail-a, telefonskog sistema, i sl.) Service based SLA je efikasan pristup. 2.3.2. Korisniki nivo SLA Ugovor sa grupom korisnika koji pokriva sve IT usluge koje ta grupa koristi (npr. sporazum izmeu odjela financija i IT odjela koji pokriva raunovodstveni sistem, sistem naplate, sistem javne nabave i bilo koji drugi informatiki sistem koji odjel financija koristi za svoje djelovanje). Klijenti esto preferiraju takav oblik SLA jer u jednom dokumentu su sadrani sve zahtjevi za IT uslugama koje oni koriste. 2.3.3. Vienivoski SLA SLA takoer moe biti definiran na vie nivoa kao sto je ilustrirano na slici 3. Sljedei primjer opisuje SLA definiran na tri nivoa: 1. Korporativni nivo pokriva sva SLM pitanja za svakog korisnika IT usluge u itavoj organizaciji. Situacije koje pokriva ovaj nivo su prilino nepromjenjiva pa esta auriranja nisu potrebna. 2. Klijentski nivo pokriva sve situacije vezane uz odreenu grupu korisnika ili poslovni odjel bez obzira na vrstu usluge koju koriste 3. Nivo usluge pokriva sve situacije vezane uz specifinu uslugu koji koriste odreene grupe klijenata

Slika 3. Vienivoski SLA

7

Ukoliko je struktura SLA definirana na vie nivoa potrebno je uloiti dodatan napor kako bi se izbjeglo nepotrebno dupliciranje na razliitim nivoima. Takoer potrebno je vie rada kako bi se uredili odnosi i veze izmeu Service Catalogue i Configuration Management System. Organizacije esto definiraju svoje standarde i predloke koji zatim slue kao polazna taka za sve SLA, SLR i OLA. Razvoj takvih standarda osigurava da su svi sporazumi razvijeni na skladan i konstantan nain te to olakavanja kasnije koritenje i upravljanje tim dokumentima. Tekst SLA treba biti kratak i jasan i ne smije ostavljati mjesta dvosmislenosti. Nema potrebe za pravnom terminologijom ve treba teiti svakodnevnom vokabularu. Preporuljivo je da SLA sadri rijenik koji definira sve pojmove koritene u tekstu ugovora koji bi mogli izazvati nejasnoe. Ukoliko SLA pokriva usluge koje se dostavljaju u inozemstvo, treba obratiti pozornost na kvalitetu prijevoda. SLA izraen na jednom jeziku koji se koristi u razliitim dijelovima svijeta mora uzeti u obzir razliitosti u terminologiji, stilu i kulturi razliitih zemalja. Gdje IT usluge pruaju druge organizacije, odnosno vanjski suradnici, ciljevi IT usluga ponekad su definirani u ugovoru, a ponekad u SLA koji je pridodan ugovoru. Koji god dokument se koristi, od kljune je vanosti da su ciljevi jasno i jednoznano dokumentirani jer to prua temelj za uspjean odnos i kvalitetnu isporuku IT usluga.

3. ivotni ciklus SLA

Definisanje ivotnog cilkusa SLA ovisi o uvedenom modelu upravljanja SLA i mogunostima arhitekture na kojoj se primjenjuje. Zajednica CoreGRID u svom radu, nadovezujui se na ivotni ciklus usluge definiran od strane TM Foruma, predlae ivotni ciklus SLA, prikazan na slici 4, gdje se svaka od faza odnosi na SLA, a ne na uslugu. U prvim fazama ivotnog ciklusa SLA formiraju se opti predloci SLA te davatelji usluga te predloke oglaavaju. Pojedini SLA je ispregovaran i dogovoren na temelju predloka. Faza pregovora je odvojena od faze dogovora zato to pregovori ne dovode uvijek u konanici do dogovora. Zatim, faza dogovora je odvojena od faze izvrenja zato to usluga opisana u SLA sporazumu moe poeti neko vrijeme nakon to je dogovoren SLA. Unutar faze izvravanja rezerviraju se resursi i stavljaju na raspolaganje kako bi se uspjeno izvrila dogovorena usluga. Za vrijeme trajanja usluge SLA je u fazi ocjenjivanja u kojoj, periodino, pregledava performanse usluge i uporeuje ih se dogovorenim performansama navedenim unutar SLA. Na kraju, kada je usluga gotova, ulazi se u zadnju obraunsku fazu unutar koje se utvruje da li je ispotovan SLA, koji su trokovi korisnika te koji se penali mogu primijeniti na davatelja usluge za krenje nekih uvjeta navedenih u SLA. Nakon navedenih faza, SLA moe i ne mora biti arhiviran iako, kako je objanjeno, obino postoji zakonski period koji propisuje minimalno vrijeme uvanja SLA zato to je to takoer i pravni dokument koji opisuje kako je pruena usluga.

Slika 4. ivotni ciklus SLA Projekt SLA@SOI definira sljedee faze ivotnog ciklusa SLA: upravljanje predlocima, pregovaranje SLA, provisioning SLA, nadzor SLA i podeavanje usluge. SLA@SOI ivotni ciklus SLA je preuzet iz specifikacije WS-Agreement. Aktivnosti u pojedinim fazama mogu se opisati na sljedei nain: Upravljanje predlocima: Razvijaju se SLA predloci SLA Pregovaranje: Dogovara se oko SLA SLA Provisioning: SLA se generira i zauzimaju se potrebni resursi Nadzor SLA sporazuma: SLA je izvren, nadgledan i odravan Podeavanje usluge: U sluaju potrebe dolazi do ponovnog pregovaranja o SLA

Slika 5. ivotni ciklus SLA prema prijedlogu SLA@SOI

Za potrebe SLA@SOI projekta napravljene su male promjene u odnosu na specifikaciju WS Agreement, najvie radi otvaranja mogunosti za ponovno pregovaranje. Za podrku takvog ivotnog ciklusa, SLA@SOI je razvio vlastiti okvir arhitekture za upravljanje SLA-om koja moe na strukturirani nain upravljati proizvoljnim tipovima resursa i povezanih SLA-ova kroz razliite slojeve i sudionike. 3.1. Arhitektura koja podrava SLA

Nakon to je opisan SLA sporazum i njegov ivotni vijek, davatelj usluga moe svojim korisnicima osigurati SLA, ako postoje podravajue komponente i podsistemi koji su dostupni unutar same infrastrukture. U nastavku e biti ukratko opisane openite potrebne komponente i funkcionalnosti arhitekture kako bi mogla podrati ivotni ciklus SLA. U prvoj fazi ivotnog ciklusa SLA mora postojati mehanizam pomou kojeg davatelj usluga moe svojim korisnicima dati do znanja svoje sposobnosti/mogunosti. To zahtijeva podsistem za oglaavanje koji takoer mora biti u interakciji sa podsistemom za rasporeivanje kako bi se saznalo koji resursi su na raspolaganju te za koje se resurse moe objaviti da su slobodni. Podsistem za oglaavanje takoer treba povezati s podsistemom za voenje rauna, tako da se moe ciljano obavijestiti o resursima one korisnike koji su koristili odreeni skup usluga u prolosti. Sljedea faza ivotnog ciklusa je pregovaranje oko SLA. Stoga, kroz podsisteme za pregovaranje i postizanje dogovora moraju biti dostupni mehanizmi za pregovore i postizanje dogovora o kasnijoj dostupnosti resursa. U trenutku kada je SLA u "aktivnoj" fazi svog ivotnog ciklusa, podsistem nadzora prua informacije o tome to se dogaa (ili ono to se dogodilo) s resursima davatelja usluga. To moe biti sistem koji agregira informacije iz resursa nie razine (kao to su pojedina raunala ili mreni usmjerivai) ili skup manjih usluga od koje svaka daje informacije. etiri glavna noviteta arhitekture, po tvrdnjama SLA@SOI konzorcija su: (1) Arhitektura podrava vieslojevito SLA upravljanje gdje SLA moe biti sastavljen i razloen kroz funkcionalne i organizacijske domene, (2) podrava proizvoljne vrste usluga (poslovne, softverske i infrastrukturne) i SLA uvjeta, (3) obuhvata kompletni ivotni ciklus SLA i usluge, (4) stvarna implementacija podrava fleksibilan razvoj, gdje se stvarne komponente mogu fleksibilno odabrati, proiriti i povezati i gdje se temeljni modeli podataka mogu proiriti.

10

3.2.

Modeliranje sporazuma o nivou usluge

Istaknutiji standard za zastupanje i pregovaranje SLA-ova je Web Services Agreement (WS Agreement). WS Agreement je razvila radna skupina Open Grid Forum GRAAP. WS Agreement definira potrebne blokove gradnje za uspostavljanje ugovora, u obliku jednog kruga pregovora bez protu ponuda: jedna strana naini ponudu, a druga strana ju jednostavno prihvati ili odbije. WS Agreement ukljuuje jezik za opis web usluga (eng. web service description language WSDL) te web service resource framework (WSRF) kao svoju jezgru. SLA se u WSAgreement prikazuju kao XML dokument te se validira pomou dokumenta XML eme. WS Agreement nudi proirenje i mehanizme valjanosti pomou ekstenzija XML eme, to zahtijeva proirenja u obliku XML dokumenata. Svrha specifikacije WS Agreement-a je podrka pri uspostavljanju sporazuma o koritenju web usluge izmeu davatelja usluge i korisnika usluge. WS Agreement definira jezik i protokol za prezentaciju usluge koju davatelj nudi, kreira sporazum koji se temelji na ponudama i za vrijeme rada usluge nadgleda dali se potiva dogovoreno. Davatelj usluge unutar ugovora nudi uslugu u skladu s uvjetima opisanim u ugovoru. Korisnik ulazi u dogovor s namjerom dobivanja jamstava o dostupnosti jedne ili vie usluga od davatelja usluga. Proces stvaranja ugovora se obino sastoji od tri koraka: inicijator dohvaa predloak od druge strane, koja oglaava ponude koje je spreman prihvatiti, inicijator daje ponudu, druga strana prihvata ili odbacuje ponudu.

Iako je specifikacija WS Agreement imala iroku primjenu nakon poetne objave iz maja 2007, pokazalo se da nedostatak mogunosti za pregovaranja o ugovoru i postojanje mogunosti samo za prihvaanje ponude je ograniavajui faktor za uporabu WS Agreement-a u nizu sluajeva. Stoga je, radna skupina Grid Resource Allocation Agreement 2008 godine zapoela pripremati proirenje WS Agreement-a koji dodaje mogunost pregovaranja. U sijenju 2011 objavljena je specifikacija WS Agreement Negotiation koja omoguuje pregovaranje novih i ponovno pregovaranje postojeih sporazuma. WS Agreement Negotiationse moe koristiti za ponovo pregovaranje postojeeg ugovora koji se iz nekog razloga treba mijenjati. WS Agreement Negotiation prua dodatni sloj prilikom izrade sporazuma pomou WS-Agreement-a koristei proiriv XML jezik za specificiranje prirode ponuda, i predloaka sporazuma kako bi se otkrili kompatibilni predloci za olakavanje procesa stvaranja valjane ponude sporazuma. U WS Agreement Negotiation modelu pregovaranje je uinjeno u kontekstu odvojenih procesa pregovaranja. Pregovaraki proces predstavlja odnos izmeu potroaa i davatelja usluge kako bi se dinamiki razmijenile informacije s ciljem stvaranja valjane ponude ugovora koja naknadno dovodi do sporazuma. Proces pregovaranja se stvara pomou Negotiation Factory, koja implementira Negotiation Factory Port Type. Proces pregovaranja je predstavljan pomou Negotiation Instance, koja implementira Negotiation Port Type i opcionalno Advertisement Port
11

Type. Negotiation Port Typedefinira osnovna svojstva pregovarake instance, metodu za razmjenu ponuda i protu ponuda, i metodu za prekid procesa pregovaranja. Osnovne komponente koje su ukljuene u proces pregovaranja prikazane su na slici 6. Projekat SLA@SOI, za razliku odWS Agreement-a, predlae svoj SLA model koji ne ovisi o zastupljenosti jednog odreenog jezika kao to je XML. SLA@SOI SLA model nudi formalni opis i razne konkretne inkarnacije (BNF, XML, Java, JSON-like). Nadalje, pregovaraki interfejs i protokol pregovaranja su odvojeni od reprezentacije SLA.

Slika 6. Prikaz komponenataWS-Agreement Negotiation Jo jedna znaajka SLA@SOI SLA modela je jednostavna proirivost. Nadalje, SLA@SOI SLA model takoer se strukturno razlikuje od WS Agreement-a jer ima mogunost implementacije naprednih mehanizama za izvravanje upita. Ti mehanizmi e takoer funkcionirati i za proirenja SLA@SOI SLA modela bez obzira jesu li poznati u trenutku kompajliranja. Stariji predloeni model za reprezentaciju SLA se zove Web Service Level Agreement (WSLA) i razvio ga je IBM. WSLA ne prua napredne mehanizme kao to su proirivost, podrku za mehanizme koji izvravaju upite i mehanizme pregovaranja. Jo jedan znaajan SLA model je SLAng, koji prua odreenu razinu neovisnosti o jeziku, budui da koristi OMG Meta Object Facility (MOF). Meutim SLAng je usmjeren na elektronike usluge i stoga prua samo ogranien skup ogranienja na kvalitetu usluge koje su specifine za pojedinu domenu. CC-Pi (eng. Constraint-Based Language for Specifying Service Level Agreements) je jo openitije rjeenje od SLAng problema modeliranja SLA, no takoer je usko povezano s samim
12

procesom pregovaranja. To dovodi do nedostatka koncepata kao to su stranke u sporazumu ili interfejsu usluge.

3.3.

Pregovaranje o SLA

Pregovaranje o SLA-u je pristup rjeavanja ponude i potranje. Taj proces moe biti automatiziran, to zahtjeva protokol pregovaranja te politike pregovaranja. Jedno od vanijih pitanja za davatelja i korisnika usluga u procesu otkrivanja je pregovaranje i pronalaenje zajednikog rjeenja koje je prihvatljivo objema stranama. Pregovaranje je zanimljivo podruje istraivanja od 1960-ih godina. Istraivai su primjenjivali kombinacije razliitih modela i tehnologija iz razliitih problemskih domena kao to su ekonomski modeli (funkcije iskoritavanja i cost-benefit modeli), genetiki algoritmi, teorije igara, pristupi uenju i modeli odluivanja od umjetne inteligencije i inteligentnih agenata za definiranje raznih pristupa pregovaranju. Pregovori se mogu odvijati izmeu dvije (bilateralni) ili vie (multilateralni) strana, a mogu ukljuivati jedno ili vie otvorenih pitanja. Stranke obino komuniciraju putem specifinih pregovarakih protokola. SLA pregovori se obino temelje na predlocima usluge koji su javno dostupni za pregovaranje. Predloak sadri skup svojstava, gdje je cijena samo jedna od njih. Veina od tih svojstava se odnose na kvalitetu usluga (QoS) oko kojih korisnik i davatelj usluge pregovaraju. Svako QoS svojstvo sadri skup ili raspon vrijednosti iz kojih korisnik moe odabrati poetne eljene vrijednosti. Nekoliko projekata i rjeenja su uzeta u obzir kako bi se razumjelo stanje u podruja SLA pregovora. Projekt OPELIX (Europski istraivaki projekt FP5) se bavio razliitim aspektima poslovnih usluga, od nuenja same usluge do njezinog otkrivanja i kasnijeg pregovaranja stvarajui elektroniki ugovor. Pregovori se provode na bilateralni nain. Projekt e-Agora predlae arhitekturu trnice u kojem korisnici koriste inteligente agente za interakciju s trnicom. Sistem prua procesni model i skup podranih protokola. Proces je definiran kao skup aktivnosti i faza. Protokoli su definirani pomou pravila i restrikcija na aktivnostima pregovaranja. Takoer uzeti su u promatranje i projekti koji isprepliu protokole pregovaranja s nainom komunikacije, odnosno izmjenom poruka. U tom smislu, ASAPM (eng. An Agent-based Fra-mework for Adaptive Management of Composite Service Lifecycle) je vie agentski sistem u kojem se odvijaju automatizirani pregovori pomou FIPAs ICNP (eng. Iterated Contract Net Protocol). Protokolom, kroz vie rundi pregovaranja, podrana je konvergencija meu ugovorima. Na slici 7 prikazan je FIPAs Iterated Contract Net Protocol (ICNP). Call-For-Proposal (CFP) (direktna
13

strelica od korisnika do davatelja) se koristi kako bi se uputio zahtjev za porukom od davatelja usluge. Propose Proposal (dvostrana strelica) koristi bilo koja strana za izmjenu ponuda i protu ponuda. Refuse Proposal oznaava nespremnost jedne od stranaka za sudjelovanjem u pregovorima. Uspjeno pregovaranje zavrava s Accept Proposal, dok se sa Reject Proposal oznaava neuspjeno sklapanje sporazuma. Failure oznaava nemogunost primanja, slanja ili interpretiranja poruke.

Slika 7. Protokol pregovaranja ICNP Meu okvirima koji se temelje na agentima, projekt BREin omoguuje obavljanje SLA pregovaranja pomou FIPA Contract Net Protocol. Protokol obuhvata vie razina. BREIN je europski projekt koji se usredotouje na pribliavanje e-poslovnih modela i koncepata, te Grid raunarstva. U tom procesu, BREIN primjenjuje razne tehnike iz podruja umjetne inteligencije, inteligentnih sistema, semantikog weba, itd.. Projekt SLA@SOI predlae model trnice usluga i okvir za SLA koji ima sljedee znaajke: (1) standardizirani modeli za opis SLA na razliitim slojevima, (2) okvir za automatizirano e-ugovaranje, (3) sistemno temeljenje SLA od poslovne razine dolje do infrastrukture, (4) metode i alate za vieslojno upravljanje SLA-om, ukljuujui planiranje, optimizaciju i osiguravanje, (5) metode i alate za nadzor i raunovodstvene usluge putem standardiziranih sistema, (6) iskoritavanje tehnologije virtualizacije na infrastrukturnoj razini za provoenje SLA. To je konceptualni i softverski okvir koji koristi automatizirane agente (SLA Manager, SLAM) za usklaeno upravljanje svim razinama aplikacije na temelju jedinstvenog SLA. Slika 8. daje pojednostavljeni pregled procesa upravljanja SLA-om i predviene interakcije.

14

Slika 8. Interakcija unutar SLA@SOI okvira

4. Operational Level Aggrement - OLA

OLA je ugovor izmeu pruatelja IT usluge i klijenta koji su dio jedne organizacije koja se bavi pruanjem usluga. OLA treba sadravati ciljeve koji e podupirati one unutar SLA kako bi se osiguralo da elementi iz SLA ne budu prekreni zbog neuspjeha prateih, potpornih djelatnosti. ITIL savjetuje da svaki SLA bude potpomognut sa jednim ili vie OLA, a da SLA djeluje kao suelje preko kojeg poslovni sistem se upoznaje sa odredbama i performansama usluge koja se osigurava. 4.1. Elementi OLA

Veina OLA definisanih prema ITIL-u sadri nekoliko zajednikih elemenata: Detalje o prethodnim izmjenama i dopunama Djelokrug ugovora Ciljeve Raspoloivost usluga Kontakte u sluaju eskalacije Definirane odgovornosti i vrijeme odziva korisnike slube Upravljanje promjenama Rjenik Listu izmjena
15

4.2.

Aktivnosti, metode i tehnike SLM faze

Kljune aktivnosti u SLM procesu su: Odreivanje, pregovaranje, dokumentacija i dogovaranje zahtjeva za nove ili promijenjene usluge u SLR, upravljanje i revizija tih usluga kroz ivotni ciklus i uvoenje u SLA Nadziranje i mjerenje uinkovitosti IT usluge i usporedba sa ciljevima definisanim u SLA Mjerenje i unaprjeenje zadovoljstva klijenata Kreiranje izvjetaja o uslugama Pregled i revizija SLA, OLA, ugovora i svih ostalih potpornih dokumenata Razvoj i dokumentiranje kontakta i odnosa sa korisnicima, poslovnim partnerima i svim interesnim skupinama Razvoj, odravanje i voenje postupaka za zapisivanje i rjeavanje pritubi i pohvala Upravljanje informacijama koje su potrebne pri upravljanju uinkom i demonstracija postignua Redovito odravanje i osiguravanje dostupnosti SLM predloka

Odnosi izmeu aktivnosti prikazani su na slici 9. koja prikazuje glavne aktivnosti SLM procesa. Sve aktivnosti trebaju biti integrisane u jedan SLM proces koji moe biti konstantno primjenjiv na sva podruja poslovanja i prema svim klijentima.

Slika 9. Proces upravljanja nivoima usluga

16

4.3.

Praenje ostvarenja razine usluga

U SLA ne bi smjelo biti ukljueno nita to se ne moe uinkovito pratiti u mjeriti prema zajedniki usuglaenom kriteriju. Ukljuivanje stavki koje se ne mogu uinkovito pratiti, gotovo uvijek rezultira sporovima i gubitkom povjerenja u SLM proces. Krajnje posljedice takvih situacija su veliki trokovi za ispravljanje nesporazuma i negativan uticaj na vjerodostojnost organizacije. Trenutne mogunosti praenja treba stalno nadgledati i nadograivati prema potrebi. Idealno rjeenje je to uiniti prije ili paralelno s izradom SLA. Vano je da praenje razine usluga se podudara sa korisnikovom percepcijom usluge. To je teko postii jer praenje samo pojedinih komponenti (npr. servera) ne znai da e usluga biti dostupna u percepciji korisnika. Percepcija korisnika je da iako kvar moe uticati na vie usluga, njih brine samo usluga kojoj trenutno ne mogu pristupiti. Bez nadzora svih komponenti koje sudjeluju u pruanju usluge, prava slika stanja ne moe se dobiti. Takoer treba educirati korisnike da prijave incidente odmah, posebice ako su kritini za pruanje nekih usluga, jer na taj nain obavjetavaju pruatelja usluga da su dogovorene razine usluga prekrene. Znatan broj organizacija svoj Service Desk povezuju sa sveobuhvatnim Configuration Management System (CMS) kako bi pratili klijentovu percepciju raspoloivosti. To moe ukljuivati i specifine promjene u nainu prijave incidenta i suelju preko kojeg se to ini. Potrebna je i koordinacija sa procesom Availability Management. Service Desk se takoer moe koristi za mjerenje vremena potrebnog za odgovor i rjeenje prijavljenog incidenta ukoliko se primjene potrebne preinake na suelju (dopune potrebne za pohranjivanje izmjerenih podataka). Bitno je osigurati da su bilo koji ciljevi definirani u SLA, ukljueni i u Service Desk alat i da se prema njima nadgleda eskalacija incidenata. Ukoliko to nije uinjeno na ispravan nain, dolazi do situacije da se prati i nadgleda ostvarenje ciljeva drugaijih od onih koji su usuglaeni u SLA, te nije mogue utvrditi da li su ciljevi ispunjeni bez dodatne manipulacije i obrade podataka. Iznimno sloeno podruje za nadziranje i mjerenje je vrijeme odziva (vrijeme koje protekne izmeu slanja prijave incidenta i primanja odgovora). esto je vrijeme odziva vrlo teko pratiti tehniki.

17

U takvim sluajevima nekoliko metoda olakava situaciju: ukljuivanje sljedee izjave u SLA: Usluge pokrivene SLA su dizajnirane za velike brzine odziva i ne oekuju se znaajna kanjenja. Ukoliko vrijeme odziva usluge prelazi n sekundi u n minuta, to treba odmah prijaviti slubi za korisnike definirati broj incidenata unutar nekog razdoblja koji se moe smatrati prihvatljivim definirati posebnu kategoriju za incidente uzrokovane neodgovarajuim vremenom odziva izrada redovnih izvjetaja o situacijama kada je vrijeme odziva definisano u SLA prekreno kako bi problem management mogao ispraviti situaciju Ovakav pristup nadilazi tehnike potekoe praenja i osigurava da su incidenti prijavljeni na odgovarajui nain i u vrijeme kad su nastali. Ovo je vrlo vano jer uzrok incidenata prouzroenih loim vremenom odziva se esto ne moe otkriti ukoliko se ne istrai odmah. U realnim situacijama incidenti prijavljeni uz loe vrijeme odziva esto su problem percepcije klijenta. Klijenti se naviknu na odreenu razinu odziva usluge u odreenom vremenskom razdoblju te se ponu aliti na sporost usluge im se vrijeme odziva uspori iako ciljevi iz SLA nisu prekreni. Treba obratiti pozornost da klijenti esto misle da je usluga spora i u situacijama kad nije. 4.4. Usporedba, mjerenje i poboljanje zadovoljstva klijenta

Nekoliko bitnih faktora se ne moe mjeriti i nadzirati klasinim proceduralnim sredstvima. Primjer je ope zadovoljstvo klijenta itavom uslugom. Na primjer, ak i kada je dolo do velikog broja prijavljenih kvarova usluge, klijenti jo mogu imati pozitivan stav i biti zadovoljni jer osjeaju na promjenama da su poduzete odgovarajue radnje da se poboljaju stvari. Naravno, situacija moe krenuti i u potpuno obratnom smjeru, te tako klijenti mogu osjeati nezadovoljstvo ak i kad ciljevi definirani u SLA nisu prekreni (neprofesionalan odnos slube za korisnike, nedostatna komunikacija i sl.). Od samog poetka odnosa, nuno je upravljati oekivanjima klijenta. To znai definisati odgovarajua oekivanja i primjerene ciljeve. Ukoliko klijentova percepcija je pokrivena njegovim oekivanjima, klijent e biti zadovoljan. SLA je samo dokument, te ne moe materijalno izmijeniti kvalitetu usluge koja se prua ali moe uticati na ponaanje obuhvaenih strana i produbiti odnos izmeu klijenta i pruatelja usluge te na taj nain ima blagotvoran uinak. Usluge ije pruanje prouzrokuje trokove trebaju biti uzete u obzir prilikom razmatranja zahtjeva klijenata. Klijentima treba omoguiti sve to mogu trokovno opravdati, naravno
18

ukoliko se to uklapa u korporativnu strategiju i predvieni proraun. Kod usluga koje nemaju troka treba osigurati da ne dolazi do pretjeranih i nerealnih zahtjeva na teret IT odjela ili bilo kojeg drugog pojedinca ili grupe. Sljedee metode mogu se koristiti za mjerenje zadovoljstva uslugom klijenta: Periodini upitnici i ankete klijenata Povratne informacije od klijenata dobivene na sastancima Telefonska istraivanja (neplanirana putem slube za korisnike ili planirana putem stalnih predstavnika) Posjeta klijenata tokom i nakon instalacije Analiza pritubi i pohvala Gdje je to mogue, ciljeve treba definisati prema ovim metodama i pratiti ih prema SLA. Ako klijenti pruaju informacije potrebno je osigurati da dobiju povratne informacije i pokazati im da su njihovi komentari uvaeni i ukljueni u akcijski plan. Sva mjerenja zadovoljstva kupca treba pregledati, ako su identificirane varijacije, treba ih analizirati i poduzeti radnje da se uklone.

19

5. Zakljuak
Pokazali smo da su se namjera i koritenje SLA ugovora znatno promijenili, jer su originalno zamiljeni kao dio programa menadmenta nivoa usluge od strane meunarodnih IT grupa. SLA ugovori su se razvili u sredstvo za pokazivanje vrijednosti koje koriste mnoga preduzea u svim aspektima industrije kako bi se zatitili od opasnih dobavljaa. Stalna dostupnost komunikacija je sad prepoznatljiva kao klju mnogih dananjih poslova. Nedavna istraivanja pokazuju da je SLA ugovor za korisnika iznad svega ostalog, ukljuujui brigu o korisnicima.Otkrili smo da mnoga preduzea smatraju komunikacije kao fizioloku potrebu; bez komunikacija ni jedan posao ne bi bio mogu. Slijedei isti nain razmiljanja napravili smo vjerodostojan sluaj, pa smo se fokusirali na kupca (1), da bi se osigurala usluga za poslovne potrebe i kako bi se te potrebe zadovoljile. Na tritu korisnik pristupa SLA ugovorima koji su utemeljeni na stvarnim finansijskim uticajima na dostupnost, a ne na trokove pruanja servisa. Proveli smo temeljito razmatranje o tome ta je potrebno da SLA bude uspjean. Ustanovili smo da SLA ugovor mora biti: Odreen sa kraja na kraj Univerzalan Znaajan u pogledu na prava metrike Odgovarajui za datu pristupnu taku (SAP) Vidljiv Finansijski prilagoen

Otkrili smo da mnogi problemi iz stvarnog svijeta uoeni u okviru industrije bi mogli biti rijeeni, ako bi se potivala odreena pravila. Razumjevanje osnovnih principa nam je omoguilo osnovu za ispitivanje postojeeg stanja SLA ugovora u industriji komunikacija uopteno.

20

6. Literatura
www. google.com http://en.wikipedia.org/wiki/Service_level_agreement http://searchitchannel.techtarget.com/definition/service-level-agreement http://www.businesslink.gov.uk/bdotg/action/detail?itemId=1073792564&t ype=RESOURCES http://www.itsm.info/SLA%20description.pdf http://www.sla-zone.co.uk/ http://www.knowledgetransfer.net/dictionary/ITIL/en/Service_Level_Agree ment.htm http://www.webopedia.com/TERM/S/Service_Level_Agreement.html http://www.checkpoint.com/services/techsupport/programs/docs/supportsla.pdf M.B. Chhetri, and I. Mueller., "ASAPM An Agent-based Fra-mework for Adaptive Management of Composite Service Lifecycle," in

IEEE/WIC/ACM International Conferences on Web Intelligence and Intelligent Agent Technology - Workshops. SLA@SOI, Project no. FP7-216556, "Deliverable D.A5.a," May 2009 http://sla-at-soi.eu/2009/03/what%e2%80%99s-in-a-service-levelagreement/. M. Debusmann, and A. Keller, "SLA-Driven Management of Distributed Systems using the common information model," inProceedings of the 8th IFIP/IEEE International Symposium on Integrated Network Management (IM2003), Colorado Springs, CO, USA, March 2003.

21