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 byste měli odvozovat z cvičení workshopů s obchodními účastníky. 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í dodržování předpisů vaší úlohy s 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. |
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žte faktory, jako je srovnávací analýza, uživatelské prostředí 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 pochopili, že nedosažování 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ý cíl úrovně služeb úlohy odráží holistickou kvalitu, včetně všech jejích závislostí. Vyspělá deklarace cíle úrovně služby by měla znamenat celkový obchodní cíl pro danou úlohu, nikoli pouze složenou z těchto závislostí. Pokud například zákazníci očekávají 99,99% dostupnost, měl by celkový cíl cíle na tento cíl cílit, 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 dělají mnoho technických rozhodnutí na základě cílů úrovně služby. Cíle úrovně služby můžou:
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 zobrazení a sdílené porozumění stavu úlohy, abyste umožnili objektivní diskuze. 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 smlouvami SLA a smlouvami SLA. 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.
Smlouvy SLA a smlouvy SLA sdílejí obchodní vztah a měly by být nezávisle řízeny. 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 cíle úrovně služby můžou 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é. Cíle cílů úrovně služeb proto obvykle cílí na 99,999% dobu provozu, která se běžně označuje jako pět devítek. Pokud cíle úrovně služeb nesplňují tyto cíle, musí organizace rychle reagovat na zmírnění selhání a zabránit výsledkům neúspěšné smlouvy SLA.
Příklad v tomto článku nastaví vysokou smlouvu 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á cílová úroveň úrovně služeb cílí na konkrétní kritéria kvality. Zvažte tyto běžné cíle úrovně služeb pro spolehlivost. Tento seznam není vyčerpávající. Přidejte 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. SLO úloh ovlivňuje služby Azure i komponenty aplikací. Zkombinujte odpovědi z následující tabulky, aby se odvozil celkový cíl úrovně služby. Tyto otázky použijte jako příklady k vyhodnocení nástroje součásti úlohy.
| Vlastnosti komponent | Interakce zákazníků | Další faktory |
|---|---|---|
| - Zpřístupňuje rozhraní API požadavků nebo odpovědí? - Má rozhraní API pro dotazy? - Jedná se o výpočetní komponentu? - Jedná se o součást zpracování úlohy? |
- Řízení přístupu roviny řízení a roviny správy 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 vydávání výpadek? - 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? Vybrali jste v závislostech partnerů? - Je vaše personál dostačující pro podporu neustálé nouzové a nouzové zálohy on-call obmě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 cíle úrovně úrovně služby, abyste mohli přizpůsobit cíle úrovně na základě důležitosti jednotlivých komponent.
V řešeních saaS (software jako služba) změřte cíle úrovně služeb na zákazníka, abyste optimalizovali prostředí jednotlivých zákazníků. Zákazníci můžou mít ve svých segmentech různé prostředky infrastruktury. V takových případech nemusí mít cíl úrovně služby pro celý systém, který agreguje všechny prostředky napříč segmenty zákazníků, smysl. Místo toho změřte cíle ú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 procenta jako 99,90 %, ale můžou to být i příkazy. 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. Rozhraní SLA jsou metriky s nastavenou prahovou hodnotou, kterou je možné upozorňovat. Můžete je shromažďovat z platformy nebo aplikace. Různé komponenty generují relevantní rozhraní SLA. Když zvolíte rozhraní SLA, zvažte faktory, které ovlivňují cíl úrovně služeb.
Pokud chcete například vypočítat cíl úrovně služby pro tok, který používá rozhraní API pro odpověď a požadavek, 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 rozhraní API a dlouhotrvající operace, jako je vytváření prostředků. Přístup k rovině dat závisí na používaných rozhraních API, z nichž každá má vlastní cíle cíle cíle SLO.
Dobré rozhraní SLI ukazuje, kdy můžete porušení cíle úrovně služeb porušovat. 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í předpisů za týden | Nedodržení předpisů 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 rozdělení produktů 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ýchpřípadechch Tyto komponenty můžete vynechat také z výpočtu.
Stejný princip se vztahuje na operace. Některé operace můžou představovat rizika nebo ovlivnit cíl úrovně služeb a jiné jsou zanedbatelné. Rozhodnutí by mělo být explicitní a postavené na konsensu.
Ilustrativní příklad definování a měření cílů úrovně služby a SLI 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í smluv SLA dobře pochopíte pokrytí, které je k dispozici 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 OK 200. 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 úloha spoléhá na sloty nasazení, nemůžete odvodit cíl úrovně služby výhradně ze smlouvy SLA služby App Service. Jako tým úloh musíte zajistit a předpovědět dostupnost dostupnosti provozu. 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ě. Back-end například musí obsahovat úložiště, potřebujete GET operaci, která může načíst soubor o velikosti nejméně 50 kB a vy potřebujete nasadit agenty na více místech 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 při selhání, protože pro účely převzetí služeb při selhání přidává sekundární oblast.
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.
Model přepnutí, ve kterém omezíte zákazníky na konkrétní oblasti, aby je segmentovali. V takových případech zacházíme s nasazeními ve více oblastech jako s samostatnými nasazeními nebo razítky v každé oblasti. Změřte stav jednotlivých kolků zvlášť pomocí SLI, která jsou vhodná pro vaši úlohu. Na základě stavu každého razítka vezměte v úvahu cíl úrovně služby pro celkovou úlohu. Pokud můžete převzít služby při selhání mezi kolky, je celkové SLO úloh vyšší, protože selhání v jednom razítku je možné obnovit prostřednictvím převzetí služeb při selhání do jiného razítka.
Věnujte pozornost tomu, kolik redundance potřebujete splnit vysoké úrovně úrovně služby. 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 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 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 s účastníky potenciální rizika, jako je ztráta dat nebo přerušení relace pro zákazníky, operací obnovení.
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. Model stavu definuje pro toky a úlohy stav, který je v pořádku, má snížený výkon a stav není v pořádku. 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ě.
Logo Grafana je ochranná známka příslušné společnosti. Použití této značky nevyžaduje žá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.
Spravovaná instance SQL je vlastněná a spravuje jiný tým a je důležitou závislostí úlohy.
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 rozhraní API definuje počáteční cíl cíle SLO pro kritické toky v aplikaci. Přijmou strategii popsanou v tématu Faktory, které ovlivňují cíle úrovně služby. 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.
Výpočet složeného SLO
Cíl úrovně dostupnosti Azure: Smlouva SLA finančního závazku pro Azure slouží jako proxy k vyhodnocení spolehlivosti platformy.
Komponenta Azure Použitelné pokrytí smlouvy SLA Nevztahuje se na smlouvu SLA Upravené SLO Azure Front Door 99,99 % pro úspěšné operace HTTP GETUkládání do mezipaměti, modul pravidel 99.98% Container Apps 99,95 % na základě nasazených aplikací, které jsou dostupné integrovaným příchozím přenosem dat 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% Private Link 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 týmu úloh k jejich cílům. Jedním faktorem může být spolehlivost schopností platformy na základě předchozích zkušeností. Například pro Container Apps a Private Link se tým cítí pohodlně, 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 úloh se rozhodne tyto faktory zvážit s 99,99% dostupností pro každou komponentu.
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 % za měsíc.
SLO konfigurace prostředků a aplikací: Tým rozpozná, že cloudové prostředky a kód aplikace musí být správně nakonfigurované. 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 % za měsíc.
Cílová úroveň provozu: Tým úloh vyvíjí dobrou kulturu DevOps podle dobře navržených principů architektury pro efektivitu provozu. Každý sprint nasadí 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é považuje potenciální výpadky způsobené opravami tísňového volání. 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ětšinou nepoužívá přibližně č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ššímu cíli úrovně služby, ale tým se rozhodne nezahrnovat časové období údržby jako součást svého SLO.
Složené SLO založené na dostupnosti operací: 99,95 % za měsíc.
Cíl úrovně služby SLO externích závislostí: Tým považuje službu SQL Managed Instance za primární závislost, která už má 99,80% faktor dostupnosti pro celkovou dostupnost platformy. Nepovažovají se za žádné další externí závislosti.
Složené SLO založené na externích závislostech: Nelze použít.
Určení celkového složeného výsledku SLO
Celkový cíl SLO složeného cíle je nastavený na 99,45 %, což odpovídá přibližně čtyřhodinovým výpadkům za měsíc.
Aby tým úloh splnil cíl cíle úrovně služby (SLO) pouze čtyři hodiny nedostupnosti za měsíc, vytvoří obměně hovorů. 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.
Nastavení smlouvy SLA pro úlohy
Smlouva SLA pro úlohu je 99,90% dostupnost za měsíc.
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í po analýze finančních plateb a předpokládaného růstu zákazníků na základě atraktivní smlouvy SLA provede toto rozhodnutí. 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
Základní toky uživatelů aplikace musí být dostupné a použitelné nebo dokonce konkurenceschopné, responzivní. Tým nastaví SLO odezvy speciálně pro rozhraní API, s výjimkou doby zpracování klienta a procházení internetových sítí. Toto cíle ú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í.