Driftsmål for appen: mål om den virker for brugerne

Det korte svar

Vælg én eller få forretningskritiske brugerrejser, definér hvad et godt resultat er, mål det så tæt på brugeren som muligt, og aftal et realistisk mål over en bestemt periode. Et målepunkt kaldes en SLI, målet kaldes en SLO, og et eksternt eller kontraktuelt løfte kan være en SLA. Begynd med interne driftsmål; lov ikke mere til kunder, end I kan måle, drive og dokumentere.

Skeln mellem måling, mål og løfte

Microsoft skelner tilsvarende mellem den kvantitative indikator, det konkrete driftsmål og den kontraktuelle aftale. Hold begreberne adskilt i dokumentationen. En intern SLO må gerne ændres, når I lærer mere; en SLA bør behandles som et forretnings- og kontraktspørgsmål, ikke som tekst en udvikler alene tilføjer på hjemmesiden.

Vælg brugerrejsen før måleværktøjet

Start med den handling, hvis fejl stopper arbejde, taber omsætning eller skader data. Microsoft anbefaler at identificere og prioritere bruger- og systemforløb efter deres betydning for virksomheden. Det gør målet teknologineutralt: samme metode virker for Firebase, Azure, Supabase, SQL og andre kombinationer.

1. 1. Navngiv resultatet. Eksempelvis “en medarbejder gemmer en sag og kan se den igen” frem for “API'et svarer”.
2. 2. Afgræns start og slut. Beskriv hvilken bruger, handling og synlig bekræftelse målingen dækker.
3. 3. Definér et godt forsøg. Aftal krav til korrekthed, svartid, fuldførelse og eventuel datafriskhed.
4. 4. Definér hvad der tæller med. Beslut hvordan brugerfejl, planlagt vedligehold, testtrafik, robotter og leverandørfejl håndteres.
5. 5. Vælg måleperioden. Perioden skal være lang nok til at vise driftens kvalitet og kort nok til, at resultatet fører til handling.

Mål det, brugeren mærker

En SLI bør svare på et konkret spørgsmål om oplevet kvalitet. Google Cloud beskriver både request-baserede indikatorer — gode hændelser delt med alle relevante hændelser — og tidsvinduer, hvor hvert interval vurderes som godt eller dårligt. Vælg den model, der passer til appens faktiske brug.

Mål gerne både fra rigtig brug og med syntetiske kontroller, men beskyt persondata og testdata. En syntetisk booking eller ordre skal være tydeligt mærket, kunne ryddes op sikkert og må ikke udløse en rigtig betaling, besked eller levering.

Sæt et realistisk mål — ikke et pyntetal

Målet skal afspejle, hvornår brugerne reelt mærker utilstrækkelig drift, og hvad det koster at forbedre den. Et højere mål kan kræve mere redundans, bedre beredskab, flere målepunkter og dyrere leverandørvalg. Et mål på 100 procent efterlader intet rum til fejl eller vedligehold og er ifølge Google SRE ikke et fornuftigt standardmål.

• Brug historiske data, hvis de findes. Se hvilke hændelser brugerne faktisk mærkede, og om den foreslåede SLI ville have fanget dem.
• Skriv afhængigheder ind. Login, database, betalingsudbyder og integrationer påvirker brugerrejsen, selv om de drives af andre.
• Aftal vedligehold tydeligt. Beslut om planlagte vinduer tæller med, og kommuniker dem før de starter.
• Begynd målbart og justér. En enkel, ærlig SLO med kendte huller er bedre end et præcist tal på en måling, der ikke repræsenterer brugeren.

Brug fejlbudgettet til beslutninger

Forskellen mellem perfekt drift og det valgte SLO kaldes et fejlbudget. Google Cloud beskriver det som den mængde dårlige hændelser eller tid, tjenesten kan have i måleperioden og stadig nå målet. Pointen er ikke at planlægge fejl, men at gøre balancen mellem ændringer og stabilitet synlig.

Alarmér på påvirkning og undersøg årsagen bagefter

CPU, hukommelse og databaseforbindelser er nyttige fejlsøgningssignaler, men de viser ikke alene brugerens resultat. Microsoft anbefaler at forbinde kritiske forløb og slutbrugeroplevelse med systemets helbred og bruge logs, målinger, traces og syntetiske kontroller til at finde årsagen.

• Alarmen har en ejer. Den går til en person eller funktion, som kan vurdere og handle.
• Alarmen beskriver påvirkningen. Den nævner brugerrejse, periode, aktuel kvalitet og link til runbook.
• Støj filtreres. En kort teknisk spids uden brugerbetydning skal ikke vække alle, mens langsom forværring ikke må forsvinde.
• Det endelige resultat kontrolleres. Efter en rettelse testes brugerrejsen og data — ikke kun den komponent, der så rød ud.

Dokumentér definitionen, så målingen kan gennemgås

Gem hvert driftsmål med ejer, brugerrejse, datakilde, formel, grænse, måleperiode, undtagelser, alarmvej og beslutning ved overskridelse. Versionér ændringer, så en pænere graf ikke skyldes, at fejlede hændelser pludselig er filtreret væk. Gennemgå målet efter væsentlige ændringer, hændelser og nye brugerbehov.

Typiske fejl

• Platformens oppetid bliver appens mål: Leverandøren kan overholde sin SLA, mens jeres kode, data eller integration er brudt.
• Alt måles samlet: Mange hurtige, uvigtige requests skjuler fejl i en sjælden, kritisk handling.
• Kun HTTP-status tæller: Et svar kan være teknisk succesfuldt, selv om ordren mangler, data er forkerte eller jobbet aldrig afsluttes.
• Målet kopieres fra en anden app: Brugsmønster, tab ved fejl, support og budget er ikke de samme.
• Alle alarmer er lige vigtige: Støj træner den ansvarlige i at ignorere beskeder og skjuler reel brugerpåvirkning.
• SLA loves før SLO kan måles: Virksomheden påtager sig et løfte uden data, ansvar og dokumenteret evne til at reagere.

Tjekliste til appens driftsmål

• ☐ En eller få kritiske brugerrejser er valgt ud fra virksomhedens reelle afhængighed.
• ☐ Hver rejse har en entydig start, slutning og definition af et godt resultat.
• ☐ SLI'en måler brugerens resultat så tæt på oplevelsen som muligt.
• ☐ Mål, periode, datakilde, filtre og undtagelser er dokumenteret.
• ☐ Målet er aftalt mellem forretning og teknisk ansvarlig og bygger ikke på et tilfældigt branchetal.
• ☐ Eksterne afhængigheder og planlagt vedligehold er behandlet eksplicit.
• ☐ Målingen kan skelne mellem brugerfejl, systemfejl og ukendt resultat.
• ☐ Alarmer viser reel påvirkning, har en navngiven modtager og peger på en runbook.
• ☐ Fejlbudgettet udløser aftalte valg om releases, fejlretning og kommunikation.
• ☐ Et eventuelt SLA-løfte er afgrænset, målbart og gennemgået som et forretnings- og kontraktspørgsmål.
• ☐ Driftsmål og målemetode gennemgås efter større ændringer og hændelser.

Relaterede guides

• Logning og overvågning: indsaml signalerne og send handlingsklare alarmer
• Driftsberedskab: fordel roller og stabilisér appen ved en hændelse
• Belastningstest: afprøv kapacitet mod realistiske brugerforløb
• Backup og gendannelse: forbind drift med RPO og RTO

Officielle kilder

Begreber, målemodeller og anbefalinger er kontrolleret mod aktuelle officielle kilder fra Microsoft og Google. Brug altid dokumentationen for jeres konkrete overvågningsplatform, når målingen skal implementeres.

• Microsoft Azure Well-Architected: Fastlæg mål for stabilitet og gendannelse
• Microsoft Azure Well-Architected: Overvåg stabilitet ud fra brugerens oplevelse
• Google Cloud Observability: SLI, SLO og fejlbudgetter
• Google SRE Workbook: Implementing SLOs