Odporúčania na definovanie cieľov spoľahlivosti
Vzťahuje sa na toto odporúčanie Power Platform Dobre architektonického kontrolného zoznamu spoľahlivosti:
RE:04 | Definujte spoľahlivosť a ciele obnovy pre komponenty, toky a celkové riešenie. Vizualizujte ciele na vyjednávanie, získanie konsenzu, nastavenie očakávaní a riadenie akcií na dosiahnutie ideálneho stavu. Použite definované ciele na vytvorenie modelu zdravia. Zdravotný model definuje, ako vyzerajú zdravé, degradované a nezdravé stavy. |
---|
Táto príručka popisuje odporúčania na definovanie cieľových metrík dostupnosti a obnovy pre kritické pracovné zaťaženia. Ciele spoľahlivosti sú odvodené prostredníctvom workshopov so zainteresovanými stranami.
Ciele sa zlepšujú monitorovaním a testovaním. Spolupracujte so svojimi internými zainteresovanými stranami na stanovení realistických očakávaní spoľahlivosti. Toto cvičenie tiež pomôže zainteresovaným stranám podporiť vaše voľby architektonického dizajnu a pochopiť, že navrhujete čo najlepšie splnenie cieľov, na ktorých ste sa dohodli.
Microsoft Power Platform rieši väčšinu problémov na úrovni infraštruktúry o dostupnosti a spoľahlivosti za vás. Dostupnosť pracovných zaťažení, ktoré vytvárate, je však spoločnou zodpovednosťou. Je dôležité pochopiť, že aj pri záväzku spoločnosti Microsoft k vysokej dostupnosti nie je riziko výpadku systému nikdy nulové.
Zvážte použitie nasledujúcich metrík na kvantifikáciu obchodných požiadaviek.
Pojem | Definícia |
---|---|
Cieľ na úrovni služby (SLO) | Percentuálny cieľ, ktorý predstavuje stav komponentu a úroveň spoľahlivosti. Čím vyššia je úroveň, tým je komponent spoľahlivejší. Zložené SLO predstavuje súhrnný cieľ celého pracovného zaťaženia a zodpovedá za jednotlivé SLO. |
Indikátor úrovne služby (SLI) | Metrika vysielaná službou. Metriky SLI sú agregované na kvantifikáciu hodnoty SLO. |
Dohoda o úrovni služieb (SLA) | Zmluvná dohoda medzi poskytovateľom služby a zákazníkom služby. Dohoda definuje SLO. Nedodržanie dohody môže mať finančné dôsledky pre poskytovateľa služieb. |
Stredný čas na zotavenie (MTTR) | Čas potrebný na obnovenie komponentu po zistení zlyhania. |
Stredný čas medzi poruchami (MTBF) | Trvanie, počas ktorého môže pracovné zaťaženie vykonávať očakávanú funkciu bez prerušenia, kým nezlyhá. |
Cieľ doby zotavenia (RTO) | Maximálny prijateľný čas, počas ktorého môže byť aplikácia nedostupná po incidente. |
Cieľ bodu obnovenia (RPO) | Maximálne prijateľné trvanie straty údajov počas incidentu. |
Definujte cieľové hodnoty pracovného zaťaženia pre tieto metriky v kontexte užívateľských a systémových tokov. Identifikujte a ohodnoťte tieto toky podľa toho, nakoľko kritické sú pre vaše požiadavky. Použite hodnoty na riadenie návrhu vašej pracovnej záťaže z hľadiska architektúry, kontroly, testovania a operácií správy incidentov. Nesplnenie cieľov ovplyvní podnikanie za hranicu tolerancie.
Kľúčové dizajnové stratégie
Technické diskusie by nemali viesť k tomu, ako definujete ciele spoľahlivosti pre vaše kritické toky. Namiesto toho by sa mali zainteresované strany zamerať na svoje požiadavky a očakávania koncových používateľov pracovnej záťaže. Technickí experti pomáhajú zainteresovaným stranám priradiť realistické číselné hodnoty, ktoré spĺňajú tieto požiadavky. Výmenou informácií technickí experti umožňujú diskusiu a dohodu o realizovateľných SLO.
Zvážte príklad, ako mapovať požiadavky na merateľné číselné hodnoty. Zainteresované strany odhadujú, že v prípade kritického toku používateľov vedie hodinový výpadok počas bežnej pracovnej doby k strate X dolárov na mesačných výnosoch. Táto suma v dolároch sa porovnáva s odhadovanými nákladmi na návrh toku, ktorý má dostupnosť SLO 99,95 percenta namiesto 99,9 percenta. Osoby s rozhodovacou právomocou musia prediskutovať, či riziko straty príjmov preváži dodatočné náklady a záťaž manažmentu, ktorá je potrebná na ochranu proti nej.
Postupujte podľa tohto vzoru pri skúmaní tokov a vytváraní úplného zoznamu cieľov.
Pamätajte, že ciele spoľahlivosti sa líšia od výkonnostných cieľov. Ciele spoľahlivosti sa zameriavajú na dostupnosť a obnovu. Ak chcete nastaviť ciele spoľahlivosti, začnite definovaním najširších požiadaviek a potom definujte konkrétnejšie metriky, aby ste splnili požiadavky na vysokej úrovni.
Požiadavky na spoľahlivosť a obnovu najvyššej úrovne a korelované metriky môžu zahŕňať napríklad dostupnosť aplikácií 99,9 percent pre všetky regióny alebo cieľovú RTO 5 hodín pre oblasť Ameriky. Definovanie týchto typov cieľov vám pomôže identifikovať, ktoré kritické toky sú zahrnuté v týchto cieľoch. Potom môžete zvážiť ciele na úrovni komponentov.
Metriky dostupnosti
Ciele dostupnosti zodpovedajú metrikám SLO, SLA a SLI.
SLO a SLA
Metriky dostupnosti korelujú s SLO, ktoré používate na definovanie SLA. Pracovná záťaž SLO určuje, koľko prestojov je v danom období tolerovateľné; napríklad menej ako 1 hodinu mesačne. Aby ste sa uistili, že dokážete splniť cieľ SLO, prečítajte si Microsoft SLA pre každý komponent.
Ak chcete vytvoriť svoje SLO, premýšľajte o:
Nefunkčné požiadavky vašej pracovnej záťaže (napríklad špičkové miery požiadaviek, súbežní používatelia) počas nasledujúcich 1-2 rokov.
Dostupné metriky toho, čo môžete merať, za konkrétne časové obdobie. Tieto údaje budú informovať o tom, aké SLI špecifikovať.
Po zhromaždení SLA pre jednotlivé komponenty pracovného zaťaženia vypočítajte zloženú SLA. Zložená zmluva SLA by sa mala zhodovať s cieľovou SLO pracovnej záťaže. Výpočet zloženej zmluvy SLA zahŕňa niekoľko faktorov v závislosti od návrhu vašej architektúry.
Definovanie správnych SLO si vyžaduje čas a starostlivé zváženie. Obchodné zainteresované strany by mali pochopiť toleranciu spoľahlivosti. Táto spätná väzba by mala informovať ciele.
Hodnoty SLA
Nasledujúca tabuľka definuje bežné hodnoty SLA.
Zmluva o úrovni služieb (SLA) | Prestoje za týždeň | Prestoje za mesiac | Prestoje za rok |
---|---|---|---|
99 % | 1.68 hodín | 7.2 hodín | 3.65 dní |
99,9 % | 10.1 minút | 43.2 minút | 8.76 hodín |
99,95 % | 5 min. | 21.6 minút | 4.38 hodín |
99,99 % | 1.01 minút | 4.32 minút | 52.56 minút |
99,999 % | 6 sekúnd | 25.9 sekúnd | 5.26 minút |
Keď uvažujete o zložených SLA v kontexte užívateľských a systémových tokov, pamätajte, že rôzni používatelia a systémové toky majú rôzne definície kritickosti. Zvážte tieto rozdiely pri vytváraní zložených SLA. Nekritické toky môžu mať komponenty, ktoré by ste mali z výpočtov vynechať, pretože ak nie sú krátkodobo dostupné, neovplyvňujú dojem zákazníka.
SLI
Predstavte si SLI ako metriky na úrovni komponentov, ktoré prispievajú k SLO. Najvýznamnejšie SLI sú tie, ktoré ovplyvňujú vaše kritické toky z pohľadu vašich zákazníkov. Pre mnohé toky zahŕňajú SLI latenciu, priepustnosť, chybovosť a dostupnosť. Dobrá SLI vám pomôže identifikovať, kedy existuje riziko porušenia SLO. Keď je to možné, korelujte SLI s konkrétnymi zákazníkmi.
Ak sa chcete vyhnúť zhromažďovaniu zbytočných metrík, obmedzte počet SLI pre každý tok. Ak je to možné, zamerajte sa na tri SLI na jeden tok.
Metriky obnovy
Ciele obnovy zodpovedajú metrikám RTO, RPO, MTTR a MTBF. Na rozdiel od cieľov dostupnosti, ciele obnovy pre tieto merania veľmi nezávisia od Microsoft SLA. Microsoft zverejňuje záruky RTO a RPO len pre niektoré produkty, napr. SQL Databáza.
Definície pre realistické ciele obnovy závisia od vás analýza režimu zlyhania a vaše plány a testovanie pre kontinuitu podnikania a zotavenie po katastrofe. Pred dokončením tejto práce prediskutujte ciele so zainteresovanými stranami a uistite sa, že váš návrh architektúry podporuje ciele obnovy podľa vášho najlepšieho pochopenia. Jasne povedzte zainteresovaným stranám, že žiadne časti pracovného zaťaženia, ktoré nie sú dôkladne testované na metriky obnovy, by nemali mať zaručené zmluvy SLA. Uistite sa, že zainteresované strany chápu, že ciele obnovy sa môžu v priebehu času meniť s aktualizáciou pracovného zaťaženia. Pracovná záťaž sa môže stať zložitejšou, keď si osvojíte nové technológie na zlepšenie používateľského zážitku. Tieto zmeny môžu zvýšiť alebo znížiť vaše metriky obnovenia.
Poznámka
MTBF môže byť náročné definovať a garantovať. Platformy ako služba (PaaS) alebo softvér ako služba (SaaS) môžu zlyhať a obnoviť sa bez akéhokoľvek upozornenia od poskytovateľa cloudu a tento proces môže byť pre vás úplne transparentný. Ak definujete ciele pre túto metriku, zahrňte iba komponenty, ktoré máte pod kontrolou.
Budovanie modelu zdravia
Použite údaje, ktoré ste zhromaždili pre svoje ciele spoľahlivosti, na zostavenie modelu zdravia pre každé pracovné zaťaženie a súvisiace kritické toky. Model zdravia definuje zdravé, degradované a nezdravé* stavy pre toky a pracovné zaťaženie. Štáty zabezpečujú primeranú operačnú prioritu. Tento model je známy aj ako model na semafore. Model priraďuje zelenú pre zdravé, žltú pre degradované a červenú pre nezdravé. Model zdravia zaisťuje, že viete, kedy sa stav prietoku zmení zo zdravého na zhoršený alebo nezdravý.
To, ako definujete zdravé, degradované a nezdravé stavy, závisí od vašich cieľov spoľahlivosti. Tu je niekoľko príkladov spôsobov, ako môžete definovať stavy:
zelený alebo zdravý stav naznačuje, že kľúčové nefunkčné požiadavky a ciele sú plne splnené a zdroje sa využívajú optimálne.
A žltý alebo zhoršený stav znamená, že jedna alebo viacero zložiek toku upozorňuje na svoj definovaný prah, ale tok je funkčný. Napríklad bolo zistené obmedzovanie úložiska.
červený alebo nezdravý stav znamená, že degradácia pretrváva dlhšie, než povoľujú vaše ciele spoľahlivosti, alebo že tok nie je dostupný.
Poznámka
Zdravotný model by nemal pristupovať ku všetkým zlyhaniam rovnako. Zdravotný model by mal rozlišovať medzi prechodnými a neprechodnými chybami. Mal by jasne rozlišovať medzi očakávanými prechodnými, ale opraviteľnými poruchami a skutočným stavom katastrofy.
Tento model funguje pomocou stratégie monitorovania a varovania, ktorá je vyvinutá a prevádzkovaná na princípoch neustáleho zlepšovania. Ako sa vaše pracovné zaťaženie vyvíja, vaše modely zdravia sa musia vyvíjať s nimi.
Podrobné pokyny o konfiguráciách monitorovania a varovania nájdete v príručke monitorovanie zdravia .
Vizualizácia
Ak chcete, aby boli vaše prevádzkové tímy a zainteresované strany o pracovnej záťaži informované o stave v reálnom čase a celkových trendoch modelu zdravia pracovnej záťaže, zvážte vytvorenie dashboardov vo vašom monitorovacom riešení. Diskutujte o riešeniach vizualizácie so zainteresovanými stranami, aby ste zaistili, že im poskytnete informácie, ktoré si cenia a ktoré sa dajú ľahko konzumovať. Môžu tiež chcieť vidieť generované prehľady týždenne, mesačne alebo štvrťročne.
Power Platform uľahčenie
Power Platform Zmluvy SLA poskytujú Microsoft záväzky týkajúce sa dostupnosti a pripojenia. Rôzne služby majú rôzne SLA a niekedy SKU v rámci služby majú rôzne SLA. Ďalšie informácie nájdete v časti Dohody o úrovni služieb pre online služby.
Dohoda Power Platform SLA obsahuje postupy na získanie kreditu služby, ak nie je splnená zmluva SLA, spolu s definíciami dostupnosti pre každú službu. Tento aspekt SLA funguje ako politika presadzovania.
Microsoft Business Applications poskytuje funkcie Business Continuity and Disaster Recovery (BCDR) pre všetky typy výroby prostredia v Dynamics 365 a Power Platform aplikáciách SaaS. Zistite, ako Microsoft zabezpečuje odolnosť vašich produkčných údajov počas regionálnych výpadkov.
Organizačné zosúladenie
Cloud Adoption Framework poskytuje návod na odporúčania pre SLO a SLI súvisiace s monitorovaním v rámci organizácie.
Ďalšie informácie nájdete v časti SLO monitorovania cloudu.
Kontrolný zoznam spoľahlivosti
Pozrite si úplný súbor odporúčaní.