Doporučení pro definování cílů spolehlivosti

Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury Azure Well-Architected Framework:

RE:04	Definujte cíle spolehlivosti a obnovení pro komponenty, toky a celkové řešení. Vizualizujte cíle pro vyjednávání, získání konsensu, nastavení očekávání a řízení akcí k dosažení ideálního stavu. K sestavení modelu stavu použijte definované cíle. Model stavu definuje, jak vypadají stavy, které jsou v pořádku, degradované a špatné.

Tato příručka popisuje doporučení pro definování metrik cílů dostupnosti a obnovení pro kritické úlohy a toky. Cíle spolehlivosti jsou odvozeny prostřednictvím cvičení workshopů s obchodními účastníky. Cíle se upřesní prostřednictvím monitorování a testování.

U interních zúčastněných stran nastavte realistická očekávání týkající se spolehlivosti úloh, aby zúčastněné strany mohly tyto očekávání sdělit zákazníkům prostřednictvím smluvních smluv. Realistická očekávání také pomáhají zúčastněným stranám porozumět rozhodnutím o návrhu architektury a vědět, že navrhujete optimální plnění cílů, na kterých jste se dohodli.

Zvažte použití následujících metrik ke kvantifikování obchodních požadavků.

Pojem	definice
Cíl na úrovni služby (SLO)	Míra výkonu a spolehlivosti úlohy nebo aplikace SLO je konkrétní měřitelný cíl nastavený pro konkrétní interakce zákazníků. Je to cíl, který jste nastavili pro úlohu v aplikaci na základě kvality služby, kterou by uživatelé měli očekávat.
Ukazatel úrovně služby (SLI)	Metrika vygenerována službou. Metriky SLI se agregují za účelem kvantifikace hodnoty SLO.
Smlouva o úrovni služeb (SLA)	Smluvní smlouva mezi poskytovatelem služeb a zákazníkem služby. Pokud smlouvu nesplníte, může to mít finanční důsledky pro poskytovatele služeb.
Střední doba obnovení (MTTR)	Doba potřebná k obnovení komponenty po zjištění selhání.
Střední doba mezi selháním (MTBF)	Doba trvání, po kterou může úloha provádět očekávanou funkci bez přerušení, dokud se nezdaří.
Plánovaná doba obnovení (RTO)	Maximální přijatelná doba, po které může být aplikace po incidentu nedostupná.
Cíl bodu obnovení (RPO)	Maximální přijatelná doba trvání ztráty dat během incidentu.

Definujte cílové hodnoty úlohy pro tyto metriky v kontextu toků uživatelů a systémových toků. Identifikujte a vyhodnotujte tyto toky podle toho, jak kritické jsou pro vaše požadavky. Hodnoty použijte k řízení návrhu vaší úlohy z hlediska architektury, kontroly, testování a operací správy incidentů. Pokud nesplníte cíle, ovlivní to firmu nad rámec úrovně tolerance.

Klíčové strategie návrhu

Technické diskuze by neměly řídit, jak definujete cíle spolehlivosti pro důležité toky. Místo toho by se obchodní účastníci měli zaměřit na zákazníky, protože definují požadavky na úlohy. Technici pomáhají zúčastněným stranám přiřazovat realistické číselné hodnoty, které odpovídají těmto požadavkům. Při sdílení znalostí umožňují technickí odborníci vyjednávání a vzájemné konsensus o realistických cílech úrovně služby.

Představte si příklad mapování požadavků na měřitelné číselné hodnoty. Zúčastněné strany odhadují, že u kritického toku uživatele je hodina výpadku v pravidelných pracovních hodinách výsledkem ztráty X dolarů v měsíčních výnosech. Tato částka v dolarech se porovnává s odhadovanou cenou návrhu toku, který má cíl úrovně dostupnosti 99,95 % místo 99,9 %. Pracovníci s rozhodovací pravomocí musí prodiskutovat, zda riziko této ztráty výnosů převáží nad přidanou zátěží a administrativní zátěží potřebnou k ochraně před ní. Při prozkoumání toků a sestavení kompletního seznamu cílů postupujte podle tohoto vzoru.

Mějte na paměti, že cíle spolehlivosti se liší od výkonnostních cílů. Cílem spolehlivosti je zaměřit se na dostupnost a obnovení. Pokud chcete nastavit cíle spolehlivosti, začněte definováním nejširších požadavků a pak definujte konkrétnější metriky pro splnění požadavků vysoké úrovně.

Požadavky na nejvyšší úroveň spolehlivosti a obnovení a korelované metriky můžou zahrnovat například dostupnost aplikace 99,9 % pro všechny oblasti nebo cílovou rto 5 hodin pro oblast Ameriky. Definování těchto typů cílů vám pomůže určit, které kritické toky jsou v těchto cílech zapojeny. Pak můžete zvážit cíle na úrovni komponent.

Kompromis: Koncepční mezera může existovat mezi technickými omezeními komponent vaší úlohy a významem pro firmu, například propustnost v megabitech za sekundu a transakcemi za sekundu. Vytvoření modelu mezi těmito dvěma zobrazeními může být náročné. Místo přetěžování řešení se k němu snažte přistupovat ekonomickým, ale smysluplným způsobem.

Metriky dostupnosti

Smlouvy SLA a smlouvy SLA

SLO je míra výkonu a spolehlivosti úlohy nebo aplikace. SLO je konkrétní měřitelný cíl nastavený pro konkrétní interakce zákazníků. Je to cíl, který jste nastavili pro úlohu nebo aplikaci na kvalitu služby, kterou by uživatelé měli očekávat.

SLO je možné definovat z hlediska různých metrik, jako je dostupnost, doba odezvy, propustnost, míra úspěšnosti a další. Například cíl úrovně služby pro webovou službu může být takový, že bude dostupný uživatelům 99,9 % času v daném měsíci nebo že bude reagovat na 95 % požadavků do 500 milisekund.

Před definováním cílů úrovně služeb pro vaši aplikaci nebo úlohu si projděte smlouvy SLA publikované Microsoftem pro podkladové služby, na které je vaše aplikace nebo úloha hostovaná.

Poznámka:

Smlouvy SLA služby Microsoftu nejsou sla platformy ani SLO.

Při kontrole smlouvy SLA pro každou službu věnujte pozornost tomu, kolik redundance potřebujete ke splnění vysokých smluv SLA. Microsoft například zaručuje vyšší smlouvy SLA pro nasazení služby Azure Cosmos DB ve více oblastech, než zaručuje nasazení s jednou oblastí.

Poznámka:

Smlouvy SLA Azure ne vždy pokrývají všechny aspekty služby. Například Aplikace Azure lication Gateway má smlouvu SLA o dostupnosti, ale funkce firewallu webových aplikací Azure neposkytuje žádnou záruku, že zabrání průchodu škodlivého provozu. Při vývoji smluv SLA a smluv SLA zvažte toto omezení.

Jakmile shromáždíte smlouvy SLA pro jednotlivé komponenty úloh, vypočítejte kombinovanou smlouvu SLA. Kombinovaná smlouva SLA by se měla shodovat s cílovým SLO úlohy. Výpočet složené smlouvy SLA zahrnuje několik faktorů v závislosti na návrhu architektury. Podívejte se na následující příklady.

Poznámka:

Hodnoty SLA v následujících příkladech jsou hypotetické a slouží pouze pro demonstrační účely. Nejsou určené k vyjádření aktuálních hodnot podporovaných Microsoftem.

Složené smlouvy SLA zahrnují více služeb, které podporují aplikaci s různými úrovněmi dostupnosti. Představte si například webovou aplikaci Aplikace Azure Service, která zapisuje do azure SQL Database. Hypoteticky můžou být tyto smlouvy SLA:

• Webové aplikace App Service = 99,95 %
• SQL Database = 99,99 %

Jaký je maximální výpadek, který můžete u této aplikace očekávat? Pokud selže kterákoli služba, selže celá aplikace. Pravděpodobnost selhání každé služby je nezávislá, takže kombinovaná smlouva SLA pro tuto aplikaci je 99,95 % × 99,99 % = 99,94 %. Tato hodnota je nižší než jednotlivé smlouvy SLA. Tento závěr není překvapením, protože aplikace, která spoléhá na více služeb, má více potenciálních bodů selhání.

Kombinovanou smlouvu SLA můžete vylepšit vytvořením nezávislých záložních cest. Pokud je například služba SQL Database nedostupná, vložte transakce do fronty, která se má zpracovat později:

V tomto návrhu je aplikace stále dostupná, i když se nemůže připojit k databázi. Pokud se ale databáze a fronta ve stejnou dobu nezdaří, selže. Očekávané procento času pro současné selhání je 0,0001 × 0,001, takže tady je kombinovaná smlouva SLA pro tuto kombinovanou cestu:

Databáze nebo fronta = 1,0 − (0,0001 × 0,001) = 99,99999 %

Celková kombinovaná smlouva SLA:

Webová aplikace a (databáze nebo fronta) = 99,95 % × 99,99999 % = ~99,95 %

Tento přístup představuje kompromisy:

• Aplikační logika je složitější.
• Platíte za frontu.
• Je potřeba zvážit problémy s konzistencí dat.

Pro nasazení ve více oblastech se složená smlouva SLA vypočítá takto:

• N je kombinovaná smlouva SLA pro aplikaci nasazenou v jedné oblasti.

• R je počet oblastí, ve kterých je aplikace nasazená.

Očekávaná pravděpodobnost, že aplikace selže ve všech oblastech současně, je ((1 − N) ^ R). Pokud je například hypotetická smlouva SLA s jednou oblastí 99,95 % :

• Kombinovaná smlouva SLA pro dvě oblasti = (1 − 0,9995) ^ 2) = 99,999975 %

• Kombinovaná smlouva SLA pro čtyři oblasti = (1 − 0,9995) ^ 4) = 99,999999 %

Definování správných cílů úrovně služby vyžaduje čas a pečlivé zvážení. Obchodní účastníci by měli pochopit, jak klíčové zákazníky aplikaci používají. Měly by také pochopit odolnost proti spolehlivosti. Tato zpětná vazba by měla informovat cíle.

Hodnoty SLA

Následující tabulka definuje běžné hodnoty SLA.

SLA	Výpadek za týden	Výpadek za měsíc	Výpadek za rok
99 %	1,68 hodiny	7,2 hodiny	3,65 dne
99,9 %	10,1 minuty	43,2 minuty	8,76 hodiny
99,95 %	5 minut	21,6 minuty	4,38 hodiny
99,99 %	1,01 minuty	4,32 minuty	52,56 minuty
99,999 %	6 sekund	25,9 sekund	5,26 minuty

Když uvažujete o složených smlouvách SLA v kontextu toků, mějte na paměti, že různé toky mají různé definice závažnosti. Při vytváření složených smluv SLA zvažte tyto rozdíly. Nekritické toky můžou obsahovat komponenty, které byste měli vynechat z výpočtů, protože nemají vliv na prostředí zákazníka, pokud jsou krátce nedostupné.

Poznámka:

Úlohy orientované na zákazníky a úlohy s interním využitím mají různé SLO. Úlohy s interním využitím můžou mít obvykle mnohem méně omezující cíle dostupnosti než úlohy orientované na zákazníky.

Rozhraní SLA

Rozhraní SLA si můžete představit jako metriky na úrovni komponent, které přispívají k cíli úrovně služeb. Nejdůležitějšími úrovněmi úrovně služeb jsou ty, které ovlivňují vaše kritické toky z pohledu vašich zákazníků. U mnoha toků zahrnují rozhraní SLA latenci, propustnost, chybovost a dostupnost. Dobrý SLI vám pomůže identifikovat, kdy je cíl úrovně služby vystaven riziku porušení zabezpečení. Korelujte SLI s konkrétními zákazníky, pokud je to možné.

Abyste se vyhnuli shromažďování nepoužitých metrik, omezte počet SLI pro každý tok. Pokud je to možné, zaměřte se na tři SLI na tok.

Metriky obnovení

Cíle obnovení odpovídají metrikám RTO, RPO, MTTR a MTBF. Na rozdíl od cílů dostupnosti nejsou cíle obnovení pro tato měření výrazně závislé na smlouvách SLA Microsoftu. Microsoft publikuje záruky RTO a RPO pouze pro některé produkty, jako je SQL Database.

Definice realistických cílů obnovení závisí na analýze režimu selhání a vašich plánech a testování provozní kontinuity a zotavení po havárii. Než tuto práci dokončíte, prodiskutujte cíle s účastníky a ujistěte se, že návrh architektury podporuje cíle obnovení, které nejlépe pochopíte. Jasně komunikujte se zúčastněnými stranami, že žádné toky nebo celé úlohy, které nejsou důkladně testovány pro metriky obnovení, by neměly mít zaručené smlouvy SLA. Ujistěte se, že zúčastněné strany chápou, že cíle obnovení se můžou v průběhu času měnit při aktualizaci úloh. Úloha se může stát složitějším, protože se zákazníci přidají nebo při přechodu na nové technologie, aby se zlepšilo uživatelské prostředí. Tyto změny můžou zvýšit nebo snížit metriky obnovení.

Poznámka:

MtBF může být náročné definovat a zaručit. Platformy jako služba (PaaS) nebo software jako služba (SaaS) můžou selhat a obnovit bez jakýchkoli oznámení od poskytovatele cloudu a proces může být pro vás nebo vaše zákazníky zcela transparentní. Pokud definujete cíle pro tuto metriku, pokryjte pouze komponenty, které jsou pod vaší kontrolou.

Při definování cílů obnovení definujte prahové hodnoty pro zahájení obnovení. Pokud například webový uzel není k dispozici déle než 5 minut, přidá se do fondu automaticky nový uzel. Definujte prahové hodnoty pro všechny komponenty a zvažte, co zahrnuje obnovení konkrétní komponenty, včetně vlivu na ostatní komponenty a závislosti. Prahové hodnoty by také měly odpovídat přechodným chybám, aby se zajistilo, že akce obnovení nespustíte příliš rychle. Zdokumentujte a sdílejte se zúčastněnými stranami potenciální rizika operací obnovení, jako je ztráta dat nebo přerušení relací pro zákazníky.

Vytvoření modelu stavu

Data, která jste shromáždili pro cíle spolehlivosti, použijte k sestavení modelu stavu pro každou úlohu a související kritické toky. Model stavu definuje pro toky a úlohy stav, který je v pořádku, má snížený výkon a stav není v pořádku. Stavy zajišťují odpovídající stanovení priorit provozu. Tento model se také označuje jako model semaforu. Model přiřadí zelenou pro zdraví, žlutou pro snížení výkonu a červenou pro špatné. Model stavu zajišťuje, že víte, kdy se stav toku změní z stavu v pořádku na snížený výkon nebo není v pořádku.

Jak definujete stav, který je v pořádku, snížený výkon a stav není v pořádku, závisí na cílech spolehlivosti. Tady je několik příkladů způsobů, jak můžete definovat stavy:

• Zelený stav nebo stav v pořádku označuje, že klíčové nefunkční požadavky a cíle jsou plně splněné a že se prostředky používají optimálně. Například 95 procent požadavků se zpracovává v <=500 ms s uzlem Azure Kubernetes Service (AKS) v procentech X.

• Žlutý nebo snížený stav značí, že jedna nebo více komponent toku upozorňuje na definovanou prahovou hodnotu, ale tok je funkční. Například bylo zjištěno omezování úložiště.

• Červený stav nebo stav není v pořádku značí, že snížení výkonu trvalo déle, než je možné povolit vašimi cíli spolehlivosti nebo že tok přestal být dostupný.

Poznámka:

Model stavu by neměl zacházet se všemi selháními stejně. Model stavu by měl rozlišovat mezi přechodnými a nepřehlednými chybami. Měl by jasně rozlišovat mezi očekávanými přechodnými, ale obnovitelnými selháními a skutečným stavem havárie.

Tento model funguje pomocí strategie monitorování a upozorňování, která se vyvíjí a provozuje na principech průběžného zlepšování. S tím, jak se vaše úlohy vyvíjejí, se s nimi musí vaše modely stavu vyvíjet.

Podrobné aspekty návrhu a doporučení pro model stavu vrstvené aplikace najdete v pokynech k modelování stavu v oblastech návrhu klíčových úloh. Podrobné pokyny ke konfiguraci monitorování a upozorňování najdete v průvodci monitorováním stavu.

Vizualizace

Pokud chcete, aby provozní týmy a zúčastněné strany úloh byly informované o stavu v reálném čase a celkovém trendu modelu stavu úloh, zvažte vytvoření řídicích panelů v řešení pro monitorování. Proberte řešení vizualizací se zúčastněnými stranami, abyste měli jistotu, že doručíte informace, které hodnotí a které se dají snadno využívat. Můžou také chtít zobrazit vygenerované sestavy týdně, měsíčně nebo čtvrtletně.

Usnadnění azure

Smlouvy SLA Azure poskytují závazky Microsoftu pro dobu provozu a připojení. Různé služby mají různé smlouvy SLA a někdy skladové položky v rámci služby mají různé smlouvy SLA. Další informace najdete v tématu Smlouvy o úrovni služeb pro online služby.

Smlouva AZURE SLA obsahuje postupy pro získání kreditu služby, pokud není splněná smlouva SLA, spolu s definicemi dostupnosti pro každou službu. Tento aspekt smlouvy SLA funguje jako penále za nedodržení.

Související odkazy

• Dobře navržená architektura – klíčové pokyny pro modelování stavu: Modelování stavu a pozorovatelnost důležitých úloh v Azure

Kontrolní seznam pro spolehlivost

Projděte si kompletní sadu doporučení.

Kontrolní seznam pro spolehlivost