SLA:n hinta

Palvelujen ylläpidossa sovitaan palvelutasosta (SLA, Service Level Agreement). SLA määrittelee esimerkiksi kuinka nopeasti tukipyyntöihin reagoidaan.

Toimittajan kannalta SLA vertautuu vakuutusmatematiikkaan. Kun palvelua pyöritetään riittävän kauan, jonakin päivänä virtapiikki käräyttää palvelimen, karkaussekunti kaataa Linuxin tai pelikaani lentää turbiiniin, ja luvatussa tasossa ei pysytä. Tällöin maksettavan korvauksen pitäisi olla pienempi kuin palvelutasosta veloitettu summa, jotta toimittaja tekee kannattavaa liiketoimintaa.

Kannattaa siis harkita kuinka paljon SLA:sta kannattaa maksaa. Mitä kauemmin palvelu on toiminut luotettavasti, sitä todennäköisemmin toimistoajan ulkopuolella esiintyvä ongelma ei ole triviaali - jolloin sen korjaus harvemmin onnistuu päivystävän asiakaspalvelu­henkilöstön toimesta.

Toisaalta alhainen SLA antaa toimittajalle mahdollisuuden vitkastella tukipyyntöjen kanssa - mitäs ette tilanneet 99,999% saavutettavuutta! Luotettavien ja vastuunsa kantavien toimittajien kanssa best effort -tyyppinen sopimus tarjoaakin usein parhaan lopputuloksen monimutkaisten SLA-määrittelyjen sijaan.

Pasi Kovanen

Pasi Kovanen
Software with Passion.

5 kommenttia

Jussi Puustinen sanoo:

Myös vanha kansanviisaus ‘sitä saa mitä mittaa’ toteutuu usein SLA mittaroinnin kanssa. SLA:ta tärkeämpi olisi ensin miettiä todelliset vaikutukset ongelmatilanteista liiketoiminnalle Antinkin mainitseman riskianalyysin pohjalta. Tämän pohjalta onkin sitten helpompi määritellä HA vaatimukset, OLA:t ja SLA:t. Liiketoinnalle on myös hyvä selittää aiheutuvat kustannukset, mikäli halutaan lähteä tavoittelemaan useampaa yhdeksikköä availabilityn ja tukipyyntöjen suhteen 24×7.

Ainakin osittain best effort -mallilla toimivien palvelutasosopimusten käyttäminen voisi myös oman näkemykseni mukaan tuoda asiakkaille merkittäviä kokonaissäästöjä useissa tapauksissa. Eteenkin silloin, kun palveluntoimittaja on riittävän pieni ja ketterä.

Yleisesti ottaen asiakkaan kannaltahan SLA:n, ja ennen kaikkea siinä määritellyt sanktiot, tulisi vastata asiakkaalle koituvia haittoja palvelutason alenemisesta alle sovittujen rajojen. Näin ollen SLA on aina tapaus/palvelukohtainen ja sen tulisi perustua toimittajan kanssa yhteistyössä tehdyn riskianalyysin tulosten pohjalle. Valitettavan harvoin tällaisia SLA-sopimuksia tosin näkee vaan uuden palvelun SLA-sopimukset tehdään suoraan jonkin vanhan palvelun pohjalta. Ja vielä harvemmin toteutunutta palvelutasoa seurataan aktiivisesti Asiakkaan toimesta.

Mikko Hällfors sanoo:

Minulta meni kyllä kirjoituksen pointti huomaamatta. Onko SLA niin tuntematon käsite, että siitä pitää kirjoittaa?
Eikös toimittajien pitäisi olla aina luotettavia ja vastuunsa kantavia? Tällöin on varmaan ihan sama mikä sopimus on ja asia tulee korjatuksi mahdollisimman nopeasti.

Jarmo Salmela sanoo:

Kunhan nyt edes jokin tuki löytyy – ja silloin se edellyttää palvelutuottajalla olevan ko. järjestelmän asiantuntemusta olemassa sen koko elinkaaren ajan. Siinä on mentaliteettiero, kun olaan palvelubisneksessä. Laitevalmistajat taas yleensä lopettavat koko tuen, kun viimeiseksi päätetty softapäivitys on lähtenyt maailmalle.
Realistinen riskianalyysi auttaa harkitsemaan SLA:n sisältöä.

Meidänkin piti vastata erääseen oppimisympäristökilpailutukseen, mutta hankintakilpailutuksen toisella kierroksella vaadittiin opettajien ja oppilaiden käyttöön toteutettavan palvelun päivystykseen 30 sekunnin vasteaika puhelimitse tuleviin tukipyyntöihin ja 30min kuluessa ongelmanratkaisu tulisi aloittaa.. Lisäksi kaikki muutkin SLA-vaatimukset olivat todennäköisesti varmuuden vuoksi kopioitu jostain tullijärjestelmän vaatimuksista..

Liity keskusteluun