Rekommendationer för analys av felläge
Gäller för denna checklista för Azure Well-Architected Framework Reliability:
| RE:03 | Använd analys av felläge (FMA) för att identifiera och prioritera potentiella fel i lösningskomponenterna. Utför FMA för att hjälpa dig att bedöma risken och effekten av varje felläge. Fastställa hur arbetsbelastningen svarar och återställs. |
|---|
Den här guiden beskriver metodtipsen för att utföra analys av felläge (FMA) för din arbetsbelastning. FMA är en metod för att identifiera potentiella felpunkter i din arbetsbelastning och tillhörande flöden och planera åtgärder i enlighet med detta. I varje steg i flödet identifierar du blastradien för flera feltyper, vilket hjälper dig att utforma en ny arbetsbelastning eller omstrukturera en befintlig arbetsbelastning för att minimera den utbredda effekten av fel.
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. Med den här verkligheten kan du med FMA utforma din arbetsbelastning så att den klarar de flesta typer av fel och återställa korrekt när ett fel inträffar.
Om du hoppar över FMA helt eller utför en ofullständig analys riskerar din arbetsbelastning att få ett oförutsägbart beteende och potentiella avbrott som orsakas av en underoptimal design.
Definitioner
| Period | Definition |
|---|---|
| Feltillstånd | En typ av problem som kan orsaka att en eller flera arbetsbelastningskomponenter försämras eller påverkas allvarligt till den grad att de inte är tillgängliga. |
| Åtgärd | De aktiviteter som du har identifierat för att åtgärda problem antingen proaktivt eller reaktivt. |
| Identifiering | Dina processer och procedurer för infrastruktur, data och appövervakning och aviseringar. |
Viktiga designstrategier
Förutsättningar
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 har samlat in och de artefakter som du har skapat i ditt arbete ger dig en konkret beskrivning av dina datasökvägar som ingår i flödena. För att du ska lyckas med fma-arbetet är noggrannhet och noggrannhet i artefakterna avgörande.
FMA-metod
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 riskreduceringsstrategier.
Dela upp arbetsbelastningen
När du går från idé till design måste du identifiera de komponenttyper som krävs för att stödja 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 hemlighetshantering eller nyckelhantering) och utgående kontroll. I det här skedet av designarbetet kanske du inte känner till de specifika tekniker som du distribuerar, så din design kan se ut som i följande exempel.
När du har skapat din ursprungliga arkitekturdesign kan du lägga över dina flöden för att identifiera de diskreta komponenter som används i dessa flöden och skapa listor eller arbetsflödesdiagram som beskriver flöden och deras komponenter. Om du vill förstå komponenternas allvarlighetsgrad använder du de kritiska definitioner som du har tilldelat till flödena. Överväg effekten av ett komponentfel på dina flöden.
Identifiera beroenden
Identifiera dina arbetsbelastningsberoenden för att utföra din analys av enskilda felpunkter. Genom att dela upp dina arbetsbelastnings- och överläggsflöden får du 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. Vanliga interna beroenden är API:er eller lösningar för hemlighets-/nyckelhantering 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 krävs komponenter utanför arbetsbelastningens omfång, till exempel ett annat program eller en tjänst från tredje part. Vanliga externa beroenden är autentiseringslösningar som Microsoft Entra ID och molnanslutningslösningar, till exempel Azure ExpressRoute.
Identifiera och dokumentera beroendena i din arbetsbelastning och inkludera dem i flödesdokumentationens artefakter.
Felpunkter
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 fler än ett felläge vid en viss tidpunkt. Dessa 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.
Operatorfel.
Planerat underhållsstopp.
Komponentöverlagring.
Analysen bör alltid finnas 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 kassan.
Överväg sannolikheten för varje typ av felläge. Vissa är mycket osannolika, till exempel avbrott i flera zoner eller flera regioner, och att lägga till åtgärdsplanering utöver redundans är inte en bra användning av resurser och tid.
Åtgärd
Riskreduceringsstrategier delas in i två breda kategorier: skapa mer återhämtning och design för försämrade prestanda.
Att skapa mer återhämtning 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 kan du identifiera potentiella felpunkter som kan inaktivera en eller flera komponenter i ditt flöde, men inte helt inaktivera 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 exemplet med e-handelsprogram 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 transaktionen.
Du måste också planera åtgärder kring beroenden. Starka beroenden spelar en viktig roll i programfunktionen och tillgängligheten. Om de är frånvarande eller upplever ett fel kan det finnas betydande effekt. Frånvaron 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 själva programmets mål. 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 driftseffektivitet vara begränsad, särskilt för nya versioner.
Identifiering
Felidentifiering är viktigt för att säkerställa att du korrekt har identifierat felpunkter i analysen och planerat dina åtgärdsstrategier korrekt. Identifiering i det här sammanhanget innebär övervakning av din infrastruktur, dina data och ditt program samt 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 Rekommendationer för övervakning.
Resultat
För resultatet av analysen skapar du en uppsättning dokument som effektivt kommunicerar 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, ansträngning 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. Att utforma riskreduceringsstrategier runt dem är inte värt kostnaden.
I följande exempeltabell finns en startpunkt för dokumentationen.
Under den första FMA-övningen kommer de dokument som du producerar främst att vara teoretisk planering. FMA-dokumenten bör granskas och uppdateras regelbundet för att säkerställa att de är uppdaterade med din arbetsbelastning. Kaostestning och verkliga upplevelser hjälper dig att förfina dina analyser över tid.
Azure-underlättande
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 din molnprogram- och tjänstresiliens.
Information om hur du tillämpar FMA-principer på vanliga Azure-tjänster finns i Analys av felläge för Azure-program.
Exempel
Följande tabell visar 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
| Komponent | Risk | Sannolikheten | Effekt/riskreducering/anmärkning | Avbrott |
|---|---|---|---|---|
| Microsoft Entra ID | Tjänstavbrott | Låg | Fullständigt avbrott i arbetsbelastningen. Beroende av Microsoft för att åtgärda. | Fullständig |
| Microsoft Entra ID | Felaktig konfiguration | Medel | Användare kan inte logga in. Ingen nedströmseffekt. Supportavdelningen rapporterar konfigurationsproblem till identitetsteamet. | Ingen |
| Azure Front Door | Tjänstavbrott | Låg | Fullständigt avbrott för externa användare. Beroende av Microsoft för att åtgärda. | Endast extern |
| Azure Front Door | Regionalt avbrott | Mycket låg | Minimal effekt. Azure Front Door är en global tjänst, så global trafikdirigering dirigerar trafik via icke-påverkade Azure-regioner. | Ingen |
| Azure Front Door | Felaktig konfiguration | Medel | Felkonfigurationer bör fångas under distributionen. Om dessa inträffar under en konfigurationsuppdatering måste administratörer återställa ändringarna. Konfigurationsuppdateringen orsakar ett kort externt avbrott. | Endast extern |
| Azure Front Door | DDOS-attack | Medel | Risk för avbrott. Microsoft hanterar DDoS-skydd (L3 och L4) och Azure Web Application Firewall blockerar de flesta hot. Potentiell risk för effekt från L7-attacker. | Risk för partiellt avbrott |
| Azure SQL | Tjänstavbrott | Låg | Fullständigt avbrott i arbetsbelastningen. Beroende av Microsoft för att åtgärda. | Fullständig |
| Azure SQL | Regionalt avbrott | Mycket låg | Redundansväxlingsgruppen redundansväxlar till den sekundära regionen. Potentiellt avbrott under redundansväxling. Mål för återställningstid (RTO) och mål för återställningspunkter som ska fastställas under tillförlitlighetstestning. | Potentiell fullständig |
| Azure SQL | Avbrott i tillgänglighetszonen | Låg | Ingen effekt | Ingen |
| Azure SQL | Skadlig attack (inmatning) | Medel | Minimal risk. Alla Azure SQL instanser är virtuella nätverk som är bundna via privata slutpunkter och nätverkssäkerhetsgrupper (NSG:er) lägger till ytterligare skydd för intra-virtuella nätverk. | Potentiell låg risk |
| App Service | Tjänstavbrott | Låg | Fullständigt avbrott i arbetsbelastningen. Beroende av Microsoft för att åtgärda. | Fullständig |
| App Service | Regionalt avbrott | Mycket låg | Minimal effekt. Svarstid för användare i regioner som påverkas. Azure Front Door dirigerar automatiskt trafik till icke-påverkade regioner. | Ingen |
| App Service | Avbrott i tillgänglighetszonen | Låg | Ingen effekt. Apptjänster har distribuerats som zonredundanta. Utan zonredundans finns det en potentiell effekt. | Ingen |
| App Service | DDOS-attack | Medel | Minimal effekt. Inkommande trafik skyddas av Azure Front Door och Azure Web Application Firewall. | Ingen |
Relaterade länkar
Checklista för tillförlitlighet
Se den fullständiga uppsättningen rekommendationer.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för