hyväksymispäivä arvosana

arvostelija

Service level Agreements

Mikael Wargh

Espoo 30.11.2007HELSINGIN YLIOPISTOTietojenkäsittelytieteen laitos

i

Tiedekunta / Osasto – Fakulet / Sektion – Faculty

Matemaattisluonnontieteellinen tiedekuntaLaitos – Institution – Department

Tietojenkäsittelytieteen laitosTekijä – Författaren – Author

Mikael WarghTyön nimi – Arbetets titel – Title

Service Level AgreementsOppiaine – Läroämne - Subject

TietojenkäsittelytiedeTyön laji – Arbetets art - Level

SeminaariesitelmäAika – Datum – Month and year

30.11.2007Sivumäärä – Sidoantal – Number of pages

19 sivuaTiivistelmä – Referat – Abstract

Palvelutasosopimukset (Service Level Agremeents, SLA) ovat osa nykypäivän liike-toimintaa. Yritykset solmivat palvelusopimuksia taatakseen luotettavat palvelutitselleen ja omille sidosryhmilleen. Palvelusopimukset ovat luonteeltaan korkeanabstraktiotason sopimuksia yhteistyökumppaneiden välillä. Palvelutasosopimustenmäärittelyyn on käytössä monia eri työkaluja, kuten myös sen toteutukseen.

ACM Computing Classification System (CCS):K.6.2 [Installation Management]: Performance and usage measurementK.6.2 [Installation Management]: Pricing and resource allocationK.6.1 [Project and People Management]: System analysis and design

Avainsanat – Nyckelord – Keywords

Palvelutasosopimukset, SLA, QoS, SLO, SLS, XML, SLAng

Säilytyspaikka – Förvaringsställe – Where deposited

Muita tietoja – Övriga uppgifter – Additional information

ii

Sisältö

1 Palvelutasosopimukset 11.1 Erilaisten SLA-sopimusten jaotteluperusteita 11.2 Palvelutasosopimuksen rakenne 21.3 Lähimmät alemman tason sopimukset 31.4 QoS 32 SLA-sopimuksien määrittely 52.1 Omia kokemuksia SLA-sopimuksen määrittelystä käytännön

työelämässä 52.2 Kehykset ja sopimuspohjat 62.3 Käytännön palvelutasolaskentaa 82.4 XML:n rooli SLA-sopimusmäärittelyissä 92.5 Valmiit järjestelmäratkaisut 112.6 SLAng 113 Yhteenveto 14Liite1: Esimerkkipalvelutasosopimus 16Lähteet 17

1

1 PalvelutasosopimuksetPalvelutasosopimukset (Service Level Agreements, SLA) ovat korkeanabstraktiotason kuvauksia kuinka tietty palvelu tulisi toimia yhteistyö-kumppaneiden kesken. SLA-sopimuksen piiriin voi kuulua vaikka logis-tiikan ostaminen yrityksen ulkopuolelta, mutta yhtä hyvin sopimus voi-daan määritellä yhtiön sisäisten kustannusyksiköiden välillekin. SLA-sopimusten rooli palvelujen hallinnassa on yleistynyt nykypäivänä eten-kin telekommunikaatioalalla [HaGe04].Termejä palvelutasosopimus ja SLA-sopimus käytetään tässä esitelmässätoistensa synonyymeinä.

1.1 Erilaisten SLA-sopimusten jaotteluperusteitaSLA sopimukset voidaan jaotella liiketoimintastrategian pohjalta kol-meen luokkaan: Ulkoisiin (external), sisäisiin (internal) ja ulkoistettuihin(outsourced) [IBM01]. Hieman tarkemmalla tasolla sopimustyypit voi-daan jaotella toimintapäämääränsä mukaan vertikaalisiin ja horisontaa-liisin sopimuksiin [BSPD03, SLE04]. Vertikaalisiin sopimustyyppeihinkuuluvat sovellus- (Application), ylläpito- (Hosting), jatkuvuus- (Persis-tence) ja kommunikaatiotyyppiset sopimukset (Communication) [LSE03].Horisontaalisesti sopimukset voidaan taas jaotella palvelu (Service), säi-liö (Container) ja tietoliikennetyyppisiin sopimuksiin (Networking)[LSE03]. SLA-sopimuksen suunnitteluvaiheessa tulisi selvittää mihinluokkaan tai luokkiin työn alla oleva sopimus kuuluu, jotta osataan kes-kittyä luokan mukaan tärkeisiin määrittelykohtiin. Yksittäisellä toimijal-la on usein siis monia palvelutasosopimuksia, jotka voivat koskea eri ta-solla niin ulkoisia palveluntarjoajia, kuin sisäisiä kustannuspaikkoja(kuva 1). Kuvassa nuolet voidaan tulkita mahdollisiksi SLA-sopimuskohteiksi.

2

Kuva 1, Esimerkkitapaus usean palveluntarjoajan ympäristöstä [Kel02]

1.2 Palvelutasosopimuksen rakennePalvelutasosopimus on useimmiten laajuudesta riippuen, jopa yli sadansivun mittainen dokumentti, jonka sisältö on monien sidosryhmien ta-paamisten ja läpikäyntien summa (esim. tekniset asiantuntijat, johto-ryhmät, lakimiehet). Liite1 sisältää sisällysluettelon esimerkkipalveluso-pimuksesta. Sopimuksen tarkempaa mahdollista sisältöä ei tässä esitel-mässä kuitenkaan käydä sen tarkemmin läpi. Tärkeimmät kohdat ovatkuitenkin rangaistukset (penalties) ja lupaukset (promises). Rangaistuk-set voidaan jaotella kolmeen ryhmään, jotka ovat [RHRM02]:

Kiinteä korvaus (fixed penalty). Jos asiakas ei saa haluamaansakapasiteettia, toimittaja maksaa asiakkaalle kiinteän ennalta sovi-tun korvaussumman.Aikarippuvainen korvaus (Delay-dependent penalty). Korvauksensuuruus riippuu ajasta, jolloin asiakas ei ole saanut SLA-sopimuksen mukaista palvelua.Suhteellinen korvaus (Proportional penalty). On tavallaan aika-riippuvainen korvaus, mutta tässä otetaan huomioon myös asiak-kaan saaman palvelustason ja luvatun palvelustason välinen suh-de, jonka perusteella lasketaan aikariippuvainen korvaus.

Lupaukset perustuvat pitkälti tarkkoihin laskentoihin siitä, mitä nykyi-sillä järjestelmillä pystytään tarjoamaan järkevien kustannusten rajois-sa. Tätä aihetta sivutaan kappaleessa 2.3. Lupausten määrittelyä tärke-ämpi seikka on kuitenkin niiden seurattavuus ja valvottavuus. Tämän

3

toteuttaminen vaatii yleensä laajan SLA-lähtöisen ajattelumallin imple-mentoinnin koko järjestelmää koskevaksi. Tähän soveltuvaa XML-pohjaista SLAng-kieltä käsittelemme kappaleessa 2.6.

1.3 Lähimmät alemman tason sopimuksetSLA-sopimuksen apuna käytetään erinäisiä alemman tason sopimuksia,joilla pyritään kuvaamaan itse SLA-sopimuksen viitoittamaa käytännöntoimintaa. SLS (Service Level Specification) tarkoituksena on toimia tek-nisenä ja operatiivisena kuvauksena SLA:n implementointiin[Wiki01].SLO (Service Level Objective) on taas SLS:n alaluokka, jossa kerrotaanpalveluparametrein mitä SLS:llä tulisi saavuttaa [IBM01, Wiki01].

SLA-sopimus on hyvin korkeatasoinen kuvaus yhteistyökumppaneidenvälisestä toiminnasta. Tämä on muuttuvien liiketoimintaympäristöjen jamuuttujien takia lähes välttämätöntä. Tämä ei kuitenkaan suoraan tar-koita sitä, että SLA-sopimus olisi staattinen harvoin päivitettävä asiakir-ja, vaan sopimusta voi joutua muuttamaan myös kesken sopimuskauden.SLA-sopimus pyritään kuitenkin määrittelemään melko yleisluontoisek-si, jolloin mahdolliset, yleensä tekniseen ympäristöön kohdistuvat muu-tokset, voitaisiin tehdä alemman tason sopimuksiin ja palvelumäärityk-siin korkeamman SLA-tason sopimuksen eheyttä rikkomatta. Huomatta-vaa on myös se, että SLA-sopimuksen määrittelyyn liittyvien sidosryhmi-en lukumäärä voi usein olla melko suuri johtuen sopimuksen laaja-alaisuudesta.

1.4 QoSSLA-sopimus liitetään usein yrityksen laatutavoitteisiin. Usein puhu-taankin SLA-sopimukseen liitetyistä QoS-laatutavoitteista (quality ofservice). Näitä ovat erikseen määriteltävät lupaukset siitä, kuinka järjes-telmän tulisi toimia yhteistyön puitteissa. Toki lupaukset SLA-sopimuksessa voivat olla myös vapaamuotoisia yhteistyöryhmän johta-mia määrityksiä, mutta QoS terminä laajoine tutkimusjulkaisuineen tar-joaa todennäköisesti paremman mallin laatutavoitteiden määrittämi-seen.

QoS-käsite voidaan edelleen jakaa eri osa-alueisiin (kuva 2).

4

Kuva 2, Viisi eri näkökulmaa QoS:ään [TB05]

Vaikka QoS eli vapaasti suomennettuna palvelun laatu kuulostaakin hy-vin abstraktilta ja yleispätevältä termiltä, on se yleensä liitetty tietolii-kennemaailmaan käsitteisiin. Termin QoS määritteli kansainvälinen te-lekommunikaatiojärjestö ITU (International Telecommunication Union)vuonna 1995 [ITU902]. ITU:n määritys on lyhennettynä seuraavanlai-nen: ”A set of quality requirements on the collective behavior of one ormore objects” [ITU902]. Käytännössä tämä tarkoittaa esimerkiksi eri tie-tovirtojen priorisointia tietoverkoissa. Yleisesti käytetty analogia QoS:stäon esimerkki siitä kuinka VoIP-liikenne priorisoidaan ”tavallisten”TCP/IP-pakettien yläpuolelle. QoS-määrityksiä on toki useampia[OnR03], joita voidaan käyttää myös tietotekniikka-alan ulkopuolella,mutta näistä määrityksistä ITU:n laatima lienee tunnetuin. Huomatta-vaa on, että yleisesti ottaen QoS ei sisällä varsinaista sopimustasonmäärittelyä, vaan se keskittyy lähinnä kuvaamaan haluttua laatutasoalähempänä teknistä toteutusta. Palveluorientoiduissa tietotekniikkajär-jestelmissä QoS on siis tärkeä käsite, jolla haluttu palvelutaso pyritäänmäärittämään.

Itse SLA-sopimuksen eheyden takaamiseksi siihen liitetyt QoS-määritykset kannattaa jakaa staattisiin ja dynaamisiin lupauksiin niidentyypin mukaan [RHRM02]. Esimerkiksi tietoliikennekäyttöpalvelusopi-mukseen liitettävään QoS:ään voidaan määritellä yhteistyöpalvelun taso(esim. kulta, hopea, pronssi) staattiseksi ja luvattu tietoliikennenopeus(esim. MB/sec) dynaamiseksi [RHRM02]. Näin ennakoitu usein muuttuvatietoliikennekapasiteetin tarve onnistuu vaivatta QoS:ään ja sitä myötenSLA:han, koska sen muutos on jo osattu ottaa huomioon.

5

2 SLA-sopimuksien määrittelyKappaleessa 2.1 esitellään kirjoittajan omia kokemuksia ja näkemyksiä,joita hän on kohdannut käytännön työelämässä SLA-sopimusneuvotteluihin osaa ottaessaan. Kappaleessa 2.2 tarkastellaanSLA-sopimusmäärittelyn kevyempää portaikkoa eli sopimuspohjia ja ke-hyksiä. Kappaleessa 2.3 käydään läpi käytännön matemaattista mallin-tamista, johon yleensä päädytään ennen kuin voidaan tehdä varsinaisiaQoS-lupauksia SLA-sopimusta varten. Kappaleessa 2.4 tarkastellaanXML:n roolia nykypäivän sopimusmäärittelyssä ja järjestelmien yhden-mukaistamisessa. Kappaleessa 2.5 tutkitaan tarkemmin XML-pohjaisenSLAng-kielen käyttöä SLA-sopimuks(i)en implementoinnissa toimin-taympäristön koko laajuudelle.

2.1 Omia kokemuksia SLA-sopimuksen määrittelystäkäytännön työelämässä

Omassa työssäni havainnut, että palvelutasosopimukset pohjautuvatyleensä vanhaan talon hyväksi toteamiin pohjiin, jota muokkaamallaluodaan omat yksilölliset sopimukset eri asiakkaille. Huomattavaa onerottaa palvelutasosopimuksen määrittely ja palvelutason määrittely,koska ne ovat käytännössä hieman eri asioita. Palvelutaso on yhteisestihyväksytty toiminnan laatutaso, joka pyritään palvelutasosopimuksellamahdollisimman hyvin kuvaamaan. Avainsanana on yhteistyö, silläkaikkia halutun palvelutason yksityiskohtia on lähes mahdoton sisällyt-tää kirjallisiin sopimuksiin ja näin ollen ristiriitatilanteita syntyy väis-tämättä. Tämän takia palvelutasosopimusta tulisikin aika ajoin tarkistaaja päivittää vastaamaan muuttuneita ja esiin tulleita tarpeita. Käytän-nössä jatkuvaan sopimusylläpitoon kuitenkin harvoin löytyy tarvittaviaresursseja.

Itse SLA-sopimuksen määrittelyprosessissa voidaan käyttää tarkenta-vaa(top-down) tai koostavaa(bottom-up) määrittelyä, sekä myös näidensekoituksia. Omassa työkokemuksessani olen havainnut, että yleisestiottaen käytetään tarkentavaa toimintatapaa asiantuntijoiden ottaessaosaa myös korkeamman tason päätöksiin. Tällöin määritellään ensiksisuuret reunaehdot esim. tavoitettavuusaika(uptime) vuodessa 99,99%,minkä jälkeen pyritään tarkentamaan miten tämä käytännössä toteute-taan. Tätä varten voidaan käyttää prosessimallinnusta, jota tarkenne-

6

taan vielä matemaattisilla laskukaavoilla. Kuten kappaleessa 1.3 todet-tiin, nämä tarkennukset päätyvät yleensä erillisiin SLS- ja SLO-sopimuksiin. Toinen vaihtoehto on käyttää koostavaa mallinnusta, jossapalveluntarjoaja selvittää ensiksi, minkä tasoisista palvelua hän voi tar-jota ja vasta sitten pyrkii sopimaan asiakkaan kanssa mahdollisista pal-veluvaihtoehdoista. Esimerkiksi monet tietoliikennepalveluja tarjoavatyritykset tarjoavat valmiin hinnastotaulukon mahdollisista eriasteisistapalvelutasosopimuksista. Tällainen valmistaulukkoon perustuva palvelu-tasosopimustarjous soveltuu tietyille, varsinkin paljon määrittelylasken-taa vaativille palvelualoille, joista edellä mainittu tietoliikenneala hyväesimerkki. Kuitenkin osapuolten syventäessä yhteistyötään esimerkiksiulkoistuksilla ja yhteistyösopimuskohteen sisältäessä paljon vaikeastimääriteltäviä muuttujia, päädytään usein yksilölliseen räätälöityyn pal-velusopimukseen, jossa suurempi osa sopimusmäärittelystä tehdään yh-dessä osapuolten kesken. Tällöin on oman kokemukseni mukaan useinkyse sekä koostavasta ja tarkentavasta sopimusprosessista, johon kum-mankin puolen asiantuntijat ottavat osaa. Tällöin asiantuntijat toimivatikään kuin tarkentavaan tyyliin, kun samaan aikaan liiketoiminnastavastaavat sopimusosapuolet pyrkivät koostamaan hyväksyttävää sopi-musratkaisua esille tuotujen teknisten yksityiskohtien puitteissa.

2.2 Kehykset ja sopimuspohjatYksi vaihtoehtoinen ja myös ehkä hieman maanläheisempi tapa on käyt-tää valmista kehystä (framework) SLA-sopimuksen määrittelyyn. Voi-daan tavallaan ajatella, että mikäli SLAng:lla (esitellään kappaleessa2.6) tai jollain muulla standardilla tavalla määritelty palvelutasosopimuson yritykseen luotu, niin sitä voidaan jatkossa käyttää myös kehyksenäuusille palvelutasosopimuksille. Toisaalta taas palvelutasosopimuksenollessa yleensä melko pitkä ja joskus myös lakiteknisesti monimutkainendokumentti voi usein olla järkevää käyttää vanhaa hyväksi havaittuamallia sopimuspohjana (template). Huomattavaa on erottaa kehys-terminja sopimuspohja-termin välinen ero. Kehys on ohjelmistotekniikan alallarunsaasti käytetty termi kuvaamaan valmiita konseptirakenteita, joidentarkoituksena on helpottaa vaikeiden ongelmien toteutusta [Wiki02, Wi-ki03, Wiki04]. Vaikka kehys-termin lavea määritys periaatteessa kattaisimyös sopimuspohjat, yleisesti mallidokumentteja käsittelevä termi onsopimuspohja (template) [Wiki05]. Usein kehys on myös huomattavastikorkeamman tason konseptuaalinen kuvaus suhteessa sopimuspohjiin.

7

Valmiita sopimuspohjia löytyy moneen tarpeeseen ja valitettavasti myösvaihtelevalla laatutasolla. Internetin tarjotessa helpon tavan dokument-tien siirtelyyn on syntynyt lukuisia sopimuspohjia myyviä yrityksiä il-maisten pohjien määrästä puhumattakaan. Näihin sopimuspohjiin tuleesuhtautua tietyllä varauksella sopimusten yksilöllisyyden ja toiminta-alueiden eroavaisuuden takia. Tärkeä yksityiskohta sopimuksessa on senlainvoimaisuus, johon valmiit sopimuspohjat hyvin harvoin oikeaoppises-ti taipuvat. Helposti voi käydä niin, että valmiin sopimuspohjan muok-kaamiseen sopimuskumppaneiden tarpeita vastaavaksi voi viedä jopaenemmän resursseja, kuin ns. puhtaalta pöydältä rakennetun sopimuk-sen määrittely.

Kehysrintamalta löytyy vaihtelevan tason malleja, mutta myös hyvin laa-jalti levinneitä ratkaisuja. Alla on lueteltu joitakin palvelutasosopimus-määrittelyyn liittyviä kehyksiä:

Telekommunikaatioalalle sopiva kehys: A Framework For Service LevelAgreement Management [TB05]. Kehys ottaa huomioon myös itse palve-lutasosopimusprosessin (kuva 3).

Kuva 3, SLA:n elinkaari [TB05]

Kuuden sigman laatutavoitteen täyttävän palvelutasosopimuksen mää-rittelykehys: Design of a systematic framework for deploying SLA usingSix Sigma methodology [ChJ06].

8

Quality Objects Group (QuO). QuO on väliohjelmistotason kehys QoS:ntakaamiseksi, niin sulautetuissa, kuin wide area network (WAN) laajui-sissa ohjelmistoissa [Kaff01, LSE03].

2.3 Käytännön palvelutasolaskentaaPalvelutasosopimusta määriteltäessä joudutaan useimmiten jossain vai-heessa turvautumaan tarjottavan järjestelmän matemaattiseen mallin-tamiseen, jotta voidaan antaa realistisia lupauksia itse tarjouskilpailuis-sa ja sopimusneuvotteluissa. On huomattavaa, ettei pelkkä matemaatti-nen vasteaikamallinnus tai vastaava riitä, sillä huomioon on otettavamyös yrityksen taloudellinen toimintaympäristö ja sen asettamat puit-teet.

Alla lyhyt esimerkki, kuinka hajautettuja ohjelmistoa tarjoava yritys voi-si laskea kustannuksiaan erilaisilla vasteaikapalvelutasoilla [MeD04].Kaavojen muuttujat:

- Ala. Ja yläindeksi kuvataan seuraavasti A <x,y>(x=alaindeksi ja y=yläindeksi).

- m | m = 1,…,M. Järjestelmän eri tahoilla olevien kompo-nenttien määrä

- V<m> on keskimääräinen käyntimäärä komponentissa oh-jelman suorituksen aikana.

- E on SLA:ssa määritelty ohjelman suoritusaika.- E<m, max> on SLA:ssa määritelty maksimi suoritusaika

yhdessä komponentissa. Luonnollisesti E<m, max> onsuurempi kuin E<m, min>, joka on minimi komponentissakäytetty aika ohjelman suorituksessa.

- Ohjelmatason SLA:n ja komponenttitason SLA:n välinensuhde on siis:

- C<m> on komponentin m veloittama rahamäärä, jokaises-ta SLA:n mukaisesta E<m, max> käynnistä.

- C eli kokonaiskustannukset olisivat siis:

9

Laskemalla kaavojen leikkauskohdat eri arvoilla saadaan suoritusajansuhteen loivasti laskeva kustannuskäyrä (kuva 4). Toisin sanoen kompo-nentti aiheuttaa enemmän kustannuksia, mitä tiukemman SLA:n puit-teissa sitä suoritetaan.

Määrittelemällä komponenteille kustannusfunktiot, voidaan etsiä koko-naiskustannuksiltaan optimaalinen ratkaisu erilaisille SLA-tasoille(esim. kulta, hopea, pronssi).

Tarkempi kuvaus laskentamallista heuristisine ratkaisualgoritmeineenlöytyy lähteestä ”Meanscé, D., Mapping Service-Level Agreements in Dis-tributed Applications” [MeD04].

2.4 XML:n rooli SLA-sopimusmäärittelyissäXML soveltuu hyvin dynaamisten palveluiden SLA-sopimusten määri-tyksiin. Sopimuksen kenttien ollessa tarkoin määriteltyjä ja niiden raja-arvojen ollessa tiedossa saadaan automaattisesti tietoja kulloisestakinpalvelutasosta ja mahdollisista epäkohdista [WYF05]. Samoin palvelu-tasosopimuksen päivittäminen ja ylläpito vastaamaan kehittyvää toimin-taympäristöä helpottuu olennaisesti [WYF05]. XML:llä kuvattu SLA onjärjestetyn rakenteensa takia mahdollista myös muokata ulkoasultaanmoneen tarpeeseen [LSE03]. Esimerkiksi varsinaiseen sopimuspaperiin

Kuva 4: Laskennallisesti määritelty kustannuskäyrä suoritusajan suhteen

10

voidaan tyylimääritystä vaihtamalla tulostaa erinäköinen dokumenttikuin järjestelmän toteutusryhmälle, jotka voivat vielä käyttää erinäisiäUML-työkaluja XML-pohjaisen SLA-sopimuksen esitykseen [SLE04].Kuvassa neljä on esimerkki XML-skeeman käytöstä SLA-sopimuksenpalvelun mittausarvon, ja kuvassa viisi varsinaisen palvelun määrityk-seen.

Kuva 5, Palvelun mittausarvon määritys XML:llä [WyF05]

Kuva 6, Palvelun määritys XML:llä [WyF05]

Metatietojen sisällyttäminen ja linkittäminen usealle tasolle voi kangis-taa ja hidastaa järjestelmän muokattavuutta, mutta joissakin tilanteissatämä on hyväksyttävä yksityiskohta automaattisiin SLA-tasomittareihinnähden. Monimutkaisissa järjestelmissä kaiken kattava XML-määrittely

11

ei välttämättä ole mahdollista, minkä takia voikin olla hyvä harkitaavainpisteiden mallintamista koko järjestelmän sijaan.

2.5 Valmiit järjestelmäratkaisutOhjelmistorintamalla on joitakin vakavammin otettavia ratkaisuja, jotkaperustuvat osaltaan XML:ään tai sitten kokonaan omien standardien va-raan esimerkiksi:

BMC:n BSM (Business system management). Järjestelmän liitty-märajapinta SLA:han hoidetaan omalla komponentillaan (Bu-siness package of service level monitoring):http://www.bmc.com/products/proddocview/0,2832,19052_19429_32473474_124675,00.htmlIBM:n SOA:http://www-306.ibm.com/software/solutions/soa/

Huomionarvoinen seikka näissä ”valmisratkaisuissa” on se, että SLA-sopimuksen koskettaessa laajaa osaa järjestelmäarkkitehtuurista, ovatnämä järjestelmäratkaisutkin yleensä hyvin laaja-alaisia ja monimutkai-sia. Itse palvelutasosopimus ei aina myöskään ole toiminnan keskipiste,vaan usein SLA-liityntä voi olla vain yksi osa koko järjestelmää. Tämäjohtunee siitä, että esimerkiksi edellä mainitut IBM:n ja BMC:n järjes-telmäratkaisut ovat suunniteltu yrityksen lähes koko toimintamalleiksija tässä mittakaavassa SLA:n rooli ei enää ole välttämättä koko toimin-nan keskipiste. Vaarana onkin, että SLA:n merkitystä ei osata näissä ko-rostaa tarpeeksi, jolloin sen kaksisuuntainen vaikutus käytäntöön eivälttämä toteudukaan. SOA:lle on jo kuitenkin tehty tutkimus, jossa silleesiteltiin SLA-pohjainen prosessiohjauksen toteutus [ZXL06]. ´

2.6 SLAngSLAng on XML:ään pohjautuva kuvauskieli, jolla voidaan kuvata QoS:nkoko merkitys järjestelmässä [LSE03, SLE04]. SLAng soveltuu järjes-telmäsuunnittelussa nimenomaan QoS-tasolle ja sopimusmäärittelyyn(kuva 7). SLAng ei kuitenkaan ole suunniteltu määrittelyn joka tasolle,minkä takia se tarvitsee tuekseen myös muita määrittelystandardeja.Esimerkiksi korkeamman tason palvelumäärityksiin WSDL-kieli (WebServices Description Language) soveltuu paremmin.

12

Kuva 7, SLAng-kielen vaikutusalueet [LSE03]

SLAngiin itsessään on mahdollista sisällyttää kaikki SLA-sopimuksenkohdat kuten sopimuskumppaneiden tiedot, rangaistukset, SLS, QoS:ntekniset yksityiskohdat jne [LSE03]. Koska WSDL- ja BPEL-kieli (Bu-siness Process Execution Language) ovat myös XML-pohjaisia, voidaanSLAng yhdistää näihin kieliin soveliailla XML-skeemoilla ja näin saadakaikenkattava sähköisen liiketoiminnan (e-business) automaatioratkaisu[LSE03].

Käytännössä SLAng:n mukainen järjestelmämäärittely tapahtuu luomal-la aluksi ympäristön komponenteista looginen puu SLA-sopimuksen suh-teen. Tämä puu on XML-skeeman (XML-scheme) muodostamisen lähtö-kohta. Puun lehdelle tulkitaan SLA-sopimus yksilöllisesti määrittelemäl-lä sille järkevät mittarit ja raja-arvot. Tässä tulee huomata, ettei SLAngrajoita mittareiden ja raja-arvojen määrityksiä, vaan jokaiselle lehdellevoidaan määrätä varsin vapaasti sille parhaiten sopivat parametrit. Sol-mua kohti voi olla myös useampia SLA-sopimuksia koskevia määrityksiä[LSE03].Tätä analogiaa käyttämällä käydään sitten koko puu läpi. Ote esimerk-kimäärittelypuusta (kuva 8).

13

Kuva 8, Esimerkkimäärittelypuu [LSE03]

SLAng:n etuja muihin vastaaviin ratkaisuihin ovat muun muassa[SLE04]:

SLAng ei keskity pelkästään internet-palveluiden kuvaamiseen.Mukana on SLA-sanasto laajalle valikoimalle eri verkkopalveluitaesim. ASP (Application Service Provision), ISP (Internet ServiceProvision) ja SSP (Storage Service Provision).SLAng:n rakenne on kehittynyt teollisuuden käytännön tarpeista.Se on siis koottu käytössä olevien SLA-sopimusten pohjalta, minkätakia se pystyy todennäköisesti tarjoamaan realistisempia ratkai-suja, kuin puhtaasti teorioiden pohjalta määritellyt ratkaisut.SLAng:in tavoite on formaalisesti määritelty palveluiden ja niitäkäyttävien asiakkaiden suhteen. Tämä vastaa yleistä palvelukäyt-tömallia [SLE04].

Formaalin mallinnuksen takia SLAng:sta ja sen tuotoksista on mahdol-lista generoida myös UML-kaavioita automaattisesti. Esimerkkinä tästäon abstrakti SLA-syntaksi SLAng:n näkökulmasta ASP-SLA-sopimuksille (kuva 9).

14

Kuva 9, Abstrakti SLAng-syntaksi ASP-SLA-sopimuksille [SLE04].

3 YhteenvetoPalvelutasosopimukset ovat näennäisen yksinkertaisesta aiheestaan huo-limatta hyvin tutkittu ja ajankohtainen alue ”yhteistoiminnan hallintapalveluorientoituneissa järjestelmissä”-sektorilla. Etenkin tietoliikenne-järjestelmien puolella on SLA:n merkitys ja vaikutus huomattava. Kysei-sellä palvelusektorilla on myös syntynyt usein SLA:han kiinteästi liittyvätermi QoS. Kaiken kattavana perusajatuksena on taata asiakkaalle hä-nen vaatimansa palvelutaso niin, että se on myös tuottajalle kannatta-vaa. Tämän takia SLA-sopimuksen tarvitsee olla huolella jäsennelty jasuunniteltu, koska siihen yleensä vedotaan kriittisissä ja joskus myös ju-ridistisissa tilanteissa. SLA-sopimus on asiakkaan ja tuottajan välisenyhteistoiminnan laatutason virallinen artefakti.

Uuden palvelutasosopimuksen määrittelyssä voidaan käyttää oman talonhyviksi kokemia vanhoja esimerkkisopimuksia. Omassa työelämässäniolen tämän tavan nähnyt olevan vallalla. Eri tilanteisiin luodut sopimus-

15

pohjat elävät talon sisällä ja muodostavat tavallaan näin osan yrityksenyhteisestä identiteetistä. Sopimuspohjia voidaan myös hakea muista läh-teistä, joista internet lienee yleisin. Näiden mallien suhteen tulee ollahyvin tarkka ja yleensä niiden soveltuvuus käytännön tilanteisiin on lä-hinnä suuntaa antava. Liitteenä on yhden internetistä haetun mallin ot-sikkorakenne [Liite 1]. Sopimuspohjia hieman korkeamman tason malle-ja edustavat kehykset. SLA-sopimuksen kehittämiseen ja luomiseen onuseita kehyksiä, joiden taso vaihtelee tilanteesta riippuen hyödyllisestähyödyttömään. Tarkkojen laatukriteerien yhteistoiminnassa (esim. pro-sessorialihankkija) kuuden sigman määrittelykehys voi olla hyvinkinhyödyllinen, kun taas esimerkiksi tietoliikennepalveluja kotitalouksiintarjoavan yrityksen kannattanee käyttää jotain kevyempää kehystä.

Itse SLA-sopimuksen sisäinen rakenne ja määrittely voidaan tehdä esi-merkiksi XML:llä käyttäen joko omaa tai valmista kieltä, kuten SLAngia.SLAng ulottaa palvelutasosopimuksessa määritellyt asiat hierarkkisestikoko järjestelmän laajuudelle, tehden siitä joskus myös hyvin raskaanmallin. XML:än käyttöä yleensä perustelee kuitenkin sen yhteensopivuusja hallittavuus useiden järjestelmien välillä. Määrittelemällä palvelu-tasosopimus tarkasti ja liittämällä siihen metatietoja on sen lukeminenja johtaminen myös alemman tason sopimuksiin, sekä toimintamalleihinmahdollista.

Käytännössä palvelutasosopimuksia tehdessä joudutaan ennemmin taimyöhemmin pureutumaan syvälle palvelua tarjoaviin järjestelmiin. Tie-totekniikkamaailmassa tämä tarkoittaa yleensä laajoja matemaattisiakuvauksia järjestelmästä. Esimerkiksi kuinka määritellä hajautetulletransaktiohallintajärjestelmälle realistinen vasteaikatavoite? Kysymyk-sen ratkaisemiseen joudumme käyttämään ainakin useata matematiikaneri osa-aluetta (esim. todennäköisyyslaskenta), järjestelmien, sekä tek-niikan syvällistä asiantuntemusta ja tietämystä yritystalouden toimin-nasta. Kuten tästä yksinkertaisesta esimerkistä huomaamme, samallakun SLA-sopimus on ylimpänä määräämässä myös alemman tason palve-lutasosopimuksia, niin samaan aikaan SLA-sopimus on lopputulemaalemman tason palvelutasomäärityksistä, laskennallisista realiteeteistaja palvelulaatulupauksista.

16

Liite1: Esimerkkipalvelutasosopimus

Alla tyypillisen palvelutasosopimuksen hakemistorakenne[http://www.businessballs.com/service_agreements_contracts_templates.htm]

1 heading/title2 description/purpose/the service (basically the product/service desc-

ription)3 parties (supplier and client - including addresses)4 date5 territory/geographical coverage6 definitions - essential glossary 'root' of frequently occurring items in

the document7 term - period of agreement8 pricing (refer if appropriate to attached schedule)9 pricing adjustment (for example annual increases linked to suitable

index)10 responsibilities of provider - include or append details of services and

responsibilities of client11 payment terms12 confidentiality13 dispute and arbitration process14 termination and force majeure15 renegotiation/renewal16 prevailing laws17 signatures and witnesses

17

Lähteet

HaGe04 Haitao Xia, Gehan Wu, Fullfilling SLA Measurability viaTwo-phased QoS Metrics Integration, IEEE CommunicationSocietys, Globecom 2004

RHRM02 Rahul, G., Huzus, S., Ramandeep, S.R., Manpreet, S., A SLAFramework for QoS Provisioning and Dynamic Capacity Allo-cation, IEEE 2002 Tenth IEEE International Workshop onQuality of Service

Kel02 Keller, A., Kar, G., Ludwig, H., Dan, A., Hellerstein, J., L.,Managing Dynamic Services: A Cotract Based Approach toConceptual Architecture, Network Operations and Manage-ment Symposium, 2002. NOMS 2002. IEEE/IFIP

ODP95 Open Distributed Processing - Reference Model, ”Part 2: Foun-dations” International standard 10746-2, ITU-T Recommen-dation X.902. 1995.

WYF05 Wenhui Sue, Yue Xu, Feng Liu, The c in Service level Agree-ments Management. Services Systems and Services Manage-ment, 2005. Proceedings of ICSSSM '05

LSE03 Lamanna, D., D., Skene, J., Emmerich, W., SLAng: A Langu-age for Defining Service Level Agreements. Distributed Com-puting Systems, 2003. FTDCS 2003

MeD04 Meanscé, D., Mapping Service-Level Agreements in Distribu-ted Applications, IEEE, George Mason University

OnR03 Onchaga, R., Extending the Quality Concept in Geo-Information Processing, Internationa Institute for Geo-Information Science and Earth Observation (ITC)

TB05 Trygar, T., Bain, G., A Framework For Service Level Agree-ment Management, Military Communications Conference,2005, MILCOM 2005

18

ChJ06 Choi, J., Design of a systematic framework fordeploying SLA using Six Sigma methodology, AdvancedCommunication Technology, 2005, ICACT 2005. The 7th In-ternational Conference on Advanced Communication Techno-logy

Kaff01 Kaff, D.A.; Rodrigues, C.; Krishnamurthy, Y.; Pyarali, I.;Schmidt, D.C., Application of the QuO quality-of-service fra-mework to a distributed video application, Distributed Objectsand Applications 2001, DOA '01. Proceedings. 3rd Interna-tional Symposium on 17-20 September 2001

ZXL06 Zhang Nan, Xue-Song Qiu, Luo-ming Meng, A SLA-basedService Process Management Approach For SOA, Communica-tions and Networking in China, 2006. ChinaCom '06

SLE04 Skene, J., Lamanna D., D., Emmerich, W., Precise Service Le-vel Agremeents, Proceedings of 26th International Conferenceon Software Engineering (ICSE’04), IEEE 2004

IBM01 Managing Service Level Agreements,http://publib.boulder.ibm.com/tividd/td/TSLA/SC32-1247-00/en_US/HTML/sl21smst02.htm#ToC, IBM, 29.11.2007

Wiki01 Service-Level Agreement,http://en.wikipedia.org/wiki/Service_Level_Agreement,29.11.2007

Wiki02 Frameworks, http://en.wikipedia.org/wiki/Framework,15.11.2007

Wiki03 Software Frameworks,http://en.wikipedia.org/wiki/Software_framework, 15.11.2007

Wiki04 Conceptual Framework,http://en.wikipedia.org/wiki/Conceptual_framework,15.11.2007

19

Wiki05 Template, http://en.wikipedia.org/wiki/Template, 15.11.2007