Doporučení pro definování cílů spolehlivosti
Platí pro toto doporučení Power Platform Dobře architektonizovaného kontrolního seznamu spolehlivosti:
| RE: 04 | Definujte spolehlivost a cíle obnovy pro komponenty, toky a celkové řešení. Vizualizujte si cíle pro vyjednávání, dosažení konsenzu, stanovení očekávání a řízení akcí k dosažení ideálního stavu. Použijte definované cíle k vytvoření modelu stavu. Model správného stavu definuje, jak vypadá stav v pořádku, degradovaný a nesprávný. |
|---|
Tato příručka popisuje doporučení pro definování metrik dostupnosti a cílů obnovy pro kritické úlohy. Cíle spolehlivosti jsou odvozeny prostřednictvím workshopů s obchodními partnery.
Cíle se zlepšují monitorováním a testováním. Spolupracujte se svými interními zainteresovanými stranami na stanovení realistických očekávání spolehlivosti. Toto cvičení také pomůže zúčastněným stranám podpořit vaše volby návrhu architektury a pochopit, že navrhujete co nejlépe splnění cílů, na kterých jste se dohodli.
Microsoft Power Platform se stará o většinu záležitosti dostupnosti a spolehlivosti na úrovni infrastruktury za vás. Dostupnost vámi sestavených úloh je však sdílená odpovědnost. Je důležité pochopit, že i se závazkem k vysoké dostupnosti společnosti Microsoft, není riziko výpadku systému nikdy nulové.
Zvažte použití následujících metrik ke kvantifikaci obchodních požadavků.
| Pojem | definice |
|---|---|
| Cíl na úrovni 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é SLO představuje agregovaný cíl celého pracovního zatížení a zohledňuje dílčí SLO. |
| Indikátor rozsahu služeb (SLI) | Metrika vydávaná službou. Metriky SLI jsou agregovány pro kvantifikaci hodnoty SLO. |
| Smlouva o rozsahu služeb (SLA) | Smluvní ujednání mezi poskytovatelem služby 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 zotavení (MTTR) | Doba potřebná k obnovení součásti po zjištění selhání. |
| Střední doba mezi selháním (MTBF) | Doba, po kterou může úloha vykonávat očekávanou funkci bez přerušení, dokud neselže. |
| Cíl doby zotavení (RTO) | Maximální přijatelná doba, po kterou může být aplikace nedostupná po incidentu. |
| Cíl bodu obnovení (RPO) | Maximální přijatelné trvání ztráty dat během incidentu. |
Definujte cílové hodnoty zátěže pro tyto metriky v kontextu toků uživatelů a systému. Identifikujte a ohodnoťte tyto toky podle toho, jak kritické jsou pro vaše požadavky. Použijte hodnoty k řízení návrhu vaší úlohy z hlediska architektury, kontroly, testování a operací správy incidentů. Nesplnění cílů ovlivní podnikání nad rámec tolerance.
Klíčové strategie návrhu
Technické diskuse by se neměly řídit tím, jak definujete cíle spolehlivosti pro vaše kritické toky. Místo toho by se obchodní partneři měli zaměřit na své požadavky a očekávání koncových uživatelů úlohy. Techničtí odborníci pomáhají zúčastněným stranám přiřadit realistické číselné hodnoty, které splňují tyto požadavky. Výměnou informací umožňují techničtí experti diskusi a dohodu o proveditelných SLO.
Zvažte příklad, jak mapovat požadavky na měřitelné číselné hodnoty. Zúčastněné strany odhadují, že v případě kritického toku uživatelů vede hodina výpadku během běžné pracovní doby ke ztrátě X dolarů na měsíčních tržbách. Tato částka v dolarech je porovnána s odhadovanými náklady na návrh toku, který má dostupnost SLO 99,95 procenta, a ne 99,9 procenta. Osoby s rozhodovací pravomocí musí diskutovat o tom, zda riziko této ztráty příjmů převáží nad přidanými náklady a zátěží managementu, která je nutná k ochraně proti této ztrátě.
Postupujte podle tohoto vzoru při zkoumání toků a sestavování úplného seznamu cílů.
Pamatujte, že cíle spolehlivosti se liší od cílů výkonu. Cíle spolehlivosti se zaměřují na dostupnost a obnovu. Chcete-li nastavit cíle spolehlivosti, začněte definováním nejširších požadavků a poté definujte specifičtější metriky pro splnění požadavků na vysoké úrovni.
Nejvyšší požadavky na spolehlivost a obnovu a korelované metriky mohou zahrnovat například dostupnost aplikací 99,9 procenta pro všechny regiony nebo cílovou RTO 5 hodin pro region Severní a Jižní Ameriky. Definování těchto typů cílů vám pomůže určit, které kritické toky se na těchto cílech podílejí. Poté můžete zvážit cíle na úrovni komponent.
Metriky dostupnosti
Cíle dostupnosti odpovídají metrikám SLO, SLA a SLI.
SLO a SLA
Metriky dostupnosti korelují s SLO, které používáte k definování SLA. SLO úlohy určuje, jaká doba prostojů je v daném období tolerovatelná, například méně než 1 hodinu měsíčně. Abyste se ujistili, že můžete splnit cíl SLO, přečtěte si smlouvy Microsoft SLA pro každou komponentu.
Chcete-li vytvořit své SLO, přemýšlejte o:
Nefunkční požadavky vaší úlohy (například maximální počet požadavků, souběžní uživatelé) v průběhu příštích 1–2 let.
Dostupné metriky toho, co můžete měřit, za konkrétní časové období. Tato data budou informovat o tom, jaké SLI specifikovat.
Poté, co shromáždíte smlouvy SLA pro jednotlivé komponenty úlohy, vypočítejte složenou SLA. Složená SLA by měla odpovídat cílové SLO úlohy. Výpočet složené SLA zahrnuje několik faktorů v závislosti na návrhu vaší architektury.
Definování správných SLO vyžaduje čas a pečlivé zvážení. Obchodní partneři by měli rozumět toleranci spolehlivosti. Tato zpětná vazba by měla informovat cíle.
Hodnoty SLA
Následující tabulka definuje běžné hodnoty SLA.
| SLA | Prostoje za týden | Prostoje za měsíc | Prostoje za rok |
|---|---|---|---|
| 99 % | 1.68 hodin | 7.2 hodin | 3.65 dní |
| 99,9 % | 10.1 minut | 43.2 minut | 8.76 hodin |
| 99,95 % | 5 minuty | 21.6 minut | 4.38 hodin |
| 99,99 % | 1.01 minut | 4.32 minut | 52.56 minut |
| 99,999 % | 6 sekund | 25.9 sekund | 5.26 minut |
Když přemýšlíte o složených SLA v kontextu uživatelských a systémových toků, nezapomeňte, že různé uživatelské a systémové toky mají různé definice kritičnosti. Při vytváření složených SLA zohledněte tyto rozdíly. Nekritické toky mohou mít součásti, které byste měli ze svých výpočtů vynechat, protože nemají vliv na zákaznické prostředí, pokud nejsou krátce dostupné.
SLI
Představte si SLI jako metriky na úrovni komponent, které přispívají k SLO. Nejvýznamnější SLI jsou ty, které ovlivňují vaše kritické toky z pohledu vašich zákazníků. U mnoha toků zahrnují SLI latenci, propustnost, chybovost a dostupnost. Dobré SLI vám pomůže identifikovat, kdy je SLO ohroženo narušením. Pokud je to možné, korelujte SLI s konkrétními zákazníky.
Chcete-li se vyhnout shromažďování zbytečný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 obnovy
Cíle obnovy odpovídají metrikám RTO, RPO, MTTR a MTBF. Na rozdíl od cílů dostupnosti cíle obnovy pro tato měření příliš nezávisí na smlouvách Microsoft SLA. Společnost Microsoft vydává záruky RTO a RPO pouze pro některé produkty, jako je SQL Database.
Definice realistických cílů obnovy se opírají o vaši analýzu režimu selhání a vaše plány a testování pro kontinuitu provozu a zotavení po havárii. Před dokončením této práce prodiskutujte cíle se zúčastněnými stranami a ujistěte se, že váš návrh architektury podporuje cíle obnovy podle vašeho nejlepšího porozumění. Jasně sdělte zúčastněným stranám, že žádné části úlohy, které nejsou důkladně testovány na metriky obnovy, by neměly mít zaručené smlouvy SLA. Ujistěte se, že zúčastněné strany chápou, že cíle obnovy se mohou v průběhu času měnit, jak se aktualizuje úloha. Úloha se může stát složitější, jak přijmete nové technologie pro zlepšení uživatelského prostředí. Tyto změny mohou zvýšit nebo snížit vaše metriky obnovení.
Poznámka:
MTBF může být náročné definovat a garantovat. Platformy jako služba (PaaS) nebo software jako služba (SaaS) mohou selhat a obnovit se bez jakéhokoli upozornění od poskytovatele cloudu a tento proces pro vás může být zcela transparentní. Pokud pro tuto metriku definujete cíle, pokryjte pouze komponenty, které máte pod kontrolou.
Vytvoření modelu správného stavu
Použijte data, která jste shromáždili pro své cíle spolehlivosti, k vytvoření modelu správného stavu pro každou úlohu a související kritické toky. Model správného stavu definuje stav v pořádku, degradovaný a nesprávný* stav pro toky a úlohu. Stavy zajišťují odpovídající operační priority. Tento model je také označovaný jako model semaforu. Model přiřazuje zelenou pro v pořádku, žlutou pro degradované a červenou pro není v pořádku. Model správného stavu zajišťuje, že víte, kdy se stav toku změní z v pořádku na degradovaný nebo není v pořádku.
Jak definujete stavy v pořádku, degradovaný a není v pořádku, závisí na vašich cílech spolehlivosti. Zde je několik příkladů způsobů, jak můžete definovat stavy:
Stav zelený nebo v pořádku znamená, že klíčové nefunkční požadavky a cíle jsou plně splněny a že zdroje jsou využívány optimálně.
Stav žlutý nebo degradovaný stav znamená, že jedna nebo více složek toku se blíží svému definovanému prahu, ale tok je funkční. Bylo například zjištěno omezování úložiště.
Stav červený nebo není v pořádku znamená, že degradace přetrvává déle, než povolují vaše cíle spolehlivosti, nebo že tok přestal být dostupný.
Poznámka:
Model správného stavu by neměl zacházet se všemi selháními stejně. Zdravotní model by měl rozlišovat mezi přechodnými a nepřechodnými chybami. Měl by jasně rozlišovat mezi očekávanými přechodnými, ale opravitelnými poruchami a skutečným stavem katastrofy.
Tento model funguje pomocí strategie monitorování a varování, která je vyvinuta a provozována na principech neustálého zlepšování. Jak se vyvíjejí vaše úlohy, musí se s nimi vyvíjet i vaše modely správného stavu.
Podrobné pokyny ke konfiguracím monitorování a upozornění naleznete v příručce monitorování stavu.
Vizualizace
Chcete-li své provozní týmy a zúčastněné strany na úloze informovat o stavu v reálném čase a celkových trendech modelu stavu úlohy, zvažte vytvoření řídicích panelů ve svém monitorovacím řešení. Diskutujte o vizualizačních řešeních se zúčastněnými stranami, abyste zajistili, že jim poskytnete informace, které pro ně mají význam a které lze snadno konzumovat. Mohou také chtít vidět generované přehledy týdně, měsíčně nebo čtvrtletně.
Usnadnění díky Power Platform
Smlouvy SLA v Power Platform poskytují závazky společnosti Microsoft týkající se provozuschopnosti a možností připojení. Různé služby mají různé smlouvy SLA a někdy i jednotlivé SKU v rámci služby mají různé smlouvy SLA. Další informace naleznete v tématu Smlouvy o rozsahu služeb pro online služby.
Smlouva Power Platform SLA zahrnuje postupy pro získání kreditu služby, pokud není SLA splněna, spolu s definicemi dostupnosti pro každou službu. Tento aspekt SLA funguje jako zásady prosazování.
Microsoft Business Applications poskytuje funkce provozní kontinuity a zotavení po havárii všem prostředím produkčního typu v aplikacích Dynamics 365 a Power Platform SaaS. Přečtěte si, jak Microsoft zajišťuje odolnost vašich produkčních dat během regionálních výpadků.
Organizační sladění
Cloud Adoption Framework poskytuje pokyny pro doporučení pro SLO a SLI související s monitorováním v celé organizaci.
Další informace najdete v části SLO pro monitorování cloudu.
Kontrolní seznam spolehlivosti
Podívejte se na úplný soubor doporučení.