Megbízhatósági célok meghatározására vonatkozó javaslatok
Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslat:
| RE:04 | Határozza meg az összetevők, a folyamatok és az általános megoldás megbízhatósági és helyreállítási céljait. Vizualizálja a célokat, hogy tárgyaljanak, konszenzusra jussanak, elvárásokat állítsanak fel, és cselekvéseket ösztönözhessenek az ideális állapot elérése érdekében. Az állapotmodell létrehozásához használja a definiált célokat. Az állapotmodell határozza meg, hogy milyen az egészséges, a csökkent és az egészségtelen állapot. |
|---|
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 érdekelt felekkel folytatott workshop-gyakorlatokon alapulnak. A célok pontosítása monitorozással és teszteléssel történik.
A belső érdekelt felekkel valós elvárásokat állíthat 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ési döntéseket, és tudniuk kell, hogy az Ön által kitűzött célok optimális kielégí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és (SLO) | Egy számítási feladat vagy alkalmazás teljesítményének és megbízhatóságának mértéke. Az SLO egy konkrét, mérhető cél, amely meghatározott ügyfél-interakciókhoz van beállítva. Ez egy olyan cél, amelyet a felhasználók által elvárt szolgáltatásminőség alapján állít be az alkalmazás számítási feladataihoz. |
| 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ásfelhasználó közötti szerződéses megállapodás. A szerződés teljesítésének elmulasztása pénzügyi következményekkel járhat a szolgáltatóra nézve. |
| A 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 az időtartam, amíg a számítási feladat megszakítás nélkül el tudja végezni 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 a követelmények szempontjából kritikus fontosságúak alapján. 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 toleranciaszinten túl is hatással lesz az üzletre.
Főbb 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 olyan reális numerikus értékeket hozzárendelni, amelyek korrelálnak ezekhez a követelményekhez. Az ismeretek megosztásakor a műszaki szakértők lehetővé teszik a reális SLO-kra vonatkozó 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 normál 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-é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 a folyamatok vizsgálatakor, és hozzon létre egy teljes listát a célokról.
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 meghatározásához először határozza meg a legtágabb követelményeket, majd határozzon meg pontosabb 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 alkalmazás 99,9 százalékos 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 megfontolhatja az összetevőszintű célokat.
Kompromisszum: Elméleti eltérés lehet a számítási feladat összetevőinek technikai korlátai és az üzlet számára 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últerjeszkedése helyett próbálja meg gazdaságos, de értelmes módon megközelíteni.
Rendelkezésre állási metrikák
SLO-k és SLA-k
Az SLO egy számítási feladat vagy alkalmazás teljesítményének és megbízhatóságának mértéke. Az SLO egy konkrét, mérhető cél, amely meghatározott ügyfél-interakciókhoz van beállítva. Ez egy olyan cél, amelyet a számítási feladathoz vagy az alkalmazáshoz beállított azon szolgáltatásminőségre vonatkozóan, amelyet a felhasználóknak várhatóan kapniuk kell.
Az SLO számos metrika, például a rendelkezésre állás, a válaszidő, az átviteli sebesség, a sikerességi arány és más metrikák alapján határozható meg. Egy webszolgáltatás SLO-jának például az lehet az oka, hogy az adott hónap 99,9%-ában lesz elérhető a felhasználók számára, vagy hogy 500 ezredmásodpercen belül válaszol a kérések 95%-ára.
Mielőtt meghatározta az alkalmazáshoz vagy számítási feladathoz tartozó SLA-kat, tekintse át a Microsoft által közzétett SLA-kat azon mögöttes szolgáltatásokhoz, amelyeken az alkalmazás vagy a számítási feladat üzemel.
Feljegyzés
A Microsoft szolgáltatás SLA-k nem platform-SLA-k vagy SLO-k
Az egyes szolgáltatások SLA-jának áttekintése során ügyeljen arra, hogy mennyi redundanciára van szükség a magas SLA-k teljesítéséhez. A Microsoft például magasabb SLA-kat garantál az Azure Cosmos DB többrégiós üzemelő példányaihoz, mint az egyrégiós üzemelő példányok esetében.
Feljegyzés
Az Azure SLA-k nem mindig fedik le a szolgáltatás minden aspektusát. Például Azure-alkalmazás átjáró rendelkezésre állási SLA-val rendelkezik, de az Azure Web Application Firewall funkciója nem garantálja, hogy a rosszindulatú forgalom áthaladjon. 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.
Feljegyzés
Az alábbi példákban szereplő SLA-értékek hipotetikusak, és csak szemléltetésre 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ük például egy Azure-alkalmazás Service-webalkalmazást, amely az 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
Mi a maximális állásidő 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 lehetséges hibaponttal rendelkezik.
Az összetett SLA-t független tartalék útvonalak létrehozásával javíthatja. Ha például az SQL Database nem érhető el, helyezze a tranzakciókat egy későbbi feldolgozásra szánt üzenetsorba:
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 kompromisszumot jelent:
- Az alkalmazáslogika összetettebb.
- Az üzenetsorért fizetnie kell.
- 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:
N az egy régióban üzembe helyezett alkalmazás összetett SLA-ja.
R az alkalmazás üzembe helyezésének régióinak száma.
Annak várható esélye, 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
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ést is. Ennek a visszajelzésnek tájékoztatnia kell a célokat.
SLA-értékek
Az alábbi táblázat általános SLA-értékeket határoz 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. Előfordulhat, hogy a nem kritikus folyamatok olyan összetevőkkel rendelkeznek, 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.
Feljegyzés
Az ügyféloldali számítási feladatok és a belső használatú számítási feladatok különböző 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 ügyfélhez kapcsolódó számítási feladatok.
SLI-k
Az SLO-kat olyan összetevőszintű metrikáknak tekinti, amelyek hozzájárulnak az SLO-khoz. A legfontosabb SLA-k azok, amelyek az ügyfelek szempontjából befolyásolják a kritikus folyamatokat. Számos 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, hogy mikor kerül veszélybe egy SLO. 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, törekedjön három SLA-ra folyamatonként.
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üggenek nagy mértékben a Microsoft SLA-jától. A Microsoft csak bizonyos termékekre, például az SQL Database-re vonatkozóan 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éseken alapulnak. Mielőtt befejezi ezt a munkát, beszélje meg az érdekelt felekkel az aspirációs célokat, é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 érdekelt felekkel, 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 feladatok összetettebbé válhatnak 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.
Feljegyzé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 metrikához, csak az Ön felügyelete alatt álló összetevőkre terjedjen ki.
A helyreállítási célok meghatározásakor határozza meg a helyreállítási küszöbértékeket. Ha például egy webcsomópont 5 percnél hosszabb ideig nem érhető el, a rendszer automatikusan hozzáad egy új csomópontot a készlethez. Határozza meg az összes összetevő küszöbértékeit, figyelembe véve, hogy egy adott összetevő milyen helyreállítást igényel, beleértve a más összetevőkre és függőségekre 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 érdekelt felekkel a helyreállítási műveletek lehetséges kockázatait, például az adatvesztést vagy a munkamenetek megszakadását az ügyfelek számára.
Állapotmodell létrehozása
A megbízhatósági célokhoz összegyűjtött adatok használatával hozza létre az állapotmodellt az egyes számítási feladatokhoz és a kapcsolódó kritikus folyamatokhoz. Az állapotmodell a folyamatok és számítási feladatok kifogástalan, csökkentett és nem kifogástalan állapotát határozza meg. Az állapotok biztosítják a megfelelő üzemeltetési rangsorolást. Ezt a modellt forgalomirányító modellnek is nevezik. A modell zöldet rendel a kifogástalan állapothoz, sárga a csökkent, a pirosat pedig a nem megfelelő állapothoz. Az állapotmodell biztosítja, hogy tudja, mikor változik a folyamat állapota kifogástalan állapotról csökkentett vagy nem kifogástalan állapotra.
Az egészséges, a csökkentett és az egészségtelen állapotok meghatározá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 egészséges állapot azt jelzi, hogy a legfontosabb nem funkcionális követelmények és célok teljes mértékben teljesülnek, és az erőforrások optimális felhasználása. A kérések 95 százalékát például =500 ms-ban <dolgozzák fel az Azure Kubernetes Service (AKS) csomópontjának X százalékos kihasználtsága mellett.
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 teljesítménycsökkenés a megbízhatósági célok által megengedettnél tovább maradt fenn, vagy hogy a folyamat elérhetetlenné vált.
Feljegyzés
Az állapotmodell nem kezelheti az összes hibát ugyanazzal. 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 katasztrófaállapot között.
Ez a modell egy monitorozási és riasztási stratégia használatával működik, amelyet a folyamatos fejlesztés alapelvei alapján fejlesztettek ki és működtetnek. A számítási feladatok fejlődésével az állapotmodelleknek velük 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 állapotfigyelési útmutatót.
Vizualizáció
Annak érdekében, hogy az üzemeltetési csapatok és a számítási feladatok érintettjei 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 biztosítsa az általuk értékes és könnyen használható információkat. Előfordulhat, hogy a létrehozott jelentéseket hetente, havonta vagy negyedévente is látni szeretnék.
Az Azure megkönnyítése
Az Azure SLA-k biztosítják a Microsoft üzemidőre és kapcsolatra vonatkozó kötelezettségvállalásait. A különböző szolgáltatások különböző 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 olyan eljárásokat tartalmaz, amelyek segítségével szolgáltatási kreditet szerezhet, 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
- Jól megtervezett keretrendszer– kritikus fontosságú útmutató 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.