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

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

RE:04	Definujte cíle spolehlivosti a obnovení pro komponenty, toky a celkové řešení. Vizualizujte cíle pro vyjednávání, dosažení konsensu, nastavení očekávání a řízení akcí k dosažení ideálního stavu. Použijte definované cíle k sestavení modelu stavu. Model stavu definuje, jak vypadá stav v pořádku, snížený výkon a stav, který není v pořádku.

Tato příručka popisuje doporučení pro definování metrik dostupnosti a cíle obnovení pro kritické úlohy a toky. Cíle spolehlivosti se odvozují prostřednictvím workshopů se zúčastněnými stranami z firmy. Cíle se upřesní prostřednictvím monitorování a testování.

S interními účastníky nastavte realistická očekávání týkající se spolehlivosti úloh, aby účastníci mohli tato 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 pochopit a podporovat vaše rozhodnutí o návrhu architektury a vědět, že navrhujete tak, aby optimálně splňoval vámi schválené cíle.

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

Období	Definice
Cíl úrovně služby (SLO)	Procentuální cíl, který představuje stav komponenty a úroveň spolehlivosti. Čím vyšší úroveň, tím spolehlivější komponenta. Složený cíl úrovně služeb představuje agregovaný cíl celé úlohy a účty pro SLO komponent.
Ukazatel úrovně služeb (SLI)	Metrika vygenerována službou. Metriky SLI se agregují za účelem kvantifikace hodnoty SLO.
Smlouva o úrovni služeb (SLA)	Smluvní dohoda mezi poskytovatelem služeb a zákazníkem služby. Smlouva definuje SLO. Nedodržení smlouvy může 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, po kterou může úloha provádět očekávanou funkci bez přerušení, dokud neselže.
Plánovaná doba obnovení (RTO)	Maximální přijatelná doba, po kterou 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 úloh pro tyto metriky v kontextu toků uživatelů a systémových toků. Identifikujte a ohodnotejte tyto toky podle toho, jak jsou důležité pro vaše požadavky. Hodnoty použijte k řízení návrhu úloh z hlediska architektury, kontroly, testování a operací správy incidentů. Nesplnění cílů bude mít vliv na firmu nad rámec úrovně tolerance.

Klíčové strategie návrhu

Technické diskuze by neměly určovat, jak definujete cíle spolehlivosti pro důležité toky. Obchodní účastníci by se místo toho měli při definování požadavků úlohy zaměřit na zákazníky. Techní odborníci pomáhají zúčastněným stranám přiřazovat reálné číselné hodnoty, které s těmito požadavky korelují. Při sdílení znalostí umožňují techní odborníci vyjednávat a vzájemně se shodovat o realistických cílech SLO.

Představte si příklad mapování požadavků na měřitelné číselné hodnoty. Účastníci odhadují, že v případě kritického toku uživatelů má hodinový výpadek během běžné pracovní doby za následek ztrátu X dolarů na měsíčních výnosech. Tato částka v dolarech se porovnává s odhadovanými náklady na návrh 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 příjmů převáží přidané náklady a administrativní zátěž potřebnou k ochraně před nimi. Při zkoumání toků postupujte podle tohoto vzoru a sestavte úplný seznam cílů.

Mějte na paměti, že cíle spolehlivosti se liší od výkonnostních cílů. Cíle spolehlivosti se zaměřují 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, které splňují požadavky 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 plánovanou dobu obnovení (RTO) 5 hodin pro oblast Amerika. Definování těchto typů cílů vám pomůže identifikovat, které kritické toky jsou do těchto cílů zapojeny. Pak můžete zvážit cíle na úrovni komponent.

Kompromis: Může existovat koncepční mezera mezi technickými omezeními komponent úloh a tím, co to znamená pro firmu, například propustnost v megabitech za sekundu a transakce za sekundu. Vytvoření modelu mezi těmito dvěma zobrazeními může být náročné. Místo toho, abyste řešení přeháněli, zkuste k němu přistupovat úsporným, ale smysluplným způsobem.

Metriky dostupnosti

SLO a smlouvy SLA

Metriky dostupnosti korelují se SLO, které slouží k definování smluv SLA. SLO úloh určuje, kolik výpadků je v daném období přípustné, například méně než 1 hodina za měsíc. Abyste měli jistotu, že můžete splnit cíl SLO, projděte si smlouvy SLA Microsoftu pro každou komponentu. Věnujte pozornost tomu, kolik redundance potřebujete, abyste splnili vysoké smlouvy SLA. Microsoft například zaručuje vyšší smlouvy SLA pro nasazení služby Azure Cosmos DB do více oblastí než pro nasazení v jedné oblasti.

Poznámka

Smlouvy Azure SLA nepokrývají vždy všechny aspekty služby. Například Azure Application Gateway má smlouvu SLA o dostupnosti, ale funkce Azure Web Application Firewall neposkytuje žádnou záruku, že zabrání průchodu škodlivého provozu. Toto omezení zvažte při vývoji smluv SLA a SLO.

Po shromáždění smluv SLA pro jednotlivé komponenty úloh vypočítejte kombinovanou smlouvu SLA. Kombinovaná smlouva SLA by měla odpovídat cílovému cíli 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 reprezentaci 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 Azure App Service webovou aplikaci, která zapisuje do Azure SQL Database. Hypoteticky by tyto smlouvy SLA mohly být:

• App Service webových aplikací = 99,95 %
• SQL Database = 99,99 procent

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 například SQL Database není k dispozici, vložte transakce do fronty, které se mají zpracovat později:

V tomto návrhu je aplikace stále dostupná, i když se nemůže připojit k databázi. Pokud však dojde k selhání databáze a fronty ve stejnou dobu, selže. Očekávané procento času současného selhání je 0,0001 × 0,001, takže tady je složená 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 % = přibližně 99,95 %

Tento přístup představuje kompromisy:

• Logika aplikace 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á následujícím způsobem:

• N je složená 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 najednou, je ((1 − N) ^ R). Pokud je například hypotetická smlouva SLA pro jednu oblast 99,95 %:

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

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

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

Hodnoty SLA

Následující tabulka definuje společ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ž přemýšlíte o složených smlouvách SLA v kontextu toků, mějte na paměti, že různé toky mají různé definice důležitosti. Tyto rozdíly zvažte při vytváření složených smluv SLA. Nekritické toky můžou obsahovat komponenty, které byste měli ve výpočtech vynechat, protože nemají vliv na prostředí zákazníka, pokud jsou krátce nedostupné.

Poznámka

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

Rozhraní SLA

Představte si úrovně úrovně služeb jako metriky na úrovni komponent, které přispívají k cíli služby. Nejvýznamnější úrovně úrovně služby 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 SLO ohroženo porušením. Pokud je to možné, porovnejte SLI s konkrétními zákazníky.

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

Metriky obnovení

Cíle obnovení odpovídají metrikám RTO, RPO, MTTR a MTBF. Na rozdíl od cílů dostupnosti nezávisí cíle obnovení pro tato měření do značné míry na smlouvách SLA Od Microsoftu. Microsoft zveřejňuje 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 se zúčastněnými stranami cíle a ujistěte se, že návrh architektury podporuje cíle obnovení, jak nejlépe rozumíte. Jasně informujte zúčastněné strany, ž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 se cíle obnovení můžou v průběhu času při aktualizaci úloh měnit. Úloha může být složitější s přidáním zákazníků nebo s přijetím nových technologií, které zlepšují prostředí zákazníků. Tyto změny můžou zvýšit nebo snížit metriky obnovení.

Poznámka

Definování a záruka MTBF může být náročné. Platformy jako služba (PaaS) nebo software jako služba (SaaS) můžou selhat a obnovit se bez jakéhokoli 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é máte pod kontrolou.

Při definování cílů obnovení definujte prahové hodnoty pro zahájení obnovení. Pokud je například webový uzel nedostupný déle než 5 minut, automaticky se do fondu přidá nový uzel. Definujte prahové hodnoty pro všechny komponenty s ohledem na to, co zahrnuje obnovení konkrétní komponenty, včetně vlivu na další komponenty a závislosti. Prahové hodnoty by také měly zohlednit přechodné chyby , aby se zajistilo, že nebudete spouštět akce obnovení 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 své cíle spolehlivosti, použijte k sestavení modelu stavu pro každou úlohu a související kritické toky. Model stavu definuje stav, stav v pořádku, degradovaný stav a stav , který není v pořádku pro toky a úlohy. Státy zajišťují odpovídající stanovení priorit provozu. Tento model se také označuje jako model semaforu. Model přiřadí zelenou pro stav v pořádku, žlutou pro snížený výkon a červenou pro stav, který není v pořádku. Model stavu zajišťuje, abyste věděli, kdy se stav toku změní ze stavu v pořádku na snížený nebo v pořádku.

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

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

• Žlutý nebo snížený stav znamená, že jedna nebo více součástí toku upozorňují 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 degradace trvala déle, než dovolují vaše cíle 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řesnostmi . 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 na základě strategie monitorování a upozorňování, která je vyvinuta a funguje na principech neustálého zlepšování. S tím, jak se vaše úlohy vyvíjejí, se s nimi musí vyvíjet i vaše modely stavu.

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

Vizualizace

Pokud chcete, aby provozní týmy a účastníci úloh byli informováni o stavu v reálném čase a celkových trendech modelu stavu úloh, zvažte vytvoření řídicích panelů v řešení monitorování. Prodiskutujte řešení vizualizace se zúčastněnými stranami, abyste měli jistotu, že doručíte informace, které si můžou přát a které se snadno spotřebovávají. Může také chtít zobrazovat vygenerované sestavy týdně, měsíčně nebo čtvrtletně.

Usnadnění Azure

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

Smlouva Azure SLA zahrnuje postupy pro získání kreditu služby v případě, že smlouva SLA není splněna, spolu s definicemi dostupnosti pro jednotlivé služby. Tento aspekt smlouvy SLA funguje jako penále za nedodržení.

Související odkazy

• Well-Architected Framework – 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