Tjenestenivåavtale (SLA) — utkast

Siden beskriver de tjenestenivåene SIAX har til hensikt å forplikte seg til. Den er publisert som et utkast: nivåene, kredittnivåene og definisjonene under skal godkjennes av selskapet og føres inn i kundeavtalen før de er bindende. Frem til da er teksten en beskrivelse av hvordan vi jobber, ikke et vilkår du kan påberope deg.

Vi publiserer utkastet i stedet for å vente til alt er fastsatt, fordi et SLA som ingen har fått lese og komme med innvendinger til, sjelden blir bra. Trenger du et signert SLA før du flytter inn, går vi gjennom punktene én og én og signerer det som faktisk gjelder for din oppsetning.

SLA-en omfatter betalende abonnement. Gratisnivåer, åpne prøveperioder og funksjoner merket beta omfattes ikke — heller ikke de ti kostnadsfrie kontrollene i Overvåking.

SIAX har ikke ISO 27001, SOC 2 eller PCI-DSS. Et SLA er en tilgjengelighetsforpliktelse, ikke en sertifisering, og de to skal ikke blandes sammen. Det vi kan vise i stedet, er GDPR-etterlevelse, at data ligger i EU, og at stacken er åpen kildekode og dermed mulig å granske.

• Åpent punkt: skal taket for kreditter ligge på 50 % av månedsavgiften eller høyere?
• Åpent punkt: skal forringet responstid uten avbrudd regnes som nedetid, og i så fall ved hvilken terskel?
• Åpent punkt: skal vakttjeneste utenfor kontortid tilbys som tilleggsvalg, og til hvilken pris?
• Åpent punkt: hvor publiseres måledata slik at du kan kontrollere tallene våre uten å spørre oss?
• Åpent punkt: hvilke nivåer skal gjelde for Backup, Domene, Overvåking og AI-gateway, som mangler forpliktelse i dette utkastet?

Forpliktelsen gjelder per tjenesteinstans og kalendermåned. Har du tre apper og to databaser, måles fem separate forpliktelser, og et nivå som ikke nås på én instans, påvirker ikke de andre.

App Hosting, Managed Postgres, Objektlagring, E-post samt Git og CI ligger på 99,9 %. De kjører på delt, redundant infrastruktur der vi kan flytte en last til en annen node uten fysisk inngrep.

VPS og dedikert server ligger på 99,5 %. Grunnen er maskinvare: går en disk, en strømforsyning eller et hovedkort i stykker, kreves et fysisk bytte i datahallen, og det tar timer snarere enn minutter. Vi lover heller 99,5 % og holder det, enn 99,9 % som forutsetter at ingen maskinvare svikter.

Backup, Domene, Overvåking og AI-gateway mangler oppetidsforpliktelse i dette utkastet. For domener styres selve driften av registeret, ikke av oss. For AI-gateway kan vi rimeligvis forplikte oss til selve gatewayens tilgjengelighet, men ikke de underliggende modelleverandørenes — hvordan det skal formuleres, er ett av punktene som gjenstår.

• App Hosting (fra 99 kr/mnd): 99,9 % — rundt 43 minutters nedetid i en 30-dagersmåned
• Managed Postgres (fra 89 kr/mnd): 99,9 % på tilkobling og spørresvar
• Objektlagring (fra 25 kr/100 GB): 99,9 % på API-et for lesing og skriving
• E-post (fra 19 kr/postkasse): 99,9 % på SMTP, IMAP og webgrensesnitt
• Git og CI (fra 199 kr for 10 brukere): 99,9 % på git- og webtjenesten; køtid for byggjobber omfattes ikke
• VPS (fra 59 kr/mnd): 99,5 % — rundt 3 timer og 36 minutters nedetid i en 30-dagersmåned
• Dedikert server (fra 890 kr/mnd): 99,5 %
• Backup, Domene, Overvåking og AI-gateway: ingen oppetidsforpliktelse i utkastet

Oppetid måles fra eksterne kontrollpunkter utenfor vår egen infrastruktur, hos en annen leverandør og i et annet nett. Måler man innenfra sitt eget datasenter, måler man bare at datasenteret fungerer, og det er akkurat det spørsmålet som er åpent under et avbrudd.

En tjeneste regnes som nede når den ikke svarer korrekt på sin protokollspesifikke kontroll. HTTP-svar i 5xx-serien regnes som nedetid; 4xx gjør det ikke, siden de som regel er svar på feilaktige kall. Nedetiden starter ved den første mislykkede kontrollen i en serie som bekreftes av minst to punkter, og slutter ved den første vellykkede.

Oppetiden for måneden beregnes som (minutter i måneden minus nedetidsminutter) delt på minutter i måneden, avrundet til to desimaler. Måneden er kalendermåned i svensk tid (CET/CEST). To desimaler er bevisst: en avrunding til én desimal ville gjort 99,87 % til en oppfylt forpliktelse.

I dette utkastet regnes bare avbrudd, ikke forringet ytelse. En database som svarer på fem sekunder i stedet for femti millisekunder, er i praksis ubrukelig, men regnes ikke som nedetid. Det er et reelt hull, og det står med blant de åpne punktene.

• Kontroll hvert 60. sekund fra minst to uavhengige eksterne punkter
• App Hosting og Git: HTTP-kall mot et kjent endepunkt
• Postgres: tilkobling pluss en enkel spørring
• Objektlagring: skriving og lesing av et testobjekt via API-et
• E-post: SMTP-håndtrykk og IMAP-innlogging
• VPS og dedikert server: nettsvar mot instansens IP, ikke mot applikasjonen din i den
• Nedetid bekreftes av to kontroller på rad før klokken begynner å telle

Klarer vi ikke å oppfylle en forpliktelse i løpet av en kalendermåned, har du rett til en kreditt på avgiften for den berørte tjenesten. Kreditten beregnes ut fra den aktuelle tjenestens månedsavgift, ikke hele fakturaen, og bare ett nivå brukes per tjeneste og måned — det høyeste som utløses.

For VPS og dedikert server, der forpliktelsen er 99,5 %, utløses det første nivået når oppetiden er under 99,5 %. De lavere nivåene er de samme for alle tjenester. Den konstruksjonen er et skrivebordsvalg i utkastet og en av tingene som bør gjennomgås før avtalen fastsettes.

I utkastet er kreditten den eneste konsekvensen ved manglende oppetid. Det er bransjestandard, men det er også en begrensning som er verdt å si rett ut: kreditten er sjelden i nærheten av hva et avbrudd koster deg. Har du en virksomhet der en times nedetid koster mer enn en månedsavgift, er riktig svar redundans over to steder, ikke et større SLA. Den samtalen tar vi heller enn å skrive opp kredittprosenten.

• Under forpliktelsen, men minst 99,0 %: 10 % av månedsavgiften
• Under 99,0 %, men minst 95,0 %: 25 % av månedsavgiften
• Under 95,0 %: 50 % av månedsavgiften
• Bare det høyeste utløste nivået brukes per tjeneste og måned
• Kreditter for flere tjenester samme måned summeres, men overstiger aldri 50 % av avgiften for én enkelt tjeneste
• Kreditt gis som fradrag på faktura, ikke som kontant tilbakebetaling

Et SLA som ikke skriver ut sine unntak, er ikke ærlig. Følgende perioder regnes ikke med i nedetiden.

De to unntakene som oftest blir en diskusjon, er kundens egen kode og overbelastningsangrep mot kundens applikasjon. Hvis appen din krasjer på grunn av tomt minne, et sertifikat utløper eller en deploy tar ned tjenesten, så fungerer plattformen — og det er plattformen vi forplikter oss til. Ved DDoS mot applikasjonen din gjør vi det vi kan for å begrense skaden, men vi lover ikke å lykkes.

Akutt vedlikehold som vi ikke rekker å varsle 72 timer i forveien, er ikke unntatt. Må vi patche et kritisk sikkerhetshull med kort varsel og det forårsaker avbrudd, regnes det som nedetid. Å kalle akuttiltak for planlagt vedlikehold er nettopp det slags smutthull som gjør SLA-er verdiløse.

• Planlagt vedlikehold som er varslet minst 72 timer i forveien og gjennomføres innenfor det varslede vinduet
• Force majeure: naturhendelser, krig, arbeidskonflikt, omfattende strøm- eller transittavbrudd, myndighetsvedtak
• Feil i kundens egen kode, konfigurasjon, container-image, ressurstildeling eller utløpte sertifikater
• Overbelastningsangrep eller trafikktopper rettet mot kundens egen applikasjon
• Avhengigheter kunden selv har valgt, utenfor vår kontroll: eksterne API-er, DNS hos annen operatør, tredjepartstjenester
• Avstengning på grunn av ubetalt faktura eller brudd på brukervilkårene
• Tiltak utført på kundens forespørsel, for eksempel gjenoppretting eller migrering
• Gratisnivåer, prøveperioder og betafunksjoner

Kreditt bes om innen 30 dager fra utgangen av måneden avbruddet inntraff. Forespørselen sendes via support og skal inneholde tjeneste, instansnavn, dato og tidsintervall samt hva du observerte. Har du egne måledata eller logger, gjør det saken enklere, men det er ikke et krav — vi stemmer alltid av mot vår egen måling.

Vi svarer på en kredittforespørsel innen ti arbeidsdager. Godkjent kreditt trekkes fra på neste faktura. Avsluttes abonnementet før kreditten er brukt, gjøres den opp kontant på sluttfakturaen.

Kreditten trekkes ikke automatisk. Vi skulle helst hatt automatisk kreditering, men det krever at målingen per kundeinstans er helt automatisert og avstemt mot faktureringen. Til det er på plass, er kreditt noe du ber om, og vi sier det heller rett ut enn å la deg tro at systemet ordner det for deg.

• Tidsfrist: 30 dager fra utgangen av måneden
• Kanal: supportsak hos SIAX
• Oppgi: tjeneste, instans, dato og tid, samt hva du observerte
• Svar fra oss: innen ti arbeidsdager
• Utbetaling: fradrag på neste faktura, kontant oppgjør på sluttfaktura

Responstiden er tiden til første kvalifiserte svar fra en person som kan handle i saken, ikke tiden til løst problem. Ingen leverandør kan love en løsningstid for en feil den ikke har sett ennå, og et SLA som gjør det, regner med at du ikke leser det.

Responstidene gjelder kontortid, mandag til fredag 09:00–17:00 svensk tid, med unntak for svenske helligdager. En sak som registreres utenfor kontortid, får klokken sin startet når neste kontordag begynner. Vi har i dag ikke døgnbemannet vakttjeneste i standardavtalen, og det skal stå her fremfor å oppdages klokken tre om natten. Trenger virksomheten din svar utenfor kontortid, er det et tilleggsvalg vi kan diskutere separat.

Alvorlighetsgraden settes av deg når du oppretter saken. Vi kan justere den hvis vurderingen er åpenbart feil, og i så fall skriver vi hvorfor.

• Kritisk: produksjonstjeneste er utilgjengelig eller data risikerer å gå tapt, ingen kjent omgåelse — svar innen 2 timer
• Høy: vesentlig funksjon er nedsatt, men virksomheten kan fortsette med omgåelse — svar innen 8 timer
• Normal: spørsmål, konfigurasjon, planlegging, endringsønsker — svar innen 1 arbeidsdag
• Kontortid: mandag–fredag 09:00–17:00 CET/CEST, unntatt svenske helligdager
• Supportsaken er det som teller for klokken, selv om chat noen ganger går raskere

Vedlikehold som kan forårsake avbrudd, legges i vinduet tirsdag til torsdag 23:00–05:00 svensk tid og varsles minst 72 timer i forveien til de tekniske kontaktene på kontoen samt i statuskanalen. Varselet angir hvilken tjeneste det gjelder, hva som gjøres, og det lengste avbruddet vi regner med.

Det meste vedlikeholdet på delt infrastruktur skjer rullerende og uten avbrudd: vi flytter last til andre noder, oppdaterer og flytter tilbake. På VPS og dedikert server går det ikke alltid, siden en kjerneoppdatering eller et maskinvarebytte krever omstart. Der bør du regne med et fåtall varslede omstarter per år.

Vi kan sjelden flytte et vedlikeholdsvindu for en enkelt kunde, men vi kan som regel styre i hvilken rekkefølge noder tas. Har du en periode der avbrudd er spesielt uheldig — årsoppgjør, kampanje, sesongtopp — si fra i forveien, så planlegger vi rundt den hvis det lar seg gjøre. Akutt sikkerhetsvedlikehold kan måtte skje med kortere varsel, og forårsaker det avbrudd, regnes det som nedetid i henhold til avsnittet over.

• Vindu: tirsdag–torsdag 23:00–05:00 CET/CEST
• Varsel: minst 72 timer i forveien, til tekniske kontakter og statuskanal
• Frekvens: regn med et fåtall vinduer per kvartal, de fleste uten avbrudd
• Rullerende oppdateringer på delt infrastruktur, varslede omstarter på VPS og dedikert server
• Akutt sikkerhetsvedlikehold kan skje med kortere varsel og unntas ikke fra nedetidsberegningen