Arkitekturstrategier för att utforma en strategi för tillförlitlighetstestning

gäller för den här rekommendationen i tillförlitlighetschecklistan för Azure Well-Architected Framework:

Tillförlitlighetstestningen fångar upp arkitektoniska svagheter innan de orsakar avbrott. Utan avsiktlig testning mot felscenarier kan du inte veta om återhämtningsmönstren faktiskt fungerar eller om din arbetsbelastning återställs inom sina definierade mål.

Du stärker arbetsbelastningens tillförlitlighet när du testar säkerhetsrisker som påverkar tillgänglighet, prestandaproblem som gör systemet oanvändbart och driftsluckor som begränsar ditt incidentsvar. Använd strategierna i den här artikeln för att etablera en testfrekvens som regelbundet validerar din arbetsbelastning utifrån dess felscenarier. Utveckla dina tester när arkitekturen ändras och incidenter avslöjar nya svagheter. Skapa trygghet i att din arbetslast kan stå emot fel, skala för att möta efterfrågan och återhämta sig inom dina RTO- och RPO-mål, samtidigt som du skapar en återkopplingsslinga som stärker tillförlitligheten över tid.

De viktigaste strategierna i den här artikeln bygger på de grundläggande testmetoderna som beskrivs i OE:09-arkitekturstrategier för testning. Granska den artikeln först. Rekommendationerna i den här guiden är begränsade till tillförlitlighet och fokuserar på att uppnå förtroende för din arbetsbelastnings förmåga att motstå fel och återställa inom dina mål.

I följande tabell definieras viktiga tillförlitlighetsvillkor som används i den här artikeln.

Definitioner

Definiera omfång för tillförlitlighetstestning baserat på tjänsttyper

När du definierar omfånget för tillförlitlighetstestningen bör du överväga modellen med delat ansvar för de tjänster som du använder. Varje tjänsttyp (IaaS, PaaS, SaaS) har olika tillförlitlighetsgarantier och olika nivåer av kontroll över felhantering. Fokusera dina tester på de aspekter av tillförlitlighet som du äger.

• Anpassa testdjupet efter ditt ansvar. För infrastrukturtjänster (IaaS) äger ditt team de flesta tillförlitlighetsbesluten, så investera i grundlig validering genom kaosteknik och felinmatning. För plattformstjänster (PaaS) och programvarutjänster (SaaS) hanterar leverantören mycket av den underliggande driftsäkerheten. Fokusera på hur din arbetsbelastning interagerar med dessa tjänster, till exempel hur den hanterar infrastrukturredundans i PaaS, begränsning, tjänstförsämring eller ändringar i belastningsmönster.

• Ta hänsyn till arbetsbelastningar med blandade tjänster. När din arbetsbelastning omfattar flera tjänsttyper varierar testningsansvaret mellan olika komponenter. Du kan testa redundans för dina VM-baserade infrastrukturkomponenter under ett avbrott i tillgänglighetszonen, men förlitar dig på providergarantier för en PaaS-databas som är utformad för hög tillgänglighet. Identifiera var dessa gränser finns och se till att testningen täcker luckorna mellan dem.

Testa mot dina tillförlitlighetsmål från slutpunkt till slutpunkt

Dina tillförlitlighetsmål, till exempel SLO: er, RTO:er och RRPOs, definierar hur din arbetsbelastning ska bete sig under felförhållanden. Använd dem som kriterier för att klara och misslyckas i fullständiga kritiska flöden, inte bara enskilda komponenter.

• Verifiera återställningen i hela flödet. En enskild komponent kan återställas inom sin RTO, men den totala återställningstiden kan överskrida målet när underordnade beroenden också behöver återställas. Ta hänsyn till total återställningstid i hela flödet, inklusive tiden för att identifiera problemet och svara.

• Definiera testens omfattning med SLO:er och felbudgetar. Din felbudget representerar den investering du kan göra i felinmatningen. Begränsa kaostestningen för att hålla dig inom dina SLO:er och använda dina flödesåterställningsmål för att definiera gränserna för varje test.

Skapa tillförlitlighetsscenarier från kritiska flöden och fellägen

Börja med de kritiska flödena i arbetsbelastningen och de fellägen som kan påverka dem. Använd analys av felläge för att identifiera de mest effektfulla felscenarierna och skapa tester som validerar dina återhämtnings- och återställningsstrategier.

Prioritera efter effekt och sannolikhet. Alla fellägen garanterar inte samma testinvestering. Fokusera först på scenarier med högsta möjliga användarpåverkan och högsta sannolikhet att inträffa. Låt analys av felläge driva den här prioriteringen.

Verifiera mekanismerna för feltolerans och återställning

Fokusera på scenarier som mest sannolikt orsakar stilleståndstid eller försämrar användarupplevelsen. Använd strategierna i det här avsnittet för att skapa tester som verifierar arbetsbelastningens förmåga att hantera fel och återställa effektivt.

Säkerhetskopiering och återställning

Säkerhetskopierings- och återställningstestningen bör verifiera att dataskyddsmetoden uppfyller dina återställningsmål.

• Fastställ en testfrekvens. Avgör hur ofta du behöver testa återställningar baserat på hur ofta säkerhetskopieringskonfigurationen, dataschemat eller infrastrukturen ändras. Vanligare ändringar kräver mer frekvent återställningstestning.

• Ange återställningsmål. Mät faktiska återställningstider mot dina RPO- och RTO-mål för att bekräfta att din säkerhetskopieringsstrategi uppfyller dina återställningsmål.

• Anta inte att säkerhetskopieringen är fullständig. Säkerhetskopior kan felkonfigureras för att endast samla in en delmängd av dina data. Verifiera dataintegritet och fullständighet, inte bara om en återställningsåtgärd lyckas.

• Testa isolerat. Verifiera återställningar i en miljö som är separat från produktion så att du kan köra noggranna kontroller utan att avbryta aktiva arbetsbelastningar.

Tillfälliga fel

Tillfälliga fel, till exempel tillfälliga nätverksavbrott, kort otillgänglighet för tjänsten och tidsgränser för anslutningar, är vanliga tillförlitlighetsrisker. Kontrollera att din arbetsbelastning hanterar dessa fel utan att påverka användarna. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

• Fokusera på det du äger. Om dina SDK:er eller plattformstjänster hanterar återförsök och kretsbrytningar automatiskt testar du vad som händer när de inbyggda mekanismerna är uttömda, till exempel när alla återförsök misslyckas eller en kretsbrytare öppnas.

• Verifiera konfigurationer för felhantering. Utvärdera arbetsbelastningens konfigurationer för felhantering. Kontrollera att återförsöksprinciper, tröskelvärden för kretsbrytare och tidsgränsvärden fungerar som förväntat under realistiska felförhållanden.

• Testa gränsen mellan tillfälligt och beständigt fel. Kontrollera att arbetsbelastningen övergår på ett smidigt sätt från återförsök till återställning eller försämring när ett fel kvarstår över förväntade tröskelvärden.

• Ta hänsyn till tillfälliga fel från återhämtningsfunktioner. Zonredundans och liknande design ger ofta tillfälliga fel under normala redundansåtgärder. En zonredundant databas kan till exempel orsaka tillfälliga anslutningsfel när trafiken övergår till en felfri zon under ett avbrott. Testa om din arbetsbelastning kan hantera dessa förväntade tillfälliga fel utan betydande användarpåverkan.

Svar på belastning och skalning

Kontrollera att arbetsbelastningen bibehåller tillförlitligheten vid ändringar på begäran, både plötsliga toppar och gradvisa ökningar. Mer information finns i skalningsstrategi. Vägledning för belastnings- och stresstestning finns i Rekommendationer för testning.

• Testa både uppskalning och nedskalning. Kontrollera att ny kapacitet kommer online tillräckligt snabbt och att inskalning inte släpper begäranden eller lämnar överblivna resurser.

• Ta hänsyn till fördröjning vid skalning. Det finns alltid en fördröjning mellan att uppfylla villkoren för att utlösa skalning och att ha ny kapacitet klar. Avgör om din arbetsbelastning kan hantera efterfrågan under det gapet eller om du behöver etablera extra kapacitet i förväg.

Fel i beroenden

Din arbetsbelastning beror sannolikt på tjänster utanför din direkta kontroll, till exempel API:er från tredje part, hanterade plattformstjänster eller delade interna tjänster. Kontrollera att din arbetsbelastning hanterar fel i dessa beroenden utan betydande störningar för användarna.

• Kategorisera beroenden efter kritiskhet. Alla beroenden garanterar inte samma testinvestering. Prioritera testning för beroenden som finns i dina kritiska flöden och som saknar inbyggda redundans- eller återställningsvägar.

• Testa reservbeteendet för varje beroende. När ett beroende blir otillgängligt bör arbetsbelastningen återgå till en alternativ sökväg eller ett annat beteende i stället för att misslyckas helt. Kontrollera att varje fallback fungerar korrekt och att annan, orelaterad funktionalitet fortsätter att fungera.

• Ta hänsyn till partiella och sammanhängande fel. Beroenden misslyckas sällan på binära sätt. Testa inte bara fullständiga avbrott. Omfatta ökad latens, intermittenta fel och delvis datatillgänglighet.

• Verifiera isolering och begränsning av påverkningsområdet. Kontrollera att ett enda beroendefel inte överlappar orelaterade funktioner.

Självbevarelsedrift och återställning

Verifiera hur din design för självläkning och självbevarelse reagerar på fel, inklusive om din arbetsbelastning kan fortsätta att fungera med begränsad kapacitet när en fullständig återställning inte kan ske omedelbart.

• Testa automatisk återställning från slutpunkt till slutpunkt. Utvärdera dina hälsomodeller för att säkerställa att de innehåller rätt kontroller. Kontrollera att dessa kontroller identifierar fel korrekt, utlöser automatiserad reparation som förväntat och returnerar systemet till ett felfritt tillstånd inom godkända tidsramar.

• Validera manuella återställningsanvisningar. Automatisk återställning täcker inte alla scenarion. Testa manuella driftmanualer under realistiska förhållanden för att säkerställa att operatörerna kan följa dem under press och inom dina återställningstidsmål.

• Validera beteendet vid kontrollerad degradering. När en komponent misslyckas bör arbetsbelastningen försämras korrekt i stället för att misslyckas helt. Testa att den kan fungera i ett reducerat läge, till exempel köbegäranden för manuell granskning, och att den försämrade upplevelsen är acceptabel för användarna. Bekräfta att ditt team vet hur arbetsbelastningen ska hanteras i det här tillståndet och hur du återställer fullständiga funktioner.

Incidenter och haveriberedskap (DR)

När en incident eller katastrof inträffar är din förmåga att snabbt identifiera den och svara effektivt kritisk. Testa dina planer och processer för att se till att de hanterar katastrofala fel och större incidenter. Använd en dedikerad miljö för DR-testning för att undvika att påverka produktionsarbetsbelastningar. Mer information finns i haveriberedskapsplanen.

• Verifiera mekanismer för incidentidentifiering. Simulera incidenter för att verifiera att övervakningsloggar samlar in nödvändig information och att aviseringar utlöses på rätt sätt. Testa till exempel hur snabbt ökade felfrekvenser för begäranden identifieras och hur ofta övervakningsdata samplas.

• Testa incidenthanteringsprocesser. Bekräfta att ditt team kan följa procedurerna för incidenthantering effektivt. Mer information finns i incidenthantering.

• Testa fullständig redundans och återställning efter fel. Att testa enskilda delar isolerat kan missa samordningsfel som bara visas under en verklig övergång. Verifiera den fullständiga redundansväxlingssekvensen, inklusive DNS-omställning, återställning av säkerhetskopior, konsekvens i datareplikeringen och återanslutning av klienter. Testa även återställning efter fel till den primära distributionen, vilket ofta är mer komplext än den första övergången.

• Verifiera kapaciteten i redundansmiljön. Fastställ att din redundansmiljö har tillräckligt med företablerad kapacitet för att hantera trafiken omedelbart vid redundansväxling utan att kollapsa under belastning. Testa att miljön kan upprätthålla åtgärder medan skalningsmekanismer aktiverar och validerar din skalningsmetod. Mer information finns i Svar på belastning och skalning.

• Mät mot dina mål. Om ett DR-test inte uppfyller din RTO eller RPO, analysera bristerna och uppdatera DR-planen därefter.

• Verifiera personer och processer. DR-tester bör verifiera kommunikationskanaler, bekräfta att operatörerna har nödvändig åtkomst och behörighet för att genomföra återställningsprocedurer samt säkerställa att de snabbt kan hitta DR-specifika driftinstruktioner under tidspress.

Testa och utvärdera din plan med tabletop-övningar

Tabletop-övningar hjälper dig att hitta luckor i tillförlitlighetstestningen innan en verklig incident exponerar dem. Genom att simulera felscenarier med ditt team kan du identifiera otestade villkor och verifiera att dina svarsprocedurer fungerar som förväntat.

• Simulera realistiska incidenter. Gå igenom ett scenario där något går fel, till exempel ett regionalt avbrott eller en felaktig driftsättning, och be ditt team beskriva vilka steg de skulle ta för att upptäcka, hantera och återhämta sig från det. Dessa diskussioner visar ofta antaganden om systembeteende som inte har verifierats genom testning.

• Omvandla resultaten till testfall. Använd de luckor och okända som visas under övningen för att skapa nya tillförlitlighetstester. Om teamet upptäcker att ingen vet hur arbetsbelastningen fungerar när ett visst beroende misslyckas är det ett scenario att lägga till i din teststrategi.

Dra nytta av planerade och oplanerade avbrott

När din arbetsbelastning är offline på grund av planerat underhåll eller ett oplanerat avbrott har du en unik möjlighet att utföra testning och förbättra din förståelse för din arbetsbelastning.

Planerat underhåll

Under underhållsperioder för uppdateringar eller korrigeringar testar du komponenter och flöden som inte ingår i underhållsarbetet. Du kan köra tester utan att riskera att oväntat nedgradera arbetsbelastningen eller ta den offline. Om du har tillräckligt med tid kan du även testa komponenterna som ingår i underhållet när arbetet är klart.

Oplanerat avbrott

Varje oplanerat avbrott är en möjlighet att stärka din strategi för tillförlitlighetstestning. När du har återställt tjänsten och slutfört granskningen efter incidenten kan du använda dina resultat för att förbättra dina tester.

• Testa dina skyddsåtgärder. Om du har tillämpat en tillfällig lösning eller en tillfällig korrigering kontrollerar du att den kan hantera förväntad belastning innan den permanenta korrigeringen är på plats.

• Sök efter liknande svagheter. Granska andra komponenter för samma konfigurations- eller designmönster som bidrog till driftstoppet. Lägg till tester för dessa komponenter innan de misslyckas på samma sätt.

Kombinera olika typer av tester

När du kör olika typer av tester tillsammans kan du avslöja tillförlitlighetsproblem som inte visas när varje test körs isolerat. En arbetsbelastning kan hantera en viss belastning under normala förhållanden, men samma belastning orsakar fel när du introducerar ett fel.

• Återanvänd befintlig testinfrastruktur. Om du redan har infrastruktur och en testsel för belastningstestning använder du den för att köra kaostester samtidigt. Att kombinera belastning och felinmatning i samma testkörning visar hur din arbetsbelastning beter sig under realistiska förhållanden, där efterfrågan och fel uppstår samtidigt.

• Starta i icke-produktionsmiljöer. Påbörja tillförlitlighetstestning i miljöer med lägre risk där du på ett säkert sätt kan utforska fellägen. Gå vidare till testning i produktion först när du har fått ut all information från icke-produktionsmiljöer och har skyddsmekanismer på plats för att begränsa påverkan och snabbt kunna rulla tillbaka.

Använda felinmatning och kaosteknik

Felinmatning och kaosteknik hjälper dig att skapa förtroende för din arbetsbelastnings återhämtning genom att avsiktligt införa fel och observera svaret. Kontrollera att du har åtgärdsstrategier på plats innan du kör experiment.

• Kör kaosexperiment regelbundet. Utvärdera testomfånget. Mata in fel i komponenter och flöden som du antar är tillförlitliga. När arkitekturen ändras uppstår nya fellägen och tidigare antaganden kanske inte längre gäller. Kör experiment regelbundet för att fånga regressioner, validera nya beroenden och bekräfta att de senaste ändringarna inte medförde några svagheter.

• Använd analys av felläge för att fokusera experiment. Varje experiment bör rikta in sig på ett specifikt fel eller en uppsättning fel och ha en tydlig hypotes, till exempel att testa ett visst flödes förmåga att motstå förlusten av en viss komponent. När experiment visar nya fellägen eller oupptäckta beroenden uppdaterar du fellägesanalysen för att hålla den aktuell.

• Begränsa påverkan vid experiment. Välj komponenter som du snabbt kan återställa och skapa realistiska förväntningar på påverkan av varje felinjektion. Om ett experiment överskrider omfånget eller ger oväntade resultat stoppar du det. Balansera insamling av meningsfulla data med att minimera effekten på användarna.

• Mät mot baslinjer. Upprätta konsekventa tillförlitlighets- och prestandamått för flöden och komponenter i varje experiment. Jämför degraderade tillståndsmått med dessa baslinjer för att förstå den fulla effekten av felet och avgöra om din återhämtningsdesign uppfyller sina mål.

• För tillbaka resultaten till teststrategin. Använd experimentresultat för att genomföra nya tester, uppdatera återställningsplaner och ligga till grund för poster i åtgärdsbackloggen. När oväntade beteenden uppstår skapar du riktade tester för dessa beteenden och utformar reparationsstrategier.

Kompromiss: Felinmatningstestning i produktion kan vara störande och kan orsaka driftstopp. Var transparent med intressenter om den här möjligheten. Sätt skydd på plats så att du kan stoppa experiment och återställa snabbt och vara flexibel när du ska köra tester eller undvika dem under känsliga perioder. För att skydda mot oavsiktliga avbrott planerar du för tillräcklig redundans och ser till att dina intressenter förstår kostnadsavvägningen.

Risk: Tillförlitlighetstestning kan utöka täckningen över många fellägen, men du bör sluta när det inte längre ger meningsfullt värde. Om du redan har en kvarvarande information om kända tillförlitlighetsproblem bör du prioritera att åtgärda problemen i stället för att lägga till fler tester.

Azure-förenkling

Azure Test Plans är en webbläsarbaserad testhanteringslösning som tillhandahåller alla funktioner som krävs för planerad manuell testning, testning av användargodkännande, undersökande testning och insamling av feedback från intressenter.

Azure Chaos Studio är en hanterad tjänst som använder kaostestning för att hjälpa dig att mäta, förstå och förbättra molnappens och tjänstens motståndskraft.

Azure applikationstestning är en tjänst som gör att du kan köra funktionella tester med Arbetsutrymmen för dramatiker- och prestandatester med Azure Load Testing för att identifiera problem i deras program.

Azure Service Health har ett planerat underhållsfönster som är ett dedikerat avsnitt i Azure portalen som håller dig informerad om kommande underhållsaktiviteter. Den visar händelser som kan påverka dina Azure resurser, vilket hjälper dig att förbereda dig i förväg.

Anslutningsövervakaren är en funktion i Azure Network Watcher som du kan använda för syntetisk övervakning och realtidstestning av nätverksanslutningar i både Azure- och hybridmiljöer. I kaostekniska scenarier kan anslutningsövervakaren användas för att mata in fel i målnätverkskomponenter och kontinuerligt mäta nyckelmått som svarstid och paketförlust. Med den här funktionen kan teamen se hur störningar påverkar nätverkets tillförlitlighet, både för enskilda flödeskomponenter och över nätverksvägar från slutpunkt till slutpunkt. Om du vill utvärdera effekten av fel och identifiera förbättringsområden jämför du telemetri för anslutningsövervakare med baslinjemått.

Relaterade länkar

• Säkerhetskopiering och haveriberedskap för Azure-program
• checklista för tillförlitlighetstestning
• Testa program för tillgänglighet och återhämtning

Checklista för tillförlitlighet

Se den fullständiga uppsättningen med rekommendationer.