Arkitekturstrategier för analys av felläge

gäller för den här rekommendationen i tillförlitlighetschecklistan för Azure Well-Architected Framework:

Analys av felläge (FMA) hjälper dig att identifiera potentiella felpunkter i din arbetsbelastning och tillhörande flöden. Den här guiden beskriver metodtipsen för att utföra FMA så att du kan planera åtgärdsåtgärder, utforma nya arbetsbelastningar eller omstrukturera befintliga arbetsbelastningar för att minimera den utbredda effekten av fel. Genom att analysera varje steg i flödet och identifiera explosionsradien för flera feltyper kan du förbättra arkitekturens motståndskraft.

En viktig grundsats i FMA är att fel inträffar oavsett hur många lager av återhämtning du tillämpar. Mer komplexa miljöer exponeras för fler typer av fel. Givet denna verklighet tillåter FMA dig att utforma din arbetslast för att klara de flesta typer av fel och återställa på ett smidigt sätt inom specificerade återställningsmål.

Om du hoppar över FMA helt eller utför en ofullständig analys riskerar din arbetsbelastning att drabbas av oförutsägbart beteende och potentiella avbrott som orsakas av en underoptimal design.

Definitioner

Granska och implementera rekommendationerna för att identifiera flöden. Det förutsätts att du har identifierat och prioriterat användar- och systemflöden baserat på kritiskhet.

De data som du samlar in och artefakterna som du skapar i ditt arbete ger dig en konkret beskrivning av dina datasökvägar som ingår i flödena. För att lyckas med ditt FMA-arbete är precision och grundlighet i artefakterna avgörande.

När du har fastställt de kritiska flödena kan du planera de komponenter som krävs. Följ sedan varje flöde steg för steg för att identifiera beroenden, inklusive tjänster från tredje part och potentiella felpunkter, och planera dina åtgärdsstrategier.

Dela upp din arbetsbelastning

När du går från idé till design identifierar du de komponenttyper som stöder din arbetsbelastning. Din arbetsbelastning avgör vilka komponenter som krävs som du måste planera för. Normalt behöver du planera för ingresskontroll, nätverk, beräkning, data, lagring, stödtjänster (t.ex. autentisering, meddelanden och hemlig eller nyckelhantering) och utgående kontroll. I det här skedet av ditt designarbete kanske du inte känner till de specifika teknologier som du kommer att använda, så din design kan komma att se ut som i följande exempel.

När du har skapat din ursprungliga arkitekturdesign lägger du över dina flöden för att identifiera de diskreta komponenter som används i dessa flöden. Skapa listor eller arbetsflödesdiagram som beskriver flödena och deras komponenter. Om du vill förstå komponenternas kritiskhet använder du de kritiska definitioner som du har tilldelat till flödena. Överväg effekten av ett komponentfel på dina flöden.

Identifiera arbetsbelastningsberoenden

Identifiera dina arbetsbelastningsberoenden för att utföra en enskild felanalys. Att dela upp arbetsbelastningen och överläggsflöden ger insikt i beroenden som är interna och externa för arbetsbelastningen.

Interna beroenden är komponenter i arbetsbelastningsomfånget som krävs för att arbetsbelastningen ska fungera. Typiska interna beroenden är API:er eller hemliga och viktiga hanteringslösningar som Azure Key Vault. För dessa beroenden samlar du in tillförlitlighetsdata, till exempel serviceavtal för tillgänglighet och skalningsgränser. Externa beroenden är nödvändiga komponenter som ligger utanför arbetsbelastningens omfång, såsom ett annat program eller en tjänst från tredje part. Vanliga externa beroenden är autentiseringslösningar som Microsoft Entra-ID och lösningar för molnanslutning, till exempel Azure ExpressRoute.

Identifiera och dokumentera beroendena i din arbetsbelastning och inkludera dem i flödesdokumentationens artefakter.

Utvärdera felpunkter i dina flöden

I arbetsbelastningens kritiska flöden bör du överväga varje komponent och avgöra hur komponenten och dess beroenden kan påverkas av ett felläge. Kom ihåg att det finns många fellägen att tänka på när du planerar för återhämtning och återställning. En komponent kan påverkas av mer än ett felläge vid en viss tidpunkt. Överväg läsfel och skrivfel separat eftersom påverkan och möjliga åtgärdssteg varierar. Fellägen omfattar:

• Regionalt avbrott. En hel Azure-region är inte tillgänglig.

• Avbrott i tillgänglighetszonen. En Azure-tillgänglighetszon är inte tillgänglig.

• Avbrott i tjänsten. En eller flera Azure-tjänster är inte tillgängliga.

• Distribuerad överbelastningsattack (DDoS) eller annan skadlig attack.

• Felaktig konfiguration av appar eller komponenter.

• Operatörsfel.

• Planerat underhållsstopp.

• Komponents överbelastning

Analysera alltid effekten i kontexten för det flöde som du försöker analysera, så se till att dokumentera effekten på användaren och det förväntade resultatet av flödet. Om du till exempel har ett e-handelsprogram och analyserar ditt kundflöde kan effekten av ett visst felläge på en eller flera komponenter vara att alla kunder inte kan slutföra utcheckningen.

Överväg sannolikheten för varje typ av felläge. Vissa fellägen är mycket osannolika, till exempel avbrott i flera zoner eller flera regioner. Att lägga till åtgärdsplanering utöver redundans är inte en bra användning av resurser och tid.

Planera begränsningsstrategier

Riskreduceringsstrategier delas in i två breda kategorier: att skapa mer återhämtning och designa för försämrade prestanda.

Att skapa mer motståndskraft omfattar att lägga till redundans till dina komponenter, till exempel infrastruktur, data och nätverk, och att se till att programdesignen följer bästa praxis för hållbarhet, till exempel att dela upp monolitiska program i isolerade appar och mikrotjänster. Mer information finns i Rekommendationer för redundans och rekommendationer för självbevarelsedrift.

Om du vill utforma för försämrad prestanda identifierar du potentiella felpunkter som kan inaktivera en eller flera komponenter i flödet, men som inte helt inaktiverar flödet. Om du vill behålla funktionerna i flödet från slutpunkt till slutpunkt kan du behöva omdirigera ett eller flera steg till andra komponenter eller acceptera att en misslyckad komponent kör en funktion, så att funktionen inte längre är tillgänglig i användarupplevelsen. Om du vill återgå till e-handelsprogrammets exempel kan en misslyckad komponent som en mikrotjänst göra att rekommendationsmotorn inte är tillgänglig, men kunderna kan fortfarande söka efter produkter och slutföra sin transaktion.

Du måste också planera åtgärdsstrategier kring beroenden. Starka beroenden spelar en viktig roll i programfunktionen och tillgängligheten. Om de är frånvarande eller inte fungerar kan de orsaka betydande effekt. Avsaknaden av svaga beroenden kan bara påverka specifika funktioner och inte påverka den övergripande tillgängligheten. Den här skillnaden återspeglar kostnaden för att upprätthålla relationen med hög tillgänglighet mellan tjänsten och dess beroenden. Klassificera beroenden som antingen starka eller svaga för att hjälpa dig att identifiera vilka komponenter som är viktiga för programmet.

Om programmet har starka beroenden som det inte kan fungera utan, bör tillgänglighets- och återställningsmålen för dessa beroenden överensstämma med målen för själva programmet. Minimera beroenden för att få kontroll över programmets tillförlitlighet. Mer information finns i Minimera samordningen mellan programtjänster för att uppnå skalbarhet.

Om programmets livscykel är nära kopplad till livscykeln för dess beroenden kan programmets operativa flexibilitet begränsas, särskilt för nya versioner.

Implementera feldetektering

Felidentifiering är viktigt för att säkerställa att du korrekt identifierar felpunkter i analysen och planerar åtgärdsstrategierna korrekt. I det här sammanhanget innebär identifiering att du övervakar din infrastruktur, dina data och ditt program och aviseringar när problem uppstår. Automatisera identifieringen så mycket som möjligt och skapa redundans i dina driftsprocesser för att säkerställa att aviseringar alltid fångas och besvaras tillräckligt snabbt för att uppfylla dina affärskrav. Mer information finns i Rekommendationerna för övervakning.

Dokumentera dina FMA-resultat

För resultatet av analysen skapar du en uppsättning dokument som effektivt förmedlar dina resultat, de beslut som du har fattat i förhållande till flödeskomponenterna och begränsningen samt effekten av felet på din arbetsbelastning.

I din analys prioriterar du de fellägen och åtgärdsstrategier som du har identifierat baserat på allvarlighetsgrad och sannolikhet. Använd den här prioriteringen för att fokusera dokumentationen på de fellägen som är vanliga och tillräckligt allvarliga för att garantera att du lägger tid, arbete och resurser på att utforma strategier för att minska riskerna. Det kan till exempel finnas vissa fellägen som är mycket sällsynta vid förekomst eller identifiering. Det är inte värt kostnaden att utforma åtgärdsstrategier kring dem.

En startpunkt för dokumentation finns i följande exempeltabell .

Under den första FMA-övningen är de dokument som du skapar mest teoretisk planering. Granska och uppdatera FMA-dokumenten regelbundet för att säkerställa att de hålls uppdaterade i takt med din arbetsbelastning. Kaostestning och verkliga upplevelser hjälper dig att förfina dina analyser över tid.

Azure övervakning

Använd Azure Monitor och Log Analytics för att identifiera problem i din arbetsbelastning. Mer information om problem som rör din infrastruktur, dina appar och databaser finns i verktyg som Application Insights, Container Insights, Network Insights, VM Insights och SQL Insights.

Azure Chaos Studio är en hanterad tjänst som använder kaosteknik för att hjälpa dig att mäta, förstå och förbättra molnappens och tjänstens motståndskraft.

Använd anslutningsövervakare och anslutningsfelsökning i Azure Network Watcher för att modellera och verifiera nätverksanslutningsscenarier innan distribution. Genom att simulera syntetiska tester och felsöka potentiella routningsvägar hjälper dessa verktyg dig att förutse och dokumentera möjliga fellägen i nätverksarkitekturen. Genom att analysera historiska virtuella nätverksflödesloggar med trafikanalys kan du också identifiera mönster för blockerad eller avvikande trafik som kan informera FMA-dokumentationen i Azure-infrastrukturen.

Example

I följande tabell visas ett FMA-exempel för en e-handelswebbplats som finns på Azure App Service-instanser med Azure SQL-databaser och som frontas av Azure Front Door.

Användarflöde: Användarinloggning, produktsökning och kundvagnsinteraktion

Relaterad länk

• Återhämtning och beroenden

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.