Servicenivåmål för molnövervakning

Den här artikeln är en del av en serie i molnövervakningsguiden.

I avsnitten nedan får du lära dig om de grundläggande principerna för servicenivåmål och hur du implementerar och tillämpar dem.

Översikt

Servicenivåmål (SLO) är mätbara mål för viktiga indikatorer på kundcentrerad servicenivå (SLO). De mäter kundens erfarenhet av en arbetsbelastning för företag eller infrastruktur och avgör om företagets tjänsteleverantör uppfyller löftena i ett formellt förhandlat serviceavtal (SLA) eller informellt avtal mellan alla parter.

Som tjänstkö förlitar du dig på Microsofts engagemang för tillförlitligheten för tjänster enligt definitionen i Microsofts serviceavtal för Azure-tjänster. På så sätt kan du fokusera på ditt ansvar i tjänstkedjan, till exempel syntetisk övervakning, nätverksanslutning och säkerhet och efterlevnad.

Terminologi

Nedan visas definitionerna för var och en av dessa termer och en kort beskrivning. Dessa definitioner är hämtade från Googles SRE-handbok.

Period	beskrivning
Serviceavtal (SLA)	Vanligtvis ett bindande åtagande mellan en tjänstleverantör och en kund. Ett avtal innehåller vanligtvis konsekvenser av att SLO-målen saknas. Vissa aspekter av tjänsten är kvalitet, tillgänglighet och ansvar enligt överenskommelse mellan tjänsteleverantören och tjänstekonsumenten.
Övervakning	Metoden att samla in kvantitativa realtidsdata om tjänster och system.
Mått	Mäter relevant tjänstbeteende och kan aggregeras till servicenivåindikatorer (SLI), som bearbetas och aggregeras för att mäta det aktuella drifttillståndet för en tjänst och kvantifiera dess beteende. SLO:er är de viktigaste indikatorerna och realtidsindikatorerna för tjänstens aktuella hälsotillstånd.
Loggar	Börjar med koden och rapporterar information om en enskild körning av en kodsökväg eller diskret händelse. Använd den här informationen för att felsöka och arbeta med att identifiera rotorsaksproblem som påverkar kundupplevelsen och tjänstens tillförlitlighet som mäts av SLO:er/SLO:er.
Servicenivåmål (SLO)	Ett målvärde för tjänstnivån, mätt med servicenivåindikatorer (SLO: er), som anger förväntningar på hur väl en tjänst presterar. Serviceavtal spårar specifikt kundupplevelsen från slutpunkt till slutpunkt. För att upprätta bra serviceavtal börjar du vanligtvis med att definiera önskad upplevelse och sedan instrumentera tjänstkoden för att mäta den upplevelsen (samla in relevanta SLO:er) och ange målet för hur du uppfyller kundernas förväntningar eller inte.
Indikator på tjänstnivå (SLI)	Ett mått som kvantifierar tjänstens kvalitet eller tillförlitlighet. Minst fyra vanliga SLO:er utvärderas: tillgänglighet, svarstid, dataflöde och felfrekvens.
Tillgänglighet	Refererar vanligtvis till den mätbara eller observerbara procentandelen av tiden som ett system är drifts- och funktionsdugligt. Du mäter tillgänglighet som ett kundanslutet mål för kontinuitet i upplevelsen, vilket påverkas av ett eller flera tillförlitlighetsproblem (och andra fellägen som rör konfigurationsändringar, uppdateringar som tillämpas med mera).
Felbudget	Procentandelen av din återstående buffert för ditt SLO. Felbudgetar är verktyget DevOps och IT använder för att balansera tjänstens tillförlitlighet med innovationstakten.

Syftet med serviceavtal

Serviceavtal har många viktiga syften när det gäller utveckling och drift av molnarbetsbelastningar, inklusive:

• Nära realtid (NRT): För att ge en NRT-vy över hälsotillståndet för en tjänst som upplevs av en kund.
• Minska TTN(time-to-notify): Öka automatiserade meddelanden om tjänstproblem till kunder, vilket avsevärt minskar tiden för att meddela (TTN).
• Primär signal till kunder: Fungera som en primär signal för distributionsåtgärder, vilket driver automatisk återställning om problem uppstår, vilket utsätter färre kunder för potentiella problem.
• Ändringsverifiering: Ange verifiering för att ändringarna uppnådde den förväntade förbättringen av kundupplevelsen.
• Fastställa prioriteringar: Hjälp teamen att förstå om de ska skapa funktioner eller arbeta med tillförlitlighet.
• Tjänststatus insikter: Aktivera objektiva, kundfokuserade diskussioner om tjänstens hälsa.
• Minska tiden att analysera: Snabba upp minskning och rotorsaksanalys (RCA) av kundproblem genom att rikta fokus till den ansvarsfulla tjänsten.
• Arkitekturberoenden: Fungerar som en viktig indata i arkitektoniska beslut när tjänster tar beroenden.
• Bygger förtroende: Ge en delad förståelse av hälsomått, vilket skapar förtroende mellan team.
• Bring transparency (Bring Transparency): Exponera samma SLO:er som vi använder för att driva vår verksamhet för våra kunder så att de kan köra sina.
• En enda fönsterruta: Aktivera en vågrät enda fönsterruta för tjänsterna och deras beroenden och uppdelningssilor.

Genom att använda SLO:er för att driva din tekniska process kan DevOps och IT få en tidig förståelse för hälsotillståndet för den program- eller infrastrukturtjänst som de skapar eller migrerar i Azure. Detta kan sedan användas för att driva både mänskliga och automatiserade beslut som måste fattas om tillförlitligheten för dessa tjänster. Den här omvandlingen i teknisk praxis kommer att avsevärt påverka tillförlitligheten för dessa tjänster på kort sikt.

Hur definierar jag serviceavtal?

Målet med ett servicenivåmål är att få tydliga signaler som korrekt mäter kvalitet ur kundens perspektiv. Varje tjänstteam skapar en liten uppsättning servicenivåmål (SLO) som definierar det tillåtna intervallet för de viktigaste mätbara måtten för tjänsten, vilket tjänstekonsumenten upplever. Ett SLO är ett definierat numeriskt mål för ett mått som genereras av en tjänst. Mått som är associerade med det här målet kan övervakas för att avgöra om tjänsten är felfri.

Här är till exempel ett förenklat exempel på ett SLO för ett internt tidsspårningsbaserat webbaserat program – Begäranden under de senaste 5 minuterna hanteras i under 1 000 millisekunder i den 99:e percentilen.

Måtten är aggregeringar av tidsseriedata som kallas servicenivåindikatorer (SLI). Var SLO:erna samlas in spelar stor roll. I exemplet ovan, om kunden interagerar med tjänsten med hjälp av ett API, är mätning av systemets svarstid och tid för att bearbeta begäranden korrekta SLO:er. Men om kunden interagerar med tjänsten med hjälp av en webbportal bör den totala tiden för att betjäna begäran även innehålla JavaScript-prestanda för webbsidan.

Fokus för tjänstägare är att fastställa följande:

• Vilka scenarier är kritiska indikatorer för tjänstens hälsa ur kundens perspektiv,
• Var du kan samla in SLO:er så att de ligger så nära kundupplevelsen som möjligt, och
• Vad ska serviceavtalen vara för dessa SLO:er?

Serviceavtal kan definieras med en gradvis metod för att uppnå resultat, eller så föreskrivs det direkt av företaget. Du använder de serviceavtal som definieras av en tjänst för att fatta arkitektoniska beslut om hur du skapar dem. Därför är det viktigt att noggrant välja vilka scenarier som ska mätas och vilken tidsram de ska mätas över. Sammanfattningsvärdet är att en SLO består av följande värden:

• Ett SLI. Till exempel är andelen tillräckligt snabba begäranden, mätt från lastbalanseraren, mindre än 400 ms.
• En varaktighet. Tidsperioden då ett mått mäts.
• Ett mål. Till exempel en målprocent av snabba begäranden till totalt antal begäranden (till exempel 90 %) som du förväntar dig att uppfylla under en viss tidsperiod.

Typer av serviceavtal

Om du tittar i hela branschen finns det två typer av serviceavtal:

• Servicecentrerade serviceavtal – Dessa serviceavtal är taktiska mål som team definierar för att förbättra kvaliteten på sin tjänst över tid gradvis. De är utformade för att vara pragmatiska mål som kan uppnås i en teknisk milstolpe. Om en tjänst till exempel för närvarande uppnår 99,7 % tillgänglighet kan teamet ange ett mål för att nå 99,9 % tillgänglighet under nästa kvartal.

• Kundcentrerade serviceavtal – Dessa serviceavtal definierar det idealiska framtida tillståndet eller målet. Vid denna tidpunkt skulle ytterligare investeringar i kvalitet anses onödiga eftersom du helt uppfyller kundernas förväntningar.

Om kunden till exempel förväntar sig att en verksamhets- eller infrastrukturtjänst som du använder ger 99,99 % tillgänglighet och tjänsten för närvarande endast uppnår 99,8 % tillgänglighet är det kundcentrerade SLO:t fortfarande 99,99 %.

Det tar tid att definiera rätt serviceavtal. Det första steget är att prata med dina kunder och förstå vad användarna vill ha från tjänsten för att härleda ett litet urval indikatorer och dokumentera det. Lär dig scenarier och toleranser för hur de använder din tjänst och vad tjänsten behöver leverera för att kunna driva verksamheten. Detta är ofta en iterativ upplevelse, med deras förväntningar från jag vill ha 100% tillgänglighet under alla förhållanden, utan påverkan på vår intäktsström, genom att hantera mycket variantförväntningar mellan kundsegment.

Övervakningsmetoder som endast tittar på tjänstens (eller tjänstinstansens) hälsa är sårbara för problem med kundupplevelser som saknas i båda ändar av spektrumet. servicehälsan korrelerar inte alltid med kvaliteten på kundupplevelsen. Det beror på att det finns olika beteendeegenskaper mellan en Azure PaaS- och SaaS-tjänst, konfigurationen av dessa Azure-tjänster, hur och var (dvs. vilken region) deras resurser distribueras och tillägget av din anpassade kod/logik, vilket ger ytterligare komplexitet.

När du definierar ett serviceavtal är det viktigt att komma ihåg att dina molnleverantörer är beroende av ditt serviceavtal. Ta hänsyn till de serviceavtal som angetts för var och en av deras tjänster. Information om Azure finns i Service Level Agreements (SLA) for Online Services (Service Level Agreements (SLA) for Online Services (Service Level Agreements (SLA) för Online Services

Hur definierar du SLO:er?

En SLI-specifikation är en formell beskrivning av användarnas förväntningar på en viss tillförlitlighetsdimension för din tjänst, till exempel svarstid eller tillgänglighet.

Börja enkelt genom att välja rätt mått för att mäta och samla in och överkomplicera det inte genom att samla in för många mått som inte är meningsfulla. Se till att de SLA:er som du definierar har en direkt relation till kundupplevelsen. Det är därför det är viktigt att förstå perspektivet för användarna att börja med bara några få indikatorer.

Om din tjänst är resursbegränsad på något sätt, till exempel minne eller CPU, kan dess mättnad också vara ett utmärkt SLI. Mättnad bör dock inte användas som ett SLO eftersom det inte direkt motsvarar en dålig användarupplevelse (en tjänst kan ha hög minnesanvändning, men användarna påverkas inte).

Vi rekommenderar att du skapar upp till tre indikatorer. Mer än tre indikatorer ger sällan betydande värde. Ofta kan överdrivet många indikatorer innebära att du inkluderar symtom på primära indikatorer. Trafik och mättnad bör vara utöver dessa tre huvudindikatorer, eftersom de beskriver tjänstbelastning och stöd för tolkning av andra tjänstindikatorer.

Hur implementerar du serviceavtal?

De SLO:er som är viktigast är de som tydligast representerar en inverkan på din tjänst ur kundens perspektiv. För många tjänster omfattar detta svarstid, dataflöde, felfrekvens och tillgänglighet. Om din tjänst har några särskilda överväganden som påverkar kundupplevelsen bör även SLO:er för dessa områden mätas. Till exempel är svarstiden för bearbetning från slutpunkt till slutpunkt för en meddelandetjänst en direkt indikator på kundupplevelsen och bör omfattas av ett SLI.

SLO-exempel

Personalavdelningen är intresserad av att modernisera sitt interna tidsspårningsbaserade webbaserade program och vara värd för det i Azure-molnet med hjälp av företagets IT. De vill att tjänsten ska fortsätta att nå alla användare i organisationen, så att de är intresserade av följande:

• Användningsrapporter och hur många användare som använder tjänsten över tid.
• Regelbunden hälsoövervakning, till exempel tillgänglighet, prestanda, säkerhet och efterlevnad (tjänstgaranti).
• Kostnad, till exempel månadskostnaden för en tjänst.
• Cybersäkerhet när det gäller att kontrollera åtkomsten till resurser och data genom att följa en Nolltillit säkerhetsstrategi.

Som vi ser i de här exemplen ovan är SLO/SLI-kategorierna och exemplen nödvändiga för att definiera tidigt i tjänstdesignen. Det skiljer sig inte alls från de lokala tjänster som du har byggt.

SLO-tabeller/SLI-kategorier

Följande exempel är inte på något sätt en fullständig lista. SLO:er för tillförlitlighet och underhåll är kännetecknande för system i årtionden, men du kan definiera serviceavtal som omfattar åtgärder för cybersäkerhet, kvalitet och användarupplevelse och kostnad.

Tjänster

Typiska högnivåmått för en tjänst eller ett system kodifieras vanligtvis i serviceavtal. De flesta moderna avtal mäter tillgänglighet som nyckel-SLO och använder enkla driftstopp baserat på viktiga arbetsbelastningsobjekt eller produktionsenheter, till exempel autentiseringstoken, postlådor eller lagringskonton.

Kategori	beskrivning	Exempel
Tillgänglighet	Enkel stilleståndstid eller genomsnittlig tid mellan underhåll eller drifttillgänglighet (MTBM/(MTBM+MDT))	99,99 % under en månadsperiod
Kapacitet	Säkerställ tillräcklig, maximal eller optimal affärs- och tjänstprestanda, dataflöde, lagring, personer, bandbredd, efterfrågan, resurser och tjänstfunktioner. Innehåller arbets- och tidsgränser för att fungera som utlösare.	% användning (CPU, lagring, minne, svarstid, dataflöde, skalning)
Säkerhet	Aktiva hot och sårbarheter (interna och externa) som kan eller orsakar skada för verksamheten, tillgångar och data.	Identifiering av HAFNIUM-hot
Regelefterlevnad	Uppdateringar, servicenivåer, härdningsefterlevnad, önskad konfigurationsavvikelse	99,5 % serviceuppdateringar för alla tillgångar
Kontinuitet	Förmåga att överleva och återhämta sig från stora katastrofer och externa händelser.	Tid (rekonstitution)
QoS (Quality of Service)	Egenskaper för användarnas faktiska upplevelse över tid.	Teams samtalskvalitet – mottagen paketförlust < 2 %

Tillförlitlighet

Tillförlitlighet, den klassiska SLO: n, innebär graden av beroende, hållbarhet och kvalitet över tid, för system, tjänster, resurser eller komponenter till fel och redundans, med hanteringsarbete som används för att åtgärda fel (till exempel att skapa mer redundans eller lägga till ett nätverk för innehållsleverans) för att öka drifttiden eller tillgängligheten. Det kan också innebära noggrannhet, återgivning, integritet och pålitlighet för data som används för att mäta SLO:er. Det kan innebära den klassiska sannolikheten att ett system utför sin avsedda funktion under angivna förhållanden, till exempel temperaturbelastning. Motståndskraft innehåller också inbyggda designfaktorer eller funktioner som ger anpassningsbarhet, till exempel skalning, nedkylning, belastningsutjämning, återställning, oförutsägbar efterfrågan, försämrad prestanda under allvarlig stress och design för kontinuitet vid större katastrofer (vanligtvis ett separat SLO).

Kategori	beskrivning	Exempel
Felfrekvens	Antal fel under de totala drifttimmarna	5 fel i 973 timmar vår .00514
Genomsnittlig tid mellan fel (MTBF)	MTBF är invertering av felfrekvens	194,6 timmar

Underhållsmöjlighet

Kombinera servicenivåmål för IT-tjänsthanteringsprocesser som incident- och problemhantering, tillsammans med SLO:er för tillförlitlighet, så att tillgänglighetsmätning kan uppnås.

Kategori	beskrivning	Exempel
Prestanda för tjänstincidenter	Efter kategori eller produkt eller prioritet.	Tids- och kostnadsmått för varje fas i incidentlivscykeln.
Prestanda för säkerhetsincidenter	Efter kategori eller produkt eller prioritet.	Tids- och kostnadsmått för varje fas i incidentlivscykeln.
Komponentens medeltid att reparera (MTTR)	Från händelseidentifiering via återställning eller reparation.
Genomsnittlig tid mellan underhåll (MTBM)	Genomsnittlig eller genomsnittlig tid mellan alla underhållsåtgärder, inklusive förebyggande åtgärder där normalt produktionsarbete utförs.	Se Fördröjningstid för underhåll
Underhållstid (MDT)	Total tid från identifiering till återställning, inklusive logistik och administrativ fördröjning.	Dags att ersätta maskinvaran med beställning, leverans och installation.

Kundupplevelse

Kategori	beskrivning	Exempel
Genomflöde	Mängden, hastigheten eller hastigheten på arbetsbelastningen eller den produktiva belastningen som placeras på ett system över tid.	Transaktioner per tidsenhet.
Felfrekvens	Antalet totala fel i procent.	% säkerhetshändelser
Svarstid	Ett mått på tid eller fördröjning från indata till utdata, förflyttning av arbete genom en process eller från program till användare.	Genomsnittliga sekunder.

Andra

Kategori	beskrivning	Exempel
Kostnad	Mät utgifter, fakturering och fakturor efter tjänst, komponent eller tid.	Kapitalkostnad eller driftskostnader
Täckning	Procentandel av komponenter, system och tjänster som hanteras (efterlevnad)	Regelefterlevnad
Flödestillförlitlighet	Fel med pulsslag, anslutningsappar, ändringar med mera.	Spåra ändringar i verksamhetskritiska företagsdata.
Produktivitet	Effektivitet för att produktivt utföra uppgifter	Arbete, tid efter medarbetare, analytikerproduktivitet.

Att tänka på

• Se till att du har åtkomst. Se till att chefer och andra personer i organisationen beviljas åtkomst till de visualiseringar som är tillgängliga i Azure Monitor eller från andra Azure-tjänster, särskilt Azure SaaS och PaaS, för att undvika att duplicera dem.

• Se till att övervakningstäckningen eller den totala tillgångssynligheten visas. Se till att agenter, utgivna loggar, tabeller och frågor för alla tillgångar som behöver hanteras och skyddas och identifiera "blinda fläckar" eller luckor i täckningen för att säkerställa realitet i SLO:er.

• Hämta rätt data framför rätt konsumenter. Se till att användare av SLO:er och SLO:er kan tolka underliggande data för att skapa förtroende och vägleda beslut med hjälp av den information som hämtas från data.

• Ge rimliga löften. När du ställer in serviceavtal som mål , särskilt när kostnadshantering är viktigt, ska du se till att den faktiska systemprestandan inte är alltför högpresterande eller underleverans, eller justera målet för att hantera kundernas förväntningar.

• Ta hänsyn till oförutsedda externa händelser. Utveckla kontinuitetsplaner och riskbedömningar för att ta hänsyn till händelser som inte står under din kontroll, till exempel väder, strömavbrott eller katastrofer.

• Konto för ändring. Se till att SLO:er står för ändringar i tjänsten eller ändringar i teknisk tillförlitlighet, dataflöde, kvalitet och underhåll – till exempel minskningar av supportpersonalen.

• Ange en balanserad uppsättning SLO:er. Se till att det finns en mängd SLO:er som ger ett balanserat eller 360-graders perspektiv på tjänsten eller systemet och fokus på tillförlitlighet.

Nästa steg

Samla in rätt data