Architectuurstrategieën voor betrouwbaarheidstests

Van toepassing op de aanbeveling voor betrouwbaarheid in de Azure Well-Architected Framework-checklist:

RE:08 Test op tolerantie- en beschikbaarheidsscenario's door de principes van chaos-engineering toe te passen. Gebruik betrouwbaarheidstests om te controleren of uw workload bestand is tegen fouten, schaal onder vraag en herstel binnen uw gedefinieerde doelen.

Betrouwbaarheidstests onderschept architectonische zwakke punten voordat ze storingen veroorzaken. Zonder opzettelijk testen tegen foutscenario's, kunt u niet weten of uw tolerantiepatronen daadwerkelijk werken of of uw workload binnen de gedefinieerde doelen herstelt.

U versterkt de betrouwbaarheid van uw workload wanneer u test op beveiligingsrisico's die van invloed zijn op beschikbaarheid, prestatieproblemen die het systeem onbruikbaar maken en operationele hiaten die uw reactie op incidenten beperken. Gebruik de strategieën in dit artikel om een testfrequentie vast te stellen die uw workload regelmatig valideert op basis van de foutmodi. Ontwikkel uw tests naarmate de architectuur verandert en incidenten nieuwe zwakke punten blootleggen. Krijg de zekerheid dat uw workload bestand is tegen fouten, kan opschalen om aan de vraag te voldoen en kan herstellen binnen uw RTO- en RPO-doelstellingen, terwijl u tegelijk een feedbacklus creëert die uw betrouwbaarheid in de loop van de tijd versterkt.

De belangrijkste strategieën in dit artikel zijn gebaseerd op de basisprocedures voor testen die worden beschreven in strategieën voor OE:09-architectuur voor testen. Lees eerst dat artikel. De aanbevelingen in deze handleiding zijn gericht op betrouwbaarheid en richten zich op het bereiken van vertrouwen in het vermogen van uw workload om fouten te weerstaan en binnen uw doelen te herstellen.

In de volgende tabel worden de belangrijkste betrouwbaarheidsvoorwaarden gedefinieerd die in dit artikel worden gebruikt.

Definities

Termijn Definitie
Availability De tijdsduur waarin een workload van een toepassing in een gezonde staat draait zonder aanzienlijke uitvaltijd.
Chaostechniek De praktijk die veilig chaostests in uw teamcultuur, technische procedures en ontwikkelingslevenscyclus opneemt om continue verbetering van de systeemtolerantie te stimuleren.
Chaostests Een gecontroleerd experiment waarmee een specifieke tolerantiehypothese wordt gevalideerd over hoe een workload zich moet gedragen onder verstorende omstandigheden.
Foutinjectie Een techniek voor het opzettelijk introduceren van fouten in een onderdeel, afhankelijkheid of systeempad.
Herstelbaarheid De mogelijkheid om normale operaties te herstellen na een onderbreking binnen de overeengekomen hersteltijd (RTO) en herstelpuntdoelen (RPO).
Resiliency De mogelijkheid van een workload om fouten te weerstaan (zoals tijdelijke fouten, infrastructuurstoringen, pieken in de vraag) en te blijven werken binnen een acceptabele gebruikerservaring.
Failover Het proces van het overschakelen naar een secundair onderdeel bij het mislukken van het primaire onderdeel.
Failback Het proces waarbij u de activiteiten in de primaire regio hervat nadat de primaire regio is hersteld.
Foutbudget Het maximaal acceptabele foutniveau voor een systeem gedurende een gedefinieerde periode, afgeleid van Service Level Objectives (SLO's).

Bereik voor betrouwbaarheidstests definiëren op basis van servicetypen

Wanneer u het bereik van uw betrouwbaarheidstests definieert, moet u rekening houden met het gedeelde verantwoordelijkheidsmodel van de services die u gebruikt. Elk servicetype (IaaS, PaaS, SaaS) wordt geleverd met verschillende betrouwbaarheidsgaranties en verschillende niveaus van controle over foutafhandeling. Richt uw tests op de aspecten van betrouwbaarheid waarvan u de eigenaar bent.

  • Testdiepte aanpassen aan uw verantwoordelijkheid. Voor Infrastructuurservices (IaaS) is uw team eigenaar van de meeste betrouwbaarheidsbeslissingen, dus investeer in grondige validatie door chaos-engineering en foutinjectie. Voor PaaS-services (Platform) en Software (SaaS) beheert de provider veel van de onderliggende betrouwbaarheid. Concentreer u op de manier waarop uw workload met deze services interageert, zoals hoe deze infrastructuurfailovers in PaaS, throttling, verminderde serviceprestaties of veranderingen in belastingspatronen afhandelt.

  • Houd rekening met workloads met meerdere services. Wanneer uw workload meerdere servicetypen omvat, variëren de verantwoordelijkheden voor het testen van onderdelen. U kunt de failover van uw vm-infrastructuuronderdelen testen tijdens een storing in de beschikbaarheidszone, maar afhankelijk zijn van providergaranties voor een PaaS-database die is ontworpen voor hoge beschikbaarheid. Bepaal waar deze grenzen zich bevinden en zorg ervoor dat uw test de hiaten hierin bedekt.

Testen op uw betrouwbaarheidsdoelen end-to-end

Uw betrouwbaarheidsdoelen, zoals SLO's, RTO's en RPO's, definiëren hoe uw workload zich moet gedragen onder foutomstandigheden. Gebruik ze als pass- en failcriteria voor volledige kritieke stromen, niet alleen afzonderlijke onderdelen.

  • Controleer het herstel in de volledige workflow. Een enkel onderdeel kan binnen de RTO worden hersteld, maar de totale hersteltijd kan uw doel overschrijden wanneer downstreamafhankelijkheden ook moeten worden hersteld. Houd rekening met de totale hersteltijd gedurende de volledige workflow, inclusief de tijd die nodig is om het probleem te identificeren en hierop te reageren.

  • Testbereik definiëren met SLO's en foutbudgetten. Uw foutbudget vertegenwoordigt de investering die u kunt maken in foutinjectie. Beperk chaostests om binnen uw SLO's te blijven en gebruik uw stroomhersteldoelen om de grenzen van elke test te definiëren.

Betrouwbaarheidsscenario's bouwen op basis van kritieke stromen en foutmodi

Begin met de kritieke stromen in uw workload en de foutmodi die van invloed kunnen zijn op deze stromen. Gebruik uw analyse van de foutmodus om de meest impactvolle foutscenario's te identificeren en tests te bouwen waarmee uw strategieën voor tolerantie en herstel worden gevalideerd.

Prioriteit geven op impact en waarschijnlijkheid. Niet elke foutmodus garandeert dezelfde testinvestering. Richt u eerst op scenario's met de hoogste mogelijke impact van de gebruiker en de hoogste kans op optreden. Laat uw foutmodusanalyse deze prioriteitsaanduiding aandrijven.

Uw fouttolerantie- en herstelmechanismen valideren

Focus op scenario's die waarschijnlijk downtime veroorzaken of de gebruikerservaring verminderen. Gebruik de strategieën in deze sectie om tests te bouwen die de mogelijkheid van uw workload valideren om fouten te verwerken en effectief te herstellen.

Back-up maken en terugzetten

Uw back-up- en hersteltests moeten valideren dat uw gegevensbeschermingsbenadering voldoet aan uw hersteldoelstellingen.

  • Stel een testfrequentie in. Bepaal hoe vaak u herstelbewerkingen moet testen op basis van hoe vaak uw back-upconfiguratie, gegevensschema of infrastructuur wordt gewijzigd. Frequentere wijzigingen vereisen vaker hersteltests.

  • Hersteldoelen instellen. Meet werkelijke hersteltijden op basis van uw RPO- en RTO-doelen om te bevestigen dat uw back-upstrategie voldoet aan uw hersteldoelstellingen.

  • Ga er niet van uit dat de back-up volledig is. Back-ups kunnen onjuist worden geconfigureerd om alleen een subset van uw gegevens vast te leggen. Valideer de gegevensintegriteit en volledigheid, niet alleen of een herstelbewerking slaagt.

  • Test afzonderlijk. Valideer herstelbewerkingen in een omgeving die losstaat van de productie, zodat u grondige controles kunt uitvoeren zonder live workloads te onderbreken.

Tijdelijke fouten

Tijdelijke fouten, zoals tijdelijke netwerkonderbrekingen, korte service- en verbindingstime-outs, zijn veelvoorkomende betrouwbaarheidsrisico's. Controleer of uw workload met deze storingen kan omgaan zonder gevolgen voor gebruikers. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

  • Richt je op wat je bezit. Als uw SDK's of platformservices automatisch nieuwe pogingen en circuitonderbreking verwerken, test u wat er gebeurt wanneer deze ingebouwde mechanismen zijn uitgeput, bijvoorbeeld wanneer alle nieuwe pogingen mislukken of een circuitonderbreker wordt geopend.

  • Valideer configuraties voor foutafhandeling. Evalueer de configuraties voor foutafhandeling van uw workload. Controleer of beleid voor opnieuw proberen, drempelwaarden voor circuitonderbrekers en time-outwaarden zich gedragen zoals verwacht onder realistische foutvoorwaarden.

  • Test de grens tussen tijdelijke en permanente fouten. Controleer of uw workload probleemloos overstapt van gedrag voor opnieuw proberen tot terugval of afname wanneer een fout zich buiten de verwachte drempelwaarden blijft voordoen.

  • Houd rekening met tijdelijke fouten door veerkrachtfuncties. Zoneredundantie en vergelijkbare ontwerpen produceren vaak tijdelijke fouten tijdens normale failoverbewerkingen. Een zoneredundante database kan bijvoorbeeld tijdelijke verbindingsfouten veroorzaken wanneer verkeer tijdens een storing naar een goede zone verschuift. Test of uw werkbelasting deze verwachte tijdelijke fouten kan afhandelen zonder aanzienlijke gevolgen voor de gebruiker.

Respons op belasting en schaalbaarheid

Controleer of uw workload de betrouwbaarheid behoudt tijdens veranderingen in de vraag, zowel plotselinge pieken als geleidelijke toenamen. Zie de schaalstrategie voor meer informatie. Zie Aanbevelingen voor tests voor richtlijnen voor belasting- en stresstests.

  • Test zowel uitschalen als inschalen. Controleer of nieuwe capaciteit snel genoeg beschikbaar komt en of het inschalen geen aanvragen laat uitvallen of verweesde resources achterlaat.

  • Houd rekening met schaalvertraging. Er is altijd een vertraging tussen het voldoen aan de voorwaarden om schaalaanpassing te activeren en nieuwe capaciteit gereed te maken. Bepaal of uw workload de vraag tijdens die kloof kan afhandelen of of u extra capaciteit vooraf moet inrichten.

Afhankelijkheidsfouten

Uw workload is waarschijnlijk afhankelijk van services buiten uw directe beheer, zoals API's van derden, beheerde platformservices of gedeelde interne services. Controleer of uw workload fouten in deze afhankelijkheden afhandelt zonder aanzienlijke onderbrekingen voor gebruikers.

  • Categoriseer afhankelijkheden op basis van kritiekheid. Niet alle afhankelijkheden rechtvaardigen dezelfde testinvestering. Prioriteit geven aan testen voor afhankelijkheden die zich in uw kritieke stromen bevinden en die geen ingebouwde redundantie- of terugvalpaden hebben.

  • Test het terugvalgedrag voor elke afhankelijkheid. Wanneer een afhankelijkheid niet beschikbaar is, moet uw workload terugvallen op een alternatief pad of gedrag in plaats van volledig te mislukken. Controleer of elke fallback correct wordt geactiveerd en of niet-gerelateerde functies naar behoren blijven werken.

  • Houd rekening met gedeeltelijke en cascadefouten. Afhankelijkheden mislukken zelden op binaire manieren. Test niet alleen volledige storingen. Bedek latentieverhogingen, onregelmatige fouten en gedeeltelijke beschikbaarheid van gegevens.

  • Valideer isolatie en beperking van de impact. Controleer of één afhankelijkheidsfout niet trapsgewijs wordt veroorzaakt door niet-gerelateerde functionaliteit.

Zelfbehoud en herstel

Controleer of uw ontwerp voor zelfherstel en zelfbehoud reageert op storingen, inclusief of uw workload in een verminderde capaciteit kan blijven werken wanneer volledig herstel niet onmiddellijk is.

  • Test het geautomatiseerde herstel end-to-end. Evalueer uw gezondheidsmodellen om ervoor te zorgen dat ze de juiste controles omvatten. Controleer of deze controles fouten nauwkeurig detecteren, geautomatiseerd herstel activeren zoals verwacht en het systeem binnen acceptabele perioden retourneren naar een goede status.

  • Valideer handmatige herstelrunbooks. Geautomatiseerd herstel omvat niet elk scenario. Test handmatige runbooks onder realistische omstandigheden om ervoor te zorgen dat operators deze onder druk en binnen uw hersteltijddoelen kunnen uitvoeren.

  • Valideer het probleemloze degradatiegedrag. Wanneer een onderdeel mislukt, moet uw workload probleemloos afnemen in plaats van volledig te mislukken. Test of deze kan worden uitgevoerd in een beperkte modus, zoals het in de wachtrij plaatsen van aanvragen voor handmatige controle en dat de verminderde ervaring acceptabel is voor gebruikers. Controleer of uw team weet hoe de workload in deze status moet worden uitgevoerd en hoe u de volledige functionaliteit kunt herstellen.

Incidenten en herstel na noodgevallen (DR)

Wanneer een incident of noodgeval optreedt, is uw mogelijkheid om het snel te detecteren en effectief te reageren essentieel. Test uw plannen en processen om ervoor te zorgen dat ze onherstelbare fouten en grote incidenten aanpakken. Gebruik een speciale omgeving voor dr-tests om te voorkomen dat dit van invloed is op productieworkloads. Zie plan voor herstel na noodgevallen voor meer informatie.

  • Valideer mechanismen voor incidentdetectie. Simuleer incidenten om te controleren of de bewakingslogboeken de benodigde informatie vastleggen en dat waarschuwingen op de juiste wijze worden geactiveerd. Test bijvoorbeeld hoe snel verhoogde foutenpercentages voor aanvragen worden gedetecteerd en hoe vaak bewakingsgegevens worden genomen.

  • Test processen voor incidentbeheer. Controleer of uw team de procedures voor het reageren op incidenten effectief kan volgen. Zie incidentrespons voor meer informatie.

  • Test de volledige automatische overschakeling bij uitval en de terugschakeling na herstel. Het afzonderlijk testen van onderdelen kan coördinatiefouten over het hoofd zien die pas tijdens een echte omschakeling aan het licht komen. Valideer de volledige failoverreeks, inclusief DNS-overschakeling, het herstellen van back-ups en consistentie van gegevensreplicatie en het opnieuw verbinden van de client. Test ook failback naar de primaire implementatie, wat vaak complexer is dan de eerste overschakeling.

  • Valideer de capaciteit in de failoveromgeving. Zorg ervoor dat uw failover-omgeving over voldoende vooraf geprovisioneerde capaciteit beschikt om verkeer direct bij een failover te verwerken zonder onder de belasting te bezwijken. Test of de omgeving de activiteiten kan blijven ondersteunen terwijl de opschalingsmechanismen worden geactiveerd, en valideer uw opschalingsaanpak. Zie Respons op belasting en schaling voor meer informatie.

  • Meet uw resultaten af tegen uw doelen. Als een DR-test niet voldoet aan uw RTO of RPO, analyseert u de hiaten en werkt u uw DR-plan dienovereenkomstig bij.

  • Valideer personen en processen. Dr-tests moeten communicatiekanalen controleren, bevestigen dat operators over de benodigde toegang en machtigingen beschikken om herstelprocedures uit te voeren en ervoor te zorgen dat ze snel DR-specifieke runbooks onder druk kunnen vinden.

Uw plan testen en evalueren met tabletop-oefeningen

Met tabletopoefeningen kunt u hiaten in uw betrouwbaarheidstests vinden voordat een echt incident ze blootstelt. Door foutscenario's met uw team te simuleren, kunt u niet-geteste voorwaarden identificeren en controleren of uw reactieprocedures werken zoals verwacht.

  • Simuleer realistische incidenten. Doorloop een foutscenario, zoals een regionale storing of een beschadigde implementatie, en laat uw team de stappen beschrijven die ze moeten nemen om deze te detecteren, erop te reageren en te herstellen. Deze discussies onthullen vaak veronderstellingen over systeemgedrag dat niet is gevalideerd door middel van testen.

  • Bevindingen omzetten in testgevallen. Gebruik de hiaten en onbekende gegevens die tijdens de oefening optreden om nieuwe betrouwbaarheidstests te maken. Als het team detecteert dat niemand weet hoe de workload zich gedraagt wanneer een specifieke afhankelijkheid uitvalt, is dat een scenario om aan uw teststrategie toe te voegen.

Profiteer van geplande en ongeplande storingen

Wanneer uw workload offline is vanwege gepland onderhoud of een niet-geplande storing, hebt u een unieke mogelijkheid om tests uit te voeren en uw kennis van uw workload te verbeteren.

Gepland onderhoud

Tijdens onderhoudsvensters voor updates of patches test u onderdelen en stromen die niet betrokken zijn bij het onderhoudswerk. U kunt tests uitvoeren zonder het risico dat de workload onverwacht verslechtert of buiten gebruik wordt gesteld. Als u voldoende tijd hebt, test u ook de onderdelen die betrokken zijn bij het onderhoud nadat het werk is voltooid.

Niet-geplande storing

Elke ongeplande storing is een kans om uw strategie voor betrouwbaarheidstests te versterken. Nadat u de service hebt hersteld en uw incidentbeoordeling hebt voltooid, gebruikt u uw bevindingen om uw tests te verbeteren.

  • Test uw risicobeperkingsmaatregelen. Als u een noodoplossing of tijdelijke oplossing hebt toegepast, controleer dan of deze de verwachte belasting aankan voordat de permanente oplossing van kracht is.

  • Zoek naar vergelijkbare kwetsbaarheden. Bekijk andere onderdelen voor dezelfde configuratie- of ontwerppatronen die hebben bijgedragen aan de storing. Voeg tests voor deze onderdelen toe voordat ze op dezelfde manier mislukken.

Verschillende soorten tests combineren

Wanneer u verschillende soorten tests samen uitvoert, kunt u betrouwbaarheidsproblemen onthullen die niet zichtbaar zijn wanneer elke test geïsoleerd wordt uitgevoerd. Een werklast kan onder normale omstandigheden een specifieke belasting verwerken, maar dezelfde belasting leidt tot uitval wanneer u een storing introduceert.

  • Bestaande testinfrastructuur opnieuw gebruiken. Als u al een infrastructuur en een testharnas voor belastingtests hebt, kunt u deze gebruiken om chaostests tegelijkertijd uit te voeren. Het combineren van belasting en foutinjectie in dezelfde testuitvoering laat zien hoe uw workload zich gedraagt onder realistische omstandigheden, waarbij de vraag en storingen zich tegelijkertijd voordoen.

  • Begin in niet-productieomgevingen. Begin met het testen van betrouwbaarheid in omgevingen met een lager risico, waar u de foutmodi veilig kunt verkennen. Schakel pas over op testen in productie nadat u alle inzichten uit niet-productieomgevingen hebt gehaald en waarborgen hebt ingesteld om de impact te beperken en snel te kunnen terugdraaien.

Foutinjectie en chaos-engineering gebruiken

Foutinjectie en chaos-engineering helpen u bij het opbouwen van vertrouwen in de tolerantie van uw workload door opzettelijk fouten te introduceren en het antwoord te observeren. Zorg ervoor dat u risicobeperkingsstrategieën hebt voordat u experimenten uitvoert.

  • Voer regelmatig chaosexperimenten uit. Evalueer uw testbereik. Injecteer fouten in onderdelen en processen waarvan u aanneemt dat ze betrouwbaar zijn. Naarmate uw architectuur verandert, ontstaan er nieuwe foutmodi en kunnen eerdere aannames mogelijk niet meer worden opgeslagen. Voer experimenten uit op een regelmatige frequentie om regressies te detecteren, nieuwe afhankelijkheden te valideren en te bevestigen dat recente wijzigingen geen zwakke punten hebben geïntroduceerd.

  • Gebruik de analyse van de foutmodus om experimenten te focussen. Elk experiment moet gericht zijn op een specifieke fout of reeks fouten en een duidelijke hypothese hebben, zoals het testen van de mogelijkheid van een bepaalde stroom om het verlies van een bepaald onderdeel te weerstaan. Als experimenten nieuwe foutmodi of niet-gedetecteerde afhankelijkheden onthullen, werkt u de analyse van de foutmodus bij om deze actueel te houden.

  • Beperk de impact tijdens experimenten. Bepaal welke onderdelen u snel kunt herstellen en formuleer weloverwogen verwachtingen over het effect van elke foutinjectie. Als een experiment buiten het bereik valt of onverwachte resultaten oplevert, stopt u het. Balancer het verzamelen van zinvolle gegevens met het minimaliseren van het effect op gebruikers.

  • Meten ten opzichte van basislijnen. Stel consistente metrische gegevens over betrouwbaarheid en prestaties vast voor de stromen en onderdelen in elk experiment. Vergelijk gedegradeerde statusmetrieken met deze basislijnen om het volledige effect van de fout te begrijpen en te bepalen of uw tolerantieontwerp voldoet aan de doelen.

  • Voer resultaten terug in uw teststrategie. Gebruik experimentresultaten om nieuwe tests uit te voeren, herstelplannen bij te werken en herstelachterstanditems te informeren. Wanneer onverwacht gedrag optreedt, maak dan gerichte tests voor dat gedrag en ontwikkel herstelstrategieën.

Compromis: Foutinjectietesten in productie kunnen verstorend werken en mogelijk tot downtijd leiden. Wees transparant met belanghebbenden over deze mogelijkheid. Stel beveiliging in, zodat u experimenten kunt stoppen en snel kunt terugdraaien en flexibel kunt blijven over het uitvoeren van tests of het vermijden van tests tijdens gevoelige perioden. Als u wilt voorkomen dat er onbedoelde storingen zijn, moet u plannen voor voldoende redundantie en ervoor zorgen dat uw belanghebbenden inzicht hebben in de kosten.

Risico: Betrouwbaarheidstests kunnen de dekking uitbreiden in veel foutmodi, maar u moet stoppen zodra het geen zinvolle waarde meer biedt. Als u al een achterstand hebt met bekende betrouwbaarheidsproblemen, moet u prioriteit geven aan het oplossen van deze problemen in plaats van meer tests toe te voegen.

Azure-ondersteuning

Azure Test Plans is een browsergebaseerde testbeheeroplossing die alle mogelijkheden biedt die nodig zijn voor geplande handmatige tests, gebruikersacceptatietests, verkennende tests en het verzamelen van feedback van belanghebbenden.

Azure Chaos Studio is een beheerde service die gebruikmaakt van chaostests om u te helpen bij het meten, begrijpen en verbeteren van uw cloudtoepassing en servicetolerantie.

Testen van Azure-apps is een service waarmee u functionele tests kunt uitvoeren met Playwright-werkruimten en prestatietests met behulp van Azure Load Testing om problemen in hun toepassingen te identificeren.

Azure Service Health heeft een gepland onderhoudsdeelvenster dat een speciale sectie is in de Azure-portal waarmee u op de hoogte blijft van toekomstige onderhoudsactiviteiten. Het markeert gebeurtenissen die van invloed kunnen zijn op uw Azure resources, zodat u zich vooraf kunt voorbereiden.

Verbindingsmonitor is een functie van Azure Network Watcher die u kunt gebruiken voor synthetische bewaking en realtime testen van netwerkconnectiviteit in zowel Azure- als hybride omgevingen. In chaos-engineeringscenario's kan verbindingsmonitor worden gebruikt om fouten in doelnetwerkonderdelen te injecteren en continu belangrijke metrische gegevens zoals latentie en pakketverlies te meten. Met deze mogelijkheid kunnen teams zien hoe onderbrekingen van invloed zijn op de netwerkbetrouwbaarheid, zowel voor afzonderlijke stroomonderdelen als voor end-to-end-netwerkpaden. Als u de impact van fouten wilt beoordelen en gebieden voor verbetering wilt identificeren, vergelijkt u de telemetrie van de verbindingsmonitor met metrische basislijngegevens.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige reeks aanbevelingen.

Controlelijst voor betrouwbaarheid

  • Last updated on