Share via

Aanbevelingen voor het uitvoeren van analyse van foutmodus

  • Artikel

Van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:03 Gebruik foutmodusanalyse (FMA) om mogelijke fouten in uw oplossingsonderdelen te identificeren en prioriteit te geven. Voer FMA uit om u te helpen het risico en effect van elke foutmodus te beoordelen. Bepaal hoe de workload reageert en herstelt.

In deze handleiding worden de best practices beschreven voor het uitvoeren van een analyse van de foutmodus (FMA) voor uw workload. FMA is de praktijk van het identificeren van potentiële storingspunten binnen uw workload en de bijbehorende stromen en het plannen van risicobeperkingsacties dienovereenkomstig. Bij elke stap van de stroom identificeert u de straal van meerdere fouttypen, zodat u een nieuwe workload kunt ontwerpen of een bestaande workload kunt herstructureren om het wijdverbreide effect van fouten te minimaliseren.

Een belangrijk kenmerk van FMA is dat er fouten optreden, ongeacht het aantal tolerantielagen dat u toepast. Complexere omgevingen worden blootgesteld aan meer soorten fouten. Gezien deze realiteit kunt u met FMA uw workload zo ontwerpen dat deze bestand is tegen de meeste soorten fouten en probleemloos herstellen wanneer er een fout optreedt.

Als u FMA helemaal overslaat of een onvolledige analyse uitvoert, loopt uw workload het risico op onvoorspelbaar gedrag en mogelijke storingen die worden veroorzaakt door een suboptimaal ontwerp.

Definities

Termijn Definitie
Foutmodus Een type probleem dat ertoe kan leiden dat een of meer workloadonderdelen worden gedegradeerd of ernstig worden beïnvloed tot het punt dat ze niet beschikbaar zijn.
Oplossing De activiteiten die u hebt geïdentificeerd om problemen proactief of reactief op te lossen.
Detectie Uw infrastructuur, gegevens en app-bewakings- en waarschuwingsprocessen en -procedures.

Belangrijke ontwerpstrategieën

Vereisten

Bekijk en implementeer de aanbevelingen voor het identificeren van stromen. Er wordt van uitgegaan dat u gebruikers- en systeemstromen hebt geïdentificeerd en prioriteit hebt gegeven op basis van kritiek.

De gegevens die u hebt verzameld en de artefacten die u in uw werk hebt gemaakt, bieden u een concrete beschrijving van uw gegevenspaden die betrokken zijn bij de stromen. Om succesvol te zijn in uw FMA-werk, is nauwkeurigheid en grondigheid in uw artefacten essentieel.

FMA-benadering

Nadat u de kritieke stromen hebt bepaald, kunt u de vereiste onderdelen ervan plannen. Volg vervolgens elke stroom stap voor stap om afhankelijkheden te identificeren, waaronder services van derden en mogelijke zwakke punten, en plan uw risicobeperkingsstrategieën.

De workload opsnleden

Wanneer u van ideegeving naar ontwerp overgaat, moet u de onderdeeltypen identificeren die nodig zijn om uw workload te ondersteunen. Uw workload bepaalt de benodigde onderdelen die u moet plannen. Normaal gesproken moet u plannen voor toegangsbeheer, netwerken, berekeningen, gegevens, opslag, ondersteunende services (zoals verificatie, berichten en geheim- of sleutelbeheer) en uitgaand verkeer. In deze fase van uw ontwerpwerk kent u mogelijk niet de specifieke technologieën die u gaat implementeren, dus uw ontwerp kan eruitzien als in het volgende voorbeeld.

Diagram met het ontwerpvoorbeeld.

Nadat u het eerste architectuurontwerp hebt gemaakt, kunt u uw stromen overlays leggen om de afzonderlijke onderdelen te identificeren die in deze stromen worden gebruikt en lijsten of werkstroomdiagrammen te maken waarin de stromen en hun onderdelen worden beschreven. Als u inzicht wilt krijgen in de ernst van de onderdelen, gebruikt u de kritieke definities die u aan de stromen hebt toegewezen. Houd rekening met het effect van een storing van een onderdeel op uw stromen.

Afhankelijkheden identificeren

Identificeer uw workloadafhankelijkheden om uw single point-of-failure-analyse uit te voeren. Het opsplitsen van uw workload en het overlayen van stromen biedt inzicht in afhankelijkheden die intern en extern zijn voor de workload.

Interne afhankelijkheden zijn onderdelen in het workloadbereik die vereist zijn om de workload te laten functioneren. Typische interne afhankelijkheden zijn API's of oplossingen voor geheim-/sleutelbeheer, zoals Azure Key Vault. Leg voor deze afhankelijkheden de betrouwbaarheidsgegevens vast, zoals beschikbaarheids-SLA's en schaallimieten. Externe afhankelijkheden zijn vereiste onderdelen buiten het bereik van de workload, zoals een andere toepassing of service van derden. Typische externe afhankelijkheden zijn verificatieoplossingen, zoals Microsoft Entra ID, en cloudconnectiviteitsoplossingen, zoals Azure ExpressRoute.

Identificeer en documenteer de afhankelijkheden in uw workload en neem deze op in uw stroomdocumentatieartefacten.

Foutpunten

Houd in de kritieke stromen van uw workload rekening met elk onderdeel en bepaal hoe dat onderdeel en de bijbehorende afhankelijkheden mogelijk worden beïnvloed door een foutmodus. Houd er rekening mee dat er veel foutmodi zijn waarmee u rekening moet houden bij het plannen van tolerantie en herstel. Elk onderdeel kan op elk gewenst moment worden beïnvloed door meer dan één foutmodus. Deze foutmodi zijn onder andere:

  • Regionale storing. Een hele Azure-regio is niet beschikbaar.

  • Uitval van beschikbaarheidszone. Een Azure-beschikbaarheidszone is niet beschikbaar.

  • Servicestoring. Een of meer Azure-services zijn niet beschikbaar.

  • Gedistribueerde denial-of-service (DDoS) of een andere schadelijke aanval.

  • Onjuiste configuratie van app of onderdeel.

  • Operatorfout.

  • Geplande onderhoudsstoring.

  • Overbelasting van onderdelen.

De analyse moet altijd in de context zijn van de stroom die u wilt analyseren. Zorg er dus voor dat u het effect op de gebruiker en het verwachte resultaat van die stroom documenteren. Als u bijvoorbeeld een e-commercetoepassing hebt en u uw klantstroom analyseert, kan het effect van een bepaalde foutmodus op een of meer onderdelen zijn dat alle klanten de betaling niet kunnen voltooien.

Houd rekening met de waarschijnlijkheid van elk type foutmodus. Sommige zijn zeer onwaarschijnlijk, zoals storingen in meerdere zones of regio's, en het toevoegen van risicobeperkingsplanning buiten redundantie is geen goed gebruik van resources en tijd.

Oplossing

Risicobeperkingsstrategieën zijn onderverdeeld in twee algemene categorieën: het bouwen van meer tolerantie en het ontwerpen voor verminderde prestaties.

Het bouwen van meer tolerantie omvat het toevoegen van redundantie aan uw onderdelen, zoals infrastructuur, gegevens en netwerken, en ervoor zorgen dat uw toepassingsontwerp de best practices voor duurzaamheid volgt, bijvoorbeeld het opsplitsen van monolithische toepassingen in geïsoleerde apps en microservices. Zie Aanbevelingen voor redundantie en Aanbevelingen voor zelfbehoud voor meer informatie.

Als u wilt ontwerpen voor verminderde prestaties, identificeert u mogelijke foutpunten die een of meer onderdelen van uw stroom kunnen uitschakelen, maar die stroom niet volledig uitschakelen. Als u de functionaliteit van de end-to-end-stroom wilt behouden, moet u mogelijk een of meer stappen omleiden naar andere onderdelen of accepteren dat een mislukt onderdeel een functie uitvoert, zodat de functie niet meer beschikbaar is in de gebruikerservaring. Om terug te keren naar het voorbeeld van de e-commercetoepassing, kan een mislukt onderdeel, zoals een microservice, ervoor zorgen dat uw aanbevelingsengine niet beschikbaar is, maar de klanten kunnen nog steeds naar producten zoeken en hun transactie voltooien.

U moet ook beperking van afhankelijkheden plannen. Sterke afhankelijkheden spelen een essentiële rol in de toepassingsfunctie en beschikbaarheid. Als ze afwezig zijn of een storing ondervinden, kan dit een aanzienlijk effect hebben. De afwezigheid van zwakke afhankelijkheden kan alleen van invloed zijn op specifieke functies en niet op de algehele beschikbaarheid. Dit onderscheid weerspiegelt de kosten voor het onderhouden van de relatie met hoge beschikbaarheid tussen de service en de bijbehorende afhankelijkheden. Classificeer afhankelijkheden als sterk of zwak om u te helpen identificeren welke onderdelen essentieel zijn voor de toepassing.

Als de toepassing sterke afhankelijkheden heeft zonder welke deze niet kan werken, moeten de beschikbaarheids- en hersteldoelen van deze afhankelijkheden overeenkomen met de doelen van de toepassing zelf. Minimaliseer afhankelijkheden om controle te krijgen over de betrouwbaarheid van toepassingen. Zie Coördinatie tussen toepassingsservices minimaliseren om schaalbaarheid te bereiken voor meer informatie.

Als de levenscyclus van de toepassing nauw is gekoppeld aan de levenscyclus van de afhankelijkheden, kan de operationele flexibiliteit van de toepassing beperkt zijn, met name voor nieuwe releases.

Detectie

Foutdetectie is essentieel om ervoor te zorgen dat u foutpunten in uw analyse correct hebt geïdentificeerd en uw risicobeperkingsstrategieën goed hebt gepland. Detectie in deze context betekent het bewaken van uw infrastructuur, gegevens en toepassing en waarschuwingen wanneer er problemen optreden. Automatiseer detectie zoveel mogelijk en bouw redundantie in uw operationele processen in om ervoor te zorgen dat waarschuwingen altijd worden opgevangen en snel genoeg worden gereageerd om aan uw bedrijfsvereisten te voldoen. Zie aanbevelingen voor bewaking voor meer informatie.

Resultaat

Voor het resultaat van uw analyse maakt u een set documenten die uw bevindingen, de beslissingen die u hebt genomen ten opzichte van de stroomonderdelen en beperking en het effect van de fout op uw workload effectief communiceren.

Geef in uw analyse prioriteit aan de foutmodi en risicobeperkingsstrategieën die u hebt geïdentificeerd op basis van ernst en waarschijnlijkheid. Gebruik deze prioriteitsaanduiding om uw documentatie te richten op de foutmodi die algemeen en ernstig genoeg zijn om de tijd, moeite en resources te besteden aan het ontwerpen van risicobeperkingsstrategieën. Er kunnen bijvoorbeeld enkele foutmodi zijn die zeer zeldzaam zijn bij het optreden of de detectie. Het ontwerpen van risicobeperkingsstrategieën om hen heen is de kosten niet waard.

Raadpleeg de volgende voorbeeldtabel voor een beginpunt van de documentatie.

Tijdens uw eerste FMA-oefening zijn de documenten die u produceert voornamelijk theoretische planning. De FMA-documenten moeten regelmatig worden gecontroleerd en bijgewerkt om ervoor te zorgen dat ze up-to-date blijven met uw workload. Chaostests en praktische ervaringen helpen u uw analyses in de loop van de tijd te verfijnen.

Azure-facilitering

Gebruik Azure Monitor en Log Analytics om problemen in uw workload te detecteren. Gebruik hulpprogramma's zoals Application Insights, Container Insights, Network Insights, VM Insights en SQL Insights voor meer inzicht in problemen met betrekking tot uw infrastructuur, apps en databases.

Azure Chaos Studio is een beheerde service die gebruikmaakt van chaos-engineering om u te helpen bij het meten, begrijpen en verbeteren van de tolerantie van uw cloudtoepassing en service.

Zie Foutmodusanalyse voor Azure-toepassingen voor informatie over het toepassen van FMA-principes op algemene Azure-services.

Voorbeeld

In de volgende tabel ziet u een FMA-voorbeeld voor een e-commercewebsite die wordt gehost op Azure App Service exemplaren met Azure SQL-databases en wordt fronted door Azure Front Door.

Gebruikersstroom: Gebruikersaanmelding, productzoekopdrachten en interactie met winkelwagentjes

Onderdeel Risico Likelihood Effect/beperking/opmerking Uitval
Microsoft Entra ID Service-onderbreking Beperkt Volledige workloadstoring. Afhankelijk van Microsoft om te herstellen. Volledig
Microsoft Entra ID Onjuiste configuratie Normaal Gebruikers kunnen zich niet aanmelden. Geen downstream-effect. Helpdesk rapporteert configuratieprobleem aan het identiteitsteam. Geen
Azure Front Door Service-onderbreking Beperkt Volledige storing voor externe gebruikers. Afhankelijk van Microsoft om te herstellen. Alleen extern
Azure Front Door Regionale storing Zeer laag Minimaal effect. Azure Front Door is een wereldwijde service, dus globale verkeersroutering leidt verkeer door niet-doorgevoerde Azure-regio's. Geen
Azure Front Door Onjuiste configuratie Normaal Onjuiste configuraties moeten worden opgevangen tijdens de implementatie. Als deze optreden tijdens een configuratie-update, moeten beheerders wijzigingen terugdraaien. Configuratie-update veroorzaakt een korte externe storing. Alleen extern
Azure Front Door DDoS-aanval Normaal Potentieel voor onderbreking. Microsoft beheert DDoS-beveiliging (L3 en L4) en Azure Web Application Firewall blokkeert de meeste bedreigingen. Potentieel risico op effect van L7-aanvallen. Mogelijke gedeeltelijke storing
Azure SQL Service-onderbreking Beperkt Volledige workloadstoring. Afhankelijk van Microsoft om te herstellen. Volledig
Azure SQL Regionale storing Zeer laag Failovergroep voor automatische failover naar secundaire regio. Mogelijke storing tijdens failover. Beoogde hersteltijd (RTO's) en beoogde herstelpunten (RPO's) die moeten worden bepaald tijdens betrouwbaarheidstests. Potentieel vol
Azure SQL Uitval van beschikbaarheidszone Beperkt Geen effect Geen
Azure SQL Schadelijke aanval (injectie) Normaal Minimaal risico. Alle Azure SQL-exemplaren zijn gebonden aan een virtueel netwerk via privé-eindpunten en netwerkbeveiligingsgroepen (NSG's) voegen verdere beveiliging binnen virtueel netwerk toe. Potentieel laag risico
App Service Service-onderbreking Beperkt Volledige workloadstoring. Afhankelijk van Microsoft om te herstellen. Volledig
App Service Regionale storing Zeer laag Minimaal effect. Latentie voor gebruikers in betrokken regio's. Azure Front Door routeert verkeer automatisch naar niet-doorgevoerde regio's. Geen
App Service Uitval van beschikbaarheidszone Beperkt Geen effect. App Services zijn geïmplementeerd als zone-redundant. Zonder zoneredundantie kan dit effect hebben. Geen
App Service DDoS-aanval Normaal Minimaal effect. Inkomend verkeer wordt beveiligd door Azure Front Door en Azure Web Application Firewall. Geen

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid