Aanbevelingen voor het uitvoeren van analyse van foutmodus
Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid van Azure Well-Architected Framework:
| RE:03 | Gebruik FMA (Foutmodusanalyse) om potentiële fouten in uw oplossingsonderdelen te identificeren en te prioriteren. Voer FMA uit om het risico en effect van elke foutmodus te beoordelen. Bepaal hoe de workload reageert en herstelt. |
|---|
In deze handleiding worden de aanbevolen procedures beschreven voor het uitvoeren van FMA(Foutmodusanalyse) 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 straalstraal van meerdere fouttypen, waarmee u een nieuwe workload kunt ontwerpen of een bestaande workload kunt herstructureren om het wijdverspreide effect van fouten te minimaliseren.
Een belangrijk tenet van FMA is dat er fouten optreden, ongeacht hoeveel tolerantielagen u toepast. Complexere omgevingen worden blootgesteld aan meer soorten fouten. Gezien deze realiteit kunt u met FMA uw workload ontwerpen om de meeste soorten fouten te weerstaan en probleemloos te herstellen wanneer er een fout optreedt.
Als u FMA helemaal overslaat of een onvolledige analyse uitvoert, loopt uw workload het risico op niet-dicterend 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. |
| Detection | Uw infrastructuur, gegevens en app-bewakings- en waarschuwingsprocessen en -procedures. |
Belangrijke ontwerpstrategieën
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 in de stromen zijn betrokken. Om succesvol te zijn in uw FMA-werk, nauwkeurigheid en grondigheid in uw artefacten is essentieel.
Nadat u de kritieke stromen hebt vastgesteld, kunt u de vereiste onderdelen plannen. Volg vervolgens elke stroom stap voor stap om afhankelijkheden te identificeren, waaronder services van derden en potentiële storingspunten, en plan uw risicobeperkingsstrategieën.
De werkbelasting opscompeteren
Wanneer u van idee tot ontwerp overstapt, moet u de onderdelentypen identificeren die nodig zijn om uw workload te ondersteunen. Uw workload bepaalt de benodigde onderdelen waarvoor u moet plannen. Normaal gesproken moet u plannen voor inkomend beheer, netwerken, berekening, gegevens, opslag, ondersteunende services (zoals verificatie, berichten en geheim of sleutelbeheer) en uitgaand beheer. In deze fase van uw ontwerpwerk weet u mogelijk niet welke specifieke technologieën u gaat implementeren, zodat uw ontwerp er mogelijk uitziet als in het volgende voorbeeld.
Nadat u het ontwerp van de eerste architectuur hebt gemaakt, kunt u uw stromen overlays maken om de afzonderlijke onderdelen te identificeren die in deze stromen worden gebruikt en lijsten of werkstroomdiagrammen te maken waarin de stromen en de bijbehorende onderdelen worden beschreven. Als u de kritiek van de onderdelen wilt begrijpen, gebruikt u de kritieke definities die u aan de stromen hebt toegewezen. Houd rekening met het effect van een onderdeelstoring op uw stromen.
Afhankelijkheden identificeren
Identificeer uw workloadafhankelijkheden voor het uitvoeren van uw analyse van single point-of-failure. Het uitvouwen van uw werkbelasting 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 nodig zijn om de workload te laten functioneren. Typische interne afhankelijkheden zijn API's of oplossingen voor geheim/sleutelbeheer, zoals Azure Key Vault. Voor deze afhankelijkheden legt u 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 evalueren
Houd in de kritieke stromen van uw workload rekening met elk onderdeel en bepaal hoe dat onderdeel en de bijbehorende afhankelijkheden kunnen worden beïnvloed door een foutmodus. Houd er rekening mee dat er veel foutmodi zijn die u moet overwegen 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.
Storing in beschikbaarheidszone. Een Azure-beschikbaarheidszone is niet beschikbaar.
Servicestoring. Een of meer Azure-services zijn niet beschikbaar.
DDoS (Distributed Denial of Service) of een andere kwaadaardige aanval.
Onjuiste configuratie van app of onderdeel.
Operatorfout.
Geplande onderhoudsstoring.
Overbelasting van onderdelen.
De analyse moet altijd in de context van de stroom staan die u probeert te analyseren, dus zorg ervoor 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 het uitchecken 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 risicobeperking buiten redundantie is geen goed gebruik van resources en tijd.
Oplossing
Risicobeperkingsstrategieën vallen in twee algemene categorieën: meer tolerantie bouwen en ontwerpen voor verminderde prestaties.
Het bouwen van meer flexibiliteit omvat het toevoegen van redundantie aan uw onderdelen, zoals infrastructuur, gegevens en netwerken, en ervoor zorgen dat uw toepassingsontwerp de aanbevolen procedures 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. Als u wilt terugkeren naar het voorbeeld van een e-commercetoepassing, kan een mislukt onderdeel, zoals een microservice, ervoor zorgen dat uw aanbevelingsengine niet beschikbaar is, maar de klanten kunnen nog steeds producten zoeken en hun transactie voltooien.
U moet ook risicobeperking plannen voor afhankelijkheden. Sterke afhankelijkheden spelen een cruciale rol in de toepassingsfunctie en beschikbaarheid. Als ze afwezig zijn of een storing ondervinden, kan dit een aanzienlijk effect hebben. Het ontbreken 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 bepalen welke onderdelen essentieel zijn voor de toepassing.
Als de toepassing sterke afhankelijkheden heeft die niet kunnen worden uitgevoerd zonder, 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.
Detection
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 de bewaking van uw infrastructuur, gegevens en toepassing en waarschuwingen wanneer er problemen optreden. Automatiseer detectie zoveel mogelijk en bouw redundantie in uw operationele processen om ervoor te zorgen dat waarschuwingen altijd worden opgevangen en snel genoeg worden gereageerd om aan uw bedrijfsvereisten te voldoen. Zie de aanbevelingen voor bewaking voor meer informatie.
Resultaat
Voor het resultaat van uw analyse maakt u een set documenten die uw bevindingen effectief communiceren, de beslissingen die u hebt genomen ten opzichte van de stroomonderdelen en risicobeperking, en het effect van de fout op uw workload.
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 te garanderen dat u tijd, moeite en resources besteedt aan het ontwerpen van risicobeperkingsstrategieën. Er kunnen bijvoorbeeld enkele foutmodi zijn die zeer zeldzaam zijn bij het optreden of detecteren. Het ontwerpen van risicobeperkingsstrategieën eromheen is de kosten niet waard.
Raadpleeg de volgende voorbeeldtabel voor een documentatiestartpunt.
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. Chaos testen en ervaringen in de praktijk helpen u bij het verfijnen van uw analyses in de loop van de tijd.
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 uw cloudtoepassing en servicetolerantie te meten, te begrijpen en te verbeteren.
Zie Foutmodusanalyse voor Azure-toepassingen voor informatie over het toepassen van FMA-principes op algemene Azure-services.
Opmerking
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, interactie met productzoekopdrachten en winkelwagen
| 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 | Gemiddeld | Gebruikers kunnen zich niet aanmelden. Geen downstream-effect. Helpdesk rapporteert configuratieprobleem aan 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 wereldwijde verkeersroutering leidt verkeer door niet-doorgevoerde Azure-regio's. | Geen |
| Azure Front Door | Onjuiste configuratie | Gemiddeld | Onjuiste configuraties moeten worden opgevangen tijdens de implementatie. Als dit gebeurt tijdens een configuratie-update, moeten beheerders wijzigingen terugdraaien. Configuratie-update veroorzaakt een korte externe storing. | Alleen extern |
| Azure Front Door | DDoS-aanval | Gemiddeld | Potentieel voor onderbreking. Microsoft beheert DDoS-beveiliging (L3 en L4) en Azure Web Application Firewall blokkeert de meeste bedreigingen. Mogelijk risico op effect van L7-aanvallen. | Potentieel voor 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 (RPO's) en beoogde herstelpunten (RPO's) die tijdens het testen van betrouwbaarheid moeten worden vastgesteld. | Potentieel vol |
| Azure SQL | Storing in beschikbaarheidszone | Beperkt | Geen effect | Geen |
| Azure SQL | Schadelijke aanval (injectie) | Gemiddeld | Minimaal risico. Alle Azure SQL-exemplaren zijn gebonden aan virtuele netwerken via privé-eindpunten en netwerkbeveiligingsgroepen (NSG's) voegen verdere intra-virtuele netwerkbeveiliging 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 automatisch verkeer naar niet-uitgevoerde regio's. | Geen |
| App Service | Storing in beschikbaarheidszone | Beperkt | Geen effect. App-services zijn geïmplementeerd als zone-redundant. Zonder zoneredundantie is er een potentieel voor effect. | Geen |
| App Service | DDoS-aanval | Gemiddeld | Minimaal effect. Inkomend verkeer wordt beveiligd door Azure Front Door en Azure Web Application Firewall. | Geen |
Verwante koppelingen
Controlelijst voor betrouwbaarheid
Raadpleeg de volledige set aanbevelingen.