Principy spolehlivého návrhu

Výpadky a poruchy jsou zásadní důvody ke znepokojení pro všechny pracovní zátěže. Spolehlivá úloha musí tyto události přežít a pokračovat v konzistentním poskytování zamýšlených funkcí. Musí být odolný , aby mohl detekovat a odolat chybám a zároveň pokračovat v provozu. Musí být obnovitelná, aby v případě, že přerušení překročí míry odolnosti, bylo možné obnovit úlohu v rámci dohodnutých cílů obnovení. Musí být také k dispozici , aby uživatelé měli přístup k úloze během slibovaného časového období na úrovni slíbené kvality.

Není reálné předpokládat, že k selháním nedojde, zejména když 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 dojít k ovlivnění uživatelského prostředí, což ohrožuje obchodní cíle.

Architektury úloh by měly mít záruky 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 jsou určené k poskytování pokynů pro aspekty spolehlivosti, které byste měli zvážit v průběhu životního cyklu vývoje. Začněte doporučenými přístupy a ospravedlněte výhody pro sadu požadavků. Po nastavení strategie můžete řídit akce pomocí kontrolního seznamu pro spolehlivost.

Pokud tyto principy u návrhu nepoužijete, s největší pravděpodobností nebude úloha připravená předvídat nebo řešit problémy v produkčním prostředí. Výsledkem může být přerušení služeb, které vede k finanční ztrátě. V případě kritických úloh by při selhání těchto principů mohlo dojít k ohrožení bezpečnosti.

Návrh pro obchodní požadavky

Získejte přehled o rozsahu úlohy, růstu uživatelů a nejdůležitějším slibům, že tým provedl externím zákazníkům a interním zúčastněným stranám.

Návrh není odhadnutelný na základě nedefinovaných nebo vágních výsledků. Spolehlivost vyžaduje záměrnou aktivitu, která dosahuje sladění s přijatelným uživatelským prostředím, omezeními návrhu a tím, jak vypadá úspěch a jak se měří.

Nastavte jasné, dosažitelné a zdokumentované cíle, vyjednané s obchodními zúčastněnými stranami a uzemněné realistickými investicemi a prognózami. Tyto požadavky budou přímo informovat vaše volby architektury, od strategií odolnosti až po pozorovatelné nástroje a plány škálování.

Přístup	Prospěch
Zaměřte se na shromažďování informací potřebných k definování rozsahu a hloubky řešení. Objasnění omezení, která ovlivňují obchodní cíle Začněte s dotazy vysoké úrovně, například: - Jakou úroveň odolnosti, obnovení, pozorovatelnosti a jednoduchosti je potřeba? – Existují definovaná omezení související s náklady, dodržováním předpisů, geografickou oblastí nebo latencí? Na základě této informace zdokumentujte, co je dostatečně dobré a jednoduché k dosažení.	Porozumění cílům a hranicím zabrání odhadování. Jinak se můžete zaseknout ve smyčce iterativního návrhu, což vede k plýtvání úsilím a zbytečným nákladům.
Řídit rozhodování překladem obchodních cílů do sdíleného porozumění architektonickým kompromisům v rámci reálných omezení. Prezentovat možnosti, které mají vliv: - Finanční náklady - Technická složitost – Aspekty zabezpečení - Provozní režie	To pomůže zúčastněným stranám porozumět nákladům, složitosti a provozním důsledkům jejich požadavků a vést je k realistickým a sladěným výsledkům.
Upřednostnit definování výsledků spolehlivosti pro každý kritický tok uživatele přes obecná měření, jako je doba provozu. Identifikujte uživatelsky orientované funkce a toky systémem a pro každý z nich vyhodnoťte jeho obchodní hodnotu, vzory využití a požadavky na odolnost. Zajistěte konsensus na úrovni toku, abyste zajistili, že rozhodnutí o návrhu zůstanou v souladu s obchodními cíli.	Tato konverzace pomáhá přesunout zúčastněné strany od netenovatelných tvrzení, jako je třeba "web musí být vždy v provozu" na praktické, dosažitelné očekávání svázané se skutečnými funkcemi a výsledky. Tyto výsledky pomáhají stanovit, co se řeší technologií a co je možné řešit dalšími plány kontinuity podnikových procesů.
Ukotvení možností návrhu kolem časových horizontů Definujte očekávání využití s realistickými prognózami. Jaká je například očekávaná zátěž uživatele při spuštění? Očekává se, že růst uživatelů bude lineární, exponenciální nebo nejistý.	Tyto informace vám pomůžou navrhnout architekturu, která bude řešit krátkodobé potřeby spolehlivosti, a zároveň se vyhnout rozhodování o návrhu, která budou vyžadovat významné přepracování pro zvládnutí budoucích horizontů. Tento přístup má vliv na to, jak přemýšlet o elasticitě, pracovních postupech řízených událostmi a umožňuje provádět strategické volby týkající se toho, jaké technické dluhy se mají buď vyřídit, nebo se jim vyhnout.
Faktor v závislostech , které by mohly omezit autonomii návrhu, jako jsou omezení organizace. Mějte na paměti centralizovanou infrastrukturu, bezpečnostní mandáty, zásady směrování sítě nebo rozhodnutí o platformě, která přímo ovlivňují to, co můžete slibovat z hlediska odolnosti, dostupnosti a obnovení.	Pochopení závislosti na službách mimo vaši kontrolu vám pomůže navrhovat s realistickými očekáváními pro spolehlivost. Zajišťuje, že vaše cíle RTO/RPO a SLO jsou dosažitelné a jasně komunikované, což pomáhá vyhnout se nadsazeným slibům a snižuje nečekaná překvapení.

Návrh pro odolnost

Úloha musí dál fungovat s plnou nebo omezenou funkčností.

Měli byste očekávat, že dojde k selháním komponent, výpadkům platformy, snížení výkonu, omezené dostupnosti prostředků a dalším chybám. Budujte odolnost systému tak, aby byl odolný vůči chybám a dokázal se elegantně přizpůsobit.

Přístup	Prospěch
Odlište komponenty, které jsou na kritické cestě, od těch, které můžou fungovat v degradovaném stavu.	Ne všechny komponenty úlohy musí být stejně spolehlivé. Určení závažnosti vám pomůže navrhnout podle závažnosti jednotlivých komponent. Odolnost komponent, které by mohly mírně zhoršovat uživatelskou zkušenost, nebudete nadměrně řešit na rozdíl od komponent, které můžou způsobit celkové problémy, pokud selžou. Návrh může být efektivní při přidělování prostředků kritickým komponentám. Můžete také implementovat strategie izolace chyb, aby v případě, že nekritická komponenta selže nebo vstoupila do degradovaného stavu, je 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 důležité 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ýpadky. Tato analýza ovlivňuje návrh možností zpracování chyb na úrovni komponenty.
Vytvářejte schopnosti sebezáchovné chování správným použitím návrhových vzorů a modulárního návrhu, pro izolaci chyb.	Systém bude moct zabránit problému v ovlivnění podřízených komponent. Systém dokáže zmírnit přechodné a trvalé selhání, kritické body výkonu a další problémy, které by mohly ovlivnit spolehlivost. Budete také schopni minimalizovat poloměr výbuchu.
Přidáním možnosti škálovat důležité komponenty (aplikace a infrastruktura) zvažte omezení kapacity služeb v podporovaných oblastech.	Úloha bude schopná zvládnout špičky a kolísání 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žena tak, aby škálovala napříč více regiony, může dokonce překonat potenciální dočasná omezení kapacity zdrojů nebo jiné problémy, které mají vliv na jeden region.
Vytvářejte redundanci ve vrstvách a odolnosti na různých aplikačních úrovních. Zaměřte se na redundanci fyzických nástrojů a okamžité replikace dat. Snažte se také o redundanci ve funkční vrstvě, která se zabývá službami, provozem a pracovníky.	Redundance pomáhá minimalizovat jednotlivé body selhání. Pokud například dojde ke komponentnímu, zónovému dostupnostnímu nebo regionálnímu výpadku, redundantní nasazení (v aktivní-aktivní nebo aktivní-pasivní) umožňuje splnit cíle dostupnosti. Přidání zprostředkovatelů brání přímé závislosti mezi součástmi a zlepšuje ukládání do vyrovnávací paměti. Obě tyto výhody podporují odolnost systému.
Nadprovisioning pro okamžité zmírnění individuálních selhání redundantních instancí a zajištění ochrany před nekontrolovanou spotřebou prostředků.	Vyšší investice do nadprovisioningu zvyšují odolnost. Systém bude během aktivního selhání fungovat při plném využití, a to i před tím, než se operace škálování můžou spustit, aby se selhání odstranilo. Stejně tak můžete snížit riziko nečekané nekontrolované spotřeby prostředků zabírající vaši plánovanou vyrovnávací paměť a získat kritický čas na zásah, než dojde k chybám systému nebo potřebě agresivního škálování.

Návrh pro obnovení

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

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

Přístup	Prospěch
Mají strukturované, otestované a zdokumentované plány obnovení , které jsou v souladu s vyjednanými cíli obnovení. Plány musí zahrnovat všechny komponenty kromě systému jako celku.	Dobře definovaný proces vede k rychlému obnovení , které může zabránit negativnímu dopadu na finance a pověst vaší firmy. Provádění pravidelných cvičení obnovení testuje proces obnovy systémových komponent, dat a kroků při selhání a obnově, aby se zabránilo nejasnostem, když jsou čas a integrita dat klíčovými ukazateli úspěchu.
Ujistěte se, že můžete opravit data všech stavových komponent v rámci cílů obnovení.	Zálohy jsou nezbytné pro obnovení systému do funkčního stavu pomocí důvěryhodného bodu obnovení, jako je například poslední známý dobrý stav. Neměnné a transakční konzistentní zálohy zajišťují, že data nejdou změnit a že obnovená data nejsou poškozená.
Implementace automatizovaných možností samoopravení v návrhu	Tato automatizace snižuje rizika z externích faktorů, jako je lidský zásah, a zkracuje cyklus opravy přerušení.
Nahraďte bezstavové komponenty neměnnými dočasnými jednotkami.	Vytváření dočasných jednotek, které můžete aktivovat a zničit na vyžádání, poskytuje opakovatelnost a konzistenci. Pomocí modelů souběžného nasazení můžete provést přechod na nové jednotky přírůstkově, což minimalizuje přerušení.

Návrh pro operace

Posun doleva v operacích za účelem předvídání podmínek selhání.

Testování selhání co nejdříve a co nejčastěji v životním cyklu vývoje a stanovení dopadu výkonu na spolehlivost. Pro účely analýzy původní příčiny a postmortem 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 výstrahy z pozorovatelných systémů jsou zásadní pro efektivní správu incidentů a průběžné vylepšování.

Přístup	Prospěch
Vytvářejte pozorovatelné systémy , které můžou korelovat telemetrii.	Monitorování a diagnostika jsou zásadní operace. Pokud se něco nepovede, musíte vědět, že selhal, když selhal, a proč selhal. Pozorovatelnost na úrovni komponenty je zásadní, ale agregovaná pozorovatelnost komponent a korelované toky uživatelů poskytují ucelený pohled na stav. Tato data jsou nutná k tomu, aby inženýři pro spolehlivost lokality upřednostnili své úsilí o nápravu.
Predikce potenciálních poruch a neobvyklého chování Zviditelnit aktivní selhání spolehlivosti pomocí prioritních a použitelných výstrah. Investujte do spolehlivých procesů a infrastruktury, které vedou k rychlejšímu třídění.	Inženýři 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 možnosti návrhu, který elegantně reaguje na selhání. Umožňuje také otestovat prahové hodnoty, které jste nastavili pro obchodní metriky.
Vytvářejte komponenty s ohledem na automatizaci a automatizujte co nejvíce.	Automatizace minimalizuje potenciál lidské chyby a přináší konzistenci při testování, nasazení a operacích.
Faktor v rutinních operacích a jejich dopad na stabilitu systému.	Úloha může podléhat probíhajícím operacím, 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.
Nepřetržitě se učí z incidentů v produkčním prostředí.	V závislosti na incidentech můžete určit dopad a dohled nad návrhem a operacemi, které by mohly být v předprodukčním prostředí nepovšimnuty. Nakonec budete schopni řídit vylepšení na základě skutečných incidentů.

Udržujte si to jednoduché

Vyhněte se nadměrnému inženýrství návrhu architektury, kódu aplikace a operací.

Často se jedná o to, co odeberete místo toho, co přidáte, což vede k nejspolehlivějším řešením. Jednoduchost snižuje plochu pro řízení, minimalizuje neekicienci a potenciální chybné konfigurace nebo neočekávané interakce. Na druhou stranu může zjednodušování způsobit oslabení systémů prostřednictvím jediného bodu selhání. Udržujte vyvážený přístup.

Přístup	Prospěch
Přidejte do architektury komponenty jenom v případě, že vám pomůžou dosáhnout cílových obchodních hodnot. Udržujte kritickou cestu efektivní.	Návrh obchodních požadavků může vést k jednoduchému řešení, které se snadno implementuje a spravuje. Vyhněte se příliš velkému počtu kritických komponent, protože každý z nich je významným bodem selhání.
Vytvořte standardy v implementaci kódu, nasazení a procesech a zdokumentujte je. Identifikujte příležitosti k vynucování těchto standardů pomocí automatizovaných ověření.	Standardy poskytují konzistenci a minimalizují lidské chyby. Přístupy, jako jsou standardní zásady vytváření názvů a příručky ke stylu kódu, vám můžou pomoct udržet kvalitu a usnadnit identifikaci prostředků při ř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í.	Kód aplikace, který je příliš podrobný, může vést k zbytečné vzájemné závislosti, dalším operacím a obtížné údržbě.
Vyvíjejte pouze dostatek kódu.	Budete moct zabránit problémům, které jsou výsledkem neefektivních implementací, jako je neočekávaná spotřeba prostředků, chyby 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 zvládnutí problémů.
Využijte výhod funkcí poskytovaných platformou a předem připravených prostředků, které vám můžou pomoct efektivně splnit obchodní cíle.	Tento přístup minimalizuje dobu vývoje. Umožňuje také spoléhat se na vyzkoušené a otestované postupy používané s podobnými úlohami.

Další kroky

Kontrolní seznam pro spolehlivost