{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/service-level-objective","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/service-level-objective/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/service-level-objective/"},"term":{"en":"Service level objective (SLO)","da":"Serviceniveaumål (SLO)"},"aka":{"en":["SLO"],"da":["SLO"]},"domain":["platform"],"cluster":"observability","layer":"process","status":"current","era":2016,"summary":{"en":"An internal target for how well a service should work, such as 99.9% of requests answered within a second over 30 days.","da":"Et internt mål for, hvor godt en tjeneste skal fungere, fx at 99,9 % af forespørgslerne besvares inden for et sekund over 30 dage."},"body":{"formal":{"en":"A target value for a measured sign of service quality, such as the share of requests that succeed or answer fast enough, over a set time window; the gap between the target and 100% is the error budget the team may spend.","da":"En målværdi for et målt tegn på servicekvalitet, fx andelen af forespørgsler, der lykkes eller besvares hurtigt nok, over en fast periode; afstanden mellem målet og 100 % er det fejlbudget, teamet må bruge af."},"plain":{"en":"Like a bus company aiming for 98% of buses on time; the timetable it prints for passengers promises less, so it has room to spare before it owes anyone money.","da":"Som et busselskab, der sigter efter, at 98 % af busserne kører til tiden; køreplanen, det lover passagererne, lover mindre, så der er luft, før det skylder nogen penge."},"inPractice":{"en":"The team behind a school communication portal allows itself 43 minutes out of service a month; after a bad release uses 40 of them, it pauses new features and spends the rest of the month on stability.","da":"Teamet bag en skoleportal tillader sig 43 minutters nedetid om måneden; da en dårlig frigivelse har brugt 40 af dem, sætter teamet nye funktioner på pause og bruger resten af måneden på stabilitet."},"whyItMatters":{"en":"It turns availability from a vague wish into a number that guides the choice between speed and stability, and warns the team before it breaks the SLA it has given its own customers.","da":"Det gør tilgængelighed fra et vagt ønske til et tal, der styrer valget mellem hastighed og stabilitet, og advarer teamet, før det bryder den SLA, det har givet sine egne kunder."}},"deepDive":{"en":"An SLO has three parts: a service level indicator (SLI), a target and a compliance window. The SRE Workbook recommends expressing every SLI as a ratio of good events to valid events, so it ranges from 0 to 100% and has a uniform meaning: for availability, successful responses divided by all valid requests, excluding for example 4xx responses caused by clients; for latency, the share of requests served faster than a threshold such as 300 ms; and for pipelines, freshness, correctness or coverage. Latency SLOs are usually stated as a percentile target (99% of requests under 300 ms) rather than an average, which hides the tail. Time-based SLIs, which count good minutes instead of good requests, weight a quiet night the same as peak hour and so tend to misrepresent user impact.\n\nThe error budget is 1 minus the target applied to the window. At 99.9% over 30 days a service may fail 0.1% of valid requests, which is 1,000 failures per million requests or, for a time-based SLI, 43.2 minutes. Rolling windows (the last 28 or 30 days) reflect what users recently experienced and avoid the budget suddenly resetting on the first of the month; calendar windows align with business reporting and SLAs. Alerting should be driven by the burn rate, the speed at which the budget is being consumed, rather than by the instantaneous SLI.\n\nThe budget becomes a management tool through an error budget policy agreed in advance between product, development and operations: for example, when the budget is exhausted, feature releases pause except for reliability fixes and security patches until the service is back within target, and any single incident consuming more than a set share of the budget requires a postmortem. Without such a policy an SLO is just a dashboard. The corollary is that a large remaining budget is permission to take risk, such as faster rollouts or chaos experiments.\n\nTargets should be set from user expectations and historical performance, not aspiration. 100% is the wrong target because users cannot distinguish it from very high availability behind their own imperfect networks, and pursuing it freezes change. An SLO also cannot realistically exceed the combined availability of hard dependencies, including third-party SLAs, without redundancy. Too many SLOs dilute attention; a few per critical user journey is typical. SLOs are best measured as close to the user as practical, at the load balancer or with client-side telemetry, because server-side metrics miss requests that never arrive. Specifications such as OpenSLO allow SLOs to be declared as code alongside services, and the SLO is then set stricter than any external SLA so that internal reaction precedes contractual breach.","da":"En SLO består af tre dele: en serviceniveauindikator (SLI), et mål og en overholdelsesperiode. SRE Workbook anbefaler at udtrykke enhver SLI som forholdet mellem gode hændelser og gyldige hændelser, så den ligger mellem 0 og 100 % og har en ensartet betydning: for tilgængelighed vellykkede svar divideret med alle gyldige forespørgsler, hvor fx 4xx-svar forårsaget af klienter udelades; for latenstid andelen af forespørgsler, der besvares hurtigere end en tærskel som 300 ms; og for datapipelines friskhed, korrekthed eller dækning. Latens-SLO'er angives normalt som et percentilmål (99 % af forespørgslerne under 300 ms) frem for et gennemsnit, der skjuler halen. Tidsbaserede SLI'er, der tæller gode minutter i stedet for gode forespørgsler, vægter en stille nat lige så højt som spidsbelastningen og giver derfor ofte et skævt billede af brugerpåvirkningen.\n\nFejlbudgettet er 1 minus målet anvendt på perioden. Ved 99,9 % over 30 dage må en tjeneste fejle på 0,1 % af de gyldige forespørgsler, hvilket er 1.000 fejl pr. million forespørgsler eller, for en tidsbaseret SLI, 43,2 minutter. Rullende perioder (de seneste 28 eller 30 dage) afspejler, hvad brugerne har oplevet for nylig, og undgår, at budgettet pludselig nulstilles den første i måneden; kalenderperioder passer til forretningsrapportering og SLA'er. Alarmering bør styres af burn rate, altså hastigheden, hvormed budgettet forbruges, frem for af den øjeblikkelige SLI.\n\nBudgettet bliver et ledelsesværktøj gennem en fejlbudgetpolitik, som produkt, udvikling og drift aftaler på forhånd: fx at når budgettet er brugt op, sættes nye funktioner på pause, bortset fra rettelser af driftssikkerhed og sikkerhedsopdateringer, indtil tjenesten er tilbage inden for målet, og at enhver enkelt hændelse, der bruger mere end en fastsat andel af budgettet, kræver en postmortem. Uden en sådan politik er en SLO bare et dashboard. Omvendt er et stort resterende budget en tilladelse til at tage risici, fx hurtigere udrulninger eller chaos-eksperimenter.\n\nMål bør fastsættes ud fra brugernes forventninger og historisk ydeevne, ikke ambitioner. 100 % er det forkerte mål, fordi brugerne ikke kan skelne det fra meget høj tilgængelighed bag deres egne ufuldkomne netværk, og fordi jagten på det fryser al forandring. En SLO kan heller ikke realistisk overstige den samlede tilgængelighed af hårde afhængigheder, herunder tredjeparters SLA'er, uden redundans. For mange SLO'er spreder opmærksomheden; nogle få pr. kritisk brugerrejse er typisk. SLO'er måles bedst så tæt på brugeren som praktisk muligt, ved loadbalanceren eller med telemetri fra klienten, fordi metrikker på serversiden overser forespørgsler, der aldrig når frem. Specifikationer som OpenSLO gør det muligt at erklære SLO'er som kode sammen med tjenesterne, og SLO'en sættes strengere end enhver ekstern SLA, så den interne reaktion kommer før kontraktbruddet."},"edges":[{"type":"requires","to":"platform/metrics","confidence":"high","strength":"normal"},{"type":"requires","to":"security/availability","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/supplier-management","why":{"en":"A supplier's SLA caps what an internal SLO can realistically promise, so SLOs are set with the suppliers' own service levels in mind.","da":"En leverandørs SLA sætter et loft over, hvad en intern SLO realistisk kan love, så SLO'er fastsættes med leverandørernes egne serviceniveauer for øje."},"confidence":"medium","strength":"normal"},{"type":"used-with","to":"ai/throughput","why":{"en":"Capacity goals for a service are often written as a minimum number of requests or tokens it must handle per second.","da":"Kapacitetsmål for en tjeneste skrives ofte som et minimum af forespørgsler eller tokens, den skal klare per sekund."},"confidence":"medium","strength":"normal"}],"depth":1,"sources":[{"title":"Google SRE book - Chapter 4, Service Level Objectives","url":"https://sre.google/sre-book/service-level-objectives/","tier":"reference","publisher":"Google"}],"draft":true}