Använda affärsmått för att utforma elastiska Azure-program

Tillgänglighetsmål för arbetsbelastningar

Har tillgänglighetsmål som serviceavtal (SLA), servicenivåindikatorer (SLA) och servicenivåmål (SLA) definierats för programmet eller viktiga scenarier?

Det är viktigt att förstå kundernas tillgänglighetsförväntningar för att kunna granska de övergripande åtgärderna för programmet. Om en kund till exempel strävar efter att uppnå ett program-SLO på , kommer den nivå av inbyggd driftsaktivitet som krävs av programmet att vara mycket större än om målet var ett 99.999%99.9% servicenivåmål.

Definiera egna mål-SLA:er för varje arbetsbelastning i din lösning så att du kan avgöra om arkitekturen uppfyller affärskraven.

Ta hänsyn till kostnader och komplexitet

Allt annat är lika, högre tillgänglighet är bättre. Men när du strävar efter fler nior växer kostnaden och komplexiteten. En drifttid 99.99% på översätts till cirka fem minuters total nedtid per månad. Är det värt den extra komplexiteten och kostnaden att nå fem nior? Svaret beror på affärskraven.

Här följer några andra saker att tänka på när du definierar ett SLA:

• Om du vill uppnå fyra nior ( 99.99% ) kan du inte förlita dig på manuella åtgärder för att återställa efter fel. Programmet måste själv kunna diagnosticera och återställa interna fel.
• Utöver fyra nior är det svårt att identifiera avbrott tillräckligt snabbt för att uppfylla serviceavtalet.
• Tänk på vilket tidsfönster som serviceavtalet mäts mot. Ju mindre fönster desto snävare tolerans. Det är inte meningsfullt att definiera serviceavtalet i termer av drifttid per timme eller dag.
• Överväg måtten för MTBF och MTTR. Ju högre serviceavtal du har, desto mindre ofta kan tjänsten gå ned och desto snabbare måste tjänsten återställas.
• Få ett avtal från dina kunder om tillgänglighetsmålen för varje del av ditt program och dokumentera det. Annars kanske din design inte uppfyller kundernas förväntningar.

Identifiera beroenden

Utför övningar för beroendemappning för att identifiera interna och externa beroenden. Exempel är beroenden som rör säkerhet eller identitet, till exempel Active Directory eller tjänster från tredje part, till exempel en betalningsleverantör eller e-posttjänst.

Var särskilt uppmärksam på externa beroenden som kan vara en felpunkt eller orsaka flaskhalsar. Om en arbetsbelastning kräver drifttid men är beroende av en tjänst med ett serviceavtal kan den tjänsten inte vara en 99.99%99.9% felpunkt i systemet. En lösning är att ha en återställningsväg om tjänsten slutar fungera. Du kan också vidta andra åtgärder för att återställa efter ett fel i tjänsten.

I följande tabell visas den potentiella totala avbrottstiden för olika nivåer i serviceavtalet.

Identifiera kritiska systemflöden

Det är viktigt att förstå kritiska systemflöden för att utvärdera den övergripande driftseffektiviteten och bör användas för att informera en hälsomodell för programmet. Den kan också se om delar av programmet är över- eller underutnyttjade och bör justeras för att bättre uppfylla affärsbehov och kostnadsmål.

Kritiska undersystem eller sökvägar genom programmet kan ha högre förväntningar på tillgänglighet, återställning och prestanda på grund av den kritiska komplexiteten i associerade affärsscenarier och funktioner. Detta hjälper också till att förstå om kostnaden kommer att påverkas på grund av dessa högre behov.

Identifiera mindre kritiska komponenter

Vissa mindre kritiska komponenter eller sökvägar genom programmet kan ha lägre förväntningar på tillgänglighet, återställning och prestanda. Mindre kritiska komponenter kan leda till kostnadsminskning genom att välja lägre SKU:er med mindre prestanda och tillgänglighet.

Återställningsmått

Härled dessa värden genom att utföra en riskbedömning och se till att du förstår kostnaden och risken för avbrott och dataförlust. Det här är icke-funktionella krav i ett system och bör styras av affärskrav.

• Mål för återställningstid (RTO) är den längsta godkända tiden som ett program inte är tillgängligt efter en incident.
• Mål för återställningspunkt (RPO) är den maximala varaktigheten för dataförlust som är acceptabel under en katastrof.

Om MTTR-värdet för en kritisk komponent i en konfiguration med hög tillgång överskrider systemets RTO kan ett fel i systemet orsaka ett oacceptabelt verksamhetsavbrott. Det innebär att du inte kan återställa systemet inom definierat RTO.

Tillgänglighetsmått

Använd dessa åtgärder för att planera för redundans och fastställa kundens serviceavtal.

• Genomsnittlig tid för återställning (MTTR) är den genomsnittliga tid det tar att återställa en komponent efter ett fel.
• Medeltid mellan fel (MTBF) är hur länge en komponent rimligen kan förväntas hålla mellan avbrott.

Förstå serviceavtal

I Azure beskriver Serviceavtal Microsofts åtaganden för drifttid och anslutning. Om serviceavtalet för en viss tjänst 99.9% är bör du förvänta dig att tjänsten är tillgänglig för 99.9% tiden. Olika tjänster har olika serviceavtal.

Azure-serviceavtalet innehåller också bestämmelser för att erhålla en tjänstkredit om serviceavtalet inte uppfylls, tillsammans med specifika definitioner av tillgänglighet för varje tjänst. Den här delen av serviceavtalet fungerar som en princip för genomdrivande.

Exemplet Serviceavtal Estimator visar hur du beräknar serviceavtalet för din arkitektur.

Sammansatta serviceavtal

Sammansatta serviceavtal omfattar flera tjänster som stöder ett program, var och en med olika tillgänglighetsnivåer. Tänk dig till exempel en App Service-webbapp som skriver till Azure SQL Database. Vid publiceringen har dessa Azure-tjänster följande serviceavtal:

• App Service webbappar = 99.95%
• SQL Database =99.99%

Vilken är den maximala avbrottstiden du förväntar dig för det här programmet? Om någon av tjänsterna går ned stannar hela programmet. Sannolikheten för att varje tjänst misslyckas är oberoende, så det sammansatta serviceavtalet för det här programmet är 99.95% × 99.99% = 99.94% . Det är lägre än de enskilda serviceavtalen, vilket inte är överraskande eftersom ett program som förlitar sig på flera tjänster har fler potentiella felpunkter.

Du kan förbättra det sammansatta serviceavtalet genom att skapa oberoende återställningsvägar. Om du till exempel SQL Database inte är tillgänglig kan du placera transaktioner i en kö som ska bearbetas senare.

Med den här lösningen fortsätter programmet att vara tillgängligt även om det inte går att ansluta till databasen. Dock går programmet ned om databasen och kön går ned på samma gång. Den förväntade procentandelen tid för ett samtidigt fel är 0.0001 × 0.001 , så det sammansatta serviceavtalet för den här kombinerade sökvägen är:

• Databas eller kö =

Det totala sammansatta serviceavtalet är:

• Webbapp och (databas eller kö) =

Det finns kompromisser med den här metoden. Programlogiken är mer komplex, du betalar för kön och du måste ta hänsyn till problem med datakonsekvens.

Serviceavtal för distributioner i flera regioner

Serviceavtal för distributioner i flera regioner omfattar en teknik med hög tillgänglighet för att distribuera programmet i mer än en region och använda Azure Traffic Manager för redundans om programmet misslyckas i en region.

Det sammansatta serviceavtalet för en distribution i flera regioner beräknas på följande sätt:

• N är det sammansatta serviceavtalet för programmet som distribueras i en region.
• R är antalet regioner där programmet distribueras.

Den förväntade chansen att programmet misslyckas i alla regioner samtidigt är ( (1 − N) ^ R ). Om serviceavtalet för en region till exempel är 99.95% :

• Det kombinerade serviceavtalet för två regioner = (1 − (1 − 0.9995) \^ 2) = 99.999975%
• Det kombinerade serviceavtalet för fyra regioner = (1 − (1 − 0.9995) \^ 4) = 99.999999%

Serviceavtalet för Traffic Manager också en faktor. Redundans misslyckas inte omedelbart i aktiv-passiva konfigurationer, vilket kan leda till driftstopp under en redundans. Läs mer i Traffic Manager endpoint monitoring and failover (Slutpunktsövervakning och redundansväxling för Traffic Manager).