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 dina lösningskomponenter. Utför FMA för att hjälpa dig att bedöma risken och effekten av varje felläge. Avgör hur arbetsbelastningen svarar och återställs. |
|---|
Den här guiden beskriver metodtipsen för att utföra fellägesanalys (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 explosionsradien 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 för att klara 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 drabbas av 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 degraderas eller påverkas allvarligt till den grad att de inte är tillgängliga. |
| Riskreducering | De aktiviteter som du har identifierat för att lösa problem proaktivt eller reaktivt. |
| Detection | Processer och procedurer för infrastruktur, data och appövervakning och aviseringar. |
Viktiga designstrategier
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 artefakterna som du har skapat i ditt arbete ger dig en konkret beskrivning av de datavägar som ingår i flödena. För att lyckas med fma-arbetet är noggrannhet och noggrannhet 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 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 hemlig 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 den första arkitekturdesignen 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ö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 beroenden
Identifiera dina arbetsbelastningsberoenden för att utföra din analys av enskilda felpunkter. 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 lösningar för hantering av hemligheter/nycklar 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 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 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. 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 överbelastning (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 utcheckningen.
Ö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 planering för åtgärder utöver redundans är inte en bra användning av resurser och tid.
Riskreducering
Riskreduceringsstrategier delas in i två breda kategorier: att skapa mer återhämtning och designa 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 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ä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. 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.
Detection
Felidentifiering är viktigt för att säkerställa att du korrekt har identifierat felpunkter i analysen och planerat åtgärdsstrategierna korrekt. Identifiering i den här kontexten innebär övervakning av 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.
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 strategier för åtgärder runt 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. 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 molnprograms- 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
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
| Komponent | Risk | Sannolikhet | Effekt/minskning/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 | Medium | 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 externt |
| 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 | Medium | Felkonfigurationer bör fångas under distributionen. Om dessa inträffar under en konfigurationsuppdatering måste administratörer återställa ändringar. Konfigurationsuppdateringen orsakar ett kort externt avbrott. | Endast externt |
| Azure Front Door | DDOS-attack | Medium | Risk för avbrott. Microsoft hanterar DDoS-skydd (L3 och L4) och Azure Web Application Firewall blockerar de flesta hoten. Potentiell risk för effekt från L7-attacker. | Potential 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 | Gruppen för automatisk redundans redundansväxling redundansväxlar över till en sekundär region. 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 full |
| Azure SQL | Avbrott i tillgänglighetszonen | Låg | Ingen effekt | Ingen |
| Azure SQL | Skadlig attack (inmatning) | Medium | Minimal risk. Alla Azure SQL-instanser är virtuella nätverksbundna 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 effektpotential. | Ingen |
| App Service | DDOS-attack | Medium | 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.