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

Toto doporučení z kontrolního seznamu pro spolehlivost Azure Well-Architected Framework platí:

RE:04	Definujte cíle spolehlivosti a obnovení pro vaši úlohu. Pomocí cílů ovlivněte svůj návrh a použijte je jako základ svého zdravotního modelu.

Tato příručka popisuje doporučení pro definování metrik cílů dostupnosti a obnovení pro kritické úlohy a toky. Cíle spolehlivosti byste měli odvozovat z workshopových cvičení s obchodními partnery. Tyto cíle pak zpřesněte monitorováním a testováním úloh.

Nastavte u interních zúčastněných stran realistická očekávání týkající se spolehlivosti úloh. Pak můžou používat smluvní smlouvy ke sdělení těchto očekávání zákazníkům. Realistická očekávání také pomáhají zúčastněným stranám pochopit a podporovat rozhodnutí o návrhu architektury a víte, že navrhujete, abyste optimálně splnili cíle, na kterých souhlasíte.

Zvažte použití následujících metrik k 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, který jste nastavili pro konkrétní interakce zákazníků. Je to cíl, který jste nastavili pro úlohu nebo aplikaci na základě kvality služby, kterou vaši zákazníci očekávají.
Ukazatel úrovně služby (SLI)	Kvantitativní měření určitého aspektu výkonu služby. SLI můžete použít k měření splnění SLO vaší úlohy.
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.
Průměrný čas obnovy (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ří.
Cílový čas 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.

Klíčové strategie návrhu

Cíle spolehlivosti představují požadovaný cíl kvality úlohy, jak slíbili svým uživatelům a obchodním zúčastněným stranám. Tento cíl zahrnuje dostupnost i obnovitelnost úlohy. Mějte na paměti, že cíle spolehlivosti se liší od výkonnostních cílů, ale do cílů spolehlivosti byste měli zahrnout výkonnostní cíle. Zvažte následující cíle spolehlivosti:

• Cíle dostupnosti definují standardy kvality systému, aby zůstaly přístupné a funkční. Pokud tyto standardy nesplňuje, považuje se systém za nespolehlivý. SLO vám pomůže zkontrolovat, jestli váš systém splňuje tyto standardy. Obchodní a technické zúčastněné strany spolupracují na nastavení realistických cílů úrovně služby a zvažují faktory, jako je srovnávací analýza, uživatelská zkušenost a profil úloh.

• Cíle správnosti zajišťují, aby úloha správně prováděla své funkce s konzistentní kvalitou. Chcete-li změřit správnost, kvantifikujte indikátory úlohy, abyste je mohli zkombinovat do sjednoceného objektivního skóre.

• Cíle obnovení odpovídají metrikám RTO, RPO, MTTR a MTBF, které kvantifikují efektivitu vašich plánů a testování provozní kontinuity a zotavení po havárii.

Aby bylo možné nastavit cíle spolehlivosti, definují obchodní zúčastněné strany obecné požadavky. Pak technickí odborníci posoudí aktuální stav úlohy a pracují na dosažení a údržbě cílů prostřednictvím monitorování a výstrah. Obě strany musí souhlasit s realistickými cíli.

Identifikujte a vyhodnotujte toky uživatelů a systémů na základě jejich důležitosti pro vaše obchodní požadavky. Pomocí těchto skóre můžete řídit návrh, kontrolu, testování a správu incidentů vaší úlohy. Nastavte cíle spolehlivosti pro tyto toky a pochopte, že nedosažení těchto cílů může výrazně ovlivnit vaši firmu.

Kompromis: Můžete mít mezeru mezi technickými limity vašeho systému a jejím obchodním dopadem, například propustností a transakcemi za sekundu. Přemostění této mezery může být těžké. Zaměřte se na praktické a nákladově efektivní řešení místo nadměrného vymýšleného řešení.

Nastavení cílů dostupnosti

Celkové SLO úlohy odráží holistickou kvalitu, včetně všech jejích závislostí. Vyspělá deklarace SLO by měla označovat celkový obchodní cíl pro danou úlohu, nikoli být pouze souhrnem těchto závislostí. Pokud například zákazníci očekávají 99,99% dostupnost, měl by se celkový SLO zaměřit na tento cíl, i když jedna část dosáhne pouze 99,80 %.

Zúčastněné strany vyhodnocují prostředí zákazníků a zvažují, jak výpadek ovlivňuje výnosy. Tyto ztráty porovnávají s náklady na návrh a provoz obchodního toku. Pracovníci s rozhodovací pravomocí se pak rozhodnou, jestli by měli utratit více peněz za spolehlivost, aby se vyhnuli ztrátě výnosů a zachovali si pověst.

Vlastníci úloh používají finanční cíle k určení cílů. Obchodní požadavky se mapují na měřitelné metriky. Cílem je identifikovat sadu faktorů, které ovlivňují kvalitu zkušeností zákazníků.

Architekti úloh činí mnoho technických rozhodnutí na základě cílů úrovně služby. Cíle úrovně služby mohou:

• Když uvažujete o dalších závislostech, slouží jako kritický vstup do rozhodnutí o architektuře.

• Poskytněte téměř v reálném čase pohled a společné porozumění stavu pracovní zátěže, abyste umožnili objektivní diskuse. Pomáhají také týmu úloh určit prioritu úsilí o zlepšení spolehlivosti a vývoje nových funkcí.

• Funguje jako primární signál pro operace nasazení, který řídí automatizované vrácení zpět, pokud dojde k problémům, a poskytuje ověření, že změny dosáhnou očekávaných vylepšení uživatelského prostředí.

• Urychlete nápravu a obnovení tím, že se zaměříte na cíle, zaměřte se na automatizované oznámení o problémech zákazníkům a vytvořte důvěru mezi týmy ve vaší organizaci.

Důležité

Musíte znát rozdíl mezi SLA a SLO. I když smlouvy SLA a SLO můžou používat nebo dokonce prezentovat podobná data, jejich záměr se liší. Smlouva SLA je formální smlouva mezi organizací a jejími zákazníky a má přímé finanční a právní důsledky, pokud organizace nedoručí svůj slib. Organizace používají SLO k vyhodnocení, jestli potenciální výpadek spadá do přípustného limitu.

SLO a SLA mají obchodní vztah a měly by být řízeny nezávisle. Pokud smlouva SLA slouží jako obchodní taktika, může ji organizace záměrně nastavit na vysokou hodnotu na základě cílů vlastníka firmy. Naopak SLOs mohou být vyšší. Jako příklad zvažte klíčové úlohy. Tato třída úloh si nemůže dovolit dlouhé výpadky, protože účinky, včetně finanční ztráty a dokonce hrozby pro bezpečnost lidí, jsou významné. SLO proto obvykle mají za cíl 99,999% dobu provozu, která se běžně označuje jako pět devítek. Pokud SLOs nesplňují stanovené cíle, musí organizace rychle reagovat, aby zmírnily selhání a zabránily důsledkům neplnění SLA.

Příklad v tomto článku stanoví vysokou úroveň SLA pro podporu obchodních cílů.

Poskytovatelé cloudových platforem a technologií publikují smlouvy SLA ve svých nabídkách. Smlouvy SLA byste měli vzít v úvahu jako součást výpočtu SLO, ale neměli byste je používat tak, jak je tomu, aniž byste porozuměli rozsahu pokrytí smlouvy SLA. Další informace najdete v tématu Posouzení dopadu smluv SLA společnosti Microsoft.

Zvažte běžné cíle úrovně služby a ovlivňující faktory

Každá SLO cílí na konkrétní kritérium kvality. Zvažte tyto běžné SLOs pro spolehlivost. Tento seznam není vyčerpávající. Přidejte SLO (cíle úrovně služeb) na základě vašich obchodních požadavků.

• Míra úspěšnosti měří úspěšnost požadavků a procesů vzhledem k těm, které vrací chybu nebo selhání úkolu.

• Latence měří čas mezi zahájením požadavku na operaci a dostupností výsledku nebo dokončení procesu.

• Kapacita měří souběžné využití, například počet odpovědí založených na omezování.

• Dostupnost měří dostupnost z pohledu zákazníků.

• Propustnost měří minimální rychlost přenosu dat během určité doby. Propustnost se měří jako jednotka přenosové rychlosti dat, například transakce za sekundu (TPS) nebo požadavky za sekundu (RPS).

Seznamte se se scénáři a tolerancemi pro vaše úlohy v Azure. Služby Azure a komponenty aplikací ovlivňují SLO úloh. Zkombinujte odpovědi z následující tabulky, abyste odvodili celkové SLO (cíl úrovně služby). Jako příklady k vyhodnocení užitečnosti komponenty zátěže použijte tyto otázky.

Vlastnosti komponent	Interakce zákazníků	Další faktory
- Zpřístupňuje rozhraní API pro požadavky nebo odpovědi? - Má rozhraní API pro dotazy? - Jedná se o výpočetní komponentu? - Jedná se o součást zpracování úlohy?	- Přístup k řídicí a spravovací rovině pro veřejné služby Azure. - Přístup k rovině dat, například operace vytvoření, čtení, aktualizace a odstranění (CRUD).	- Zahrnuje váš proces uvolňování výpadky? - Jaká je pravděpodobnost zavedení chyb? Pokud se úloha integruje s jinými systémy, možná budete muset zvážit chyby integrace. - Jak rutinní operace , jako jsou opravy, ovlivňují cíl dostupnosti? Zohlednili jste závislosti partnerů? - Je vaše personální dostatečné pro podporu nepřetržitých nouzových a záložních služeb v pohotovostním střídání? - Má aplikace hlučné sousedy mimo váš rozsah kontroly, které mohou potenciálně způsobit přerušení?

Určení oboru SLO

SLO můžete nastavit na různých úrovních, například pro každou aplikaci, úlohu nebo konkrétní tok ve vašem systému. Nastavte úrovňové cíle služeb, abyste mohli přizpůsobit cíle na základě důležitosti jednotlivých komponent.

V řešeních SaaS (software jako služba) měřte SLOs na zákazníka, abyste optimalizovali zákaznickou zkušenost. Zákazníci můžou mít ve svých segmentech různé infrastrukturní prostředky. V takových případech nemusí mít systémové SLO, které agreguje všechny prostředky napříč všemi segmenty zákazníků, smysl. Místo toho měřte standardy úrovně služeb, které odpovídají konkrétnímu kontextu každého zákazníka. Další informace najdete v tématu Modely tenantů pro víceklientské řešení.

Definování složených cílů SLO

Cíle úrovně služby musí být měřitelné a měřené v rámci okna pozorovatelnosti.

SLO jsou často vyjádřeny procenty, jako je 99,90 %, ale mohou být také stanoveními. Pomocí obou metod získáte číselnou hodnotu, která zahrnuje všechny faktory.

SLO se skládá z měřitelných SLI, které definují přijatelné faktory. SLI jsou metriky s nastavenou prahovou hodnotou, na kterou lze upozorňovat. Můžete je shromažďovat z platformy nebo aplikace. Různé komponenty generují relevantní rozhraní SLA. Když zvolíte indikátory úrovně služeb (SLI), zvažte faktory, které ovlivňují cíle úrovně služeb (SLO).

Pokud chcete například vypočítat SLO pro tok, který používá API pro požadavky a odpovědi, změřte latenci serveru a dobu zpracování požadavků. Propustnost a míra chyb se nevztahují na průběžná výpočetní prostředí, jako jsou virtuální počítače, škálovací sady nebo Azure Batch.

U přístupu k řídicí rovině zvažte míru chyb a latenci pro odpovědi z API a dlouhodobé operace, jako je vytváření prostředků. Přístup k datové rovině závisí na používaných rozhraních API, z nichž každé má vlastní cíle SLO.

Dobré SLI ukazuje, kdy můžete porušit svůj SLO. Obvykle se měří v percentilech. Tady jsou některé běžně používané percentily a odhadovaný čas nedodržení očekávané dostupnosti.

Účel	Nedodržování za týden	Nedodržení za měsíc	Nedodržování předpisů za rok
99 %	1,68 hodiny	7,20 hodin	3,65 dne
99.90%	10,10 minut	43,20 minut	8,76 hodiny
99,95 %	5 minut	21,60 minut	4,38 hodiny
99,99 %	1,01 minuty	4,32 minuty	52,56 minuty
99,999 %	6 sekund	25,90 sekund	5,26 minuty

Důležité

Složená hodnota SLO je kombinací přispívajících faktorů.

Příklad složeného SLO je 99,95 % × 99,99999 % = ~99,95 %.

Při vytváření složených cílů úrovně služby pro různé toky zvažte jejich různou důležitost a relevanci. Toky můžou mít komponenty, které považujete za nekritické a vynechané z výpočtů. Jejich vynechání můžete odůvodnit na základě toho, jestli jejich krátká nedostupnost ovlivňuje zkušenosti zákazníka. V některých případech nemusí být komponenta relevantní pro případ použití, který zvažujete pro SLO. Tyto komponenty můžete vynechat také z výpočtu.

Stejný princip se vztahuje na operace. Některé operace mohou představovat rizika nebo ovlivnit SLO, zatímco jiné jsou nevýznamné. Rozhodnutí by mělo být explicitní a postavené na konsensu.

Ilustrativní příklad, jak definovat a měřit SLOs a SLIs, najdete v části Příklad.

Posouzení dopadu smluv SLA microsoftu

Smlouva SLA společnosti Microsoft poskytuje přehled o dostupnosti oblastí, ke kterým se Microsoft zavazuje. Smlouvy SLA nezaručují nabídku jako celek. Při vyhodnocování SLA je důležité mít dobré porozumění rozsahu pokrytí, který je poskytován kolem publikovaného percentilu.

Zvažte službu Web Apps, která je funkcí služby Aplikace Azure Service. Funkce je považována za dostupnou, když v daném případě použití vrátí stav 200 OK. V rámci tohoto konkrétního kontextu a časového rámce se nevztahuje na finanční záruku dostupnosti funkcí, jako je snadné ověřování nebo přepínání slotů. Měli byste zvážit oblasti, které nejsou výslovně uvedené ve smlouvě, jako dostupné v rámci maximálního úsilí platformy.

Takže pokud vaše pracovní zátěž spoléhá na sloty nasazení, nemůžete odvodit SLO, tedy cíl úrovně služby, výhradně ze SLA služby App Service. Jako tým zodpovědný za pracovní zátěž musíte zajistit a předpovědět dostupnost provozní doby. Tato předpověď však může být nejistá, což je důvod, proč úzce svázání SLO se smlouvou SLA platformy může být problematické.

Podívejte se na jiný příklad. Pokud má Služba Azure Front Door 99,99% dostupnost, musí váš návrh dodržovat konkrétní kritéria publikovaná ve smlouvě. Váš back-end musí například obsahovat úložiště, potřebujete operaci GET, která může načíst soubor o velikosti nejméně 50 KB, a musíte nasadit agenty alespoň na pěti geograficky různorodých místech. Tento úzký případ použití služby Azure Front Door nezaručuje funkce, jako je ukládání do mezipaměti, pravidla směrování nebo firewall webových aplikací. Tyto aspekty spadají mimo rozsah smlouvy SLA.

Implementace cílů ve více oblastech

Z hlediska spolehlivosti je nasazení ve více oblastech implementací principu redundance. Cílem je zmírnit riziko regionálního výpadku nebo snížení výkonu. Tato strategie, pokud je správně navržená, může zlepšit cíle úrovně služeb, protože přidává sekundární oblast pro účely převzetí služeb při selhání.

Existují dva hlavní případy použití:

• Model vysoké dostupnosti, ve kterém distribuujete zatížení napříč oblastmi, abyste měli větší kapacitu. Vysoká dostupnost neomezuje uživatele úloh na oblast a výkon celého systému přispívá k SLO.

• Přepážkový vzor, ve kterém omezíte zákazníky na konkrétní oblasti, aby je rozdělili do segmentů. V takových případech zacházejte s nasazeními ve více oblastech jako se samostatnými nasazeními nebo razítky v každé oblasti. Změřte zdravotní stav jednotlivých kolků zvlášť pomocí SLI indikátorů, které jsou vhodné pro vaše pracovní zatížení. Zvažte SLO (cílový úroveň služby) vašeho celkového pracovního zatížení na základě stavu každého razítka. Pokud můžete převzít při selhání mezi razítky, je celkové SLO úloh vyšší, protože selhání v jednom razítku je možné obnovit prostřednictvím převzetí při selhání do jiného razítka.

Kompromis: Určete, zda snížení rizika stojí za přidanou složitost. Cíle ve více oblastech také přinášejí provozní složitosti, jako je koordinace nasazení, zajištění konzistence dat a zpracování latence. Tyto operace jsou během obnovení významné. Váš tým by měl tyto složitosti zvážit s vyšší odolností.

Věnujte pozornost tomu, kolik redundance potřebujete k dosažení vysoké úrovně SLO. Microsoft například zaručuje vyšší smlouvy SLA pro nasazení azure Cosmos DB ve více oblastech, než zaručuje pro nasazení v jedné oblasti.

Definování metrik obnovení

Definice realistických cílů obnovení, jako jsou rto, RPO, MTTR a metriky MTBF, spoléhají na analýzu režimu selhání a plány a testování provozní kontinuity a zotavení po havárii. Když tyto cíle definujete, zaužte záruky obnovení poskytované platformou. Microsoft publikuje záruky RTO a RPO pouze pro některé produkty, jako je Azure SQL Database.

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 ani celé úlohy, které nejsou důkladně testovány ohledně metrik obnovení, by neměly mít zaručené 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 může být při přidávání zákazníků složitější nebo při zavádění nových technologií, 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. Modely PaaS (Platforma jako služba) nebo SaaS můžou selhat a obnovit bez 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.

Když definujete cíle obnovení, definujte prahové hodnoty pro zahájení obnovení. Pokud například webový uzel není k dispozici déle než pět minut, automaticky přidejte do fondu 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 zainteresovanými stranami potenciální rizika, jako je ztráta dat nebo přerušení zákaznické relace, obnovovacích operací.

Monitorování a vizualizace cílů

Data, která shromáždíte pro cíle spolehlivosti, použijte k sestavení modelu stavu pro každou úlohu a související kritické toky. Zdravotní model definuje zdravé, degradovaný a nezdravé stavy pro toky a úlohy. Když se stav změní, měl by model upozornit příslušné strany. Podrobné aspekty návrhu a doporučení najdete v pokynech k modelování stavu.

Pokud chcete udržovat provozní týmy a zúčastněné strany úloh informované, vytvořte vizualizaci, která odráží stav v reálném čase a celkové trendy modelu stavu úloh. Proberte řešení vizualizací se zúčastněnými stranami, abyste zajistili, že doručíte informace, které budou hodnotit 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 produkty v rámci služby mají různé smlouvy SLA. Další informace najdete v tématu Smlouvy SLA pro online služby.

Smlouva AZURE SLA obsahuje postupy pro získání kreditu služby, pokud vaše úloha nesplňuje smlouvu SLA, spolu s definicemi dostupnosti pro každou službu. Tento aspekt smlouvy SLA funguje jako penále za nedodržení.

Prozkoumejte řídicí panely Azure Monitoru pro váš vizualizační systém.

Příklad

Contoso, Ltd. navrhuje nové mobilní prostředí pro systém lístků událostí. Tady je architektura vysoké úrovně.

Diagram architektury s různými komponentami Azure Mobilní zařízení pro kontrolu lístků se připojuje ke službě Azure Front Door, která má zásady tls (Transport Layer Security), firewall webových aplikací (WAF) a pravidla. Azure Front Door se připojuje ke službě Container Apps prostřednictvím připojení Azure Private Link. Virtuální počítače sestavovacího agenta se připojují k Azure DevOps, Container Apps a privátním koncovým bodům. Spravovaná instance SQL je v poli s popiskem *Externí tým*. Pole platformy pozorovatelnosti úloh obsahuje pracovní prostor v protokolech služby Azure Monitor, Application Insights, Službě Azure Managed Grafana, upozorněních a nastavení diagnostiky. Tato architektura také zobrazuje ikony pro Azure DNS, Microsoft Entra ID, Azure Key Vault a spravované identity.

Logo Grafana je ochranná známka příslušné společnosti. Použití této značky neznamená žádné doporučení.

Komponenty

Tady jsou některé komponenty, které ilustrují koncept definice SLO. V této architektuře jsou komponenty, které nejsou zahrnuty v následujícím seznamu. I když je key Vault například součástí toku kritických požadavků, není součástí případu použití odpovědi. Pokud služba Key Vault není k dispozici, bude aplikace dál fungovat pomocí tajných kódů načtených během spouštění. Pokud ale aplikace potřebuje škálovat, stane se dostupnost služby Key Vault kritickou, protože nové uzly je potřeba načíst s tajnými kódy. V tomto příkladu se operace škálování nepovažují. Pro stručnost jsou vynechány další komponenty.

• Azure Front Door je jediný vstupní bod, který zveřejňuje rozhraní API, které zákazníci používají k odesílání požadavků.

• Azure Container Apps je prostředí, které vlastní tým úloh a používá ke spouštění obchodní logiky pro aplikaci.

• SQL Managed Instance je vlastněna a spravována jiným týmem a je důležitou závislostí pracovní zátěže.

• Azure Private Link poskytuje privátní připojení mezi nasazeními Azure Front Door a Container Apps. Spravovaná instance SQL je také vystavená aplikaci prostřednictvím privátního koncového bodu.

V této architektuře tým API definuje počáteční cíl SLO pro kritické toky v aplikaci. Přijmou strategii popsanou v Faktorech, které ovlivňují SLOs. Cílem je definovat cíle, které pokrývají základní funkce bez příliš zdůraznění doplňkových funkcí. Měří stav tří kritických toků uživatelů, které zahrnují všechny základní cloudové funkce a provádějí kód napříč nasazeními. Tyto toky ale nepokrývají veškerý kód ani přístup k datům. Tady jsou vlivové faktory.

Vypočítejte složené SLO

• Úroveň dostupnosti Azure (SLO): SLA finančního závazku pro Azure slouží jako proxy k vyhodnocení spolehlivosti platformy.

  Komponenta Azure	Použitelné pokrytí SLA	Není pokryto SLA	Upravené SLO
  Azure Front Door	99,99 % pro úspěšné operace HTTP GET	Ukládání do mezipaměti, modul pravidel	99.98%
  Kontejnerové aplikace	99,95 % na základě nasazených aplikací, které jsou dostupné vestavěným vstupem	Automatické škálování, možnosti úložiště tokenů	99,95 %
  Spravovaná instance SQL	99,99 % na základě připojení k instanci SQL Serveru	Výkon, uchovávání dat	99.80%
  Soukromý odkaz	99,99 % na základě celých minut, když síť privátního koncového bodu nepřijme provoz nebo když provoz neprotékal mezi koncovým bodem a službou Private Link	Jednotlivá selhání trvající méně než jednu minutu	99,99 %

  Úprava je založena na několika faktorech, které závisí na slibu pracovního týmu ohledně jejich cílů. Jedním faktorem může být spolehlivost schopností platformy na základě předchozích zkušeností. Například u Container Apps a Private Link se tým cítí pohodlně převzít hodnotu SLA tak, jak je.

  Existují také drobné faktory. Například tým sníží hodnotu SLO pro službu SQL Managed Instance na 99,80 %, aby zohlednil potenciální selhání v operacích s daty, jako jsou změny schématu a zálohování.

  Tým nastaví složené SLO výpočtem dopadu jednotlivých upravených hodnot SLO. Tato hodnota je 99,72 %.

  Existují i další faktory, které přispívají. Architektura spoléhá na síťové komponenty Azure, jako jsou virtuální sítě a skupiny zabezpečení sítě (NSG), které nemají publikovanou smlouvu SLA. Tým odpovědný za zátěž se rozhodne zohlednit tyto faktory s dostupností 99,99 % pro každou součást.

  Složené SLO založené na predikované dostupnosti platformy: 99,68 % za měsíc.

• SLO kódu aplikace: Tým uznává, že chyby v kódu aplikace nebo uložené procedury můžou ovlivnit dostupnost systému a přidělují jednu hodinu měsíčního výpadku, aby se zohlednily chyby související s kódem.

  K odhadu cíle úrovně služby pro jednotlivé faktory, jako jsou vady kódu, problémy se škálováním a další aspekty související s kódem, používají běžné percentily výpadků .

  Složené SLO založené na kódu a dostupnosti dat: 99,86 % měsíčně.

• SLO konfigurace prostředků a aplikací: Tým si uvědomuje, že cloudové prostředky a kód aplikace musí být správně nakonfigurovány. Tento cíl zahrnuje nastavení pravidel automatického škálování, nasazení pravidel NSG a výběr správné velikosti skladových položek. Aby se zohlednily chyby konfigurace, rozpočtují 10 minut měsíčního výpadku, což je přibližně 99,98% dostupnost.

  Složené SLO založené na dostupnosti konfigurace: 99,95 % měsíčně.

• Cílová úroveň provozu: Tým úloh vyvíjí dobrou kulturu DevOps podle dobře navržených principů architektury pro efektivitu provozu. Nasadí v každém sprintu cloudové prostředky, konfiguraci a kód.

  Tým považuje nasazení za riziko, protože může ohrozit běžící systém. V důsledku aktualizací certifikátu TLS, změn DNS nebo nástrojů může dojít k chybám. Tým také bere v úvahu potenciální výpadky způsobené nouzovými opravami. Rozpočtují celkem 20 minut měsíčních výpadků, což je přibližně 99,95% dostupnost.

  Časové období údržby jsou určená časová období, během kterých dochází k údržbě nebo aktualizacím systému. Rozhraní API se v průměru nepoužívá asi čtyři hodiny každý den. Aby se snížilo riziko nedostupnosti, může tým naplánovat úlohy údržby během těch méně aktivních hodin. Tento přístup vede k vyšší úrovni služeb (SLO), ale tým se rozhodne nezahrnout čas pro údržbu jako součást jejich SLO.

  Složené SLO založené na dostupnosti operací: 99,95 % za měsíc.

• SLO externích závislostí: Tým považuje SQL Managed Instance za primární závislost, která má už 99,80% dostupnost započítánu do celkové dostupnosti platformy. Nepovažovají se za žádné další externí závislosti.

  Složené SLO založené na externích závislostech: Nelze použít.

Stanovení celkového složeného výsledku SLO

Celkový složený cíl SLO je nastaven na 99,45 %, což odpovídá přibližně čtyř hodinám výpadků za měsíc.

Aby pracovní tým splnil cíl úrovně služby (SLO) spočívající v maximálně čtyřech hodinách nedostupnosti za měsíc, vytvoří pohotovostní rotaci. Zákaznická podpora i syntetické monitorování transakcí můžou vyvolat podporu SRE (On-Call Site Reliability Engineering), která okamžitě zahájí kroky obnovení pro řešení problémů s SLO.

Nastavit SLA pro zátěž

SLA pro pracovní zátěž je 99,90% dostupnost měsíčně.

Právní a finanční oddělení týmu úloh nastavily smlouvu SLA pro úlohu s 99,90% dostupností za měsíc, což překračuje cíl SLO 99,45 %. Toto rozhodnutí učiní po analýze finančních výplat a předpokládaného růstu zákazníků na základě atraktivní SLA. Smlouva SLA zahrnuje dva základní toky uživatelů a zahrnuje aspekty výkonu, nejen dostupnost. Jedná se o počítané riziko, které obchodní tým bere jako přínos pro firmu, a technický tým o závazku ví.

Nastavení SLO správnosti

Hlavní toky uživatelů v aplikaci musí být dostupné a dobře použitelné, nebo dokonce rychle reagující ve srovnání s konkurencí. Tým nastaví SLO odezvy speciálně pro rozhraní API, s výjimkou doby zpracování klienta a procházení internetových sítí. Tento cíl úrovně služby vyhodnocují pouze během období dostupnosti. Vyberou 75. percentil jako cíl cíle úrovně služby i měření výkonu, který zachycuje typické uživatelské prostředí a vylučuje scénáře nejhoršího případu.

Související odkazy

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