Megbízhatósági célok meghatározására vonatkozó javaslatok

Erre az Azure Well-Architected Framework megbízhatósági ellenőrzőlistára vonatkozó javaslatra vonatkozik:

RE:04

Határozza meg az összetevők, a folyamatok és a teljes megoldás megbízhatósági és helyreállítási céljait. Vizualizálja a célokat, hogy tárgyaljon, konszenzust szerezzen, elvárásokat állítson be, és cselekvéseket hajtson végre az ideális állapot elérése érdekében. A definiált célok használatával hozza létre az állapotmodellt. Az állapotmodell határozza meg, hogy milyen állapotú, csökkentett teljesítményű és nem kifogástalan állapotú állapotok jelennek meg.

Ez az útmutató a kritikus számítási feladatok és folyamatok 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élok az üzleti érdekeltekkel folytatott workshop-gyakorlatokon alapulnak. A célok pontosítása monitorozással és teszteléssel történik.

A belső érdekelt felekkel reális elvárásokat állítson be a számítási feladatok megbízhatóságával kapcsolatban, hogy az érdekelt felek szerződéses megállapodásokon keresztül kommunikálhassák ezeket az elvárásokat az ügyfelekkel. A reális elvárások segítenek az érdekelt feleknek megérteni és támogatni az architekturális tervezéssel kapcsolatos döntéseket, és tudni, hogy az Ön által elfogadott célok optimális teljesítése érdekében tervez.

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

Időszak	Definíció
Szolgáltatási szint célkitűzése (SLO)	Százalékos cél, amely az összetevő állapotát és a megbízhatósági szintet jelöli. Minél magasabb a szint, annál megbízhatóbb az összetevő. Az összetett SLO a teljes számítási feladat és az összetevő SLO-k fiókjainak összesített célját jelöli.
Szolgáltatásszintű mutató (SLI)	Egy szolgáltatás által kibocsátott metrika. Az SLI-metrikák összesítése egy SLO-érték számszerűsítéséhez.
Szolgáltatásiszint-szerződés (SLA)	A szolgáltató és a szolgáltatói ügyfél közötti szerződéses megállapodás. A szerződés határozza meg az SLO-kat. A szerződés teljesítésének elmulasztása pénzügyi következményekkel járhat a szolgáltatóra nézve.
Helyreállítás átlagos ideje (MTTR)	Az összetevő hiba észlelése utáni visszaállításához szükséges idő.
Hiba közötti középidő (MTBF)	Az időtartam, amelyre a számítási feladat megszakítás nélkül képes végrehajtani a várt függvényt, amíg el nem meghiúsul.
Helyreállítási időre vonatkozó célkitűzés (RTO)	Az az elfogadható maximális idő, amikor egy alkalmazás egy incidens után nem érhető el.
Helyreállítási időkorlát (RPO)	Az incidens során bekövetkező adatvesztés maximális elfogadható időtartama.

A számítási feladat célértékeinek meghatározása ezekhez a metrikákhoz a felhasználói folyamatok és a rendszerfolyamatok kontextusában. Azonosítsa és értékelje ezeket a folyamatokat azzal, hogy mennyire kritikusak a követelményeknek. Az értékekkel megtervezheti a számítási feladatokat az architektúra, a felülvizsgálat, a tesztelés és az incidenskezelési műveletek szempontjából. A célok teljesítésének elmulasztása a tűréshatáron túli üzletmenetre is hatással lesz.

Fő tervezési stratégiák

A technikai megbeszélések nem vezethetnek a kritikus folyamatok megbízhatósági céljainak meghatározásához. Ehelyett az üzleti érdekelt feleknek az ügyfelekre kell összpontosítaniuk, mivel meghatározzák a számítási feladatok követelményeit. A műszaki szakértők segítenek az érdekelt feleknek reális numerikus értékeket hozzárendelni, amelyek korrelálnak az említett követelményekkel. Az ismeretek megosztásakor a műszaki szakértők lehetővé teszik a reális SLO-król való tárgyalásokat és kölcsönös konszenzust.

Vegyünk egy példát arra, hogyan képezhetők le a követelmények mérhető numerikus értékekre. Az érdekelt felek becslése szerint egy kritikus felhasználói folyamat esetén egy óra állásidő a szokásos munkaidőben X dollár havi bevételkiesést eredményez. Ezt a dollárösszeget hasonlítjuk össze egy olyan folyamat tervezésének becsült költségével, amelynek rendelkezésre állási SLO-értéke 99,95 százalék, nem pedig 99,9 százalék. A döntéshozóknak meg kell vitatniuk, hogy a bevételkiesés kockázata meghaladja-e az ezzel szembeni védelemhez szükséges többletköltségeket és felügyeleti terhet. Kövesse ezt a mintát, miközben megvizsgálja a folyamatokat, és összeállítja a célok teljes listáját.

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 legtágabb követelményeket, majd adjon meg konkrétabb metrikákat a magas szintű követelményeknek való megfelelés érdekében.

A legmagasabb szintű megbízhatósági és helyreállítási követelmények és a korrelált metrikák közé tartozhat például egy 99,9 százalékos alkalmazás-rendelkezésre állás 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 megfontolhatja az összetevőszintű célokat.

Kompromisszum: Elméleti eltérés lehet a számítási feladat összetevőinek technikai korlátozásai és az üzlet szempontjából ez mit jelent, például a másodpercenkénti megabitek átviteli sebessége és a másodpercenkénti tranzakciók között. A két nézet közötti modell létrehozása kihívást jelenthet. A megoldás túlindulása helyett próbálja meg gazdaságos, de értelmes módon megközelíteni.

Rendelkezésre állási metrikák

SLA-k és SLA-k

A rendelkezésre állási metrikák korrelálnak az SLA-khoz, amelyeket az SLA-k definiálásához használ. A számítási feladat SLO-ja határozza meg, hogy mennyi állásidő tolerálható egy adott időszakban, például havonta kevesebb mint 1 óra. Annak érdekében, hogy biztosan megfeleljen az SLO-célnak, tekintse át az egyes összetevők Microsoft SLA-ját. Ügyeljen arra, hogy mennyi redundanciára van szüksége a magas SLA-knak való megfeleléshez. A Microsoft például magasabb SLA-kat garantál az Azure Cosmos DB többrégiós üzemelő példányai esetében, mint az egyrégiós üzemelő példányok esetében.

Megjegyzés

Az Azure SLA-k nem mindig fedik le a szolgáltatás minden aspektusát. Például Azure Application Gateway rendelkezik rendelkezésre állási SLA-val, de az Azure Web Application Firewall funkció nem garantálja, hogy a rosszindulatú forgalom ne haladjon át. Az SLA-k és SLO-k fejlesztésekor vegye figyelembe ezt a korlátozást.

Miután összegyűjtötte az egyes számítási feladatok összetevőihez tartozó SLA-kat, számítsa ki az ö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úratervtől függően több tényezőt is magában foglal. Vegye figyelembe az alábbi példákat.

Megjegyzés

Az alábbi példákban szereplő SLA-értékek hipotetikusak , és csak bemutatási célokra szolgálnak. Ezek nem a Microsoft által támogatott aktuális értékeket jelölik .

Az összetett SLA-k több olyan szolgáltatást is magukban foglalnak, amelyek támogatják az alkalmazásokat, eltérő rendelkezésre állási szinttel. Vegyünk például egy Azure App Service webalkalmazást, amely Azure SQL Database-be ír. Elméletileg ezek az SLA-k a következők lehetnek:

• App Service webalkalmazások = 99,95 százalék
• SQL Database = 99,99 százalék

Milyen maximális állásidőre számíthat az alkalmazáshoz? Ha valamelyik szolgáltatás meghibásodik, akkor a teljes alkalmazás meghibásodik. Az egyes szolgáltatások meghibásodásának valószínűsége független, ezért az alkalmazás összetett SLA-ja 99,95 százalék × 99,99 százalék = 99,94 százalék. Ez az érték alacsonyabb, mint az egyes SLA-k. Ez a következtetés nem meglepő, mert egy több szolgáltatásra támaszkodó alkalmazás több potenciális hibaponttal rendelkezik.

Az összetett SLA továbbfejlesztéséhez hozzon létre független tartalék útvonalakat. Ha például SQL Database nem érhető el, helyezze a tranzakciókat egy üzenetsorba a későbbi feldolgozáshoz:

Ebben a kialakításban az alkalmazás akkor is elérhető, ha nem tud csatlakozni az adatbázishoz. Azonban meghiúsul, ha az adatbázis és az üzenetsor egyszerre meghiúsul. Az egyidejű hiba várható időaránya 0,0001 × 0,001, ezért a kombinált útvonal összetett SLA-ja a következő:

Adatbázis vagy üzenetsor = 1,0 − (0,0001 × 0,001) = 99,99999 százalék

A teljes összetett SLA:

Webalkalmazás és (adatbázis vagy üzenetsor) = 99,95 százalék × 99,99999 százalék = ~99,95 százalék

Ez a megközelítés kompromisszumokat jelent:

• Az alkalmazáslogika összetettebb.
• Fizetnie kell az üzenetsorért.
• Figyelembe kell vennie az adatkonzisztencia problémáit.

Többrégiós üzemelő példányok esetén az összetett SLA kiszámítása a következőképpen történik:

• Az N az egy régióban üzembe helyezett alkalmazás összetett SLA-ja.

• R azoknak a régióknak a száma, ahol az alkalmazás üzembe van helyezve.

A várt esély arra, hogy az alkalmazás minden régióban egyszerre meghiúsul( ((1 − N) ^ R). Ha például a hipotetikus egyrégiós SLA 99,95 százalék:

• Két régió összesített SLA-ja = (1 − (1 − 0,9995) ^ 2) = 99,999975 százalék

• A négy régió összesített SLA-ja = (1 − (1 − 0,9995) ^ 4) = 99,999999 százalék

A megfelelő SLO-k meghatározása időt és gondos megfontolást igényel. Az üzleti érdekelt feleknek tisztában kell lennie azzal, hogy a legfontosabb ügyfelek hogyan használják az alkalmazást. Meg kell érteniük a megbízhatósági tűréshatárt is. Ennek a visszajelzésnek tájékoztatnia kell a célokat.

SLA-értékek

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

SLA	Állásidő hetente	Állásidő havonta	Állásidő évente
99%	1,68 óra	7,2 óra	3,65 nap
99.9%	10,1 perc	10,1 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 a folyamatok kontextusában az összetett SLA-kra gondol, ne feledje, hogy a különböző folyamatok különböző 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 olyan összetevőket tartalmazhatnak, amelyeket ki kell hagynia a számításokból, mert azok nem befolyásolják az ügyfélélményt, ha rövid ideig nem érhetők el.

Megjegyzés

Az ügyféloldali számítási feladatok és a belső használatú számítási feladatok eltérő SLO-kkal rendelkeznek. A belső használatú számítási feladatok általában sokkal kevésbé korlátozó rendelkezésre állási SLO-kkal rendelkezhetnek, mint az ügyfelek számára elérhető számítási feladatok.

SLI-k

Az SLO-kat olyan összetevőszintű metrikáknak tekinti, amelyek hozzájárulnak az SLO-khoz. A legjelentősebb SLA-k azok, amelyek az ügyfelek szempontjából befolyásolják a kritikus folyamatokat. Sok folyamat esetében az SLA-k közé tartozik a késés, az átviteli sebesség, a hibaarány és a rendelkezésre állás. A jó SLI segít azonosítani, ha egy SLO-t fennáll a behatolás veszélye. Ha lehetséges, korrelálja az SLI-t adott ügyfelekkel.

A felesleges 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, irányonként három SLA legyen.

Helyreállítási metrikák

A helyreállítási célok RTO-, RPO-, MTTR- és MTBF-metrikáknak felelnek meg. A rendelkezésre állási célokkal ellentétben ezeknek a méréseknek a helyreállítási céljai nem függnek nagy mértékben a Microsoft SLA-któl. A Microsoft csak bizonyos termékek, például SQL Database esetében 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ági és vészhelyreállítási terveken és tesztelésen 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 lehető legjobban támogatja a helyreállítási célokat. Egyértelműen közölje az érdekeltekkel, hogy a helyreállítási metrikákhoz nem alaposan tesztelt folyamatoknak vagy teljes számítási feladatoknak nem kellett volna garantált SLA-kat biztosítaniuk. 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ése során. A számítási feladat összetettebbé válhat az ügyfelek hozzáadásakor vagy új technológiák bevezetésekor az ügyfélélmény javítása érdekében. Ezek a módosítások növelhetik vagy csökkenthetik a helyreállítási metrikákat.

Megjegyzés

Az MTBF meghatározása és garantálása kihívást jelenthet. A szolgáltatásként nyújtott platformok (PaaS) vagy a szolgáltatásként nyújtott szoftverek (SaaS) a felhőszolgáltató értesítése nélkül meghiúsulhatnak és helyreállhatnak, és a folyamat teljesen átlátható lehet Önnek vagy ügyfeleinek. Ha célokat határoz meg ehhez a metrikahoz, csak az Ön felügyelete alatt álló összetevőkre terjed ki.

Helyreállítási célok meghatározásakor definiáljon küszöbértékeket a helyreállítás elindításához. Ha például egy webcsomópont több mint 5 percig nem érhető el, a rendszer automatikusan hozzáad egy új csomópontot a készlethez. Definiáljon küszöbértékeket az összes összetevőhöz, figyelembe véve, hogy egy adott összetevőhöz milyen helyreállítás tartozik, beleértve a többi összetevőre és függőségre gyakorolt hatást is. A küszöbértékeknek átmeneti hibákat is figyelembe kell vennie , hogy ne induljanak el túl gyorsan a helyreállítási műveletek. Dokumentálja és ossza meg az érdekeltekkel a helyreállítási műveletek lehetséges kockázatait, például az adatvesztést vagy a munkamenet megszakadását az ügyfelek számára.

Állapotmodell létrehozása

A megbízhatósági célokhoz gyűjtött adatok felhasználásával hozza létre az állapotmodellt az egyes számítási feladatokhoz és a kapcsolódó kritikus folyamatokhoz. Az állapotmodellek a folyamatok és számítási feladatok kifogástalan, csökkentett és nem kifogástalan állapotait határozzák meg. Az állapotok biztosítják a megfelelő műveleti rangsorolást. Ezt a modellt forgalomirányító modellnek is nevezik. A modell zöldet rendel az egészségeshez, sárga a csökkentett teljesítményűhöz, a pirosat pedig a nem megfelelő állapothoz. Az állapotmodell biztosítja, hogy tudja, mikor változik egy folyamat állapota kifogástalan állapotról csökkentett vagy nem kifogástalan állapotra.

Az kifogástalan, csökkentett teljesítményű és nem kifogástalan állapotok definiálása a megbízhatósági céloktól függ. Íme néhány példa az állapotok definiálásának módjaira:

• A zöld vagy kifogástalan állapot azt jelzi, hogy a legfontosabb nem funkcionális követelmények és célok teljes mértékben teljesülnek, és hogy az erőforrásokat optimálisan használják. A kérések 95%-át például =500 ms-ban <dolgozza fel a rendszer, és Azure Kubernetes Service (AKS) csomópontot használ X százalékban.

• A sárga vagy csökkentett állapot azt jelzi, hogy a folyamat egy vagy több összetevője riasztást küld a megadott küszöbértékhez, de a folyamat működőképes. A rendszer például tárterület-szabályozást észlelt.

• A piros vagy nem kifogástalan állapot azt jelzi, hogy a romlás a megbízhatósági célok által megengedettnél hosszabb ideig maradt fenn, vagy hogy a folyamat elérhetetlenné vált.

Megjegyzés

Az állapotmodell nem kezelhet minden hibát ugyanazzal a módszerrel. Az állapotmodellnek különbséget kell tennie az átmeneti és a nem átmeneti hibák között. Egyértelműen különbséget kell tenni a várt átmeneti, de helyreállítható hibák és a valódi vészállapot között.

Ez a modell egy monitorozási és riasztási stratégia használatával működik, amely a folyamatos fejlesztés alapelvein alapul. A számítási feladatok fejlődésével az állapotmodelleknek együtt kell fejlődniük.

A rétegzett alkalmazásállapot-modell részletes tervezési szempontjait és javaslatait a kritikus fontosságú számítási feladatok tervezési területein található állapotmodellezési útmutatóban találja. A monitorozási és riasztási konfigurációkkal kapcsolatos részletes útmutatásért tekintse meg az állapotmonitorozási útmutatót.

Vizualizáció

Annak érdekében, hogy az üzemeltetési csapatok és a számítási feladatok érdekeltjei folyamatosan értesüljenek a számítási feladatok állapotának valós idejű állapotáról és általános trendjeiről, érdemes lehet irányítópultokat létrehozni a monitorozási megoldásban. A vizualizációs megoldások megvitatása az érdekelt felekkel annak biztosítása érdekében, hogy ön az általuk értékelt és könnyen használható információkat adja meg. A létrehozott jelentéseket hetente, havonta vagy negyedévente is látni szeretnék.

Azure-beli facilitálás

Az Azure SLA-k biztosítják a Microsoftnak az üzemidőre és a kapcsolatra vonatkozó kötelezettségvállalásait. A különböző szolgáltatások eltérő SLA-kkal rendelkeznek, és néha a szolgáltatáson belüli termékváltozatok eltérő SLA-kkal rendelkeznek. További információ: Szolgáltatási szintű szerződések online szolgáltatások.

Az Azure SLA tartalmazza a szolgáltatás kreditjének beszerzésére vonatkozó eljárásokat, ha az SLA nem teljesül, valamint az egyes szolgáltatások rendelkezésre állásának definícióit. Az SLA ezen eleme kényszerítési házirendként működik.

Kapcsolódó hivatkozások

• Well-Architected keretrendszer kritikus fontosságú útmutatója az állapotmodellezéshez: A kritikus fontosságú számítási feladatok állapotmodellezése és megfigyelhetősége az Azure-ban

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

Tekintse meg a javaslatok teljes készletét.

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