Services levels, een SLA(G) in de lucht?

Het uitbesteden van computerservices door middel van cloud computing leidt tot nieuwe vraagstukken. Hoewel iedereen zich druk maakt over de mogelijkheden en de functies die erbij komen, zullen we ons dus wel degelijk zorgen moeten maken over de service levels.

Service levels zijn afspraken die gemaakt worden door vrager en aanbieder van computerdiensten. In de wereld van outsourcing is dit vrij normaal. maar ook intern hebben organisaties dit soort afspraken. Het principe werkt zo: Als er een bedrijfskritische applicatie is wil de organisatie geen verstoringen hebben in hun belangrijkste bedrijfsprocessen. Men spreekt dan af dat dit het hoogste service level krijgt (zeg severity level 1). De it-afdeling neemt daarop maatregelen. De servers, databases en alles wat erom heen hangt wordt dan vaak redundant uitgevoerd. Immers mocht er onverhoop een server uitvallen, dan kan de andere dit overnemen. De sla wordt dan gehaald. Vaak wel met minder capaciteit, maar het belangrijkste bedrijfsproces kan gewoon doorgaan.

Zo zijn er ook afspraken op andere levels. Deze applicaties worden minder belangrijk geacht, maar men wil wat zekerheden. De machine moet bijvoorbeeld weer binnen acht uur up and running zijn. De maatregelen die een it-afdeling vaak neemt is het zorgen van een goede back-up die een korte restore tijd heeft.

Nu zijn er over deze afspraken met betrekking tot beschikbaarheid, ook afspraken over de hoogte van de betaling van de service. Je zult begrijpen dat een it-afdeling meer moeite doet bij een severity 1, dan bij een severity 4. dat komt omdat er ook geprioriseerd moet worden, en dat de middelen nog wel anders kunnen zijn om weer in een operationele status te komen. Zolang de afspraken bekend zijn en elke partij die nakomt is er vaak niets aan de hand.

Andere situatie

Bij cloud computing is de situatie van hoe de infrastructuur is opgezet van oorsprong al anders. Als een leverancier wil beginnen met het hosten van zijn applicatie of een dienst wil aanbieden via de cloud zal hij bij voorbaat al een aantal zaken regelen. Zo zal het gebruikelijk zijn om high end systemen op te zetten in meerdere data centers. Hiermee wordt meteen al redundantie gecreëerd. Ook de systemen zijn al high end. Maar heb je hierom gevraagd? Wilde je die applicatie nu echt redundant uitgevoerd hebben? Misschien was dat niet nodig, omdat de applicatie normaal in jouw organisatie een severity 3 zou zijn.

Laten we dan even voorstellen dat je dus toch inderdaad de severity level van de applicatie de allerhoogste is, is dan het aangebodene wel wat je wilt?

We kunnen nog een stapje verder gaan. Want vaak heb je in een eigen omgeving meerdere sla's. Een goed voorbeeld is een netwerk sla die je ook hebt. Deze heeft natuurlijk effect op jouw sla voor die sla-service voor een severity 1. Als er iets van het netwerk uitvalt dan is er een impact op elk component. Goede SLA's houden hier rekening mee. Zo is ook het netwerk redundant opgezet.

Anders denken

De redenen hierboven is naar mijn mening een aanleiding om anders te denken over service levels. Vroeger vertaalden we dat via beschikbaarheid naar technische opzet. Of dit nu een redundant netwerk is of de setup van redundante servers. Beide zijn vaak goed ingeregeld. We zullen dus iets anders moeten bedenken voor een cloud. Immers zelfs het netwerk van de cloud naar het interne netwerk is redundant uitgevoerd De vertaling die we nu moeten maken is een vertaling van beschikbaarheid naar service nivo, we moeten een stapje verder gaan dan we nu doen. Een ander denkpatroon is dus nodig.

Daar moet een duidelijk beeld van worden gezet. Want zeker een service nivo is moeilijk te definieren. Ik vergelijk het altijd maar (hoe makkelijk dat ook is) met reizen met de trein. Ik wil een aantal dingen als ik met de trein rijd. Ik wil dat hij op tijd vertrekt en op tijd aankomt, op een lange route wil ik een kop koffie en ik wil geïnformeerd worden als er iets aan de hand is wat verstoord wordt. Hoe kan ik dat vertalen naar it?

Allereerst wil ik dus dat de applicatie gewoon werkt. Als tweede wil ik af en toe wat extra's zien, bijvoorbeeld een rapportage over bijvoorbeeld gebruik en als er inderdaad in de markt wat veranderd in de business waar ik zit dan wil ik daar informatie over en vooral hoe mijn leverancier hier op inspeelt. Ik wil dus eigenlijk een service leverancier in plaats van een applicatie leverancier. Juist dat is wat een cloud computing-leverancier moet kunnen toevoegen. Maar alles heeft een prijs. Dus als ik alleen een applicatie wil die het doet, betaal ik daarvoor, maar wil ik meer dan moet ik er voor betalen.

Naleven

Een andere kant van een sla treedt op als inderdaad de sla niet wordt nageleefd. Daar wordt vaak een straf in de vorm van geld gezet. In het geval van beschikbaarheid valt daar nog redelijk goed te meten hoe lang iets niet beschikbaar is. Een rapportage die niet of niet goed geleverd wordt is ook nog zeer goed meetbaar. Het wordt lastig als de extra's niet goed zijn. Stel er wordt een marktverwachting uitgesproken en die komt niet uit. Moet de leverancier dan gestraft worden? Hij moet nu eenmaal aan honderd klanten een update leveren. Tja, daar gaat al weer een service nivo. Misschien moeten we wel op een andere manier naar service levels kijken, anders zoals ik beschreef. Uitgangspunt echter blijft hetzelfde. De applicatie moet beschikbaar zijn en de gebruiker moet geen vertraging vinden bij het gebruik van de applicatie.

Het zal lastig worden als de leverancier maar één applicatie levert. Immers delen van de core business bestaat bijvoorbeeld niet alleen uit het verkopen of maken van een product. Men heeft vaak ook logistiek in huis, of hr of erm. Een service level komt al eerder ter sprake als een leverancier meer applicaties levert dan één applicatie alleen. Ik zie dan ook wel gebeuren dat er aanbieders (brokers of outsourcing partijen) komen die straks een complete omgeving aanbieden.

De reden daarvoor is ook al vrij simpel. Om al deze leveranciers te managen is nogal wat nodig. Het is daarom handig bij het opzetten van een sla een intermediar te hebben die adviseert. Niet zomaar een consultant maar een bedrijf dat dit werk doet voor meer bedrijven. It in de cloud krijgt zo een grotere toegevoegde waarde. Het advies moet duidelijk over een aantal zones heengaan. Het overzicht moet worden bewaard met betrekking tot de applicaties die in de cloud zijn. Als men dat te ingewikkeld vindt, moet men een partner vinden die de gewenste diensten aanbiedt en men daar afspraken mee maakt op het terrein van sla.