Onderwerp: Real SLA's datacenters

Na de downtime van enkele maanden geleden van LCL in belgie viel me op dat men bij LCL altijd sprak van het enige datacenter in Belgie met een 0% downtime garantie maar dat LCL in een artikel (http://www.knack.be/nieuws/technolog...icle15379.html) bevestigd dat ze maar een uptime garanderen van 99,98% op hun datacenter. Nog meer valt op dat er op de huidige site van LCL nergens nog enige referentie naar een SLA wordt gemaakt.

Het valt me ook op dat heel wat hosters bij LCL een hogere SLA claimen dan deze 99,98% van hun datacenter wat onmogelijk is , je SLA is zo hoog als de SLA van je zwakste schakel. Ik neem aan dat in nederland ook deze problemen voordoen.
Is het geen goed idee om bij elke hosting offer een SLA required te maken , misschien één voor datacenter en één voor netwerk ...

nu wordt er gegoocheld wordt met allerhande uptime claims

voor de leken : een SLA of Service Level Agreement is een bepaling die aanduid hoeveel werk een hoster gestoken heeft om een hoge uptime te garanderen. Als je ergens in je infrastructuur een "single point of failure" hebt kan je geen SLA van 100% claimen.

er kan misschien een lijst gemaakt worden van reeele SLA van de verschillende datacenters ...

Wacht even, dat is niet waar een SLA voor bedoeld is. Dit is puur om aan een klant welke een SLA afneemt, bepaalde garanties te verstrekken. Sommige bedrijven geven automatisch SLA's af, andere doen dit standaard niet.

Een SLA beschrijft niet in alle gevallen hoe een netwerk of datacentrum in elkaar zit. Vaak beschrijft het wel wat de escalatie tijden zijn, welke niveau's er zijn, en welke garanties eraan hangen bijvoorbeeld.

Bovendien kun je natuurlijk wel een SLA afgeven met hogere percentages als je inkoop (of zwakke schakel(s). In een SLA geef je dan aan wat de compensatie is voor het niet halen van je SLA. Vaak is dat restitutie van het betaalde bedrag, maar je kunt natuurlijk ook andere (hogere) compensatie aanbieden, of de mogelijkheid om eerder het contract te ontbinden.

Ik ben wel met je eens dat het raar is dat er een SLA afgegeven kan worden met niet-reeele garanties voor uptime. Als afnemer moet je je m.i. dan ook niet blindstaren op een SLA. Wat heb je immers aan een SLA met 100% restitutie van je maandbedrag voor een rack (zeg: 1200 euro) als de schade voor jou als afnemer veel hoger ligt. Het is dan ook veel belangrijker WIE die garantie afgeeft, en met welke voorwaarden. Vertrouwen en een goede communicatie met je leverancier is denk ik veel belangrijker!

Oorspronkelijk geplaatst door EWMS

Bovendien kun je natuurlijk wel een SLA afgeven met hogere percentages als je inkoop (of zwakke schakel(s). In een SLA geef je dan aan wat de compensatie is voor het niet halen van je SLA. Vaak is dat restitutie van het betaalde bedrag, maar je kunt natuurlijk ook andere (hogere) compensatie aanbieden, of de mogelijkheid om eerder het contract te ontbinden.

Bovenstaande ben ik het mee eens maar het gros wat hier rondloopt denkt het volgende
SLA als ik meer dan 3 dagen offline ben kan ik xx.xxx euros claimen

voorbeeld
Als ze 250 euro betalen per jaar eisen ze ook 250 euro en de schade terug.

Ik ben wel met je eens dat het raar is dat er een SLA afgegeven kan worden met niet-reeele garanties voor uptime. Als afnemer moet je je m.i. dan ook niet blindstaren op een SLA.

Uptime zegt tegenwoordig niets:
Voorbeeld je server kan doordraaien (uptime op stroom)
Maar als het netwerk faalt heb je nog steeds een halve downtime
Klinkt raar maar toch hebben meerdere mensen dit of andersom meegemaakt.

Wat heb je immers aan een SLA met 100% restitutie van je maandbedrag voor een rack (zeg: 1200 euro) als de schade voor jou als afnemer veel hoger ligt. Het is dan ook veel belangrijker WIE die garantie afgeeft, en met welke voorwaarden. Vertrouwen en een goede communicatie met je leverancier is denk ik veel belangrijker!

Ik denk dat niemand meer dan de maandelijkse kosten gaat retourneren bij
het falen van de uptime procedure, is niet meer dan logisch bij 1 downtime zou het bedrijf aan claims de volgende dag al falliet zijn.

Denk dat het beter is om te kijken naar SLA met daarin
Maximale tijd die er nodig is om herstel te bieden.

een uptime met schadevergoeding clausule heb je ook maar dan zit je niet in de webhosting
maar eerder in loadballanced oplossingen wat gemaakt is om niet te falen.

Lijkt mij dat je een uptime SLA biedt op de beschikbaarheid van de dienst, of de oorzaak nou netwerk, stroom of de stand van de maan is doet er niet toe.
Dan zit je altijd nog met het punt van onderhoud. Valt dit wel of niet binnen de uptime garantie? Dan moet je ook weer nadenken over wanneer onderhoud mag plaatsvinden, en wanneer het buiten de standaard vensters zit, valt het dan onder de uptime garantie?

Onderhoud moet gewoon uitgevoerd kunnen worden zonder je uptime
om zeep te helpen

in geval van stroom (met A en B feed)
onderhoud aan de A feed terwijl de server naar de B feed overgaan

in geval van netwerk (minimaal 3 uplinks en redundante routers)
1 uplink uit je router de rest van het verkeer moet over de andere uplinks kunnen gaan

Het is allemaal mogelijk maar je ziet vaak dat de klant NIET bereid is hiervoor te betalen.

Onderhoud mag dus gewoon tussentijds gebeuren maar mag GEEN SPOF zijn
want dan zit er iets tussen de SLA niet goed.
Human Errors kunnen uiteraard altijd voorkomen hier is geen garantie op.

Oorspronkelijk geplaatst door Phu

Ik denk dat niemand meer dan de maandelijkse kosten gaat retourneren bij
het falen van de uptime procedure, is niet meer dan logisch bij 1 downtime zou het bedrijf aan claims de volgende dag al falliet zijn.

Denk dat het beter is om te kijken naar SLA met daarin
Maximale tijd die er nodig is om herstel te bieden.

een uptime met schadevergoeding clausule heb je ook maar dan zit je niet in de webhosting
maar eerder in loadballanced oplossingen wat gemaakt is om niet te falen.

Dat is ook precies wat ik wilde zeggen. Maar ook de maximale hersteltijd is natuurlijk niet echt een harde garantie. Het kost de aanbieder hooguit de prijs die ze rekenen voor hun dienst.

Veel belangrijker is het om vertrouwen te hebben in een bedrijf, gebaseerd op bijvoorbeeld ervaringen (van anderen), historische uptime, kwaliteit van de infrastructuur/techniek en reputatie, waarbij ze hun inspanningen bovendien nog vastleggen in een SLA.

Een extreem voorbeeld is een SLA voor een (shared) webhostingaccountje van 'n paar tientjes per maand, waarop je een webshop gaat hosten (bedrijfskritische applicatie). Je hebt dan weinig aan de financiele compensatie als je door downtime een hoop omzet mist. Maar zelfs bij managed server van honderden euro's per maand heb je dat effect. Je afhankelijkheid van de dienst is veel groter. Niemand zit dan te wachten op compensatie! Je wil gewoon dat 't spul werkt.

En natuurlijk is een SLA belangrijk. Het geeft een handvat met harde afspraken waarop je een aanbieder kan afrekenen. Ik vind het alleen niet het belangrijkste aspect bij de selectie van je leverancier. Ik denk dat je eerst een aanbieder zou moeten zoeken die je de juiste (technische en bedrijfskundige) oplossing voor je probleem kan bieden. Daarna maak of bezegel je met zo'n partij de leverafspraken in een SLA.

Oorspronkelijk geplaatst door gjtje

of de oorzaak nou netwerk, stroom of de stand van de maan is doet er niet toe.

Dat is maar net hoe je het bekijkt. Netwerkdowntime is natuurlijk erg; een stroomonderbreking zorg (potentieel) ook nog eens voor hardwareschade! In sommige DC's is het zelf plaatsen van UPS'en e.d. niet toegestaan. Je zou maar naar het DC moeten om defecte hardware te vervangen. Je zult dan altijd zien dat net dat onderdeel niet op voorraad is etc etc. Heel gek is het dus niet om daar onderscheid in te maken.

Onderhoud telt niet mee voor je SLA.

Je hoort je onderhoud dan ook wel correct te plannen en uit te voeren.
Ik denk dat elke zichzelf respecterende isp wel contractueel heeft vastgelegd dat geplande werken bij voorkeur op een bepaald tijdstip plaatsvinden (bijv. zaterdag tussen00u00 en 04u00).
Als daarnaast alle klanten nog gecontacteerd worden, zie ik er helemaal geen probleem in. Dit is ook een van de redenen dat bij mijn werkgever geplande werken met een onderbreking voor klanten, minstens 1 maand op voorhand dient aangekondigd te worden.

Of onderhoud wel of niet telt hangt volgens mij volledig af van de algemene voorwaarden. Ook of netwerk al dan niet inbegrepen is in de SLA en de bepaling op welke periode de garantie geldig is. Downtime van 99.98% per maand hoeft niet lang te zijn. Als dit een garantie is op jaarbasis dan ligt dit weer net totaal anders. 99.98% op een jaar is lang.

Oorspronkelijk geplaatst door roelp

Onderhoud telt niet mee voor je SLA.

Je hoort je onderhoud dan ook wel correct te plannen en uit te voeren.
Ik denk dat elke zichzelf respecterende isp wel contractueel heeft vastgelegd dat geplande werken bij voorkeur op een bepaald tijdstip plaatsvinden (bijv. zaterdag tussen00u00 en 04u00).
Als daarnaast alle klanten nog gecontacteerd worden, zie ik er helemaal geen probleem in. Dit is ook een van de redenen dat bij mijn werkgever geplande werken met een onderbreking voor klanten, minstens 1 maand op voorhand dient aangekondigd te worden.

Echt wel het staat toch niet voor niet in je Service Level Agreement
vaak een van de volgende punten

Om u zo goed mogelijk van dienst te zijn kan het mogelijk zijn dat er noodonderhoud gepleegd dient te worden dit word maximaal xx aantal uren van te voren aangekondigd

Dus jij hebt SLA's waarin niets over geplande of ongeplande onderhoud staat ?
Lekkere SLA heb je dan

Oorspronkelijk geplaatst door digi128pci

Of onderhoud wel of niet telt hangt volgens mij volledig af van de algemene voorwaarden. Ook of netwerk al dan niet inbegrepen is in de SLA en de bepaling op welke periode de garantie geldig is. Downtime van 99.98% per maand hoeft niet lang te zijn. Als dit een garantie is op jaarbasis dan ligt dit weer net totaal anders. 99.98% op een jaar is lang.

Denk dat u uptime bedoelt en downtime van 0.02 % dan
Zou niet leuk zijn om maar paar uur per maand online te zijn
of een paar dagen per jaar online.

@Phu
Ik bedoel dat onderhoud tijdens een maintenance window niet meetelt om in aanmerking te komen voor vergoedingen voor het niet halen van een bepaalde uptime.

Om de goede werking van je netwerk te kunnen garanderen, dien je ook een onderscheid te maken in normaal onderhoud, en noodonderhoud. Ik verkies nog steeds een gecontroleerde downtime boven een echte panne die veel langer aansleept omdat je niet eerder actie ondernomen hebt.

Je kan nog proberen alles redundant uit te voeren, op een bepaald ogenblik zul je toch eens onderhoud moeten uitvoeren waardoor klanten geaffecteerd worden. Het belangrijkste is volgens mij nog steeds om je klanten ruim op voorhand te verwittigen via een duidelijke communicatie.

Oorspronkelijk geplaatst door filvdg

Na de downtime van enkele maanden geleden van LCL in belgie viel me op dat men bij LCL altijd sprak van het enige datacenter in Belgie met een 0% downtime garantie maar dat LCL in een artikel (http://www.knack.be/nieuws/technolog...icle15379.html) bevestigd dat ze maar een uptime garanderen van 99,98% op hun datacenter. Nog meer valt op dat er op de huidige site van LCL nergens nog enige referentie naar een SLA wordt gemaakt.

Het valt me ook op dat heel wat hosters bij LCL een hogere SLA claimen dan deze 99,98% van hun datacenter wat onmogelijk is , je SLA is zo hoog als de SLA van je zwakste schakel. Ik neem aan dat in nederland ook deze problemen voordoen.
Is het geen goed idee om bij elke hosting offer een SLA required te maken , misschien één voor datacenter en één voor netwerk ...

nu wordt er gegoocheld wordt met allerhande uptime claims

voor de leken : een SLA of Service Level Agreement is een bepaling die aanduid hoeveel werk een hoster gestoken heeft om een hoge uptime te garanderen. Als je ergens in je infrastructuur een "single point of failure" hebt kan je geen SLA van 100% claimen.

er kan misschien een lijst gemaakt worden van reeele SLA van de verschillende datacenters ...

Uptime garanties staan in je contract alsook de compensatie hiervoor.

LCL sprak ook niet van een 0% downtime garantie maar een "zero downtime REPUTATION"

Dewelke ze voor ons nog steeds hebben aangezien wij geen hinder hebben ondervonden van deze storing.

De inhoud van de contracten van LCL zijn geheim dus wij kunnen niets publiceren over de garanties en compensaties van LCL die ze in hun contracten geven.

Je kan als provider een hogere garantie (bv 99.99%) maar als je dan 99.98% uptime maar haalt kan je niets claimen van het DC en moet je zelf opdraaien voor die compensatie. Het is niet slim om het te doen maar zeker mogelijk.

Het betreft hier de eerste (gedeeltelijke!) stroomstoring in 7 jaar, alles is er dubbel redundant, de oorzaak van die panne kan niet meer voorkomen door de maatregelen die LCL genomen heeft.

Is het niet veel belangrijker om in een SLA aan te geven wat de verwerkingstijd is om een storing te verhelpen? Een storing kan voorkomen, bij de beste zelfs. Het belangrijkste is dat deze zo snel mogelijk verholpen is. Wat er in een SLA echt hoort te staan is als volgt:

- Indien storing
- Welke maatregelen worden er genomen?
* Is er een plek waar mensen kunnen vinden wat de storing betreft?
* Is er een storingsnummer voor de klant?
- Storing moet binnen ** of zelfs * uur worden opgelost. Wat indien dit niet wordt behaald?

Wat je kan doen als de storing niet wordt behaald, is aangeven in de SLA dat je een derde partij inschakelt om het probleem te verhelpen of dat de diensten ergens anders online worden gebracht.

Een financiele compensatie is 1 van de dingen welke erg onbelangrijk zijn. Het is de bedoeling dat de dienst zo snel mogelijk online komt en in de SLA wordt beschreven welke maatregelen je neemt om de dienst zo snel mogelijk weer online te brengen.

Definieer eerst eens uptime?

Juist, dat is lastig, daarom spreken wij vaak van een Technische beschikbaarheid in plaats van een uptime.

Wat we bijvoorbeeld aan klanten geven: http://crew.pcextreme.nl/~wido/doc/t...hikaarheid.pdf

Daar moet je denk ik ook met een DC naar gekeken worden, wat is up? Als de stroom op feed A staat of moeten beide feeds het doen?