Rekommendationer för att definiera tillförlitlighetsmål
Gäller för denna checklista för Azure Well-Architected Framework Reliability:
| RE:04 | Definiera tillförlitlighets- och återställningsmål för komponenterna, flödena och den övergripande lösningen. Visualisera målen för att förhandla, få konsensus, ställa in förväntningar och driva åtgärder för att uppnå det ideala tillståndet. Använd de definierade målen för att skapa hälsomodellen. Hälsomodellen definierar hur felfria, degraderade och ohälsosamma tillstånd ser ut. |
|---|
Den här guiden beskriver rekommendationerna för att definiera tillgänglighets- och återställningsmålmått för kritiska arbetsbelastningar och flöden. Du bör härleda tillförlitlighetsmål från workshopövningar med affärsintressenter. Förfina sedan dessa mål genom att övervaka och testa dina arbetsbelastningar.
Ställ in realistiska förväntningar med dina interna intressenter om arbetsbelastningens tillförlitlighet. Sedan kan de använda avtal för att förmedla dessa förväntningar till kunderna. Realistiska förväntningar hjälper också intressenter att förstå och stödja dina beslut om arkitekturdesign och vet att du utformar för att optimalt uppfylla de mål som du är överens om.
Överväg att använda följande mått för att kvantifiera dina affärskrav.
| Period | Definition |
|---|---|
| Servicenivåmål (SLO) | Ett mått på prestanda och tillförlitlighet för en arbetsbelastning eller ett program. En SLO är ett specifikt, mätbart mål som du anger för specifika kundinteraktioner. Det är ett mål som du anger för din arbetsbelastning eller ditt program baserat på den tjänstkvalitet som dina kunder förväntar sig att få. |
| Indikator på tjänstnivå (SLI) | Ett kvantitativt mått på en viss aspekt av en tjänsts prestanda. Du kan använda ett SLI för att mäta arbetsbelastningens efterlevnad med ett servicenivåmål. |
| Serviceavtal (SLA) | Ett avtal mellan tjänsteleverantören och servicekund. Om avtalet inte uppfylls kan det få ekonomiska konsekvenser för tjänsteleverantören. |
| Genomsnittlig tid för återställning (MTTR) | Den tid det tar att återställa en komponent när ett fel har identifierats. |
| Genomsnittlig tid mellan fel (MTBF) | Hur lång tid arbetsbelastningen kan utföra den förväntade funktionen utan avbrott tills den misslyckas. |
| Mål för återställningstid (RTO) | Den maximala godkända tid som ett program kan vara otillgängligt efter en incident. |
| Mål för återställningspunkt (RPO) | Den maximala acceptabla varaktigheten för dataförlust under en incident. |
Viktiga designstrategier
Tillförlitlighetsmål representerar det önskade kvalitetsmålet för en arbetsbelastning, vilket utlovas till användarna och affärsintressenterna. Det målet omfattar både tillgänglighet och återställning av arbetsbelastningen. Tänk på att tillförlitlighetsmål skiljer sig från prestandamål, men du bör inkludera prestandamål i tillförlitlighetsmål. Överväg följande tillförlitlighetsmål:
Tillgänglighetsmål definierar kvalitetsstandarderna för att ett system ska förbli tillgängligt och funktionellt. Om det inte uppfyller dessa standarder anses systemet vara otillförlitligt. Använd serviceavtal för att kontrollera om systemet uppfyller dessa standarder. Affärs- och tekniska intressenter samarbetar för att ange realistiska serviceavtal och ta hänsyn till faktorer som jämförande analys, användarupplevelse och arbetsbelastningsprofilen.
Korrekthetsmålen säkerställer att arbetsbelastningen utför sina funktioner korrekt med konsekvent kvalitet. För att mäta korrekthet kvantifierar du arbetsbelastningens indikatorer så att du kan kombinera dem till en enhetlig objektiv poäng.
Återställningsmål motsvarar RTO-, RPO-, MTTR- och MTBF-mått, som kvantifierar effektiviteten i dina planer och testning för affärskontinuitet och haveriberedskap.
För att ange tillförlitlighetsmål definierar affärsintressenter breda krav. Sedan utvärderar tekniska experter arbetsbelastningens aktuella tillstånd och arbetar för att uppnå och underhålla mål genom övervakning och aviseringar. Båda parter måste enas om realistiska mål.
Identifiera och bedöma användar- och systemflöden baserat på deras betydelse för dina affärsbehov. Använd dessa poäng för att vägleda design, granskning, testning och incidenthantering av din arbetsbelastning. Ange tillförlitlighetsmål för dessa flöden och förstå att om du inte uppfyller dessa mål kan det påverka din verksamhet avsevärt.
Kompromiss: Du kan ha en lucka mellan systemets tekniska gränser och dess affärspåverkan, till exempel dataflöde jämfört med transaktioner per sekund. Att överbrygga denna lucka kan vara tufft. Sikta på en praktisk och kostnadseffektiv lösning i stället för överengineering.
Ange tillgänglighetsmål
Det övergripande servicenivåmålet för en arbetsbelastning återspeglar den holistiska kvaliteten, inklusive alla dess beroenden. En mogen deklaration av SLO bör ange det övergripande affärsmålet för den arbetsbelastningen, inte bara en sammansatt av dessa beroenden. Om kunderna till exempel förväntar sig 99,99 % tillgänglighet bör det övergripande serviceavtalet sträva efter det målet, även om en del endast uppnår 99,80 %.
Intressenter utvärderar kundupplevelsen och överväger hur driftstopp påverkar intäkterna. De jämför den här förlusten med kostnaden för att utforma och driva affärsflödet. Beslutsfattarna bestämmer sedan om de ska spendera mer pengar på tillförlitlighet för att undvika intäktsförluster och behålla sitt rykte.
Arbetsbelastningsägare använder ekonomiska mål för att fastställa mål. Affärskrav mappas till mätbara mått. Målet är att identifiera en uppsättning faktorer som påverkar kvaliteten på kundupplevelsen.
Arbetsbelastningsarkitekter fattar många tekniska beslut baserat på serviceavtal. Serviceavtal kan:
Fungera som viktiga indata i arkitekturbeslut när du överväger andra beroenden.
Ge en nära realtidsvy och delad förståelse av hälsotillståndet för en arbetsbelastning för att möjliggöra objektiva diskussioner. De hjälper också arbetsbelastningsteamet att prioritera arbetet med att förbättra tillförlitligheten och utveckla nya funktioner.
Fungera som en primär signal för distributionsåtgärder, som driver automatisk återställning om problem uppstår och ger validering att ändringarna uppnår de förväntade förbättringarna av kundupplevelsen.
Påskynda reparationen och återställningen genom att fokusera på mål, köra automatiserade meddelanden om problem till kunder och skapa förtroende mellan team i din organisation.
Viktigt!
Du måste känna till skillnaden mellan serviceavtal och serviceavtal. Även om serviceavtal och serviceavtal kan använda eller till och med presentera liknande data är deras avsikt annorlunda. Ett serviceavtal är ett formellt kontrakt mellan en organisation och dess kunder, och det har direkta ekonomiska och juridiska konsekvenser om organisationen inte uppfyller sitt löfte. Organisationer använder SLO:er för att utvärdera om den potentiella stilleståndstiden ligger inom de toleransbara gränserna.
Serviceavtal och serviceavtal delar en affärsrelation och bör kontrolleras oberoende av varandra. Om serviceavtalet fungerar som en affärstaktik kan organisationen avsiktligt ange det till ett högt värde baserat på företagets ägares mål. Omvänt kan serviceavtal vara högre. Se verksamhetskritiska arbetsbelastningar som ett exempel. Den här arbetsbelastningsklassen har inte råd med långa stilleståndstider eftersom effekterna, inklusive ekonomiska förluster och till och med hot mot människors säkerhet, är betydande. Därför riktar sig SLO vanligtvis till 99,999 % drifttid, vilket vanligtvis kallas de fem niorna. Om serviceavtal inte uppfyller dessa mål måste organisationer reagera snabbt för att minimera fel och förhindra resultatet av ett misslyckat serviceavtal.
Exemplet i den här artikeln anger ett högt serviceavtal för att stödja affärsmål.
Molnplattforms- och teknikleverantörer publicerar serviceavtal på sina erbjudanden. Du bör överväga serviceavtalen som en del av SLO-beräkningen, men du bör inte använda dem som de är utan att förstå serviceavtalets täckningsomfång. Mer information finns i Utvärdera effekten av Microsofts serviceavtal.
Överväg vanliga serviceavtal och påverka faktorer
Varje servicenivåmål riktar sig mot ett specifikt kvalitetskriterier. Överväg dessa vanliga serviceavtal för tillförlitlighet. Den här listan är inte fullständig. Lägg till serviceavtal baserat på dina affärskrav.
Framgångsfrekvensen mäter lyckade begäranden och processer i förhållande till dem som returnerar ett fel eller misslyckas med uppgiften.
Svarstiden mäter tiden mellan när en begäran om en åtgärd initieras och när resultatet är tillgängligt eller processen är klar.
Kapaciteten mäter samtidig användning, till exempel antalet begränsningsbaserade svar.
Tillgänglighet mäter drifttid ur kundernas perspektiv.
Dataflödet mäter den lägsta dataöverföringshastigheten under en viss tidsperiod. Dataflödet mäts som en datahastighetsenhet, till exempel transaktioner per sekund (TPS) eller begäranden per sekund (RPS).
Förstå scenarier och toleranser för din arbetsbelastning i Azure. Både Azure-tjänster och programkomponenter påverkar arbetsbelastningens SLO. Kombinera svar från följande tabell för att härleda det övergripande SLO:t. Använd dessa frågor som exempel för att utvärdera arbetsbelastningskomponentens verktyg.
| Komponentegenskaper | Kundinteraktion | Andra faktorer |
|---|---|---|
| – Exponerar den API:er för begäran eller svar? – Har den fråge-API :er? - Är det en beräkningskomponent ? - Är det en jobbbearbetningskomponent ? |
- Åtkomst till kontrollplan och hanteringsplan för offentliga Azure-tjänster. - Dataplansåtkomst, till exempel crud-åtgärder (create, read, update och delete). |
– Innebär din lanseringsprocess avbrottstid? - Vad är sannolikheten för att införa buggar? Om arbetsbelastningen integreras med andra system kan du behöva överväga integreringsbuggar. – Hur påverkar rutinåtgärder som korrigeringar tillgänglighetsmålet? Har du räknat med partnerberoenden? - Räcker bemanningen för att stödja konstant rotation vid nöd- och nödsäkerhetskopiering? – Har programmet bullriga grannar utanför din kontrollomfång som potentiellt kan orsaka störningar? |
Fastställa SLO-omfånget
Du kan ange serviceavtal på olika nivåer, till exempel för varje program, arbetsbelastning eller ett specifikt flöde i systemet. Ange nivåspecifika serviceavtal så att du kan anpassa serviceavtal baserat på varje komponents betydelse.
I SaaS-lösningar (programvara som en tjänst) mäter du serviceavtal per kund för att optimera varje kunds upplevelse. Kunder kan ha olika infrastrukturresurser i sina segment. I sådana fall kanske ett systemomfattande SLO som aggregerar alla resurser i kundsegment inte är meningsfullt. Mät i stället SLO:er som överensstämmer med varje kunds specifika kontext. Mer information finns i Innehavarmodeller för en lösning med flera klientorganisationer.
Definiera sammansatta SLO-mål
Serviceavtal måste vara mätbara och mäts inom ett observerbarhetsfönster.
SLO:er är ofta procenttal som 99,90 %, men de kan också vara instruktioner. Använd båda metoderna för att hämta ett numeriskt värde som innehåller alla faktorer.
Ett serviceavtal består av mätbara SLO:er som definierar acceptabla faktorer. SLO:er är mått med ett angivet tröskelvärde som kan aviseras. Du kan samla in dem från en plattform eller ett program. Olika komponenter genererar relevanta SLO:er. När du väljer SLO:er bör du överväga faktorer som påverkar SLO:et.
Om du till exempel vill beräkna SLO för ett flöde som använder ett svars- och begärande-API mäter du serverns svarstid och bearbetningstid för begäranden. Dataflödes- och felfrekvenser gäller inte för kontinuerliga beräkningsmiljöer som virtuella datorer, skalningsuppsättningar eller Azure Batch.
För kontrollplansåtkomst bör du överväga felfrekvenser och svarstider för API-svar och långvariga åtgärder som att skapa resurser. Åtkomst till dataplanet beror på vilka API:er som används, var och en med sina egna SLO-mål.
Ett bra SLI visar när du kan bryta mot en SLO. Den mäts vanligtvis i percentiler. Här följer några vanliga percentiler och den uppskattade tiden för inkompatibilitet till den förväntade tillgängligheten.
| Mål | Inkompatibilitet per vecka | Inkompatibilitet per månad | Inkompatibilitet per år |
|---|---|---|---|
| 99 % | 1,68 timmar | 7,20 timmar | 3,65 dagar |
| 99.90% | 10,10 minuter | 43,20 minuter | 8,76 timmar |
| 99,95 % | 5 minuter | 21,60 minuter | 4,38 timmar |
| 99,99 % | 1,01 minuter | 4,32 minuter | 52,56 minuter |
| 99,999 % | 6 sekunder | 25,90 sekunder | 5,26 minuter |
Viktigt!
Ett sammansatt SLO-värde är en produktdistribution av de bidragande faktorerna.
Ett exempel på sammansatt SLO är 99,95 % × 99,99999 % = ~99,95 %.
När du skapar sammansatta serviceavtal för olika flöden bör du tänka på deras varierande allvarlighetsgrad och relevans. Flöden kan ha komponenter som du anser vara icke-kritiska och utelämna från dina beräkningar. Du kan motivera deras utelämnande baserat på om deras korta otillgänglighet påverkar kundens upplevelse. I vissa fall kanske en komponent inte är relevant för det användningsfall som du överväger för SLO. Du kan också utelämna dessa komponenter från beräkningen.
Samma princip gäller för åtgärder. Vissa åtgärder kan medföra risker eller påverka SLO och andra är obetydliga. Beslutet bör vara explicit och bygga på samförstånd.
Ett illustrativt exempel på hur du definierar och mäter SLO:er och SLO:er finns i avsnittet Exempel .
Utvärdera effekten av Microsofts serviceavtal
Ett Microsoft-serviceavtal ger insikt i tillgängligheten för områden som Microsoft förbinder sig till. Serviceavtal garanterar inte ett erbjudande som helhet. När du utvärderar serviceavtal har du en god förståelse för den täckning som tillhandahålls kring den publicerade percentilen.
Överväg Web Apps, en funktion i Azure App Service. Funktionen anses vara tillgänglig när den returnerar statusen 200 OK i ett angivet användningsfall. Inom den specifika kontexten och tidsramen täcker den inte en ekonomiskt säkerhetskopierad garanti för tillgängligheten av funktioner som Easy Auth eller fackväxling. Du bör överväga områden som inte uttryckligen nämns i avtalet som tillgängliga för plattformens bästa arbete.
Så om din arbetsbelastning förlitar sig på distributionsplatser kan du inte härleda ditt SLO enbart från App Service SLA. Som arbetsbelastningsteam måste du säkra och förutsäga tillgängligheten för drifttiden. Den här förutsägelsen kan dock vara osäker, vilket är anledningen till att det kan vara problematiskt att nära binda ditt serviceavtal till plattformens serviceavtal.
Överväg ett annat exempel. Om Azure Front Door har 99,99 % tillgänglighet måste din design följa specifika kriterier som publiceras i avtalet. Till exempel måste serverdelen innehålla lagring, du behöver en GET åtgärd som kan hämta en fil med minst 50 KB i storlek och du måste distribuera agenter på flera platser på minst fem geografiskt olika platser. Det här smala användningsfallet för Azure Front Door garanterar inte funktioner som cachelagring, routningsregler eller en brandvägg för webbprogram. Dessa aspekter ligger utanför serviceavtalets omfång.
Implementera mål för flera regioner
Ur ett tillförlitlighetsperspektiv är distribution i flera regioner en implementering av principen om redundans. Målet är att minska risken för ett regionalt avbrott eller försämrade prestanda. Den här strategin, när den är korrekt utformad, kan förbättra serviceavtalen eftersom den lägger till en sekundär region i redundanssyfte.
Det finns två huvudsakliga användningsfall:
Mönster för hög tillgänglighet, där du distribuerar en belastning mellan regioner för mer kapacitet. Hög tillgänglighet begränsar inte arbetsbelastningsanvändare till en region, och hela systemets prestanda bidrar till SLO.
Skottmönster, där du begränsar kunder till specifika regioner för att segmentera dem. I sådana fall behandlar du distributioner i flera regioner som separata distributioner eller stämplar i varje region. Mät hälsotillståndet för varje stämpel separat med de SLO:er som är lämpliga för din arbetsbelastning. Överväg den övergripande arbetsbelastningens SLO baserat på hälsotillståndet för varje stämpel. Om du kan redundansväxla mellan stämplar är din övergripande arbetsbelastnings-SLO högre eftersom ett fel i en stämpel kan återställas via en redundansväxling till en annan stämpel.
Var uppmärksam på hur mycket redundans du behöver för att uppfylla höga serviceavtal. Microsoft garanterar till exempel högre serviceavtal för distributioner i flera regioner av Azure Cosmos DB än det garanterar för distributioner med en region.
Definiera återställningsmått
Definitioner för realistiska återställningsmål, till exempel RTO-, RPO-, MTTR- och MTBF-mått, förlitar sig på analys av felläge och dina planer och testning för affärskontinuitet och haveriberedskap. När du definierar dessa mål tar du hänsyn till återställningsgarantierna som tillhandahålls av plattformen. Microsoft publicerar RTO- och RPO-garantier endast för vissa produkter, till exempel Azure SQL Database.
Innan du slutför det här arbetet ska du diskutera ambitiösa mål med intressenter och se till att arkitekturdesignen stöder återställningsmålen så bra som du förstår. Kommunicera tydligt för intressenter att alla flöden eller hela arbetsbelastningar som inte testas noggrant för återställningsmått inte ska ha garanterade serviceavtal. Se till att intressenterna förstår att återställningsmålen kan ändras med tiden när arbetsbelastningarna uppdateras. Arbetsbelastningen kan bli mer komplex när du lägger till kunder eller när du använder nya tekniker för att förbättra kundupplevelsen. Dessa ändringar kan öka eller minska dina återställningsmått.
Kommentar
MTBF kan vara svårt att definiera och garantera. PaaS- eller SaaS-modeller (Plattform som en tjänst) kan misslyckas och återställas utan något meddelande från molnleverantören, och processen kan vara helt transparent för dig eller dina kunder. Om du definierar mål för det här måttet täcker du endast komponenter som står under din kontroll.
När du definierar återställningsmål definierar du tröskelvärden för att initiera en återställning. Om en webbnod till exempel inte är tillgänglig i mer än fem minuter lägger du automatiskt till en ny nod i poolen. Definiera tröskelvärden för alla komponenter och fundera över vad återställningen för en specifik komponent innebär, inklusive effekten på andra komponenter och beroenden. Dina tröskelvärden bör också ta hänsyn till tillfälliga fel för att säkerställa att du inte startar återställningsåtgärder för snabbt. Dokumentera och dela med intressenterna de potentiella riskerna, till exempel dataförlust eller sessionsavbrott för kunder, för återställningsåtgärder.
Övervaka och visualisera målen
Använd de data som du samlar in för dina tillförlitlighetsmål för att skapa din hälsomodell för varje arbetsbelastning och tillhörande kritiska flöden. En hälsomodell definierar felfria, degraderade och felfria tillstånd för flöden och arbetsbelastningar. När tillståndet ändras bör modellen varna de ansvariga parterna. Detaljerade designöverväganden och rekommendationer finns i Vägledning för hälsomodellering.
Om du vill hålla dina driftteam och arbetsbelastningsintressenter informerade skapar du en visualisering som återspeglar realtidsstatusen och de övergripande trenderna för arbetsbelastningshälsomodellen. Diskutera visualiseringslösningar med intressenterna för att säkerställa att du levererar information som de värdesätter och som är lätt att använda. De kanske också vill se genererade rapporter varje vecka, varje månad eller kvartal.
Azure-underlättande
Azure-serviceavtal tillhandahåller Microsoft-åtaganden för drifttid och anslutning. Olika tjänster har olika serviceavtal, och ibland har produkter inom en tjänst olika serviceavtal. Mer information finns i Serviceavtal för onlinetjänster.
Azure SLA innehåller procedurer för att få en tjänstkredit om din arbetsbelastning inte uppfyller serviceavtalet, tillsammans med definitioner av tillgänglighet för varje tjänst. Den här delen av serviceavtalet fungerar som en princip för genomdrivande.
Utforska Azure Monitor-instrumentpanelerna för visualiseringssystemet.
Exempel
Contoso, Ltd. utformar en ny mobil upplevelse för sitt biljettsystem för evenemang. Här är den övergripande arkitekturen.
Grafana-logotypen är ett varumärke som tillhör respektive företag. Inget godkännande understås av användningen av det här märket.
Komponenter
Här är några komponenter som illustrerar begreppet SLO-definition. Det finns komponenter i den här arkitekturen som inte ingår i följande lista. Även om Key Vault till exempel är en del av det kritiska begärandeflödet är det inte en del av svarsanvändningsfallet. Om Key Vault inte är tillgängligt fortsätter programmet att fungera med hjälp av hemligheter som läses in under starten. Men om programmet behöver skalas blir Key Vault-tillgängligheten kritisk eftersom nya noder måste läsas in med hemligheter. I det här exemplet beaktas inte skalningsåtgärder. Andra komponenter utelämnas för korthet.
Azure Front Door är den enda startpunkten som exponerar ett API som kunder använder för att skicka begäranden.
Azure Container Apps är den miljö som arbetsbelastningsteamet äger och använder för att köra affärslogik för programmet.
SQL Managed Instance ägs och hanteras av ett annat team och är ett kritiskt beroende av arbetsbelastningen.
Azure Private Link tillhandahåller privata anslutningar mellan distributioner av Azure Front Door och Container Apps. SQL Managed Instance exponeras också för programmet via en privat slutpunkt.
I den här arkitekturen definierar API-teamet ett första SLO-mål för kritiska flöden i programmet. De antar den strategi som beskrivs i Faktorer som påverkar SLO:er. De syftar till att definiera mål som täcker kärnfunktionerna utan att alltför betona kompletterande funktioner. De mäter hälsotillståndet för tre kritiska användarflöden, som omfattar alla kärnfunktioner i molnet och kör kod mellan distributioner. Dessa flöden omfattar dock inte all kod- eller dataåtkomst. Här är de faktorer som påverkar.
Beräkna ett sammansatt SLO
SLO för Azure-tillgänglighet: Serviceavtalet för ekonomiskt åtagande för Azure fungerar som en proxy för att utvärdera plattformens tillförlitlighet.
Azure-komponent Tillämplig SLA-täckning Omfattas inte av serviceavtal Justerat SLO Azure Front Door 99,99 % för lyckade HTTP-åtgärder GETCachelagring, regelmotor 99.98% Container Apps 99,95 % baserat på distribuerade appar som kan nås av den inbyggda ingressen Funktioner för automatisk skalning, tokenlagring 99,95 % SQL-hanterad instans 99,99 % baserat på anslutningen till SQL Server-instansen Prestanda, datakvarhållning 99.80% Private Link 99,99 % baserat på hela minuter när det privata slutpunktsnätverket inte accepterade trafik eller när trafiken inte flödade mellan slutpunkten och Private Link-tjänsten Enskilda fel varar i mindre än en minut 99,99 % Justeringen baseras på flera faktorer som är beroende av arbetsbelastningsteamets löfte om sina mål. En faktor kan vara förtroende för plattformens kapacitet baserat på tidigare erfarenhet. För Container Apps och Private Link känner sig teamet till exempel bekvämt med att ta SLA-värdet som det är.
Det finns också nyanserade faktorer. Teamet sänker till exempel SLO-värdet för SQL Managed Instance till 99,80 % för att ta hänsyn till potentiella fel i deras dataåtgärder, till exempel schemaändringar och säkerhetskopiering.
Teamet anger det sammansatta SLO:et genom att beräkna effekten av enskilda, justerade SLO-värden. Det här värdet är 99,72 %.
Det finns andra bidragande faktorer. Arkitekturen förlitar sig på Azure-nätverkskomponenter som virtuella nätverk och nätverkssäkerhetsgrupper (NSG:er) som inte har något publicerat serviceavtal. Arbetsbelastningsteamet bestämmer sig för att överväga dessa faktorer med 99,99 % tillgänglighet för varje komponent.
Ett sammansatt SLO baserat på förväntad plattformstillgänglighet: 99,68 % per månad.
Programkod-SLO: Teamet bekräftar att buggar i deras programkod eller lagrade procedurer kan påverka systemets tillgänglighet, och de allokerar en timmes månatlig stilleståndstid för att ta hänsyn till kodrelaterade fel.
De använder vanliga stilleståndsprocentiler för att uppskatta SLO för enskilda faktorer som kodfel, skalningsproblem och andra kodrelaterade överväganden.
Ett sammansatt SLO baserat på kod- och datatillgänglighet: 99,86 % per månad.
SLO för resurs- och programkonfiguration: Teamet inser att molnresurser och programkod måste vara korrekt konfigurerade. Det här målet omfattar att konfigurera regler för automatisk skalning, distribuera NSG-regler och välja rätt storlek på SKU:er. För att ta hänsyn till konfigurationsfel budgeteras 10 minuters månatlig stilleståndstid, vilket är cirka 99,98 % tillgänglighet.
Ett sammansatt SLO baserat på konfigurationstillgänglighet: 99,95 % per månad.
Drifts-SLO: Arbetsbelastningsteamet utvecklar en bra DevOps-kultur genom att följa väldefinierade ramverksprinciper för operational excellence. De distribuerar molnresurser, konfiguration och kodar varje sprint.
Teamet anser att distributioner är en risk eftersom de kan destabilisera ett system som körs. Det kan uppstå fel till följd av TLS-certifikatuppdateringar, DNS-ändringar eller verktygsfel. Teamet överväger också potentiell stilleståndstid som orsakas av nödkorrigeringar. De budgetar totalt 20 minuters månatlig stilleståndstid, vilket är cirka 99,95 % tillgänglighet.
Underhållsperioder är avsedda tidsperioder under vilka systemunderhåll eller uppdateringar sker. API:et används mestadels i ungefär fyra timmar varje dag. För att minska risken för otillgänglighet kan teamet schemalägga underhållsaktiviteter under de mindre aktiva timmarna. Den här metoden leder till ett högre servicenivåmål, men teamet bestämmer sig för att inte inkludera underhållsperioden som en del av sitt servicenivåmål.
Ett sammansatt SLO baserat på drifttillgänglighet: 99,95 % per månad.
SLO för externa beroenden: Teamet betraktar SQL Managed Instance som det primära beroendet, som redan har en tillgänglighet på 99,80 % som räknas in i den övergripande plattformstillgängligheten. Inga andra externa beroenden beaktas.
Ett sammansatt SLO baserat på externa beroenden: Inte tillämpligt.
Fastställa det övergripande sammansatta SLO-resultatet
Det övergripande sammansatta SLO-målet anges till 99,45 %, vilket motsvarar cirka fyra timmars stilleståndstid per månad.
För att uppfylla SLO-målet på endast fyra timmars otillgänglighet per månad upprättar arbetsbelastningsteamet en jourrotation. Både kundsupport och syntetisk transaktionsövervakning kan anropa SRE-stöd (Site Reliability Engineering) på jour för att snabbt starta återställningssteg för att åtgärda SLO-problem.
Ange serviceavtalet för arbetsbelastning
Serviceavtalet för arbetsbelastningen är 99,90 % tillgänglighet per månad.
Arbetsbelastningsteamets juridiska avdelningar och ekonomiavdelningar anger serviceavtalet för arbetsbelastningen till 99,90 % tillgänglighet per månad, vilket överskrider SLO-målet på 99,45 %. De fattar det här beslutet när de har analyserat ekonomiska utbetalningar jämfört med den beräknade kundtillväxten baserat på ett attraktivt serviceavtal. Serviceavtalet omfattar två grundläggande användarflöden och innehåller prestandaöverväganden, inte bara tillgänglighet. Det är en beräknad risk som affärsteamet tar för att gynna verksamheten, och teknikteamet är medvetna om åtagandet.
Ange korrekt SLO
Programmets grundläggande användarflöden måste vara tillgängliga och användbara, eller till och med konkurrenskraftigt, dynamiska. Teamet anger en svarstids-SLO specifikt för API:et, exklusive klientbearbetningstid och internetnätverksbläddering. De utvärderar endast detta serviceavtal under perioder av tillgänglighet. De väljer den 75:e percentilen som både SLO-målet och prestandamätningen, vilket fångar den typiska kundupplevelsen och exkluderar scenarier i värsta fall.
Relaterade länkar
Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure
Checklista för tillförlitlighet
Se den fullständiga uppsättningen rekommendationer.