Strategie architektury pro návrh strategie testování spolehlivosti

se vztahuje na toto doporučení kontrolního seznamu spolehlivosti v Azure Well-Architected Framework:

RE:08 řekl: Otestujte scénáře odolnosti a dostupnosti pomocí principů chaosu. Pomocí testování spolehlivosti ověřte, že vaše úloha dokáže odolat chybám, škálovat pod poptávkou a obnovit v rámci definovaných cílů.

Testování spolehlivosti zachycuje architektonické nedostatky před tím, než způsobí výpadky. Bez záměrného testování ve scénářích selhání nemůžete zjistit, jestli vzorce odolnosti skutečně fungují nebo jestli se vaše úlohy obnoví v rámci definovaných cílů.

Spolehlivost úloh posilujete při testování rizik zabezpečení, která ovlivňují dostupnost, problémy s výkonem, kvůli kterým je systém nepoužitelný, a provozní mezery, které omezují reakci na incidenty. Pomocí strategií popsaných v tomto článku nastavte frekvenci testování, která bude pravidelně ověřovat pracovní zátěž s ohledem na její způsoby selhání. Rozvíjejte své testy tak, jak se architektura mění a incidenty odhalují nové slabiny. Zajistěte si jistotu, že vaše úloha dokáže odolat chybám, škálovat tak, aby splňovala poptávku, a obnovovat se v rámci cílů RTO a RPO, a zároveň vytvořte smyčku zpětné vazby, která v průběhu času posiluje stav spolehlivosti.

Klíčové strategie v tomto článku vycházejí ze základních testovacích postupů popsaných ve strategiích architektury OE:09 pro testování. Nejprve si přečtěte tento článek. Doporučení v této příručce jsou zaměřena na spolehlivost a soustředí se na dosažení jistoty, že vaše úloha dokáže odolat poruchám a obnovit se v rámci vašich stanovených cílů.

Následující tabulka definuje klíčové termíny spolehlivosti používané v tomto článku.

Definice

Termín Definition
Availability Doba, po kterou je úloha aplikace spuštěná v dobrém stavu bez významného výpadku.
chaosové inženýrství Postup, který bezpečně zahrnuje testování chaosu do týmové kultury, technických postupů a životního cyklu vývoje, aby se zajistila kontinuální vylepšení odolnosti systému.
Testování chaosu Kontrolovaný experiment, který ověřuje konkrétní hypotézu odolnosti ohledně toho, jak se má úloha chovat za rušivých podmínek.
Simulace chyb Technika, která záměrně zavádí chyby součásti, závislosti nebo systémové cesty.
Návratnost Schopnost obnovit normální operace po přerušení v rámci dohodnutých cílů doby obnovení (RTO) a bodu obnovení (RPO).
Resiliency Schopnost úlohy odolat chybám (jako jsou přechodné chyby, výpadky infrastruktury, špičky poptávky) a pokračovat v provozu v přijatelném uživatelském prostředí.
Failover Proces přepnutí na sekundární komponentu při selhání primární komponenty.
Failback Proces, při kterém obnovíte provoz v primární oblasti poté, co se obnoví.
Rozpočet chyb Maximální přijatelná úroveň selhání systému v definovaném období odvozená od cílů úrovně služeb (SLA).

Definování rozsahu testování spolehlivosti na základě typů služeb

Když definujete rozsah testování spolehlivosti, zvažte model sdílené odpovědnosti služeb, které používáte. Každý typ služby (IaaS, PaaS, SaaS) má různé záruky spolehlivosti a různé úrovně kontroly nad zpracováním selhání. Zaměřte testování na oblasti spolehlivosti, za které odpovídáte.

  • Shodujte hloubku testování s vaší zodpovědností. Pro služby infrastruktury (IaaS) vlastní váš tým většinu rozhodnutí o spolehlivosti, takže investujte do důkladného ověřování prostřednictvím chaosu a injektáže chyb. U služeb platformy (PaaS) a softwaru (SaaS) spravuje poskytovatel většinu základní spolehlivosti. Zaměřte se na to, jak vaše pracovní zátěž spolupracuje s těmito službami, například jak zvládá převzetí služeb při selhání infrastruktury v prostředí PaaS, omezování propustnosti, degradaci služby nebo změny ve vzorcích zatížení.

  • Zohledněte úlohy se smíšenými službami. Pokud vaše úloha pokrývá více typů služeb, odpovědnosti za testování se v jednotlivých komponentách liší. Při výpadku zóny dostupnosti můžete otestovat failover komponent infrastruktury založených na virtuálních počítačích, ale u databáze PaaS navržené pro vysokou dostupnost se spoléháte na záruky poskytovatele. Určete, kde jsou tyto hranice, a ujistěte se, že testování pokrývá mezery mezi nimi.

Testování cílů spolehlivosti od konce do konce

Vaše cíle spolehlivosti, jako jsou SLO, RTO a RPO, definují, jak by se vaše pracovní zátěž měla chovat při selhání. Používejte je jako kritéria pro úspěch a neúspěch v rámci kompletních kritických procesů, nejen pro jednotlivé komponenty.

  • Ověřte obnovení v celém procesu. Jednu komponentu lze sice obnovit v rámci jejího RTO, ale celková doba obnovy může překročit cílovou hodnotu, pokud je třeba obnovit i navazující závislosti. Zohledněte celkovou dobu obnovy v celém procesu, včetně času potřebného k detekci problému a reakci na něj.

  • Definujte rozsah testování pomocí cílů úrovně služby a rozpočtů chyb. Váš chybový rozpočet představuje, kolik můžete investovat do vnášení chyb. Omezte testování chaosu tak, aby zůstalo v rámci vašich SLO, a k definování hranic každého testu použijte cíle obnovy toku.

Vytváření scénářů spolehlivosti z kritických toků a režimů selhání

Začněte u kritických toků ve své pracovní zátěži a u způsobů selhání, které je mohou ovlivnit. Využijte analýzu režimu selhání k identifikaci nejvíce ovlivněných scénářů selhání a sestavení testů, které ověřují vaši strategii odolnosti a obnovení.

Určete prioritu podle dopadu a pravděpodobnosti. Ne každý režim selhání zaručuje stejnou investici do testování. Nejprve se zaměřte na scénáře s nejvyšším potenciálním dopadem na uživatele a s nejvyšší pravděpodobností výskytu. Nechte analýzu režimu selhání řídit toto stanovení priority.

Ověření mechanismů odolnosti proti chybám a obnovení

Zaměřte se na scénáře, které s největší pravděpodobností způsobují výpadky nebo snižují uživatelské prostředí. Strategie v této části slouží k sestavení testů, které ověřují schopnost úloh efektivně zpracovávat chyby a obnovovat.

Zálohování a obnovení

Testování zálohování a obnovení by mělo ověřit, že váš přístup k ochraně dat splňuje vaše cíle obnovení.

  • Stanovte frekvenci testování. Zjistěte, jak často potřebujete testovat obnovení na základě četnosti změn konfigurace zálohování, schématu dat nebo infrastruktury. Častější změny vyžadují častější testování obnovy.

  • Nastavte cíle obnovení. Porovnejte skutečné doby obnovy s cílovými hodnotami RPO a RTO, abyste ověřili, že vaše strategie zálohování splňuje vaše cíle obnovy.

  • Nepředpokládejte úplnost zálohování. Zálohy můžou být chybně nakonfigurované tak, aby zachytály jenom podmnožinu dat. Ověřte integritu a úplnost dat, a ne jenom to, jestli operace obnovení proběhne úspěšně.

  • Testujte izolovaně. Ověřte obnovení v prostředí odděleném od produkčního prostředí, abyste mohli provádět důkladné kontroly bez přerušení živých úloh.

Přechodné chyby

Přechodná selhání, jako jsou momentální přerušení sítě, krátká nedostupnost služby a vypršení časových limitů připojení, jsou běžná rizika spolehlivosti. Ověřte, že vaše úloha zpracovává tyto chyby, aniž by to mělo vliv na uživatele. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

  • Zaměřte se na to, co vlastníte. Pokud sady SDK nebo služby platformy zpracovávají opakované pokusy a přerušení okruhu automaticky, otestujte, co se stane, když se tyto integrované mechanismy vyčerpá, například když se všechny pokusy nezdaří nebo se otevře jistič.

  • Ověřte konfigurace zpracování chyb. Vyhodnoťte konfigurace zpracování chyb vaší úlohy. Ověřte, že se zásady opakování, prahové hodnoty jističe a hodnoty časového limitu chovají podle očekávání za realistických chybových podmínek.

  • Otestujte hranici mezi přechodným a trvalým selháním. Ověřte, že vaše úloha plynule přechází z opakování pokusů do záložního nebo degradovaného režimu, pokud selhání přetrvává déle, než odpovídá očekávaným prahovým hodnotám.

  • Počítejte s přechodnými chybami způsobenými funkcemi odolnosti. Redundance zón a podobná řešení často způsobují přechodné chyby během běžných operací převzetí služeb při selhání. Například zónově redundantní databáze může způsobit přechodné selhání připojení, když se provoz během výpadku přesune do zóny, která je v pořádku. Otestujte, jestli vaše úloha zvládne tyto očekávané přechodné chyby bez významného dopadu na uživatele.

Reakce na zátěž a škálování

Ověřte, že vaše pracovní zátěž zůstává spolehlivá při změnách zatížení, a to jak při náhlých špičkách, tak při postupném nárůstu. Další informace najdete v tématu Strategie škálování. Pokyny pro zátěžové a zátěžové testování najdete v tématu Doporučení pro testování.

  • Otestujte škálování ven i dovnitř. Ověřte, že se nová kapacita uvádí do provozu dostatečně rychle a že snižování kapacity nezpůsobuje ztrátu požadavků ani nezanechává osiřelé prostředky.

  • Počítejte s prodlevou při škálování. Mezi splněním podmínek pro aktivaci škálování a připraveností nové kapacity vždy dochází ke zpoždění. Určete, jestli vaše úloha dokáže zpracovat poptávku během této mezery nebo jestli potřebujete předem zřídit další kapacitu.

Chyby závislostí

Vaše úloha pravděpodobně závisí na službách mimo vaši přímou kontrolu, jako jsou rozhraní API třetích stran, služby spravované platformy nebo sdílené interní služby. Ověřte, že vaše pracovní zátěž dokáže zvládat selhání těchto závislostí bez výrazného narušení pro uživatele.

  • Kategorizovat závislosti podle závažnosti Ne všechny závislosti zaručují stejnou investici do testování. Upřednostněte testování závislostí, které jsou ve vašich kritických tocích a které nemají předdefinované redundance nebo náhradní cesty.

  • Otestujte náhradní chování pro každou závislost. Pokud se závislost stane nedostupnou, vaše úloha by měla přejít na alternativní cestu nebo chování, místo aby zcela selhala. Ověřte, že se jednotlivé náhradní funkce správně aktivují a že nesouvisející funkce nadále fungují.

  • Počítejte s částečnými a kaskádovými selháními. Závislosti zřídka selžou binárními způsoby. Netestujte jen úplné výpadky. Pokrývá zvýšení latence, občasné chyby a částečnou dostupnost dat.

  • Ověřte izolaci a omezení rozsahu dopadu. Ověřte, že selhání jedné závislosti není kaskádově propojeno s nesouvisejícími funkcemi.

Sebezáchování a obnovení

Ověřte, jak váš návrh samoopravení a samozáchování reaguje na poruchy, včetně toho, jestli vaše úloha může pokračovat v provozu v omezené kapacitě, pokud úplné obnovení není okamžité.

  • Testování kompletního automatizovaného obnovení Vyhodnoťte své modely stavu, abyste měli jistotu, že obsahují správné kontroly. Ověřte, že tyto kontroly přesně detekují selhání, aktivují automatizovanou nápravu podle očekávání a v přijatelném časovém rámci vrátí systém do stavu v pořádku.

  • Ověřte ruční runbooky pro obnovení. Automatizované obnovení nebude zahrnovat každý scénář. Testujte manuální runbooky v realistických podmínkách, abyste měli jistotu, že je operátoři dokážou provádět i pod tlakem a v rámci stanovených cílů doby obnovení.

  • Ověřte chování při postupné degradaci služeb. Když některá komponenta selže, vaše pracovní zátěž by se měla řízeně omezit, místo aby zcela selhala. Otestujte, že může fungovat v omezeném režimu, jako je například řazení požadavků na ruční kontrolu a že je pro uživatele přijatelné snížení výkonu. Ověřte, že váš tým ví, jak pracovat s úlohou v tomto stavu a jak obnovit plnou funkčnost.

Incidenty a zotavení po havárii (DR)

Když dojde k incidentu nebo havárii, vaše schopnost rychle ho rozpoznat a efektivně reagovat je kritická. Otestujte plány a procesy a ujistěte se, že řeší závažné selhání a závažné incidenty. Pro testování obnovy po havárii použijte vyhrazené prostředí, aby nedošlo k ovlivnění produkčních úloh. Další informace najdete v plánu zotavení po havárii.

  • Ověřte mechanismy detekce incidentů. Simulujte incidenty, abyste ověřili, že protokoly monitorování zaznamenávají potřebné informace a že se výstrahy aktivují odpovídajícím způsobem. Otestujte například, jak rychle se zjistí zvýšená míra selhání požadavků a jak často se vzorkují data monitorování.

  • Testování procesů správy incidentů Ověřte, že váš tým může efektivně dodržovat postupy reakce na incidenty. Další informace najdete v tématu reakce na incidenty.

  • Otestujte úplné převzetí služeb při selhání a navrácení služeb po obnovení. Testování jednotlivých částí izolovaně může zmeškat selhání koordinace, která se zobrazí pouze během skutečného přechodu. Ověřte úplnou sekvenci převzetí služeb při selhání, včetně přepnutí DNS, obnovení záloh a konzistence replikace dat a opětovného připojení klientů. Otestujte také návrat na primární nasazení, který je často složitější než počáteční přepnutí.

  • Ověřte kapacitu v prostředí pro převzetí služeb při selhání. Ujistěte se, že vaše prostředí pro převzetí služeb při selhání má dostatečnou předem připravenou kapacitu, aby okamžitě po převzetí služeb při selhání zvládlo provoz, aniž by se pod zatížením zhroutilo. Otestujte, že prostředí dokáže udržovat operace, zatímco mechanismy škálování aktivují a ověřují váš přístup ke škálování. Další informace najdete v tématu Odezva při zatížení a škálování.

  • Porovnejte výsledky se svými cíli. Pokud test zotavení po havárii nesplňuje vaše RTO nebo RPO, analyzujte nedostatky a odpovídajícím způsobem aktualizujte svůj plán zotavení po havárii.

  • Ověřte lidi a proces. Testování DR by mělo ověřit komunikační kanály, potvrdit, že operátoři mají potřebný přístup a oprávnění k provádění postupů obnovy, a zajistit, aby ve vypjaté situaci dokázali rychle najít runbooky pro DR.

Otestujte a vyhodnoťte svůj plán pomocí tabletop cvičení

Tabletop cvičení vám pomohou odhalit nedostatky v testování spolehlivosti dříve, než je odhalí skutečný incident. Simulací scénářů selhání s vaším týmem můžete identifikovat neotestované podmínky a ověřit, že postupy reakce fungují podle očekávání.

  • Simulace realistických incidentů Projděte si scénář selhání, například oblastní výpadek nebo poškozené nasazení, a požádejte váš tým, aby popsal kroky, které by provedly k detekci, reagování na ně a zotavení z něj. Tyto diskuze často odhalí předpoklady o chování systému, které se neověřily prostřednictvím testování.

  • Proměňte závěry na testovací případy. Využijte nedostatky a nejasnosti, které vyjdou najevo v průběhu cvičení, k vytvoření nových testů spolehlivosti. Pokud tým zjistí, že nikdo neví, jak se úloha chová v případě selhání konkrétní závislosti, jedná se o scénář přidání do testovací strategie.

Využití výhod plánovaných a neplánovaných výpadků

Pokud je vaše úloha offline kvůli plánované údržbě nebo neplánovanému výpadku, máte jedinečnou příležitost provést testování a zlepšit porozumění vaší úloze.

Plánovaná údržba

Během časových období údržby pro aktualizace nebo opravy testujte součásti a toky, které nejsou součástí údržby. Testy můžete spouštět bez rizika neočekávaného snížení zatížení nebo jeho offline režimu. Pokud máte dostatek času, otestujte také součásti, které jsou součástí údržby po dokončení práce.

Neplánovaný výpadek

Každý neplánovaný výpadek je příležitostí posílit strategii testování spolehlivosti. Po obnovení služby a dokončení závěrečné kontroly incidentu využijte vaše zjištění ke zlepšení testů.

  • Otestujte opatření pro zmírnění rizik. Pokud jste použili alternativní řešení nebo dočasnou opravu, ověřte, že dokáže zpracovat očekávané zatížení, než bude trvalá oprava zavedená.

  • Vyhledejte podobné slabiny. Zkontrolujte další komponenty pro stejné vzory konfigurace nebo návrhu, které přispěly k výpadku. Přidejte testy pro tyto komponenty dříve, než selžou stejným způsobem.

Kombinování různých typů testů

Když spustíte různé typy testů společně, můžete odhalit problémy se spolehlivostí, které nejsou viditelné, když se jednotlivé testy spustí izolovaně. Úloha může za normálních podmínek zpracovávat konkrétní zatížení, ale stejné zatížení způsobuje selhání při zavedení chyby.

  • Znovu použijte existující testovací infrastrukturu. Pokud už máte infrastrukturu a testovací sadu pro zátěžové testování, použijte ji ke souběžným spouštění testů chaosu. Kombinace simulace zátěže a poruch v rámci jednoho testovacího běhu ukazuje, jak se vaše pracovní zátěž chová za realistických podmínek, kdy se současně objevuje zatížení i poruchy.

  • Začněte v neprodukčním prostředí. Začněte testovat spolehlivost v prostředích s nižším rizikem, kde můžete bezpečně zkoumat režimy selhání. Přesuňte se do produkčního testování až po vyčerpání přehledů z neprodukčního prostředí a zajištění bezpečnostních opatření k omezení poloměru výbuchu a rychlému vrácení zpět.

Použití injekce chyb a chaotického inženýrství

Injektáž chyb a inženýring chaosu pomáhají budovat důvěru v odolnost vaší úlohy tím, že záměrně zavádějí chyby a sledují odezvu. Před spuštěním experimentů se ujistěte, že máte zavedené strategie zmírnění rizik.

  • Pravidelně spouštět experimenty s chaosem. Vyhodnoťte rozsah testu. Vložte chyby do komponent a toků, které předpokládáte, že jsou spolehlivé. Jak se vaše architektura mění, objevují se nové režimy selhání a předchozí předpoklady už nemusí zůstat. Spusťte experimenty s pravidelným tempem, abyste zachytili regrese, ověřili nové závislosti a potvrdili, že nedávné změny nezavádějí slabé stránky.

  • Pomocí analýzy režimu selhání zaměřte experimenty. Každý experiment by měl cílit na konkrétní chybu nebo sadu chyb a mít jasnou hypotézu, například testování schopnosti daného toku odolat ztrátě konkrétní komponenty. Když experimenty odhalí nové režimy selhání nebo nezjiscené závislosti, aktualizujte analýzu režimu selhání, aby byla aktuální.

  • Obsahují poloměr výbuchu během experimentů. Cílové komponenty, které můžete rychle obnovit a nastavit informovaná očekávání o účinku každé injektáže selhání. Pokud experiment překročí rozsah nebo vytvoří neočekávané výsledky, zastavte ho. Vyvážení shromažďování smysluplných dat s minimalizací dopadu na uživatele

  • Měření proti směrnému plánu. Vytvořte konzistentní metriky spolehlivosti a výkonu pro toky a komponenty v každém experimentu. Porovnejte metriky degradovaného stavu s těmito výchozími hodnotami, abyste pochopili plný dopad poruchy a určili, zda návrh odolnosti systému splňuje stanovené cíle.

  • Zahrňte výsledky zpět do své testovací strategie. Využijte výsledky experimentu k navržení nových testů, aktualizaci plánů obnovy a upřesnění položek backlogu nápravných opatření. Když se objeví neočekávané chování, vytvořte pro ně cílené testy a navrhněte strategie nápravy.

kompromis: Testování injektování chyb v produkčním prostředí může být rušivé a může potenciálně způsobit výpadky. Buďte transparentní se zúčastněnými stranami o této možnosti. Nasaďte bezpečnostní opatření, abyste mohli rychle zastavit experimenty a vrátit se zpět a zůstat flexibilní, kdy spouštět testy nebo se jim vyhnout během citlivých období. Pokud chcete chránit před nezamýšlenými výpadky, naplánujte dostatečnou redundanci a ujistěte se, že zúčastněné strany chápou kompromis mezi náklady.

Riziko: Testování spolehlivosti může rozšířit pokrytí napříč mnoha režimy selhání, ale měli byste ho zastavit, jakmile už neposkytuje smysluplnou hodnotu. Pokud už máte backlog známých problémů se spolehlivostí, určete prioritu řešení těchto problémů místo přidávání dalších testů.

Usnadnění na platformě Azure

Azure Test Plans je řešení pro správu testů založené na prohlížeči, které poskytuje všechny možnosti potřebné pro plánované ruční testování, testování přijetí uživatelů, průzkumné testování a shromažďování zpětné vazby od zúčastněných stran.

Azure Chaos Studio je spravovaná služba, která pomocí testování chaosu pomáhá měřit, pochopit a zlepšit odolnost cloudových aplikací a služeb.

Testování aplikací Azure je služba, která umožňuje spouštět funkční testy s Pracovní prostory dramatiků a testy výkonnosti pomocí Azure Load Testing k identifikaci problémů v aplikacích.

Azure Service Health má podokno plánované údržby, což je vyhrazený oddíl na portálu Azure, který vás informuje o nadcházejících aktivitách údržby. Zvýrazní události, které můžou ovlivnit vaše Azure prostředky a pomáhají vám připravit se předem.

Monitorování připojení je funkce služby Azure Network Watcher , kterou můžete použít k syntetickému monitorování a testování síťového připojení v reálném čase v azure i v hybridních prostředích. Ve scénářích chaosu je možné monitorování připojení použít k vkládání chyb do cílových síťových komponent a průběžnému měření klíčových metrik, jako je latence a ztráta paketů. Tato funkce umožňuje týmům sledovat, jak přerušení ovlivňuje spolehlivost sítě, a to jak pro jednotlivé komponenty toku, tak pro cesty k síti typu end-to-end. Pokud chcete posoudit dopad chyb a identifikovat oblasti pro zlepšení, porovnejte telemetrii monitorování připojení se základními metrikami.

Kontrolní seznam pro spolehlivost

Podívejte se na úplný soubor doporučení.

Kontrolní seznam pro spolehlivost

  • Last updated on