Oppetidsprocenten er den tid, en tjeneste var oppe, divideret med den samlede tid og ganget med 100. En måned på 30 dage har 43.200 minutter; med 27 minutters nedetid er oppetiden (43.200 − 27) ÷ 43.200 × 100 = 99,9375 %.
Formlen er enkel. Det er sværere at nå frem til et tal, du kan stå inde for: du skal beslutte, hvad den samlede tid er, hvad der tæller som nedetid, hvad der skal holdes udenfor, og hvordan flere dele af et system skal kombineres. Denne guide gennemgår hver af dem med eksempler og forklarer derefter, hvordan oppetid adskiller sig fra tilgængelighed og pålidelighed.
Skal det gå hurtigt, omregner oppetidsberegneren nedetid til en procent og en procent til tilladt nedetid.
Formlen for oppetid
Oppetid % = (Samlet tid − Nedetid) ÷ Samlet tid × 100
Samlet tid og nedetid skal være i samme enhed. Minutter er det praktiske valg for en måned, sekunder hvis du har brug for større præcision.
PeriodeMinutterSekunderDag1.44086.400Uge10.080604.800Måned på 30 dage43.2002.592.000Måned på 31 dage44.6402.678.400Gennemsnitlig måned (30,4375 dage)43.8302.629.800År (365,25 dage)525.96031.557.600
Brug periodens reelle længde, når du rapporterer på en kontrakt, da de fleste SLA’er måles pr. kalendermåned. Beregneren bruger den gennemsnitlige måned, så mål kan sammenlignes retfærdigt, og derfor viser den 99,938 % for de samme 27 minutter.
Ud fra tjek i stedet for minutter
Hvis dine data er en liste over tjek frem for tidspunkter for nedbrud, er oppetiden andelen af tjek, der lykkedes:
Oppetid % = Vellykkede tjek ÷ Alle tjek × 100
Med et tjek hvert minut har en måned på 30 dage 43.200 tjek. Hvis 40 af dem fejlede, er oppetiden 43.160 ÷ 43.200 × 100 = 99,907 %. Det virker kun, når tjekkene kører med et fast interval, og hvert fejlet tjek tælles som et helt intervals nedetid. Med tjek hvert femte minut tæller et nedbrud på 30 sekunder enten som fem minutter eller slet ikke.
Eksempler
Flere hændelser på én måned
En webshop havde tre hændelser i en måned på 30 dage: 12 minutter den 4., 7 minutter den 15. og 24 minutter den 27. Læg dem sammen først: 43 minutter. Derefter (43.200 − 43) ÷ 43.200 × 100 = 99,9005 %. En måned på 30 dage med 99,9 % tillader 43 minutter og 12 sekunder, så webshoppen holdt sig inden for målet med 12 sekunder til overs.
Når planlagt vedligeholdelse holdes udenfor
Hvis din SLA undtager vedligeholdelse, skal vedligeholdelsestiden trækkes fra den samlede tid, ikke kun fra nedetiden:
Oppetid % = (Samlet tid − Vedligeholdelse − Nedetid) ÷ (Samlet tid − Vedligeholdelse) × 100
Et eksempel: en måned på 30 dage med et vedligeholdelsesvindue på 2 timer og 30 minutters uplanlagt nedetid. Uden vedligeholdelse: (43.200 − 120 − 30) ÷ (43.200 − 120) × 100 = 99,930 %. Hvis vedligeholdelsen i stedet tælles som nedetid: (43.200 − 150) ÷ 43.200 × 100 = 99,653 %. Samme måned, to vidt forskellige tal, og derfor skal SLA’en sige, hvilket der gælder.
Sat overvågning på pause fungerer på samme måde. Hvis ingen målte, er den tid hverken oppe eller nede, og den hører ikke med i den samlede tid.
Sådan kombinerer du oppetiden for flere komponenter
De fleste tjenester afhænger af mere end én ting. Hvordan du kombinerer deres oppetid, afhænger af, om de er koblet i serie eller redundante.
Komponenter i serie
Når alle komponenter skal virke, ganger du deres oppetider. Et website, der kræver både en app-server med 99,9 % og en database med 99,9 %, kan højst nå 0,999 × 0,999 = 99,8 %, forudsat at de fejler på forskellige tidspunkter. Tilføj en betalingsudbyder med 99,9 %, og checkout falder til omkring 99,7 %. Hver afhængighed, du tilføjer, sænker loftet.
Redundante komponenter
Når hver af to komponenter kan klare opgaven, er tjenesten kun nede, når begge er. To servere med 99 % hver giver i teorien 1 − (0,01 × 0,01) = 99,99 %. I praksis deler de ofte netværk, deploy eller en konfigurationsfejl, så de fejler samtidig oftere, end regnestykket forudsætter. Betragt resultatet som en øvre grænse, ikke et løfte.
Tag ikke gennemsnittet på tværs af monitorer
Hvis forsiden havde 100 % og checkout 99,0 %, beskriver et gennemsnit på 99,5 % ikke noget, kunderne har oplevet. Rapportér hver komponent for sig, og definér på forhånd, hvilke der udgør “tjenesten” i din SLA.
Oppetid vs. tilgængelighed vs. pålidelighed
De tre ord bruges ofte som synonymer. De måler forskellige ting, og når du ved, hvilket du mener, bliver tallet mere brugbart.
Oppetid er andelen af tiden, hvor tjenesten kunne nås og svarede. Det er det, formlen ovenfor beregner, og det, de fleste SLA’er mener.
Tilgængelighed er andelen af tiden, hvor tjenesten kunne bruges: den kunne nås, svarede korrekt og hurtigt nok. En side, der er 40 sekunder om at indlæse, er oppe, men ikke tilgængelig. Tæller du langsomme eller forkerte svar som fejl, måler du tilgængelighed.
Pålidelighed er, hvor længe tjenesten kører uden at fejle, typisk målt som MTBF (mean time between failures, gennemsnitlig tid mellem fejl). Den siger, hvor ofte noget går i stykker, ikke hvor længe det forbliver i stykker.
Tilgængelighed forbinder de to andre tal gennem en klassisk formel:
Tilgængelighed = MTBF ÷ (MTBF + MTTR)
MTTR er den gennemsnitlige tid til genopretning. En tjeneste, der i gennemsnit fejler hver 720. time (én gang om måneden) og er en time om at komme sig, har 720 ÷ 721 = 99,86 % tilgængelighed. Formlen viser også de to måder at forbedre den på: fejl sjældnere, eller kom dig hurtigere. MTTR, MTTA og MTBF forklaret gennemgår, hvordan du måler og forbedrer hver af dem.
To tjenester med samme oppetid kan opleves meget forskelligt. Ét nedbrud på 43 minutter om måneden og 43 nedbrud på ét minut om måneden giver samme procent, men det sidste afbryder dine brugeres arbejde hver dag. Derfor er det værd at følge antallet af hændelser ved siden af oppetidsprocenten.
Typiske fejl
At måle indefra. Serverlogs kan ikke registrere en forespørgsel, der aldrig nåede frem. DNS-problemer, udløbne certifikater og netværksfejl viser sig kun i eksterne tjek.
At tælle hvert eneste blip. Et enkelt fejlet tjek skyldes ofte netværket, ikke din tjeneste. Bekræft fejl med et ekstra tjek, før de tælles som nedetid, ellers bliver dine tal lavere end det, brugerne oplevede.
At runde op. 99,896 % er ikke 99,9 %. Når du sammenligner med et mål, så rund ned, eller vis nok decimaler til at skelne dem fra hinanden.
At tjekke for sjældent. Tjekintervallet bestemmer opløsningen. Tjek hvert 5. eller 10. minut kan ikke fortælle dig, om du nåede en måned med 99,95 %, som tillader 22 minutter.
Kun at tjekke forsiden. En cachet forside kan forblive oppe, mens login eller checkout fejler. Overvåg de veje, brugerne er afhængige af.
Få tallene uden et regneark
Uptimecheck beregner oppetid på den måde, denne guide beskriver. Oppetidsovervågning tjekker så ofte som hvert minut fra Stockholm, London og New York og bekræfter hvert fejlet tjek fra en anden lokation. Oppetiden er den andel af perioden, der er uden et bekræftet nedbrud; vedligeholdelsesvinduer og tid på pause tæller ikke imod den.
Rapporter viser oppetid, nedetid og hændelser pr. monitor for denne måned, sidste måned eller de seneste 7, 30 eller 90 dage, målt mod et SLA-mål fra 99 % til 99,99 %, med download som CSV. Se sådan kører du rapporter mod et SLA-mål.
Kunderapporter sender de samme tal til dem, du arbejder for. Se kunderapporter.
Statussider viser kunderne 90 dages oppetidshistorik pr. komponent. Se statussider.
Vil du se, hvad et mål tillader, før du forpligter dig til det, så læs hvad 99,9 % oppetid betyder, eller prøv SLA- og oppetidsberegneren.
Stop med at beregne oppetid i hånden. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.