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élokat az üzleti érdekelt felekkel folytatott workshop-gyakorlatokból kell származtatnia. Ezután finomíthatja ezeket a célokat a számítási feladatok monitorozásával és tesztelésével.
Valós elvárásokat támaszthat a belső érdekelt felekkel a számítási feladatok megbízhatóságával kapcsolatban. Ezután szerződéses megállapodásokkal közölhetik 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 tudni, hogy az Ön által kitűzött 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é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, amelyet meghatározott ügyfél-interakciókhoz állít be. Ez egy olyan cél, amelyet a számítási feladathoz vagy az alkalmazáshoz állít be az ügyfelek által elvárt szolgáltatásminőség alapján. |
| Szolgáltatásszintű mutató (SLI) | A szolgáltatás teljesítményének egy adott aspektusának mennyiségi mérése. SLI-vel mérheti a számítási feladatok SLO-nak való megfelelését. |
| 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, amely alatt a számítási feladat megszakítás nélkül el tudja végezni a várt függvényt, amíg meg 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. |
Főbb tervezési stratégiák
A megbízhatósági célok a számítási feladatok kívánt minőségi célját képviselik, ahogyan azt a felhasználók és az üzleti érdekelt felek is megígérték. Ez a cél magában foglalja a számítási feladat rendelkezésre állását és helyreállíthatóságát is. Ne feledje, hogy a megbízhatósági célok eltérnek a teljesítménycéloktól, de a teljesítménycélokat a megbízhatósági célok közé kell foglalnia. Vegye figyelembe a következő megbízhatósági célokat:
A rendelkezésre állási célok határozzák meg a rendszer akadálymentes és működőképes maradására vonatkozó minőségi szabványokat. Ha nem felel meg ezeknek a szabványoknak, a rendszer megbízhatatlannak minősül. Az SLO-k segítségével ellenőrizheti, hogy a rendszer megfelel-e ezeknek a szabványoknak. Az üzleti és műszaki érdekelt felek együttműködve valós SLO-kat állíthatnak be, és figyelembe vehetnek olyan tényezőket, mint az összehasonlító elemzés, a felhasználói élmény és a számítási feladatok profilja.
A helyességi célok biztosítják, hogy a számítási feladat megfelelően, konzisztens minőségben végezze el a feladatait. A helyesség méréséhez számszerűsítse a számítási feladat mutatóit, hogy egységes, objektív pontszámban kombinálhassa őket.
A helyreállítási célok RTO-, RPO-, MTTR- és MTBF-metrikáknak felelnek meg, amelyek számszerűsítik a tervek hatékonyságát, valamint az üzletmenet-folytonossági és vészhelyreállítási tesztelés hatékonyságát.
A megbízhatósági célok meghatározásához az üzleti érdekelt felek széles körű követelményeket határoznak meg. Ezt követően a műszaki szakértők értékelik a számítási feladat aktuális állapotát, és monitorozással és riasztásokkal dolgoznak a célok elérésén és fenntartásán. Mindkét félnek meg kell egyeznie a reális célokról.
A felhasználói és rendszerfolyamatok azonosítása és pontszáma az üzleti követelmények szempontjából fontosságuk alapján. Ezekkel a pontszámokkal vezérelheti a számítási feladat tervezését, áttekintését, tesztelését és incidenskezelését. Állítson be megbízhatósági célokat ezekhez a folyamatokhoz, és ismerje meg, hogy ezeknek a céloknak a sikertelen teljesítése jelentős hatással lehet a vállalkozására.
Kompromisszum: Előfordulhat, hogy a rendszer technikai korlátai és üzleti hatása között van eltérés, például az átviteli sebesség és a másodpercenkénti tranzakciók között. A szakadék áthidalása nehéz lehet. A túlterjedés helyett gyakorlati és költséghatékony megoldást kell keresnie.
Rendelkezésre állási célkitűzések beállítása
A számítási feladatok teljes SLO-értéke a holisztikus minőséget tükrözi, beleértve az összes függőségét is. Az SLO érett deklarációjának az adott számítási feladat általános üzleti célját kell jeleznie, nem csupán a függőségek összetettségét. Ha például az ügyfelek 99,99%-os rendelkezésre állást várnak, a teljes SLO-nak erre a célra kell törekednie, még akkor is, ha egy rész csak 99,80%-ot ér el.
Az érdekelt felek értékelik az ügyfélélményt, és mérlegelik, hogy az állásidő milyen hatással van a bevételre. Összehasonlítják ezt a veszteséget az üzleti folyamat tervezésének és működtetésének költségével. A döntéshozók ezután eldöntik, hogy több pénzt kell-e költeniük a megbízhatóságra, hogy elkerüljék a bevételkiesést és fenntartsák a hírnevüket.
A számítási feladatok tulajdonosai pénzügyi célokat használnak a célkitűzések meghatározásához. Az üzleti követelmények mérhető metrikákra képezhetők le. A cél olyan tényezők azonosítása, amelyek befolyásolják az ügyfélélmény minőségét.
A számítási feladatok tervezői számos technikai döntést hoznak az SLO-k alapján. Az SLO-k a következőket tehetik:
Az architekturális döntések kritikus fontosságú bemenete, ha más függőségeket is figyelembe vesz.
Közel valós idejű nézet és a számítási feladatok állapotának közös megértése az objektív megbeszélések lehetővé tétele érdekében. Emellett segítenek a számítási feladatokért felelős csapatnak a megbízhatóság javítása és az új funkciók fejlesztése érdekében tett erőfeszítések rangsorolásában.
Az üzembehelyezési műveletek elsődleges jelzése, amely problémák esetén az automatikus visszaállítást vezérli, és ellenőrzi, hogy a módosítások a várt javulást érik-e el az ügyfélélményben.
Felgyorsíthatja a szervizelést és a helyreállítást azáltal, hogy a célkitűzésekre összpontosít, automatikusan értesíti az ügyfeleket a problémákról, és bizalmat épít ki a szervezet csapatai között.
Fontos
Ismernie kell az SLA-k és az SLO-k közötti különbséget. Bár az SLA-k és az SLO-k hasonló adatokat használhatnak vagy mutathatnak be, a szándékuk eltérő. Az SLA egy hivatalos szerződés a szervezet és ügyfelei között, és közvetlen pénzügyi és jogi következményekkel jár, ha a szervezet nem teljesíti az ígéretét. A szervezetek SLO-kkal értékelik, hogy a lehetséges állásidő a tűrhető korlátokon belül van-e.
Az SLA-k és az SLA-k üzleti kapcsolaton osztoznak, és egymástól függetlenül kell szabályozni. Ha az SLA üzleti taktikaként szolgál, a szervezet szándékosan magas értékre állíthatja az üzleti tulajdonos céljai alapján. Ezzel szemben az SLO-k magasabbak lehetnek. Tekintsük példaként a kritikus fontosságú számítási feladatokat. Ez a számítási feladatosztály nem engedheti meg magának a hosszú állásidőt, mert a hatások, beleértve a pénzügyi veszteséget és az emberi biztonságot fenyegető veszélyeket is jelentősek. Ezért az SLO-k általában 99,999%-os üzemidőt céloznak meg, amelyet általában öt kilencesnek neveznek. Ha az SLA-k nem felelnek meg ezeknek a céloknak, a szervezeteknek gyorsan reagálnia kell a hibák enyhítésére, és meg kell akadályozni a sikertelen SLA-k kimenetelét.
A cikkben szereplő példa magas SLA-t állít be az üzleti célok támogatására.
A felhőplatform- és technológiaszolgáltatók SLA-kat tesznek közzé ajánlataikban. Az SLO-k számítása során figyelembe kell vennie az SLO-kat, de az SLA hatókörének megértése nélkül ne használja őket. További információ: A Microsoft SLA-k hatásának felmérése.
Vegye figyelembe a gyakori SLO-kat és befolyásoló tényezőket
Minden SLO meghatározott minőségi kritériumokat céloz meg. A megbízhatóság érdekében vegye figyelembe ezeket a gyakori SLO-kat. Ez a lista nem teljes. SLO-kat adhat hozzá az üzleti követelményeknek megfelelően.
A sikerességi arány a kérések és folyamatok sikerességét méri azokhoz képest, amelyek hibát adnak vissza, vagy sikertelenek a feladatuk.
A késés azt az időtartamot méri, amely a műveletre vonatkozó kérés kezdeményezése és az eredmény rendelkezésre állása vagy a folyamat befejezése között van.
A kapacitás az egyidejű használatot méri, például a szabályozáson alapuló válaszok számát.
A rendelkezésre állás az ügyfelek szempontjából méri az üzemidőt.
Az átviteli sebesség a minimális adatátviteli sebességet méri egy bizonyos idő alatt. Az átviteli sebesség adatsebesség-egységként van mérve, például másodpercenkénti tranzakciók (TPS) vagy másodpercenkénti kérések (RPS).
Az Azure-beli számítási feladatok forgatókönyveinek és tűréseinek megismerése. Az Azure-szolgáltatások és az alkalmazásösszetevők egyaránt hatással vannak a számítási feladatok SLO-jára. A teljes SLO származtatásához egyesítse a következő táblázat válaszait. Ezeket a kérdéseket példákként használva értékelje ki a számítási feladat összetevőjének segédprogramját.
| Összetevők jellemzői | Interakció az ügyfelekkel | Egyéb tényezők |
|---|---|---|
| – Elérhetővé teszi a kérés- vagy válasz API-kat? – Rendelkezik lekérdezési API-kkal? - Ez egy számítási összetevő? - Ez egy feladatfeldolgozó összetevő? |
- Vezérlősík- és felügyeletisík-hozzáférés a nyilvános elérésű Azure-szolgáltatásokhoz. - Adatsík-hozzáférés, például létrehozási, olvasási, frissítési és törlési (CRUD) műveletek. |
– A kiadási folyamat állásidőt is magában foglal? - Mi a valószínűsége a hibák bevezetésének? Ha a számítási feladat más rendszerekkel integrálódik, érdemes megfontolnia az integrációs hibákat. – Hogyan befolyásolják az olyan rutinműveletek , mint a javítások a rendelkezésre állási célt? Figyelembe vesz partnerfüggőségeket? - Elegendő a személyzete ahhoz, hogy támogassa a folyamatos vészhelyzeti és vészhelyzeti biztonsági mentés ügyeleti rotációját? - Az alkalmazás zajos szomszédai vannak az Ön hatókörén kívül, ami fennakadásokat okozhat? |
Az SLO-hatókör meghatározása
Az SLO-kat különböző szinteken állíthatja be, például az egyes alkalmazásokhoz, számítási feladatokhoz vagy egy adott folyamathoz a rendszerben. Állítsa be a szintspecifikus SLO-kat, hogy az egyes összetevők fontossága alapján testre szabhassa az SLO-kat.
A szolgáltatott szoftver (SaaS) megoldásokban az ügyfélenkénti SLO-k mérése az egyes ügyfelek felhasználói élményének optimalizálása érdekében. Előfordulhat, hogy az ügyfelek különböző infrastruktúra-erőforrásokkal rendelkeznek a szegmenseikben. Ilyen esetekben nem feltétlenül van értelme egy olyan rendszerszintű SLO-nak, amely az összes erőforrást összesíti az ügyfélszegmensek között. Ehelyett olyan SLO-kat mérjen, amelyek igazodnak az egyes ügyfelek adott környezetéhez. További információ: Több-bérlős megoldás bérlői modelljei.
Összetett SLO-célok meghatározása
Az SLO-knak mérhetőnek és mérhetőnek kell lenniük egy megfigyelhetőségi ablakban.
Az SLO-k gyakran százalékok, például 99,90%, de lehetnek utasítások is. Mindkét módszerrel olyan numerikus értéket kaphat, amely az összes tényezőt tartalmazza.
Az SLO mérhető SLO-kból áll, amelyek elfogadható tényezőket határoznak meg. Az SLI-k meghatározott küszöbértékkel rendelkező metrikák, amelyek riasztást kaphatnak. Ezeket egy platformról vagy alkalmazásból gyűjtheti össze. A különböző összetevők releváns SLA-kat bocsátanak ki. Az SLO-k kiválasztásakor vegye figyelembe az SLO-t befolyásoló tényezőket.
Például egy válasz- és kérelem API-t használó folyamat SLO-jának kiszámításához mérje a kiszolgáló késését és a kérelmek feldolgozási idejét. Az átviteli sebesség és a hibaarányok nem vonatkoznak a folyamatos számítási környezetekre, például a virtuális gépekre, a méretezési csoportokra vagy az Azure Batchre.
A sík hozzáférésének szabályozásához vegye figyelembe az API-válaszok és a hosszú ideig futó műveletek, például az erőforrás-létrehozás hibaarányát és késését. Az adatsík-hozzáférés a használt API-któl függ, amelyek mindegyike saját SLO-célokkal rendelkezik.
Egy jó SLI megmutatja, hogy mikor törhet át egy SLO-t. Általában percentilisben mérik. Íme néhány gyakran használt percentilis és a várt rendelkezésre állás becsült meg nem felelési ideje.
| Cél | Meg nem felelőség hetente | Meg nem felelőség havonta | Meg nem felelőség évente |
|---|---|---|---|
| 99% | 1,68 óra | 7,20 óra | 3,65 nap |
| 99.90% | 10,10 perc | 43,20 perc | 8,76 óra |
| 99,95% | 5 perc | 21.60 perc | 4,38 óra |
| 99,99% | 1,01 perc | 4,32 perc | 52,56 perc |
| 99,999% | 6 másodperc | 25,90 másodperc | 5,26 perc |
Fontos
Az összetett SLO-érték a közreműködő tényezők termékeloszlása.
Egy összetett SLO például 99,95% × 99,99999% = ~99,95%.
Amikor összetett SLO-kat hoz létre a különböző folyamatokhoz, vegye figyelembe azok eltérő kritikusságát és relevanciáját. A folyamatok olyan összetevőket tartalmazhatnak, amelyeket nem kritikusnak tekint, és kihagyják a számításokat. A kihagyásukat azzal indokolhatja, hogy rövid elérhetetlenségük hatással van-e az ügyfél tapasztalatára. Bizonyos esetekben előfordulhat, hogy egy összetevő nem releváns az SLO-hoz megfontolandó használati eset szempontjából. Ezeket az összetevőket a számításból is kihagyhatja.
Ugyanez az elv vonatkozik a műveletekre is. Bizonyos műveletek kockázatot jelenthetnek, vagy hatással lehetnek az SLO-ra, mások pedig jelentéktelenek. A döntésnek explicitnek kell lennie, és konszenzusra kell épülnie.
Az SLO-k és SLI-k definiálásának és mérésének szemléltető példáját a Példa szakaszban találja.
A Microsoft SLA-k hatásának felmérése
A Microsoft SLA bemutatja, hogy a Microsoft mely területeken kötelezi el magát. A SLA-k nem garantálják az ajánlat egészét. Az SLA-k értékelésekor jól ismeri a közzétett percentilis körül biztosított lefedettséget.
Vegye figyelembe a Web Apps szolgáltatást, a Azure-alkalmazás Szolgáltatás egyik funkcióját. A szolgáltatás akkor tekinthető elérhetőnek, ha egy adott használati esetben 200 OK állapotot ad vissza. Ebben a konkrét kontextusban és időkeretben nem nyújt pénzügyileg támogatott garanciát az olyan funkciók rendelkezésre állására, mint az Easy Auth vagy a pontváltás. Érdemes megfontolni azokat a területeket, amelyek nem szerepelnek kifejezetten a megállapodásban, a platform legjobb erőfeszítései által elérhetőnek kell tekinteni.
Így ha a számítási feladat üzembehelyezési pontokra támaszkodik, az SLO nem származtatható kizárólag az App Service SLA-ból. Számítási feladatokért felelős csapatként az üzemidő rendelkezésre állásának fedezetét és előrejelzését kell elvégeznie. Ez az előrejelzés azonban bizonytalan lehet, ezért problémás lehet az SLO-nak a platform SLA-hoz való szoros csatlakoztatása.
Vegyünk egy másik példát. Ha az Azure Front Door 99,99%-os rendelkezésre állású, a tervnek meg kell felelnie a szerződésben közzétett konkrét feltételeknek. A háttérrendszernek például tartalmaznia kell a tárterületet, olyan műveletre van szüksége GET , amely legalább 50 KB méretű fájlt tud lekérni, és ügynököket kell üzembe helyeznie több helyen, legalább öt földrajzilag különböző helyen. Az Azure Front Door szűk használati esete nem garantálja az olyan funkciókat, mint a gyorsítótárazás, az útválasztási szabályok vagy a webalkalmazási tűzfal. Ezek a szempontok az SLA hatókörén kívül esnek.
Többrégiós célok megvalósítása
Megbízhatósági szempontból a többrégiós üzembe helyezés a redundancia elvének megvalósítása. A cél a regionális kimaradás vagy a teljesítménycsökkenés kockázatának csökkentése. Ez a stratégia, ha megfelelően van kialakítva, javíthatja az SLO-kat, mivel feladatátvételi célokra egy másodlagos régiót ad hozzá.
Két fő felhasználási eset létezik:
Magas rendelkezésre állási minta, amelyben a terhelést régiók között osztja el a nagyobb kapacitás érdekében. A magas rendelkezésre állás nem korlátozza a számítási feladatok felhasználóit egy régióra, és a teljes rendszer teljesítménye hozzájárul az SLO-hoz.
Válaszfalminta, amelyben az ügyfeleket adott régiókra korlátozza szegmentálásra. Ilyen esetekben a többrégiós üzemelő példányokat minden régióban külön üzemelő példányként vagy bélyegként kell kezelni. Az egyes bélyegek állapotát külön mérje meg a számítási feladatnak megfelelő SLI-kkel. Vegye figyelembe a teljes számítási feladat SLO-ját az egyes bélyegek állapota alapján. Ha feladatátvételt végezhet a bélyegek között, akkor a teljes számítási feladat SLO-értéke magasabb, mert az egyik bélyeg meghibásodása helyreállítható egy feladatátvétellel egy másik bélyegre.
Ügyeljen arra, hogy mennyi redundanciára van szükség a magas SLO-k eléré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.
Helyreállítási metrikák definiálása
A reális helyreállítási célok, például az RTO, az RPO, az MTTR és az MTBF metrikák definíciói a hibamód elemzésére, valamint az üzletmenet-folytonossági és vészhelyreállítási tervekre és tesztelésre támaszkodnak. A célok meghatározásakor vegye figyelembe a platform által biztosított helyreállítási garanciákat. A Microsoft csak bizonyos termékekre, például az Azure SQL Database-re vonatkozóan tesz közzé RTO- és RPO-garanciákat.
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 feladat összetettebbé válhat, amikor ügyfeleket ad hozzá, vagy amikor új technológiákat vezet be 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 platform (PaaS) vagy az SaaS-modellek a felhőszolgáltató értesítése nélkül meghiúsulhatnak és helyreállhatnak, és a folyamat teljesen átlátható lehet Az Ön vagy az ügyfelek számára. Ha célokat határoz meg ehhez a metrikához, csak az Ön felügyelete alatt álló összetevőkre terjedjen 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 percnél hosszabb ideig nem érhető el, automatikusan vegyen fel egy új csomópontot a készletbe. Határozza meg az összes összetevő küszöbértékeit, és gondolja át, hogy egy adott összetevő helyreállítása milyen hatással van, 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 é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.
A célok monitorozása és vizualizációja
A megbízhatósági célokhoz gyű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 állapot megváltozásakor a modellnek értesítenie kell a felelős feleket. Részletes tervezési szempontokért és javaslatokért tekintse meg az állapotmodellezési útmutatót.
Az üzemeltetési csapatok és a számítási feladatok érintettjeinek tájékoztatása érdekében hozzon létre egy vizualizációt, amely tükrözi a számítási feladatok állapotmodelljének valós idejű állapotát és általános trendjeit. A vizualizációs megoldások megvitatása az érdekelt felekkel annak biztosítása érdekében, hogy ön olyan információkat biztosítson, amelyeket értékelnek, és amelyeket könnyen felhasználhat. 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ékek különböző SLA-kkal rendelkeznek. További információ: SLA-k a online szolgáltatások.
Az Azure SLA szolgáltatáshitel beszerzésére szolgáló eljárásokat tartalmaz, ha a számítási feladat nem felel meg az SLA-nak, 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.
Ismerkedjen meg a vizualizációs rendszer Azure Monitor-irányítópultjaival.
Példa
A Contoso, Ltd. új mobilélményt tervez az eseményjegy-kezelő rendszeréhez. Itt található a magas szintű architektúra.
A Grafana embléma a megfelelő vállalat védjegye. A védjegy használata nem utal jóváhagyásra.
Összetevők
Íme néhány összetevő, amely az SLO-definíció fogalmát szemlélteti. Az architektúra olyan összetevőket tartalmaz, amelyek nem szerepelnek az alábbi listában. Például annak ellenére, hogy a Key Vault a kritikus kérések folyamatának része, nem része a válaszhasználati esetnek. Ha a Key Vault nem érhető el, az alkalmazás továbbra is működik az indítás során betöltött titkos kulcsok használatával. Ha azonban az alkalmazást skálázni kell, a Key Vault rendelkezésre állása kritikus fontosságúvá válik, mivel az új csomópontokat titkos kódokkal kell betölteni. Ebben a példában a skálázási műveletek nem tekinthetők meg. A rendszer kihagy más összetevőket a rövidség kedvéért.
Az Azure Front Door az egyetlen belépési pont, amely egy OLYAN API-t tesz elérhetővé, amelyet az ügyfelek kérések küldéséhez használnak.
Az Azure Container Apps az a környezet, amelyet a számítási feladatokért felelős csapat birtokol és használ az alkalmazás üzleti logikájának futtatásához.
A felügyelt SQL-példányt egy másik csapat birtokolja és felügyeli, és a számítási feladat kritikus függősége.
Az Azure Private Link privát kapcsolatot biztosít az Azure Front Door és a Container Apps üzemelő példányai között. A felügyelt SQL-példány privát végponton keresztül is elérhető az alkalmazás számára.
Ebben az architektúrában az API-csapat meghatároz egy kezdeti SLO-célt az alkalmazásban lévő kritikus folyamatokhoz. Az SLO-kat befolyásoló tényezőkben leírt stratégiát fogadják el. Céljuk, hogy olyan célkitűzéseket határozzanak meg, amelyek lefedik az alapvető funkciókat anélkül, hogy túlzottan hangsúlyozzák a kiegészítő funkciókat. Három kritikus felhasználói folyamat állapotát mérik, amelyek az összes alapvető felhőfunkciót magukban foglalják, és kódot hajtanak végre az üzemelő példányok között. Ezek a folyamatok azonban nem fedik le az összes kódot vagy adathozzáférést. Íme a befolyásoló tényezők.
Összetett SLO kiszámítása
Azure rendelkezésre állási SLO: Az Azure-hoz készült pénzügyi kötelezettségvállalási SLA proxyként szolgál a platform megbízhatóságának felméréséhez.
Azure-összetevő Alkalmazható SLA-lefedettség Az SLA nem fedi le Módosított SLO Azure Front Door 99,99% a sikeres HTTP-műveletekhez GETGyorsítótárazás, szabálymotor 99.98% Container Apps 99,95% a beépített bejövő forgalom által elérhető üzembe helyezett alkalmazások alapján Automatikus skálázás, jogkivonattár képességei 99,95% SQL Managed Instance 99,99% az SQL Server-példányhoz való kapcsolat alapján Teljesítmény, adatmegőrzés 99.80% Private Link 99,99% egész perc alapján, amikor a privát végpont hálózata nem fogadta el a forgalmat, vagy ha a forgalom nem áramlott a végpont és a Private Link szolgáltatás között Egy percnél rövidebb ideig tartó egyéni hibák 99,99% A módosítás több tényezőn alapul, amelyek a számítási feladatok csapatának a célkitűzéseknek való ígéretétől függnek. Az egyik tényező lehet a platform képességeinek megbízhatósága a korábbi tapasztalatok alapján. A Container Apps és a Private Link esetében például a csapat úgy érzi, hogy az SLA-értéket a lehető legnagyobb biztonságban érzi.
Vannak árnyalt tényezők is. A csapat például 99,80%-ra csökkenti a felügyelt SQL-példány SLO-értékét, hogy figyelembe vegyék az adatműveleteik esetleges hibáit, például a sémamódosításokat és a biztonsági mentéseket.
A csapat az összetett SLO-t az egyes, igazított SLO-értékek hatásának kiszámításával állítja be. Ez az érték 99,72%.
Vannak más közreműködő tényezők is. Az architektúra olyan Azure-hálózati összetevőkre támaszkodik, mint például a virtuális hálózatok és a közzétett SLA-val nem rendelkező hálózati biztonsági csoportok (NSG-k). A számítási feladatokért felelős csapat úgy dönt, hogy figyelembe veszi ezeket a tényezőket, amelyek minden összetevőhöz 99,99%-os rendelkezésre állással rendelkeznek.
A platform előrejelzett rendelkezésre állásán alapuló összetett SLO: havonta 99,68%.
Alkalmazáskód SLO: A csapat elismeri, hogy az alkalmazáskódban vagy a tárolt eljárásokban található hibák hatással lehetnek a rendszer rendelkezésre állására, és havi egyórás állásidőt osztanak ki a kóddal kapcsolatos hibák figyelembe vételéhez.
Gyakori állásidő-percentilisekkel becsülik meg az SLO-t olyan egyedi tényezőkre, mint a kódhibák, a skálázási problémák és más kódokkal kapcsolatos szempontok.
A kód és az adatok rendelkezésre állásán alapuló összetett SLO: havonta 99,86%.
Erőforrás- és alkalmazáskonfigurációs SLO: A csapat felismeri, hogy a felhőbeli erőforrásokat és az alkalmazáskódot megfelelően kell konfigurálni. Ez a cél magában foglalja az automatikus skálázási szabályok beállítását, az NSG-szabályok üzembe helyezését és a termékváltozatok megfelelő méretének kiválasztását. A konfigurációs hibák figyelembevétele érdekében 10 perces havi állásidőt ütemeznek, ami körülbelül 99,98%-os rendelkezésre állás.
Összetett SLO a konfiguráció rendelkezésre állása alapján: 99,95% havonta.
Üzemeltetési SLO: A számítási feladatok csapata a jól megtervezett keretrendszer működési kiválósági alapelveinek követésével fejleszti ki a jó DevOps-kultúrát. Felhőbeli erőforrásokat, konfigurációt és kódot helyeznek üzembe minden futamban.
A csapat kockázatnak tekinti az üzembe helyezéseket, mert destabilizálhatják a futó rendszert. A TLS-tanúsítványfrissítések, DNS-módosítások vagy eszközhibák miatt előfordulhatnak hibák. A csapat emellett a vészhelyzeti javítások által okozott lehetséges állásidőt is figyelembe veszi. Összesen 20 perces havi állásidőt ütemeznek, ami körülbelül 99,95%-os rendelkezésre állás.
A karbantartási időszakok olyan időszakok, amelyek során a rendszer karbantartása vagy frissítése történik. Az API többnyire naponta körülbelül négy órán át nem használható. Az elérhetetlenség kockázatának csökkentése érdekében a csapat karbantartási feladatokat ütemezhet a kevésbé aktív órákban. Ez a megközelítés magasabb SLO-t eredményez, de a csapat úgy dönt, hogy nem foglalja bele a karbantartási időszakot az SLO-ba.
Összetett SLO a műveletek rendelkezésre állása alapján: 99,95% havonta.
Külső függőségek SLO: A csapat elsődleges függőségnek tekinti a felügyelt SQL-példányt, amely már 99,80%-os rendelkezésre állással rendelkezik a teljes platform rendelkezésre állásában. A rendszer nem veszi figyelembe a többi külső függőséget.
Külső függőségeken alapuló összetett SLO: Nem alkalmazható.
A teljes összetett SLO-eredmény meghatározása
A teljes összetett SLO-célérték 99,45%, ami körülbelül négy órányi állásidőnek felel meg havonta.
Ha havonta csak négy órányi elérhetetlenségi SLO-célt szeretne teljesíteni, a számítási feladatokat kezelő csapat ügyeleti rotációt hoz létre. Az ügyféltámogatás és a szintetikus tranzakciók monitorozása is meghívhatja a helyszíni megbízhatósági mérnöki (SRE) támogatást, hogy azonnal elindítsa a helyreállítási lépéseket az SLO-problémák megoldásához.
A számítási feladat SLA-jának beállítása
A számítási feladat SLA-ja havonta 99,90%-os rendelkezésre állású.
A számítási feladatokért felelős csapat jogi és pénzügyi részlegei havonta 99,90%-os rendelkezésre állási rendelkezésre állásra állítják be a számítási feladatra vonatkozó SLA-t, amely meghaladja a 99,45%-os SLO-célt. Ezt a döntést azután hozzák meg, hogy egy vonzó SLA alapján elemzik a pénzügyi kifizetéseket és az előre jelzett ügyfélnövekedést. Az SLA két alapvető felhasználói folyamatot fed le, és teljesítménybeli szempontokat is tartalmaz, nem csak a rendelkezésre állást. Ez egy számított kockázat, amelyet az üzleti csapat vállal az üzlet érdekében, és a mérnöki csapat tisztában van a kötelezettségvállalással.
A helyességi SLO beállítása
Az alkalmazás alapvető felhasználói folyamatainak elérhetőnek és használhatónak, vagy akár versenyképesnek kell lenniük. A csapat kifejezetten az API-hoz állít be válaszidő-SLO-t, kivéve az ügyfélfeldolgozási időt és az internetes hálózati bejárást. Ezt az SLO-t csak a rendelkezésre állási időszakokban értékelik ki. A 75. percentilist választják az SLO-célként és a teljesítménymérésként is, amely rögzíti a tipikus ügyfélélményt, és kizárja a legrosszabb eseteket.
Kapcsolódó hivatkozások
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.