![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
SLA-gesprek
Dit gaat niet over een gesprek over salade, maar over mijn maandelijks Service Level Agreement gesprek met onze web design en hosting partner. Dit gesprek vind ik elke maand heel leuk om te doen, omdat er een goede dynamiek is tussen alle betrokkenen. Met z'n vijven bespreken we de actiepunten en prestaties van de afgelopen maand; mijn manager, onze interne hosting beheerder, service manager van de hosting partij, service manager van web design partij en mijzelf. Normaal is hier ook nog de projectmanager van een grote web-applicatie bij, maar die was deze keer niet aanwezig.
De meeting begint met de actielijst. Zaken die vorige maand zijn afgesproken komen ter sprake, om de voortgang van deze punten te bespreken. Ook lang lopende problemen en acties staan op de lijst incl. de verantwoordelijke partij(en). Voorbeelden van actiepunten zijn:
Na de actielijst komt de SLA rapportage van de hosting partij: er zijn geen bijzonderheden en de servers zijn in de maand december 100% beschikbaar geweest. Ik word nog wel even op mijn vingers getikt omdat ik voor aanvragen van changes (bijv in DNS) direct naar hun helpdesk bel, terwijl het afgesproken proces loopt via de web design partij. Mijn manager reageert nonchalant en als het voor hem geen probleem is, maak ik me er ook niet druk over.
Als laatste onderwerp van de meeting bespreken we de SLA rapportage van de web design partij. Hierin wordt vooral gekeken naar de reactie- en oplostijd voor vragen, changes en bugs. Deze zijn ingedeeld in prioriteiten en per prioriteit gelden andere tijden. Ditmaal hebben ze voor de laagste prioriteit 93% van de keren binnen de afgesproken tijd gehandeld. Voor de hogere prioriteiten is dit 100%. Niet slecht dus. Verder zijn er nog wat langlopende changes die worden besproken. Het is namelijk nog wel eens zo dat ze zaken op 'resolved' zetten wanneer ze het niet binnen de SLA-tijd kunnen oplossen. Op deze manier zie je dat niet in de rapportage, maar dat is dus eigenlijk ook niet de bedoeling. In dit geval gaat het voornamelijk over het implementeren van de Google Analytics code in bestaande websites die lang op zich laat wachten.
Verder waren er in de maand december geen grote problemen met websites, dus we zijn ruim binnen de afgesproken tijd klaar met het gesprek. Aan mij dan nog de taak om de actielijst te updaten en dan zien we elkaar over maand weer in dezelfde opstelling.
De meeting begint met de actielijst. Zaken die vorige maand zijn afgesproken komen ter sprake, om de voortgang van deze punten te bespreken. Ook lang lopende problemen en acties staan op de lijst incl. de verantwoordelijke partij(en). Voorbeelden van actiepunten zijn:
- De SQL server in de acceptatie-omgeving zit bijna tegen de max van het geheugen. Deze moet opgeschoond worden en/of extra geheugen bijgeplaatst
- De migratie van domeinnamen en DNS loopt, maar hiermee wordt gewacht tot de migratie van het datacenter compleet is
- Uit monitoring blijkt dat twee websites stukken slechter presteren qua bereikbaarheid dan anderen. Oorzaak onderzoeken en evt direct actie ondernemen
Na de actielijst komt de SLA rapportage van de hosting partij: er zijn geen bijzonderheden en de servers zijn in de maand december 100% beschikbaar geweest. Ik word nog wel even op mijn vingers getikt omdat ik voor aanvragen van changes (bijv in DNS) direct naar hun helpdesk bel, terwijl het afgesproken proces loopt via de web design partij. Mijn manager reageert nonchalant en als het voor hem geen probleem is, maak ik me er ook niet druk over.
Als laatste onderwerp van de meeting bespreken we de SLA rapportage van de web design partij. Hierin wordt vooral gekeken naar de reactie- en oplostijd voor vragen, changes en bugs. Deze zijn ingedeeld in prioriteiten en per prioriteit gelden andere tijden. Ditmaal hebben ze voor de laagste prioriteit 93% van de keren binnen de afgesproken tijd gehandeld. Voor de hogere prioriteiten is dit 100%. Niet slecht dus. Verder zijn er nog wat langlopende changes die worden besproken. Het is namelijk nog wel eens zo dat ze zaken op 'resolved' zetten wanneer ze het niet binnen de SLA-tijd kunnen oplossen. Op deze manier zie je dat niet in de rapportage, maar dat is dus eigenlijk ook niet de bedoeling. In dit geval gaat het voornamelijk over het implementeren van de Google Analytics code in bestaande websites die lang op zich laat wachten.
Verder waren er in de maand december geen grote problemen met websites, dus we zijn ruim binnen de afgesproken tijd klaar met het gesprek. Aan mij dan nog de taak om de actielijst te updaten en dan zien we elkaar over maand weer in dezelfde opstelling.
31-01 Narrowcasting: off topic
11-01 Wildgroei redirects
Reacties
Door
skabouter,
woensdag 18 januari 2012 12:22
Dus je eist wel zaken als snelle response time, hoge uptime e.d. maar een simpele (logische) work-flow afspraak vanuit de kant van de aanbieder wordt genegeerd?Ik word nog wel even op mijn vingers getikt omdat ik voor aanvragen van changes (bijv in DNS) direct naar hun helpdesk bel, terwijl het afgesproken proces loopt via de web design partij. Mijn manager reageert nonchalant en als het voor hem geen probleem is, maak ik me er ook niet druk over.
Door
robtaal,
woensdag 18 januari 2012 14:34
Wie weet hoeveel afspraken er zijn gemaakt met dat bedrijf. Het is volgens mij niet zo dat hij systematisch de regels negeert... Gewoon een puntje om aan te werken.
Door
Katerin,
woensdag 18 januari 2012 15:19
Het is wel een verkeerde instelling.
Of het nu 1 keer is of stelselmatig.
Of het nu 1 keer is of stelselmatig.
Door
NoUseWhatsoever,
woensdag 18 januari 2012 15:25
Valt wel mee. Ik was er niet bij toen die afspraken werden gemaakt; dat was namelijk ruim een jaar geleden. Het staat niet in de SLA dus ik was er ook niet van op de hoogte. Nu wel, dus zal ik er ook op letten.Katerin schreef op woensdag 18 januari 2012 @ 15:19:
Het is wel een verkeerde instelling.
Of het nu 1 keer is of stelselmatig.
Dit soort dingen gebeuren nu eenmaal, ook van hun kant. Ik schrijf ook dat zij dingen sluiten terwijl ze niet afgerond zijn om binnen SLA te kunnen vallen...
[Reactie gewijzigd op woensdag 18 januari 2012 15:26]
Door
-ko-,
woensdag 18 januari 2012 17:26
Dat is toch de hele reden achter SLA meetings? Het process controleren en doorspreken om vervolgens situaties waar het niet volgens de procedures gaat te constateren en dan op verbetering aansturen? (naast de lopende zaken / changes uiteraard)
Lekker boeiend dat je op je vingers getikt wordt. Je probeert gewoon je werk te doen (want je logt die calls niet voor niks) en dan gaat er wel eens iets fout of je doet iets verkeerd. Vind de reacties boven deze overdreven.
Lekker boeiend dat je op je vingers getikt wordt. Je probeert gewoon je werk te doen (want je logt die calls niet voor niks) en dan gaat er wel eens iets fout of je doet iets verkeerd. Vind de reacties boven deze overdreven.
Door
Katerin,
woensdag 18 januari 2012 17:40
Dat kan ik natuurlijk ook niet ruiken..NoUseWhatsoever schreef op woensdag 18 januari 2012 @ 15:25:
[...]
Valt wel mee. Ik was er niet bij toen die afspraken werden gemaakt; dat was namelijk ruim een jaar geleden. Het staat niet in de SLA dus ik was er ook niet van op de hoogte. Nu wel, dus zal ik er ook op letten.
Dit soort dingen gebeuren nu eenmaal, ook van hun kant. Ik schrijf ook dat zij dingen sluiten terwijl ze niet afgerond zijn om binnen SLA te kunnen vallen...
Het staat er nogal nonchalant.
Door
Bospa01,
woensdag 18 januari 2012 20:15
Ditmaal hebben ze voor de laagste prioriteit 93% van de keren binnen de afgesproken tijd gehandeld.
Dus 7% van alle calls zijn buiten SLA ?
Dus 7% van alle calls zijn buiten SLA ?
Door
siepeltjuh,
woensdag 18 januari 2012 20:46
SLA rond oplostijden zijn altijd problematisch, de afspraken zijn vaak helder, maar het vastleggen niet.
Bereikbaarheid van servers zijn makkelijk te meten door het te automatiseren. Een klacht in behandeling nemen en oplossen is veel moeilijker te registreren. Wanneer start de melding? Wanneer is het gereed, wat is gereed? Ook al leg je al dat soort dingen vast, dan nog heb je de menselijke factor die een klacht/procedure beoordeelt.
Zie bijvoorbeeld de opmerking over het sluiten van een ticket ondanks dat deze nog niet opgelost is. Gebeurt zo vaak.
Heel die rapportages zijn zo voor interpretatie vatbaar. Zeker wanneer het management er naar kijkt en oordeelt zonder eigenlijk ook maar enig idee te hebben hoe het in de praktijk werkt.
Bereikbaarheid van servers zijn makkelijk te meten door het te automatiseren. Een klacht in behandeling nemen en oplossen is veel moeilijker te registreren. Wanneer start de melding? Wanneer is het gereed, wat is gereed? Ook al leg je al dat soort dingen vast, dan nog heb je de menselijke factor die een klacht/procedure beoordeelt.
Zie bijvoorbeeld de opmerking over het sluiten van een ticket ondanks dat deze nog niet opgelost is. Gebeurt zo vaak.
Heel die rapportages zijn zo voor interpretatie vatbaar. Zeker wanneer het management er naar kijkt en oordeelt zonder eigenlijk ook maar enig idee te hebben hoe het in de praktijk werkt.
Door
NoUseWhatsoever,
woensdag 18 januari 2012 22:26
Ik snap dat dat raar klinkt, maar in de SLA is ook overeengekomen dat zij voor de lagere prio's, (maar) 90% van de keren binnen de gestelde tijd moeten reageren/oplossen.TLRnZ schreef op woensdag 18 januari 2012 @ 20:15:
Ditmaal hebben ze voor de laagste prioriteit 93% van de keren binnen de afgesproken tijd gehandeld.
Dus 7% van alle calls zijn buiten SLA ?
[Reactie gewijzigd op woensdag 18 januari 2012 22:29]
Door
mati1983,
donderdag 19 januari 2012 08:39
Leuk stukje om als service manager te lezen .
Processen zijn echter met een reden op een bepaalde manier ingericht. Zaken als KPI's en service levels hebben hier waarschijnlijk een relatie mee. Wanneer processen niet praktisch zijn, dan zou ik dat bespreken en samen tot een alternatief komen (indien mogelijk).
Ook, kijkend naar de voorbeelden die je aan draagt, vind ik het een bijzonder hoog operationeel karakter hebben.. Maar wellicht ligt dat ook aan de invulling die de verschillende partijen aan de term 'service manager' hebben gegeven. Zelf probeer ik het operationele zoveel mogelijk aan mijn techneuten over te laten en focus ik me bij de SLA meetings met mijn klant vooral op zaken als klanttevredenheid, forecasting, KPI's, etc..
Uit nieuwsgierigheid: Hoe worden zulke zaken in jullie govervance afgehandeld? Door account management bv..?
.Processen zijn echter met een reden op een bepaalde manier ingericht. Zaken als KPI's en service levels hebben hier waarschijnlijk een relatie mee. Wanneer processen niet praktisch zijn, dan zou ik dat bespreken en samen tot een alternatief komen (indien mogelijk).
Ook, kijkend naar de voorbeelden die je aan draagt, vind ik het een bijzonder hoog operationeel karakter hebben.. Maar wellicht ligt dat ook aan de invulling die de verschillende partijen aan de term 'service manager' hebben gegeven. Zelf probeer ik het operationele zoveel mogelijk aan mijn techneuten over te laten en focus ik me bij de SLA meetings met mijn klant vooral op zaken als klanttevredenheid, forecasting, KPI's, etc..
Uit nieuwsgierigheid: Hoe worden zulke zaken in jullie govervance afgehandeld? Door account management bv..?
Door
NoUseWhatsoever,
donderdag 19 januari 2012 08:57
Deze zaken bespreken we met de web design partij in een apart maandelijks gesprek, waarbij hun directeur en een sr account manager aanwezig zijn. Met de hosting partij hebben we dergelijke gesprekken niet.mati1983 schreef op donderdag 19 januari 2012 @ 08:39:
...... Zelf probeer ik het operationele zoveel mogelijk aan mijn techneuten over te laten en focus ik me bij de SLA meetings met mijn klant vooral op zaken als klanttevredenheid, forecasting, KPI's, etc..
Uit nieuwsgierigheid: Hoe worden zulke zaken in jullie govervance afgehandeld? Door account management bv..?
Door
Ninja1,
vrijdag 20 januari 2012 15:14
Er valt me een ding op: De SQL server in de acceptatie-omgeving zit bijna tegen de max van het geheugen. Deze moet opgeschoond worden en/of extra geheugen bijgeplaatst.
Nou kan het natuurlijk geen enkel kwaad om meer geheugen te plaatsen.
Je zult echter al snel zien dat ook dan al het, aan SQL server, toegekende geheugen in gebruik zal zijn.
SQL gebruikt geheugen namelijk als cache en het liefst zo veel mogelijk.
Nou kan het natuurlijk geen enkel kwaad om meer geheugen te plaatsen.
Je zult echter al snel zien dat ook dan al het, aan SQL server, toegekende geheugen in gebruik zal zijn.
SQL gebruikt geheugen namelijk als cache en het liefst zo veel mogelijk.
Door
NoUseWhatsoever,
vrijdag 20 januari 2012 15:17
Even nagekeken in de actielijst en het ging idd niet om geheugen, maar opslagruimte. My badNinja1 schreef op vrijdag 20 januari 2012 @ 15:14:
Er valt me een ding op: De SQL server in de acceptatie-omgeving zit bijna tegen de max van het geheugen. Deze moet opgeschoond worden en/of extra geheugen bijgeplaatst.
Nou kan het natuurlijk geen enkel kwaad om meer geheugen te plaatsen.
Je zult echter al snel zien dat ook dan al het, aan SQL server, toegekende geheugen in gebruik zal zijn.
SQL gebruikt geheugen namelijk als cache en het liefst zo veel mogelijk.
Door
Ninja1,
vrijdag 20 januari 2012 15:43
Aha, opslag, daar is altijd een tekort aan.
Nog wel afhankelijk van welke bestanden op de opslag staan die ruimte tekort krijgt.
Log bestanden kunnen met een goede backup procedure telkens worden geschoond en kunnen vrij klein blijven afhankelijk van de grootte van lopende transacties.
Backup bestanden kunnen opgeschoond worden, bv oude full backup verwijderen als een nieuwe full gemaakt is.
TempDB bestanden kun je weinig aan doen, die groeit tot maximale ingestelde grootte, groot = goed.
Data bestanden zullen groeien over tijd, bv logging van events zal blijven groeien tenzij de hele oude data geschoond wordt.
Aangezien best practice is om aparte schijven te gebruiken voor de diverse doeleinden is probleemgebied meestal beperkt.
Nog wel afhankelijk van welke bestanden op de opslag staan die ruimte tekort krijgt.
Log bestanden kunnen met een goede backup procedure telkens worden geschoond en kunnen vrij klein blijven afhankelijk van de grootte van lopende transacties.
Backup bestanden kunnen opgeschoond worden, bv oude full backup verwijderen als een nieuwe full gemaakt is.
TempDB bestanden kun je weinig aan doen, die groeit tot maximale ingestelde grootte, groot = goed.
Data bestanden zullen groeien over tijd, bv logging van events zal blijven groeien tenzij de hele oude data geschoond wordt.
Aangezien best practice is om aparte schijven te gebruiken voor de diverse doeleinden is probleemgebied meestal beperkt.