Architectuurstrategieën voor het uitvoeren van analyse van foutmodus

Van toepassing op deze aanbeveling uit de betrouwbaarheid checklist van het Azure Well-Architected Framework:

Analyse van foutmodus (FMA) helpt u potentiële storingspunten binnen uw workload en de bijbehorende stromen te identificeren. In deze handleiding worden de aanbevolen procedures beschreven voor het uitvoeren van FMA, zodat u risicobeperkingsacties kunt plannen, nieuwe workloads kunt ontwerpen of bestaande workloads kunt herstructureren om het wijdverspreide effect van fouten te minimaliseren. Door elke stap van uw proces te analyseren en de impact van verschillende soorten fouten te bepalen, kunt u de veerkracht van uw architectuur verbeteren.

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 binnen gedefinieerde hersteldoelstellingen.

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

Definities

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 verzamelt en de artefacten die u in uw werk maakt, 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.

Deel uw werklast op

Wanneer u overstapt van ideeën naar ontwerp, identificeert u de onderdelentypen die uw workload 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 uw eerste architectuurontwerp hebt gemaakt, legt u uw stromen eroverheen om de afzonderlijke onderdelen te identificeren die in die stromen worden gebruikt. Maak lijsten of werkstroomdiagrammen 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 tussen workloads identificeren

Identificeer uw workloadafhankelijkheden om uw single point of failure analysis uit te voeren. Het opdelen van uw werkbelasting en het overleggen van stromen biedt inzicht in de afhankelijkheden die intern en extern zijn voor de werkbelasting.

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 en 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.

Evalueer faalpunten in uw flows

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 storingsmodi zijn waarmee u rekening moet houden bij het plannen van veerkracht en herstel. Elk onderdeel kan op elk gewenst moment worden beïnvloed door meer dan één foutmodus. Overweeg leesfouten en schrijffouten afzonderlijk omdat de impact en mogelijke beperkingsstappen variëren. Foutmodi zijn onder andere:

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

• Beschikbaarheidzonestoring. 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.

Analyseer altijd het effect in de context van het proces dat u probeert te analyseren, dus zorg ervoor dat u de impact op de gebruiker en het verwachte resultaat van dat proces documenteert. 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 foutmodi zijn zeer onwaarschijnlijk, zoals storingen in meerdere zones of meerdere regio's. Het toevoegen van risicobeperkingsplanning buiten redundantie is geen goed gebruik van resources en tijd.

Strategieën voor risicobeperking plannen

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, zoals het opsplitsen van monolithische toepassingen in geïsoleerde apps en microservices. Zie Aanbevelingen voor redundantie en aanbevelingen voor zelfbehoudvoor 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 of defect zijn, kunnen ze een aanzienlijk effect veroorzaken. 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 schaalbaarheidte 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.

Foutdetectie implementeren

Foutdetectie is essentieel om ervoor te zorgen dat u foutenpunten in uw analyse correct identificeert en uw risicobeperkingsstrategieën goed plant. In deze context betekent detectie dat u uw infrastructuur, gegevens en toepassing bewaakt en waarschuwingen ontvangt 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 het bewaken vanvoor meer informatie.

Uw FMA-bevindingen documenteer

Maak voor het resultaat van uw analyse 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 referentiepunt.

Tijdens uw eerste FMA-oefening zijn de documenten die u produceert voornamelijk theoretische planning. Controleer en werk de FMA-documenten regelmatig bij 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-monitoring

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 uw cloudtoepassing en servicetolerantie.

Gebruik verbindingsmonitor en verbindingsproblemen in Azure Network Watcher om scenario's voor netwerkconnectiviteit te modelleren en te valideren vóór de implementatie. Door synthetische tests te simuleren en mogelijke routeringspaden op te lossen, kunt u met deze hulpprogramma's mogelijke foutmodi in uw netwerkarchitectuur anticiperen en documenteren. Door historische stroomlogboeken van virtuele netwerken te analyseren met verkeersanalyses, kunt u patronen van geblokkeerd of afwijkend verkeer identificeren dat uw FMA-documentatie mogelijk informeert over de Azure-infrastructuur.

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, interactie met productzoekopdrachten en winkelwagen

Verwante koppeling

• Veerkracht en afhankelijkheden

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.