Tjänstenivåavtal (SLA) — utkast

Sidan beskriver de servicenivåer SIAX avser att åta sig. Den är publicerad som ett utkast: nivåerna, kreditnivåerna och definitionerna nedan ska godkännas av bolaget och föras in i kundavtalet innan de är bindande. Fram till dess är texten en beskrivning av hur vi arbetar, inte ett villkor du kan åberopa.

Vi publicerar utkastet i stället för att vänta tills allt är fastställt, eftersom ett SLA som ingen fått läsa och invända mot sällan blir bra. Behöver du ett påskrivet SLA innan du flyttar in går vi igenom punkterna en och en och skriver under det som faktiskt gäller för din uppsättning.

SLA:t omfattar betalande abonnemang. Gratisnivåer, öppna testperioder och funktioner märkta beta omfattas inte — inte heller de tio kostnadsfria kontrollerna i Övervakning.

SIAX har inte ISO 27001, SOC 2 eller PCI-DSS. Ett SLA är ett tillgänglighetsåtagande, inte en certifiering, och de två ska inte blandas ihop. Det vi kan visa i stället är GDPR-efterlevnad, att data ligger i EU och att stacken är öppen källkod och därmed möjlig att granska.

• Öppen punkt: ska taket för krediter ligga på 50 % av månadsavgiften eller högre?
• Öppen punkt: ska försämrad svarstid utan avbrott räknas som nertid, och i så fall vid vilken tröskel?
• Öppen punkt: ska jour utanför kontorstid erbjudas som tillval, och till vilket pris?
• Öppen punkt: var publiceras mätdata så att du kan kontrollera våra siffror utan att fråga oss?
• Öppen punkt: vilka nivåer ska gälla för Backup, Domän, Övervakning och AI-gateway, som saknar åtagande i det här utkastet?

Åtagandet gäller per tjänsteinstans och kalendermånad. Har du tre appar och två databaser mäts fem separata åtaganden, och en missad nivå på en instans påverkar inte de andra.

App Hosting, Managed Postgres, Objektlagring, E-post samt Git och CI ligger på 99,9 %. De körs på delad, redundant infrastruktur där vi kan flytta en last till en annan nod utan fysiskt ingrepp.

VPS och dedikerad server ligger på 99,5 %. Skälet är hårdvara: går en disk, ett nätaggregat eller ett moderkort sönder krävs ett fysiskt byte i datahallen, och det tar timmar snarare än minuter. Vi lovar hellre 99,5 % och håller det än 99,9 % som förutsätter att inget järn går sönder.

Backup, Domän, Övervakning och AI-gateway saknar uppetidsåtagande i det här utkastet. För domäner styrs själva driften av registryt, inte av oss. För AI-gateway kan vi rimligen åta oss gatewayens egen tillgänglighet men inte de underliggande modellleverantörernas — hur det ska formuleras är en av punkterna som återstår.

• App Hosting (från 99 kr/mån): 99,9 % — cirka 43 minuters nertid i en 30-dagarsmånad
• Managed Postgres (från 89 kr/mån): 99,9 % på anslutning och frågesvar
• Objektlagring (från 25 kr/100 GB): 99,9 % på API:t för läsning och skrivning
• E-post (från 19 kr/brevlåda): 99,9 % på SMTP, IMAP och webbgränssnitt
• Git och CI (från 199 kr för 10 användare): 99,9 % på git- och webbtjänsten; kötid för byggjobb omfattas inte
• VPS (från 59 kr/mån): 99,5 % — cirka 3 timmar och 36 minuters nertid i en 30-dagarsmånad
• Dedikerad server (från 890 kr/mån): 99,5 %
• Backup, Domän, Övervakning och AI-gateway: inget uppetidsåtagande i utkastet

Uppetid mäts från externa kontrollpunkter utanför vår egen infrastruktur, hos en annan leverantör och i ett annat nät. Mäter man inifrån sitt eget datacenter mäter man bara att datacentret fungerar, vilket är precis den fråga som är öppen under ett avbrott.

En tjänst räknas som nere när den inte svarar korrekt på sin protokollspecifika kontroll. HTTP-svar i 5xx-serien räknas som nertid; 4xx gör det inte, eftersom de i regel är svar på felaktiga anrop. Nertiden börjar vid den första misslyckade kontrollen i en serie som bekräftas av minst två punkter, och slutar vid den första lyckade.

Uppetiden för månaden beräknas som (minuter i månaden minus nertidsminuter) delat med minuter i månaden, avrundat till två decimaler. Månaden är kalendermånad i svensk tid (CET/CEST). Två decimaler är medvetet: en avrundning till en decimal skulle göra 99,87 % till ett uppfyllt åtagande.

I det här utkastet räknas endast avbrott, inte försämrad prestanda. En databas som svarar på fem sekunder i stället för femtio millisekunder är i praktiken oanvändbar men räknas inte som nertid. Det är en verklig lucka och den står med bland de öppna punkterna.

• Kontroll var 60:e sekund från minst två oberoende externa punkter
• App Hosting och Git: HTTP-anrop mot en känd slutpunkt
• Postgres: anslutning plus en enkel fråga
• Objektlagring: skrivning och läsning av ett testobjekt via API:t
• E-post: SMTP-handskakning och IMAP-inloggning
• VPS och dedikerad server: nätsvar mot instansens IP, inte mot din applikation i den
• Nertid bekräftas av två kontroller i följd innan klockan börjar räkna

Missar vi ett åtagande under en kalendermånad har du rätt till en kredit på avgiften för den drabbade tjänsten. Krediten beräknas på den tjänstens månadsavgift, inte på hela fakturan, och endast en nivå tillämpas per tjänst och månad — den högsta som utlöses.

För VPS och dedikerad server, där åtagandet är 99,5 %, utlöses den första nivån när uppetiden understiger 99,5 %. De lägre nivåerna är desamma för alla tjänster. Den konstruktionen är ett skrivbordsval i utkastet och en av sakerna som bör granskas innan avtalet fastställs.

I utkastet är krediten den enda påföljden vid missad uppetid. Det är branschstandard, men det är också en begränsning värd att säga rakt ut: krediten är sällan i närheten av vad ett avbrott kostar dig. Har du en verksamhet där en timmes stillestånd kostar mer än en månadsavgift är rätt svar redundans över två platser, inte ett större SLA. Det samtalet tar vi hellre än att skriva upp kreditprocenten.

• Under åtagandet men lägst 99,0 %: 10 % av månadsavgiften
• Under 99,0 % men lägst 95,0 %: 25 % av månadsavgiften
• Under 95,0 %: 50 % av månadsavgiften
• Endast den högsta utlösta nivån tillämpas per tjänst och månad
• Krediter för flera tjänster samma månad summeras, men överstiger aldrig 50 % av avgiften för en enskild tjänst
• Kredit utgår som avdrag på faktura, inte som kontant återbetalning

Ett SLA som inte skriver ut sina undantag är inte ärligt. Följande perioder räknas inte in i nertiden.

De två undantag som oftast blir en diskussion är kundens egen kod och överbelastningsattacker mot kundens applikation. Om din app kraschar på slut minne, ett certifikat löper ut eller en deploy tar ned tjänsten, så fungerar plattformen — och det är plattformen vi åtar oss. Vid DDoS mot din applikation gör vi vad vi kan för att mildra, men vi lovar inte att lyckas.

Akut underhåll som vi inte hinner avisera 72 timmar i förväg är inte undantaget. Måste vi patcha ett kritiskt säkerhetshål med kort varsel och det orsakar avbrott, så räknas det som nertid. Att kalla akutåtgärder för planerat underhåll är precis det slags kryphål som gör SLA:n värdelösa.

• Planerat underhåll som aviserats minst 72 timmar i förväg och genomförs inom det aviserade fönstret
• Force majeure: naturhändelser, krig, arbetsmarknadskonflikt, omfattande el- eller transitavbrott, myndighetsbeslut
• Fel i kundens egen kod, konfiguration, container-image, resurstilldelning eller utgångna certifikat
• Överbelastningsattacker eller trafiktoppar riktade mot kundens egen applikation
• Beroenden kunden själv valt utanför vår kontroll: externa API:er, DNS hos annan operatör, tredjepartstjänster
• Avstängning på grund av obetald faktura eller brott mot användarvillkoren
• Åtgärder utförda på kundens begäran, till exempel återställning eller migrering
• Gratisnivåer, testperioder och betafunktioner

Kredit begärs inom 30 dagar från utgången av den månad avbrottet inträffade. Begäran görs via support och ska innehålla tjänst, instansnamn, datum och tidsintervall samt vad du observerade. Har du egna mätdata eller loggar underlättar det, men det är inget krav — vi stämmer alltid av mot vår egen mätning.

Vi svarar på en kreditbegäran inom tio arbetsdagar. Godkänd kredit dras av på nästa faktura. Om abonnemanget avslutas innan krediten hunnit användas regleras den kontant på slutfakturan.

Krediten dras inte automatiskt. Vi hade hellre haft automatisk kreditering, men det kräver att mätningen per kundinstans är helt automatiserad och avstämd mot faktureringen. Tills det är på plats är kredit något du begär, och vi säger det hellre rakt ut än låter dig tro att systemet sköter det åt dig.

• Tidsgräns: 30 dagar från månadens utgång
• Kanal: supportärende hos SIAX
• Ange: tjänst, instans, datum och tid, samt vad du såg
• Svar från oss: inom tio arbetsdagar
• Utbetalning: avdrag på nästa faktura, kontant reglering på slutfaktura

Svarstiden är tiden till första kvalificerade svar från en person som kan agera i ärendet, inte tiden till löst problem. Ingen leverantör kan utlova en lösningstid för fel den inte sett ännu, och ett SLA som gör det räknar med att du inte läser det.

Svarstiderna gäller kontorstid, måndag till fredag 09:00–17:00 svensk tid, med undantag för svenska helgdagar. Ett ärende som registreras utanför kontorstid får sin klocka startad när nästa kontorsdag börjar. Vi har i dag inte jour dygnet runt i standardavtalet, och det ska stå här snarare än upptäckas klockan tre på natten. Behöver din verksamhet svar utanför kontorstid är det ett tillval att prata om separat.

Allvarlighetsgraden sätts av dig när du skriver ärendet. Vi kan justera den om bedömningen är uppenbart fel, och i så fall skriver vi varför.

• Kritiskt: produktionstjänst är otillgänglig eller data riskerar att gå förlorad, ingen känd kringgång — svar inom 2 timmar
• Högt: väsentlig funktion är nedsatt men verksamheten kan fortsätta med kringgång — svar inom 8 timmar
• Normalt: frågor, konfiguration, planering, ändringsönskemål — svar inom 1 arbetsdag
• Kontorstid: måndag–fredag 09:00–17:00 CET/CEST, exklusive svenska helgdagar
• Supportärendet är det som räknas för klockan, även om chatt ibland går fortare

Underhåll som kan orsaka avbrott läggs i fönstret tisdag till torsdag 23:00–05:00 svensk tid och aviseras minst 72 timmar i förväg till de tekniska kontakterna på kontot samt i statuskanalen. Aviseringen anger vilken tjänst det gäller, vad som görs och det längsta avbrott vi räknar med.

Det mesta underhållet på delad infrastruktur sker rullande och utan avbrott: vi flyttar last till andra noder, uppdaterar och flyttar tillbaka. På VPS och dedikerad server går det inte alltid, eftersom en kärnuppdatering eller ett hårdvarubyte kräver omstart. Där ska du räkna med ett fåtal aviserade omstarter per år.

Vi kan sällan flytta ett underhållsfönster för en enskild kund, men vi kan i regel styra i vilken ordning noder tas. Har du en period där avbrott är särskilt olämpligt — bokslut, kampanj, säsongstopp — säg till i förväg så planerar vi runt den om det går. Akut säkerhetsunderhåll kan behöva ske med kortare varsel, och orsakar det avbrott räknas det som nertid enligt avsnittet ovan.

• Fönster: tisdag–torsdag 23:00–05:00 CET/CEST
• Avisering: minst 72 timmar i förväg, till tekniska kontakter och statuskanal
• Frekvens: räkna med ett fåtal fönster per kvartal, de flesta utan avbrott
• Rullande uppdateringar på delad infrastruktur, aviserade omstarter på VPS och dedikerad server
• Akut säkerhetsunderhåll kan ske med kortare varsel och undantas inte från nertidsberäkningen