Principy návrhu spolehlivosti

Článek
11/15/2023

Výpadky a poruchy představují vážné obavy pro všechny úlohy. Spolehlivá úloha musí tyto události přežít a musí i nadále konzistentně poskytovat zamýšlenou funkčnost. Musí být odolný , aby mohl detekovat, odolat selháním a zotavit se z ní během přijatelného časového období. Musí být také k dispozici , aby uživatelé měli přístup k úloze během slíbené doby na úrovni slíbené kvality.

Není reálné předpokládat, že k selháním nedojde, zejména pokud je úloha vytvořená tak, aby běžela v distribuovaných systémech. Některé komponenty můžou selhat, zatímco jiné budou dál fungovat. V určitém okamžiku může být ovlivněno uživatelské prostředí, což ohrožuje obchodní cíle.

Architektury úloh by měly mít záruku spolehlivosti v kódu aplikace, infrastruktuře a provozu. Možnosti návrhu by neměly měnit záměr určený obchodními požadavky. Tyto změny by měly být považovány za významné kompromisy.

Principy návrhu mají poskytovat pokyny pro aspekty spolehlivosti, které byste měli zvážit v průběhu životního cyklu vývoje. Začněte s doporučenými přístupy a ospravedlněte výhody sady požadavků. Po nastavení strategie můžete akce řídit pomocí kontrolního seznamu pro spolehlivost.

Pokud tyto principy ve svém návrhu nepoužijete, úloha s největší pravděpodobností nebude připravená předvídat nebo řešit problémy v produkčním prostředí. Výsledkem můžou být přerušení služeb, která vedou k finanční ztrátě. V případě kritických úloh může nedodržení těchto zásad ohrozit bezpečnost.

Návrh pro obchodní požadavky

Shromážděte obchodní požadavky se zaměřením na zamýšlený nástroj úlohy.

Požadavky musí zahrnovat uživatelské prostředí, data, pracovní postupy a charakteristiky, které jsou pro danou úlohu jedinečné. Výsledek procesu požadavků musí jasně uvádět očekávání. Cíle musí být dosažitelné a vyjednávány s týmem s ohledem na konkrétní investici. Musí být zdokumentovány, aby podporovaly technologické volby, implementace a operace.

Přístup	Výhoda
Kvantifikovat úspěch nastavením cílů indikátorů pro jednotlivé komponenty, systémové toky a systém jako celek. Jsou díky těmto cílům toky uživatelů spolehlivější?	Metriky kvantifikují očekávání. Umožňují vám pochopit složitosti a určit, jestli jsou náklady na podřízené tyto složitosti v rámci investičního limitu. Cílové hodnoty označují ideální stav. Hodnoty můžete použít jako testovací prahové hodnoty, které vám pomůžou zjistit odchylky od tohoto stavu a jak dlouho trvá návrat do cílového stavu. Požadavky na dodržování předpisů musí mít také předvídatelné výsledky pro toky v rámci oboru. Stanovení priority těchto toků přivádí pozornost k oblastem, které jsou nejcitlivější.
Seznamte se s závazky platformy. Zvažte limity, kvóty, oblasti a omezení kapacity pro služby.	Smlouvy o úrovni služeb (SLA) se liší podle služby. Ne všechny služby a funkce jsou pokryté stejně. Ne všechny služby nebo funkce jsou dostupné ve všech oblastech. Většina omezení prostředků předplatného je pro jednotlivé oblasti. Dobré znalosti o pokrytí a limitech vám můžou pomoct odhalit odchylky a vytvořit mechanismy odolnosti a obnovení.
Určete závislosti a jejich vliv na odolnost.	Sledování závislé infrastruktury, služeb, rozhraní API a funkcí vyvinutých jinými týmy nebo třetími stranami vám pomůže určit, jestli může úloha fungovat bez těchto závislostí. Pomůže vám také pochopit kaskádová selhání a zlepšit podřízený provoz. Vývojáři můžou implementovat odolné vzory návrhu , které zvládnou potenciální selhání při používání externích služeb, které můžou být náchylné k selháním.

Návrh pro odolnost proti chybám

Úloha musí i nadále fungovat s plnou nebo omezenou funkčností.

Měli byste očekávat, že dojde k selhání komponent, výpadkům platformy, snížení výkonu, omezené dostupnosti prostředků a dalším chybám. Vytvořte odolnost systému tak, aby byl odolný proti chybám a mohl se elegantně snižovat.

Přístup	Výhoda
Odliší komponenty, které jsou na kritické cestě , od těch, které mohou fungovat v degradované stavu.	Ne všechny komponenty úlohy musí být stejně spolehlivé. Určení důležitosti vám pomůže při návrhu podle závažnosti jednotlivých komponent. Nebudete překonávat odolnost komponent, které by mohly mírně zhoršit uživatelské prostředí, na rozdíl od komponent, které mohou způsobit kompletní problémy, pokud selžou. Návrh může být efektivní při přidělování prostředků důležitým komponentám. Můžete také implementovat strategie izolace chyb, aby v případě, že nekritická komponenta selže nebo přejde do degradovaného stavu, bylo možné ji izolovat, aby se zabránilo kaskádovým selháním.
Identifikujte potenciální body selhání v systému, zejména pro kritické komponenty, a určete vliv na toky uživatelů.	Můžete analyzovat případy selhání, poloměr výbuchu a intenzitu selhání: úplný nebo částečný výpadek. Tato analýza ovlivňuje návrh možností zpracování chyb na úrovni komponent.
Sestavte možnosti sebezáchovy pomocí správných vzorů návrhu a modularizací návrhu za účelem izolace chyb.	Systém dokáže zabránit tomu, aby problém ovlivnil podřízené komponenty. Systém bude schopen zmírnit přechodná a trvalá selhání, kritické body výkonu a další problémy, které můžou mít vliv na spolehlivost. Budete také moct minimalizovat poloměr výbuchu.
Přidejte možnost horizontálního navýšení kapacity důležitých komponent (aplikací a infrastruktury) s ohledem na omezení kapacity služeb v podporovaných oblastech.	Úloha bude schopná zvládnout výkyvy a špičky proměnlivé kapacity. Tato funkce je zásadní v případě neočekávaného zatížení systému, jako je nárůst platného využití. Pokud je úloha navržená tak, aby škálovat na více oblastí, může dokonce překonat potenciální dočasná omezení kapacity prostředků nebo jiné problémy, které mají dopad na jednu oblast.
Vytvořte redundanci ve vrstvách a odolnost na různých aplikačních vrstvách. Zaměřte se na redundanci fyzických nástrojů a okamžitou replikaci dat. Zaměřte se také na redundanci ve funkční vrstvě, která pokrývá služby, provoz a pracovníky.	Redundance pomáhá minimalizovat jednotlivé body selhání. Pokud například dojde k výpadku komponenty, zónového nebo oblastního, redundantní nasazení (aktivní-aktivní nebo aktivní-pasivní) vám umožní splnit cíle doby provozu. Přidání zprostředkovatelů zabraňuje přímé závislosti mezi komponentami a zlepšuje ukládání do vyrovnávací paměti. Obě tyto výhody posílí odolnost systému.
Nadměrné zřizování k okamžitému zmírnění jednotlivých selhání redundantních instancí a k ukládání do vyrovnávací paměti proti nehotovým prostředkům.	Vyšší investice do nadlimitace zvyšují odolnost. Systém bude během aktivního selhání dál fungovat na plný provoz, a to i před zahájením operací škálování, které by chybu napravily. Podobně můžete snížit riziko neočekávaného využití prostředků, které si nárokuje plánovanou vyrovnávací paměť, získání kritické doby třídění, než dojde k chybám systému nebo agresivnímu škálování.

Návrh pro obnovení

Úloha musí být schopná předvídat většinu selhání všech velikostí a zotavit se z nich s minimálním narušením uživatelského prostředí a obchodních cílů.

Dokonce i vysoce odolné systémy vyžadují přístupy připravenosti na havárii, a to jak v návrhu architektury, tak v provozu úloh. V datové vrstvě byste měli mít strategie, které můžou opravit stav úlohy v případě poškození.

Přístup	Výhoda
Mít strukturované, otestované a zdokumentované plány obnovení , které jsou v souladu s vyjednanými cíli obnovení. Plány musí kromě celého systému pokrývat i všechny komponenty.	Dobře definovaný proces vede k rychlému zotavení , které může zabránit negativnímu dopadu na finance a pověst vaší firmy. Provádění pravidelných postupů obnovení testuje proces obnovení součástí systému, dat a kroků převzetí služeb při selhání a navrácení služeb po obnovení, aby se předešlo nejasnostem, když jsou klíčovými měřítky úspěchu čas a integrita dat .
Ujistěte se, že můžete opravit data všech stavových komponent v rámci cílů obnovení.	Zálohy jsou nezbytné k tomu, aby se systém vrátil do funkčního stavu pomocí důvěryhodného bodu obnovení, jako je poslední známý dobrý stav. Neměnné a transakce konzistentní zálohy zajišťují, že data nelze změnit a obnovená data nejsou poškozena.
Implementujte do návrhu automatizované funkce samoopravení .	Tato automatizace snižuje rizika vyplývající z externích faktorů, jako je lidský zásah, a zkracuje cyklus oprav přerušení.
Nahraďte bezstavové komponenty neměnnými dočasnými jednotkami.	Vytváření dočasných jednotek, které můžete na vyžádání aktivovat a zničit, poskytuje opakovatelnost a konzistenci. Pomocí modelů souběžného nasazení můžete přechod na nové jednotky inkrementální a minimalizovat tak výpadky.

Návrhy pro provozní tým

Posun doleva v operacích, aby se předvídaly podmínky selhání.

Testujte selhání v rané fázi a často v životním cyklu vývoje a určete dopad výkonu na spolehlivost. V zájmu analýzy původní příčiny a následných posmrtných kroků potřebujete mít sdílený přehled o stavu závislostí a probíhajících selháních napříč týmy. Přehledy, diagnostika a upozornění z pozorovatelných systémů jsou zásadní pro efektivní správu incidentů a neustálé zlepšování.

Přístup	Výhoda
Vytvářejte pozorovatelné systémy , které můžou korelovat telemetrii.	Monitorování a diagnostika jsou zásadní operace. Pokud něco selže, musíte vědět, že došlo k selhání, kdy došlo k selhání a proč došlo k selhání. Pozorovatelnost na úrovni komponent je základní, ale agregovaná pozorovatelnost komponent a korelované toky uživatelů poskytují ucelený pohled na stav. Tato data jsou potřebná k tomu, aby technici spolehlivosti lokality mohli upřednostnit své úsilí o nápravu.
Predikce potenciálních poruch a neobvyklého chování Zviditelněte chyby aktivní spolehlivosti pomocí výstrah s prioritou a s možností použití. Investujte do spolehlivých procesů a infrastruktury, které vedou k rychlejšímu třídění.	Technici spolehlivosti webu mohou být okamžitě upozorněni, aby mohli zmírnit probíhající incidenty živého webu a proaktivně zmírnit potenciální selhání identifikovaná prediktivními výstrahami předtím, než se stanou živými incidenty.
Simulace selhání a spouštění testů v produkčním a předprodukčním prostředí	Je výhodné zaznamenat selhání v produkčním prostředí, abyste mohli nastavit realistická očekávání pro obnovení. To vám umožní zvolit návrh, který bude elegantně reagovat na chyby. Umožňuje také otestovat prahové hodnoty, které nastavíte pro obchodní metriky.
Vytvářejte komponenty s ohledem na automatizaci a automatizujte co nejvíce.	Automatizace minimalizuje riziko lidské chyby a přináší konzistenci pro testování, nasazení a provoz.
Zatěžujte rutinní operace a jejich vliv na stabilitu systému.	Úloha může být předmětem probíhajících operací, jako jsou revize aplikací, audity zabezpečení a dodržování předpisů, upgrady komponent a procesy zálohování. Kontrola těchto změn zajišťuje stabilitu systému.
Průběžně se učí z incidentů v produkčním prostředí.	Na základě incidentů můžete určit dopad a dohled při návrhu a operacích, které můžou být v předprodukci bez povšimnutí. Nakonec budete moct provádět vylepšení na základě reálných incidentů.

Udržujte to jednoduché

Vyhněte se přetěžování návrhu architektury, kódu aplikace a operací.

K nejspolehlivějším řešením často vede to, co odeberete, a ne to, co přidáte. Jednoduchost zmenšuje plochu pro řízení, minimalizuje neefektivnost a potenciální chybné konfigurace nebo neočekávané interakce. Na druhou stranu, nadměrné zjednodušení může přinést jednotlivé body selhání. Udržujte vyvážený přístup.

Přístup	Výhoda
Komponenty můžete do architektury přidávat jenom v případě, že vám pomůžou dosáhnout cílových obchodních hodnot. Udržujte kritickou cestu štíhlou.	Návrh pro obchodní požadavky může vést k jednoduchému řešení, které se snadno implementuje a spravuje. Vyhněte se příliš mnoha kritickým komponentám, protože každá z nich představuje významný bod selhání.
Vytvořte standardy pro implementaci, nasazení a procesy kódu a zdokumentujte je. Identifikujte příležitosti k vynucení těchto standardů pomocí automatizovaných ověření.	Standardy zajišťují konzistenci a minimalizují lidské chyby. Přístupy, jako jsou standardní zásady vytváření názvů a průvodci stylem kódu, vám můžou pomoct udržet kvalitu a usnadnit identifikaci prostředků během řešení potíží.
Vyhodnoťte, jestli se teoretické přístupy překládají na pragmatičtější návrh , který se vztahuje na vaše případy použití.	Příliš podrobný kód aplikace může vést ke zbytečné vzájemné závislosti, dalším operacím a obtížné údržbě.
Vytvořte jen dostatek kódu.	Budete schopni zabránit problémům, které jsou výsledkem neefektivních implementací, jako jsou neočekávané využití prostředků, selhání uživatelů nebo toků dat a chyby kódu. Naopak problémy se spolehlivostí by měly vést ke kontrolě kódu, aby se zajistilo, že je kód dostatečně odolný pro řešení problémů.
Využijte funkce poskytované platformou a předem připravené prostředky, které vám pomůžou efektivně plnit obchodní cíle.	Tento přístup minimalizuje dobu vývoje. Umožňuje také spoléhat se na vyzkoušené a otestované postupy , které byly použity u podobných úloh.

Další kroky

Kontrolní seznam spolehlivosti