Javaslatok a megbízhatósági célok meghatározásához

Erre Power Platform a jól felépített megbízhatósági ellenőrzőlista-javaslatra vonatkozik:

RE:04

Megbízhatósági és helyreállítási célok meghatározása az összetevőkhöz, a folyamatokhoz és a teljes megoldáshoz. Vizualizálja a célokat a tárgyalásokhoz, a konszenzus eléréséhez, az elvárások meghatározásához és az ideális állapot eléréséhez szükséges intézkedések ösztönzéséhez. Az állapotmodell létrehozásához használja a meghatározott célokat. Az állapotmodell határozza meg, hogyan néznek ki az egészséges, csökkentett teljesítményű és nem megfelelő állapotok.

Ez az útmutató a kritikus számítási feladatok rendelkezésre állási és helyreállítási célmetrikáinak meghatározására vonatkozó javaslatokat ismerteti. A megbízhatósági célokat az üzleti érdekelt felekkel folytatott műhelygyakorlatok során vezetik le.

A célokat nyomon követéssel és teszteléssel javítják. Működjön együtt a belső érdekelt felekkel, hogy reális elvárásokat fogalmazzon meg a megbízhatósággal kapcsolatban. Ez a gyakorlat abban is segít, hogy az érdekelt felek támogassák az architekturális tervezési döntéseket, és megértsék, hogy a tervezés a lehető legjobban megfeleljen a megállapodott céloknak.

Microsoft Power Platform A legtöbb infrastruktúraszintű rendelkezésre állási és megbízhatósági problémát kezeli. A létrehozott számítási feladatok rendelkezésre állása azonban megosztott felelősség. Fontos megérteni, hogy még a Microsoft magas rendelkezésre állás iránti elkötelezettségeellenére sem nulla a rendszerleállás kockázata.

Fontolja meg az alábbi metrikák használatát az üzleti követelmények számszerűsítéséhez.

Kifejezés	Definíció
Szolgáltatói cél (SLO)	Az összetevő állapotát és a megbízhatósági szintet jelölő százalékos cél. Minél magasabb a szint, annál megbízhatóbb az alkatrész. Az összetett SLO a teljes számítási feladat összesített célját jelöli, és az összetevő SLO-k számláit jelöli.
Szolgáltatási szint jelző (SLI)	Egy szolgáltatás által kibocsátott metrika. Az SLI-metrikák összesítve számszerűsítik az SLO-értéket.
Szolgáltatói szerződés (SLA)	A szolgáltató és a szolgáltató közötti szerződéses megállapodás. A megállapodás meghatározza az SLO-kat. A megállapodás be nem tartása pénzügyi következményekkel járhat a szolgáltató számára.
Átlagos felépülési idő (MTTR)	Az összetevő visszaállításához szükséges idő a hiba észlelése után.
Átlagos meghibásodási idő (MTBF)	Az az időtartam, ameddig a számítási feladat megszakítás nélkül végrehajthatja a várt funkciót, amíg meg nem hiúsul.
Helyreállítási időre vonatkozó célkitűzés (RTO)	Az a maximális elfogadható idő, ameddig egy alkalmazás nem érhető el egy incidens után.
Helyreállítási pont célkitűzése (RPO)	Az adatvesztés maximális elfogadható időtartama egy incidens során.

Határozza meg a számítási feladat célértékeit ezekhez a metrikákhoz a felhasználói és rendszerfolyamatok kontextusában. Azonosítsa és pontozza ezeket a folyamatokat aszerint, hogy mennyire kritikusak a követelményei szempontjából. Az értékekkel vezérelheti a számítási feladatok tervezését az architektúra, a felülvizsgálat, a tesztelés és az incidenskezelési műveletek tekintetében. A célok elérésének elmulasztása a tűréshatáron túl érinti az üzletet.

Kulcsfontosságú tervezési stratégiák

A technikai megbeszélések nem határozhatják meg a kritikus folyamatok megbízhatósági céljainak meghatározását. Ehelyett az üzleti érdekelt feleknek a követelményeikre és a számítási feladat végfelhasználóinak elvárásaira kell összpontosítaniuk. A műszaki szakértők segítenek az érdekelt feleknek reális számértékeket hozzárendelni, amelyek megfelelnek ezeknek a követelményeknek. Az információcsere révén a műszaki szakértők lehetővé teszik a megvalósítható SLO-k megvitatását és megállapodását.

Vegyünk egy példát arra, hogyan lehet a követelményeket mérhető numerikus értékekre leképezni. Az érdekelt felek becslése szerint egy kritikus felhasználói folyamat esetén egy óra leállás a szokásos munkaidőben X dollár havi bevételkiesést eredményez. Ezt a dollárösszeget összehasonlítjuk egy olyan folyamat tervezésének becsült költségével, amelynek rendelkezésre állási SLO-ja 99,95 százalék helyett 99,9 százalék. A döntéshozóknak meg kell vitatniuk, hogy a bevételkiesés kockázata meghaladja-e az ellene való védekezéshez szükséges többletköltségeket és irányítási terheket.

Kövesse ezt a mintát a folyamatok vizsgálata és a célok teljes listájának összeállításakor.

Ne feledje, hogy a megbízhatósági célok eltérnek a teljesítménycéloktól. A megbízhatósági célok a rendelkezésre állásra és a helyreállításra összpontosítanak. A megbízhatósági célok beállításához először határozza meg a legszélesebb körű követelményeket, majd határozzon meg konkrétabb metrikákat a magas szintű követelményeknek való megfeleléshez.

A legmagasabb szintű megbízhatósági és helyreállítási követelmények, valamint a korrelált metrikák közé tartozhat például az alkalmazás 99,9%-os rendelkezésre állása az összes régióban, vagy egy 5 órás cél RTO az amerikai régióban. Az ilyen típusú célok meghatározása segít azonosítani, hogy mely kritikus folyamatok vesznek részt ezekben a célokban. Ezután fontolóra veheti az összetevőszintű célokat.

Rendelkezésre állási metrikák

A rendelkezésre állási célok SLO-, SLA- és SLI-metrikáknak felelnek meg.

SLO-k és SLA-k

A rendelkezésre állási metrikák az SLO-k meghatározásához használt SLO-kkal korrelálnak. A számítási feladatok SLO-ja határozza meg, hogy egy adott időszakban mennyi állásidő tolerálható; Például kevesebb, mint 1 óra havonta. Annak érdekében, hogy megfeleljen az SLO-célnak, tekintse át az egyes összetevők Microsoft SLA-it.

Az SLO-k létrehozásához gondolja át a következőket:

• A számítási feladatok nem funkcionális követelményei (például a kérések csúcsaránya, az egyidejű felhasználók) a következő 1–2 évben.

• Rendelkezésre álló mérőszámok arról, hogy mit mérhető egy adott időszakban. Ezek az adatok tájékoztatják arról, hogy milyen SLI-ket kell megadni.

Miután összegyűjtötte az egyes számítási feladatok összetevőinek SLA-it, számítson ki egy összetett SLA-t. Az összetett SLA-nak meg kell egyeznie a számítási feladat cél SLO-jával. Az összetett SLA kiszámítása az architektúra kialakításától függően több tényezőt is magában foglal.

A megfelelő SLO-k meghatározása időt és alapos mérlegelést igényel. Az üzleti érdekelt feleknek meg kell érteniük a megbízhatósági tűrést. Ennek a visszajelzésnek tájékoztatnia kell a célpontokat.

SLA-értékek

Az alábbi táblázat a gyakori SLA-értékeket határozza meg.

SZOLGÁLTATÁSISZINT-SZERZŐDÉS	Heti állásidő	Állásidő havonta	Állásidő évente
99%	1.68 óra	7.2 óra	3.65 nap
99.9%	10.1 perc	43.2 perc	8.76 óra
99.95%	5 perc	21.6 perc	4.38 óra
99.99%	1.01 perc	4.32 perc	52.56 perc
99.999%	6 másodperc	25.9 másodperc	5.26 perc

Ha az összetett SLA-kra a felhasználói és rendszerfolyamatok kontextusában gondol, ne feledje, hogy a különböző felhasználói és rendszerfolyamatok eltérő kritikussági definíciókkal rendelkeznek. Vegye figyelembe ezeket a különbségeket az összetett SLA-k létrehozásakor. A nem kritikus folyamatok tartalmazhatnak olyan összetevőket, amelyeket ki kell hagynia a számításokból, mert nem befolyásolják az ügyfélélményt, ha rövid időre nem érhetők el.

SLI-k

Az SLI-kre olyan összetevőszintű metrikákként gondolhat, amelyek hozzájárulnak az SLO-hoz. A legjelentősebb SLI-k azok, amelyek az ügyfelek szemszögéből befolyásolják a kritikus folyamatokat. Számos folyamat esetében az SLI-k közé tartozik a késés, az átviteli sebesség, a hibaarány és a rendelkezésre állás. Egy jó SLI segít azonosítani, ha fennáll az SLO megsértésének veszélye. Ha lehetséges, korrelálja az SLI-t adott ügyfelekkel.

A haszontalan metrikák gyűjtésének elkerülése érdekében korlátozza az SLI-k számát az egyes folyamatokhoz. Ha lehetséges, folyamatonként három SLI-t célozzon meg.

Helyreállítási metrikák

A helyreállítási célok megfelelnek az RTO, RPO, MTTR és MTBF metrikáknak. A rendelkezésre állási célokkal ellentétben ezeknek a méréseknek a helyreállítási céljai nem függenek nagymértékben a Microsoft SLA-itól. A Microsoft csak bizonyos termékekre, például SQL Database-re tesz közzé RTO- és RPO-garanciákat.

A reális helyreállítási célok definíciói a hibamód elemzésén , valamint az üzletmenet-folytonosság és a vészhelyreállítás tervein és tesztelésén alapulnak. A munka befejezése előtt beszélje meg a célokat az érdekelt felekkel, és győződjön meg arról, hogy az architektúra kialakítása a legjobb megértés szerint támogatja a helyreállítási célokat. Egyértelműen kommunikálja az érdekelt felekkel, hogy a számítási feladat azon részei, amelyek nincsenek alaposan tesztelve a helyreállítási metrikákhoz, nem rendelkezhetnek garantált SLA-kkal. Győződjön meg arról, hogy az érdekelt felek tisztában vannak azzal, hogy a helyreállítási célok idővel változhatnak a számítási feladatok frissítésével. A számítási feladat összetettebbé válhat, ha új technológiákat vezet be a felhasználói élmény javítása érdekében. Ezek a módosítások növelhetik vagy csökkenthetik a helyreállítási mutatókat.

Feljegyzés

Az MTBF meghatározása és garantálása kihívást jelenthet. A platformok, mint szolgáltatás (PaaS) vagy a szoftverek, mint szolgáltatás (SaaS) meghibásodhatnak és helyreállhatnak a felhőszolgáltató értesítése nélkül, és a folyamat teljesen átlátható lehet az Ön számára. Ha célokat határoz meg ehhez a mutatóhoz, csak azokat az összetevőket vegye figyelembe, amelyek az Ön irányítása alatt állnak.

Egészségügyi modell építése

A megbízhatósági célokhoz gyűjtött adatok segítségével építse fel az egyes számítási feladatokhoz és a kapcsolódó kritikus folyamatokhoz tartozó állapotmodellt. Az állapotmodell a folyamatok és a munkaterhelések egészséges, leromlott és nem megfelelő* állapotát határozza meg. Az államok biztosítják a megfelelő operatív prioritások meghatározását. Ez a modell közlekedési lámpa modellként is ismert . A modell zöldet rendel az egészséges, sárgát a leromlott, pirosat pedig az egészségtelen állapothoz. Az állapotmodell biztosítja, hogy tudni lehessen, mikor változik egy folyamat állapota egészségesről leromlott vagy nem megfelelő állapotra.

Az egészséges, leromlott és nem egészséges állapotok meghatározása a megbízhatósági céloktól függ. Íme néhány példa arra, hogyan definiálhatod az állapotokat:

• A zöld vagy egészséges állapot azt jelzi, hogy a kulcsfontosságú nem funkcionális követelmények és célok teljes mértékben teljesülnek, és az erőforrásokat optimálisan használják fel.

• A sárga vagy leromlott állapot azt jelzi, hogy a folyamat egy vagy több összetevője riasztást küld a meghatározott küszöbértékhez képest, de a folyamat működőképes. Például a rendszer tárhely-szabályozást észlelt.

• A piros vagy nem megfelelő állapot azt jelzi, hogy a romlás a megbízhatósági célok által megengedettnél hosszabb ideig tart, vagy hogy az adatfolyam nem érhető el.

Feljegyzés

Az egészségügyi modellnek nem szabad minden hibát ugyanúgy kezelnie. Az állapotmodellnek különbséget kell tennie az átmeneti és a nem átmeneti hibák között. Világosan meg kell különböztetnie a várhatóan átmeneti, de helyrehozható hibákat és a valódi katasztrófaállapotot.

Ez a modell egy olyan monitorozási és riasztási stratégia alkalmazásával működik, amelyet a folyamatos fejlesztés elvei alapján fejlesztettek ki és működtetnek. Ahogy a munkaterhelések fejlődnek, az állapotmodelleknek is velük együtt kell fejlődniük.

A monitorozási és riasztási konfigurációkkal kapcsolatos részletes útmutatásért lásd az állapotmonitorozási útmutatót.

Képi megjelenítés

Annak érdekében, hogy az operatív csapatok és a munkaterhelésben érdekelt felek tájékozottak legyenek a munkaterhelés-állapotmodell valós idejű állapotáról és általános trendjeiről, érdemes lehet **irányítópultokat** létrehozni a monitorozási megoldásban. ... Beszélje meg a vizualizációs megoldásokat az érdekelt felekkel, hogy biztosan azokat az információkat juttassa el a rendszerbe, amelyeket értékelnek, és amelyek könnyen felhasználhatók. Előfordulhat, hogy heti, havi vagy negyedéves jelentéseket is szeretnének látni.

Power Platform elősegítés

Power Platform Az SLA-k biztosítják a Microsoftnak az üzemidőre és a csatlakozásra vonatkozó kötelezettségeit. A különböző szolgáltatások eltérő SLA-kkal rendelkeznek, és néha az egy szolgáltatáson belüli SKU-k is eltérő SLA-kkal rendelkeznek. További információkért lásd: Online szolgáltatásokra vonatkozó szolgáltatási szintű szerződések.

Az Power Platform SLA tartalmazza a szolgáltatási jóváírás megszerzésének eljárásait, ha az SLA feltételei nem teljesülnek, valamint az egyes szolgáltatások elérhetőségének definícióit. Az SLA ezen aspektusa végrehajtási irányelvként működik.

A Microsoft Business Applications üzletmenet-folytonossági és katasztrófa utáni helyreállítási (BCDR) funkciókat biztosít minden éles típusú környezetben a Dynamics 365 és Power Platform SaaS-alkalmazásokban. Ismerje meg, hogyan biztosítja a Microsoft az éles adatok rugalmasságát a regionális kimaradások során.

Szervezeti összehangolás

A Cloud Adoption Framework útmutatást nyújt az SLO-kra és SLI-kre vonatkozó ajánlásokhoz a szervezeten belüli monitorozással kapcsolatban.

További információkért lásd: Felhőalapú monitorozási SLO-k.

Megbízhatósági ellenőrzőlista

Tekintse meg a teljes javaslatot.

Megbízhatósági ellenőrzőlista