Serviceniveauaftale (SLA) — udkast

Siden beskriver de serviceniveauer, SIAX agter at forpligte sig til. Den er offentliggjort som et udkast: niveauerne, kreditniveauerne og definitionerne nedenfor skal godkendes af virksomheden og indføres i kundeaftalen, før de er bindende. Indtil da er teksten en beskrivelse af, hvordan vi arbejder — ikke et vilkår, du kan påberåbe dig.

Vi offentliggør udkastet i stedet for at vente, til alt er fastlagt, fordi et SLA, som ingen har fået læst og gjort indsigelse mod, sjældent bliver godt. Har du brug for et underskrevet SLA, før du flytter ind, går vi punkterne igennem én for én og underskriver det, der faktisk gælder for din opsætning.

SLA'et omfatter betalende abonnementer. Gratisniveauer, åbne prøveperioder og funktioner mærket beta er ikke omfattet — det er de ti gratis kontroller i Overvågning heller ikke.

SIAX har ikke ISO 27001, SOC 2 eller PCI-DSS. Et SLA er en tilgængelighedsforpligtelse, ikke en certificering, og de to må ikke blandes sammen. Det, vi i stedet kan vise, er GDPR-efterlevelse, at data ligger i EU, og at stakken er open source og dermed mulig at gennemgå.

• Åbent punkt: skal loftet for kreditter ligge på 50 % af månedsafgiften eller højere?
• Åbent punkt: skal forringet svartid uden afbrud tælle som nedetid, og i så fald ved hvilken tærskel?
• Åbent punkt: skal vagtordning uden for kontortid tilbydes som tilvalg, og til hvilken pris?
• Åbent punkt: hvor offentliggøres måledata, så du kan kontrollere vores tal uden at spørge os?
• Åbent punkt: hvilke niveauer skal gælde for Backup, Domæne, Overvågning og AI-gateway, som mangler en forpligtelse i dette udkast?

Forpligtelsen gælder pr. tjenesteinstans og kalendermåned. Har du tre apps og to databaser, måles fem separate forpligtelser, og et niveau, der ikke opfyldes på én instans, påvirker ikke de øvrige.

App Hosting, Managed Postgres, Objektlagring, E-mail samt Git og CI ligger på 99,9 %. De kører på delt, redundant infrastruktur, hvor vi kan flytte en last til en anden node uden fysisk indgreb.

VPS og dedikeret server ligger på 99,5 %. Årsagen er hardware: går en disk, en strømforsyning eller et bundkort i stykker, kræves der en fysisk udskiftning i datacentret, og det tager timer snarere end minutter. Vi lover hellere 99,5 % og holder det end 99,9 %, som forudsætter, at ingen hardware går i stykker.

Backup, Domæne, Overvågning og AI-gateway mangler en oppetidsforpligtelse i dette udkast. For domæner styres selve driften af registeret, ikke af os. For AI-gateway kan vi rimeligvis forpligte os til selve gatewayens tilgængelighed, men ikke de underliggende modelleverandørers — hvordan det skal formuleres, er et af de punkter, der stadig mangler.

• App Hosting (fra 99 kr/md.): 99,9 % — cirka 43 minutters nedetid i en 30-dages måned
• Managed Postgres (fra 89 kr/md.): 99,9 % på forbindelse og forespørgselssvar
• Objektlagring (fra 25 kr/100 GB): 99,9 % på API'et for læsning og skrivning
• E-mail (fra 19 kr/postkasse): 99,9 % på SMTP, IMAP og webgrænseflade
• Git og CI (fra 199 kr for 10 brugere): 99,9 % på git- og webtjenesten; kø-tid for buildjobs er ikke omfattet
• VPS (fra 59 kr/md.): 99,5 % — cirka 3 timer og 36 minutters nedetid i en 30-dages måned
• Dedikeret server (fra 890 kr/md.): 99,5 %
• Backup, Domæne, Overvågning og AI-gateway: ingen oppetidsforpligtelse i udkastet

Oppetid måles fra eksterne kontrolpunkter uden for vores egen infrastruktur, hos en anden leverandør og i et andet netværk. Måler man indefra sit eget datacenter, måler man kun, at datacentret fungerer — hvilket er netop det spørgsmål, der er åbent under et nedbrud.

En tjeneste tælles som nede, når den ikke svarer korrekt på sin protokolspecifikke kontrol. HTTP-svar i 5xx-serien tæller som nedetid; 4xx gør ikke, da de som regel er svar på fejlagtige kald. Nedetiden starter ved den første mislykkede kontrol i en serie, der bekræftes af mindst to punkter, og slutter ved den første, der lykkes.

Oppetiden for måneden beregnes som (minutter i måneden minus nedetidsminutter) divideret med minutter i måneden, afrundet til to decimaler. Måneden er kalendermåned i svensk tid (CET/CEST). To decimaler er bevidst: en afrunding til én decimal ville gøre 99,87 % til en opfyldt forpligtelse.

I dette udkast tælles kun afbrud, ikke forringet ydeevne. En database, der svarer på fem sekunder i stedet for halvtreds millisekunder, er i praksis ubrugelig, men tæller ikke som nedetid. Det er et reelt hul, og det står med blandt de åbne punkter.

• Kontrol hvert 60. sekund fra mindst to uafhængige eksterne punkter
• App Hosting og Git: HTTP-kald mod et kendt endpoint
• Postgres: forbindelse plus en simpel forespørgsel
• Objektlagring: skrivning og læsning af et testobjekt via API'et
• E-mail: SMTP-håndtryk og IMAP-login
• VPS og dedikeret server: netværkssvar mod instansens IP, ikke mod din applikation i den
• Nedetid bekræftes af to kontroller i træk, før uret begynder at tælle

Hvis vi ikke lever op til en forpligtelse i en kalendermåned, har du ret til en kredit på afgiften for den berørte tjeneste. Kreditten beregnes på den pågældende tjenestes månedsafgift, ikke på hele fakturaen, og kun ét niveau anvendes pr. tjeneste og måned — det højeste, der udløses.

For VPS og dedikeret server, hvor forpligtelsen er 99,5 %, udløses det første niveau, når oppetiden kommer under 99,5 %. De lavere niveauer er de samme for alle tjenester. Den konstruktion er et skrivebordsvalg i udkastet og en af de ting, der bør gennemgås, før aftalen fastlægges.

I udkastet er kreditten den eneste konsekvens ved manglende oppetid. Det er branchestandard, men det er også en begrænsning, det er værd at sige ligeud: kreditten kommer sjældent i nærheden af, hvad et nedbrud koster dig. Har du en virksomhed, hvor en times stilstand koster mere end en månedsafgift, er det rigtige svar redundans på tværs af to lokationer, ikke et større SLA. Den samtale tager vi hellere end at skrue kreditprocenten op.

• Under forpligtelsen, men mindst 99,0 %: 10 % af månedsafgiften
• Under 99,0 %, men mindst 95,0 %: 25 % af månedsafgiften
• Under 95,0 %: 50 % af månedsafgiften
• Kun det højest udløste niveau anvendes pr. tjeneste og måned
• Kreditter for flere tjenester samme måned lægges sammen, men overstiger aldrig 50 % af afgiften for en enkelt tjeneste
• Kredit gives som fradrag på fakturaen, ikke som kontant tilbagebetaling

Et SLA, der ikke skriver sine undtagelser ud, er ikke ærligt. Følgende perioder regnes ikke med i nedetiden.

De to undtagelser, der oftest bliver til diskussion, er kundens egen kode og overbelastningsangreb mod kundens applikation. Hvis din app crasher på grund af manglende hukommelse, et certifikat udløber, eller en deploy tager tjenesten ned, så fungerer platformen — og det er platformen, vi forpligter os til. Ved DDoS mod din applikation gør vi, hvad vi kan, for at afbøde det, men vi lover ikke, at det lykkes.

Akut vedligeholdelse, som vi ikke når at varsle 72 timer i forvejen, er ikke undtaget. Skal vi patche et kritisk sikkerhedshul med kort varsel, og det medfører afbrud, tæller det som nedetid. At kalde akutte indgreb for planlagt vedligeholdelse er præcis det slags smuthul, der gør SLA'er værdiløse.

• Planlagt vedligeholdelse, der er varslet mindst 72 timer i forvejen, og som gennemføres inden for det varslede vindue
• Force majeure: naturbegivenheder, krig, arbejdsmarkedskonflikt, omfattende el- eller transitafbrud, myndighedsbeslutninger
• Fejl i kundens egen kode, konfiguration, container-image, ressourcetildeling eller udløbne certifikater
• Overbelastningsangreb eller trafiktoppe rettet mod kundens egen applikation
• Afhængigheder, kunden selv har valgt uden for vores kontrol: eksterne API'er, DNS hos anden operatør, tredjepartstjenester
• Nedlukning på grund af ubetalt faktura eller brud på brugervilkårene
• Indgreb udført på kundens anmodning, for eksempel gendannelse eller migrering
• Gratisniveauer, prøveperioder og betafunktioner

Kredit skal anmodes om inden for 30 dage fra udgangen af den måned, hvor afbruddet skete. Anmodningen sendes via support og skal indeholde tjeneste, instansnavn, dato og tidsinterval samt hvad du observerede. Har du egne måledata eller logs, gør det det lettere, men det er ikke et krav — vi afstemmer altid med vores egen måling.

Vi svarer på en kreditanmodning inden for ti arbejdsdage. Godkendt kredit trækkes fra på næste faktura. Afsluttes abonnementet, før kreditten er nået at blive brugt, afregnes den kontant på slutfakturaen.

Kreditten trækkes ikke automatisk. Vi ville hellere have haft automatisk kreditering, men det kræver, at målingen pr. kundeinstans er fuldt automatiseret og afstemt med faktureringen. Indtil det er på plads, er kredit noget, du skal anmode om, og det siger vi hellere ligeud, end vi lader dig tro, at systemet klarer det for dig.

• Tidsfrist: 30 dage fra månedens udgang
• Kanal: supportsag hos SIAX
• Angiv: tjeneste, instans, dato og tid samt hvad du så
• Svar fra os: inden for ti arbejdsdage
• Udbetaling: fradrag på næste faktura, kontant afregning på slutfaktura

Svartiden er tiden til det første kvalificerede svar fra en person, der kan handle i sagen, ikke tiden til et løst problem. Ingen leverandør kan love en løsningstid for en fejl, den ikke har set endnu, og et SLA, der gør det, regner med, at du ikke læser det.

Svartiderne gælder kontortid, mandag til fredag 09:00–17:00 svensk tid, med undtagelse af svenske helligdage. En sag, der registreres uden for kontortid, får sit ur startet, når næste kontordag begynder. Vi har i dag ikke døgnvagt i standardaftalen, og det skal stå her frem for at blive opdaget klokken tre om natten. Har din virksomhed brug for svar uden for kontortid, er det et tilvalg, vi kan tale om separat.

Alvorlighedsgraden sættes af dig, når du opretter sagen. Vi kan justere den, hvis vurderingen tydeligvis er forkert, og i så fald skriver vi hvorfor.

• Kritisk: produktionstjeneste er utilgængelig, eller data risikerer at gå tabt, ingen kendt workaround — svar inden for 2 timer
• Høj: væsentlig funktion er nedsat, men driften kan fortsætte med en workaround — svar inden for 8 timer
• Normal: spørgsmål, konfiguration, planlægning, ændringsønsker — svar inden for 1 arbejdsdag
• Kontortid: mandag–fredag 09:00–17:00 CET/CEST, eksklusive svenske helligdage
• Det er supportsagen, der tæller for uret, selvom chat nogle gange går hurtigere

Vedligeholdelse, der kan medføre afbrud, lægges i vinduet tirsdag til torsdag 23:00–05:00 svensk tid og varsles mindst 72 timer i forvejen til de tekniske kontakter på kontoen samt i statuskanalen. Varslingen angiver, hvilken tjeneste det gælder, hvad der udføres, og det længste afbrud vi regner med.

Det meste vedligeholdelse på delt infrastruktur sker rullende og uden afbrud: vi flytter last til andre noder, opdaterer og flytter tilbage. På VPS og dedikeret server er det ikke altid muligt, da en kerneopdatering eller en hardwareudskiftning kræver genstart. Der skal du regne med et fåtal varslede genstarter om året.

Vi kan sjældent flytte et vedligeholdelsesvindue for en enkelt kunde, men vi kan som regel styre, i hvilken rækkefølge noder tages. Har du en periode, hvor afbrud er særligt uheldigt — regnskabsafslutning, kampagne, sæsontop — så sig til i forvejen, så planlægger vi uden om den, hvis det kan lade sig gøre. Akut sikkerhedsvedligeholdelse kan være nødt til at ske med kortere varsel, og medfører det afbrud, tæller det som nedetid i henhold til afsnittet ovenfor.

• Vindue: tirsdag–torsdag 23:00–05:00 CET/CEST
• Varsling: mindst 72 timer i forvejen, til tekniske kontakter og statuskanal
• Frekvens: regn med et fåtal vinduer pr. kvartal, de fleste uden afbrud
• Rullende opdateringer på delt infrastruktur, varslede genstarter på VPS og dedikeret server
• Akut sikkerhedsvedligeholdelse kan ske med kortere varsel og er ikke undtaget fra nedetidsberegningen