Architektúrastratégiák a hibamód-elemzés végrehajtásához

Az Azure Well-Architected-keretrendszer megbízhatósági ellenőrzőlistájára vonatkozó javaslat:

RE:03	Hibamód-elemzéssel (FMA) azonosíthatja a számítási feladat lehetséges hibáit. Azonosítsa a függőségeket és a hibapontokat, és dolgozzon ki kockázatcsökkentési stratégiákat ezekhez a hibákhoz.

Ez az útmutató a számítási feladat hibamód-elemzésének (FMA) elvégzésére vonatkozó ajánlott eljárásokat ismerteti. Az FMA az a gyakorlat, amely azonosítja a lehetséges meghibásodási pontokat a számítási feladatban és a kapcsolódó folyamatokban, és ennek megfelelően tervezi a kockázatcsökkentési műveleteket. A folyamat minden lépésénél azonosítja a több hibatípus robbanási sugarát, amely segít új számítási feladatok tervezésében vagy meglévő számítási feladatok újrabontásában a hibák széles körű hatásának minimalizálása érdekében.

Az FMA egyik legfontosabb eleme, hogy a hibák attól függetlenül történnek, hogy hány rugalmassági réteget alkalmaz. Az összetettebb környezetek több típusú meghibásodásnak vannak kitéve. Ennek a valóságnak megfelelően az FMA lehetővé teszi, hogy a számítási feladatot úgy tervezze meg, hogy ellenálljon a legtöbb hibatípusnak, és a meghatározott helyreállítási célkitűzéseken belül zökkenőmentesen helyreálljon.

Ha teljes egészében kihagyja az FMA-t, vagy hiányos elemzést végez, a számítási feladat ki van téve a nem előre nem meghatározott viselkedésnek és a nem optimális kialakítás által okozott lehetséges kimaradásoknak.

Definíciók

Időszak	Definition
Hiba mód	Olyan problématípus, amely egy vagy több számítási feladat összetevőjének romlását vagy súlyosan érintettségét okozhatja a elérhetetlenségig.
Mitigation	Azok a tevékenységek, amelyeket ön azonosított a problémák proaktív vagy aktív kezelése érdekében.
Észlelés	Az infrastruktúra, az adatok és az alkalmazások monitorozása és riasztási folyamatai és eljárásai.

Megjegyzés:

A hibák megkülönböztetése a hibáktól. A hiba olyan váratlan esemény egy rendszeren belül, amely megakadályozza, hogy a rendszer továbbra is megfelelően működjön. Például egy hálózati partíciót okozó hardverhiba kudarc. A hibák általában beavatkozást vagy adott kialakítást igényelnek az adott hibaosztályhoz. Ezzel szemben a hibák a normál műveletek elvárt részét képezik, a rendszer azonnal kezeli, és egy hiba után a rendszer továbbra is ugyanazon a kapacitáson fog működni. A bemeneti ellenőrzés során felfedezett hibák például üzleti logikával kezelhetők.

Tekintse át és implementálja a folyamatok azonosítására vonatkozó javaslatokat. Feltételezzük, hogy a kritikusság alapján azonosította és rangsorolja a felhasználói és rendszerfolyamatokat.

Az összegyűjtött adatok és a munkában létrehozott összetevők konkrét leírást nyújtanak a folyamatok során érintett adatútvonalakról. Az FMA-munka sikeressége érdekében az összetevők pontossága és alapossága kritikus fontosságú.

A kritikus folyamatok meghatározása után megtervezheti a szükséges összetevőket. Ezután kövesse az egyes folyamatokat lépésről lépésre a függőségek azonosításához, beleértve a külső szolgáltatásokat és a lehetséges meghibásodási pontokat, és tervezze meg a kockázatcsökkentési stratégiákat.

A számítási feladat felbontása

Az ideációról a tervezésre való áttérés során azonosítania kell a számítási feladat támogatásához szükséges összetevőtípusokat. A számítási feladat határozza meg azokat a szükséges összetevőket, amelyekhez terveznie kell. Általában terveznie kell a bejövő forgalom vezérlését, a hálózatkezelést, a számítást, az adatokat, a tárolást, a támogató szolgáltatásokat (például hitelesítést, üzenetkezelést, titkos vagy kulcskezelést) és a kimenő forgalom vezérlését. A tervezési munka ezen szakaszában előfordulhat, hogy nem ismeri azokat a technológiákat, amelyeket üzembe fog helyezni, így a tervezés az alábbi példához hasonlóan nézhet ki.

A kezdeti architektúraterv létrehozása után átfedheti a folyamatokat, hogy azonosítsa az ezekben a folyamatokban használt különálló összetevőket, és listákat vagy munkafolyamat-diagramokat hozzon létre, amelyek a folyamatokat és azok összetevőit írják le. Az összetevők kritikusságának megértéséhez használja a folyamatokhoz rendelt kritikussági definíciókat. Fontolja meg, hogy egy összetevő meghibásodása milyen hatással van a folyamatokra.

Függőségek azonosítása

Azonosítsa a számítási feladatok függőségeit az egyetlen hibapont-elemzés végrehajtásához. A számítási feladatok felbontása és a folyamatok felülírása betekintést nyújt a számítási feladaton belüli és kívüli függőségekbe.

A belső függőségek olyan összetevők a számítási feladat hatókörében, amelyek szükségesek a számítási feladat működéséhez. A tipikus belső függőségek közé tartoznak az API-k vagy a titkos kulcsok/kulcskezelési megoldások, például az Azure Key Vault. Ezekhez a függőségekhez rögzítse a megbízhatósági adatokat, például a rendelkezésre állási SLA-kat és a skálázási korlátokat. A külső függőségek olyan szükséges összetevők, amelyek nem tartoznak a számítási feladat hatókörébe, például egy másik alkalmazás vagy külső szolgáltatás. A tipikus külső függőségek közé tartoznak a hitelesítési megoldások, például a Microsoft Entra ID és a felhőkapcsolati megoldások, például az Azure ExpressRoute.

Azonosíthatja és dokumentálhatja a számítási feladat függőségeit, és belefoglalhatja őket a folyamatdokumentáció összetevőibe.

Hibapontok kiértékelése

A számítási feladatok kritikus folyamataiban vegye figyelembe az egyes összetevőket, és állapítsa meg, hogy az összetevőt és függőségeit hogyan befolyásolhatja egy hibamód. Ne feledje, hogy a rugalmasság és a helyreállítás tervezésekor számos hibamódot kell figyelembe venni. Bármely összetevőt egyszerre több meghibásodási mód is érinthet. Fontolja meg külön az olvasási és írási hibákat, mert a hatás és a lehetséges kockázatcsökkentési lépések eltérőek. A hibamódok a következők:

• Regionális kimaradás. Egy teljes Azure-régió nem érhető el.

• Rendelkezésre állási zóna kimaradása. Az Azure rendelkezésre állási zónája nem érhető el.

• Szolgáltatáskimaradás. Egy vagy több Azure-szolgáltatás nem érhető el.

• Elosztott szolgáltatásmegtagadás (DDoS) vagy más rosszindulatú támadás.

• Alkalmazás vagy összetevő helytelen konfigurálása.

• Operátorhiba.

• Tervezett karbantartási leállás.

• Összetevő túlterhelése.

Az elemzésnek mindig az elemezni kívánt folyamat kontextusában kell lennie, ezért mindenképpen dokumentálja a felhasználóra gyakorolt hatást és a folyamat várható eredményét. Ha például egy e-kereskedelmi alkalmazással rendelkezik, és az ügyfélfolyamatot elemzi, egy adott hibamód egy vagy több összetevőre gyakorolt hatása lehet, hogy az összes ügyfél nem tudja befejezni a kivételt.

Vegye figyelembe az egyes hibamódok valószínűségét. Néhány nagyon valószínűtlen, például a többzónás vagy többrégiós kimaradások, és a redundancián túli kockázatcsökkentési tervezés nem jó erőforrás- és időfelhasználás.

Mitigation

A kockázatcsökkentési stratégiák két széles kategóriába sorolhatók: a nagyobb rugalmasság és a teljesítmény romlása érdekében történő tervezés.

A rugalmasság növelése magában foglalja a redundancia hozzáadását az összetevőkhöz, például az infrastruktúrához, az adatokhoz és a hálózatkezeléshez, valamint annak biztosítását, hogy az alkalmazás kialakítása kövesse a tartósságra vonatkozó ajánlott eljárásokat, például a monolitikus alkalmazások izolált alkalmazásokra és mikroszolgáltatásokra való lebontását. További információt a redundanciára vonatkozó javaslatok és az önmegőrzésre vonatkozó javaslatok című témakörben talál.

Ha csökkentett teljesítményre szeretne tervezni, azonosítsa azokat a lehetséges meghibásodási pontokat, amelyek letilthatják a folyamat egy vagy több összetevőjét, de ne tiltsa le teljesen ezt a folyamatot. A végpontok közötti folyamat működésének fenntartásához előfordulhat, hogy át kell irányítania egy vagy több lépést más összetevőkre, vagy el kell fogadnia, hogy egy hibás összetevő futtat egy függvényt, így a függvény már nem érhető el a felhasználói felületen. Ha vissza szeretne térni az e-kereskedelmi alkalmazás példájához, előfordulhat, hogy egy hibás összetevő, például egy mikroszolgáltatás miatt a javaslati motor nem érhető el, de az ügyfelek továbbra is kereshetnek termékeket, és végrehajthatják a tranzakciójukat.

A függőségek körül is terveznie kell a kockázatcsökkentést. Az erős függőségek kritikus szerepet játszanak az alkalmazásfüggvényekben és a rendelkezésre állásban. Ha hiányoznak, vagy hibás működést tapasztalnak, jelentős hatásuk lehet. A gyenge függőségek hiánya csak bizonyos funkciókat érinthet, és nem befolyásolhatja a teljes rendelkezésre állást. Ez a különbség a szolgáltatás és függőségei közötti magas rendelkezésre állási kapcsolat fenntartásának költségeit tükrözi. A függőségek besorolása erős vagy gyenge, így könnyebben azonosíthatja, hogy mely összetevők nélkülözhetetlenek az alkalmazáshoz.

Ha az alkalmazás olyan erős függőségekkel rendelkezik, amelyek nélkül nem tud működni, ezeknek a függőségeknek a rendelkezésre állási és helyreállítási céljainak összhangban kell lennie az alkalmazás céljaival. A függőségek minimalizálása az alkalmazások megbízhatóságának szabályozásához. További információ: Az alkalmazásszolgáltatások közötti koordináció minimalizálása a méretezhetőség érdekében.

Ha az alkalmazás életciklusa szorosan kapcsolódik a függőségei életciklusához, az alkalmazás működési rugalmassága korlátozott lehet, különösen az új kiadások esetében.

Észlelés

A hibaészlelés elengedhetetlen annak biztosításához, hogy megfelelően azonosította a hibapontokat az elemzésben, és megfelelően megtervezhesse a kockázatcsökkentési stratégiákat. Ebben a kontextusban az észlelés az infrastruktúra, az adatok és az alkalmazás monitorozását, valamint a problémák esetén történő riasztást jelenti. A lehető legnagyobb mértékben automatizálhatja az észlelést, és redundanciát építhet be a műveleti folyamatokba, így biztosítva, hogy a riasztások mindig le legyenek kapva, és elég gyorsan reagáljanak az üzleti követelményeknek való megfeleléshez. További információkért tekintse meg a figyelésre vonatkozó javaslatokat.

Outcome

Az elemzés eredményéhez hozzon létre egy dokumentumkészletet, amely hatékonyan közli az eredményeket, a folyamat összetevőihez és a kockázatcsökkentéshez kapcsolódó döntéseket, valamint a hiba számítási feladatra gyakorolt hatását.

Az elemzés során rangsorolja a súlyosság és a valószínűség alapján azonosított hibamódokat és kockázatcsökkentési stratégiákat. Ezzel a rangsorolással a dokumentációt azokra a gyakori és súlyos meghibásodási módokra összpontosíthatja, amelyek elegendő időt, erőfeszítést és erőforrást igényelnek a kockázatcsökkentési stratégiák megtervezésére. Előfordulhatnak például olyan hibamódok, amelyek előfordulása vagy észlelése során nagyon ritkán fordul elő. A körülöttük lévő kockázatcsökkentési stratégiák tervezése nem éri meg a költségeket.

A dokumentáció kiindulópontját az alábbi példatáblában találja.

A kezdeti FMA-gyakorlat során az ön által készített dokumentumok többnyire elméleti tervezést fognak végezni. Az FMA-dokumentumokat rendszeresen felül kell vizsgálni és frissíteni kell annak biztosítása érdekében, hogy up-to-date állapotban maradjanak a számítási feladattal. A káosztesztelés és a valós élmények segítenek az elemzések időbeli finomításában.

Az Azure megkönnyítése

Az Azure Monitor és a Log Analytics használatával észlelheti a számítási feladatokkal kapcsolatos problémákat. Az infrastruktúrával, alkalmazásokkal és adatbázisokkal kapcsolatos problémák további megismeréséhez használjon olyan eszközöket, mint az Application Insights, a Container Insights, a Network Insights, a VM Insights és az SQL Insights.

Azure Chaos Studio egy olyan felügyelt szolgáltatás, amely káosztechnikát használ a felhőalkalmazások és -szolgáltatások rugalmasságának méréséhez, megértéséhez és javításához.

Az Azure Network Watcher kapcsolatfigyelő és kapcsolati hibaelhárításának használatával modellezheti és ellenőrizheti a hálózati kapcsolati forgatókönyveket az üzembe helyezés előtt. A szintetikus tesztek szimulálásával és a lehetséges útválasztási útvonalak hibaelhárításával ezek az eszközök segítenek a hálózati architektúra lehetséges meghibásodási módainak előrejelzésében és dokumentálásában. Emellett a korábbi virtuális hálózati forgalmi naplók forgalomelemzéssel történő elemzésével azonosíthatja a blokkolt vagy rendellenes forgalom mintáit, amelyek az FMA dokumentációját az Azure-infrastruktúrában tájékoztathatják.

Example

Az alábbi táblázat egy FMA-példát mutat be egy olyan e-kereskedelmi webhelyre, amely Azure App Service-példányokon és Azure SQL-adatbázisokkal van üzemeltetve, és amelyet az Azure Front Door használ.

Felhasználói folyamat: Felhasználói bejelentkezés, termékkeresés és bevásárlókocsi-interakció

Összetevő	Kockázat	Likelihood	Effektus/Kockázatcsökkentés/Megjegyzés	Outage
Microsoft Entra ID	Szolgáltatáskimaradás	Low	Teljes számítási feladatkimaradás. A Szervizelés a Microsofttól függ.	Full
Microsoft Entra ID	Misconfiguration	Közepes	A felhasználók nem tudnak bejelentkezni. Nincs alsóbb rétegbeli hatás. A kód kifogja a hitelesítési kivételeket. Az ügyfélszolgálat a fejlesztési csapatnak jelenti a konfigurációs problémát.	Csak külső
Azure Front Door	Szolgáltatáskimaradás	Low	Teljes kimaradás külső felhasználók számára. A Szervizelés a Microsofttól függ.	Csak külső
Azure Front Door	Regionális kimaradás	Nagyon alacsony	Minimális hatás. Az Azure Front Door egy globális szolgáltatás, így a globális forgalomirányítás nem érintett Azure-régiókon keresztül irányítja a forgalmat.	None
Azure Front Door	Misconfiguration	Közepes	A helytelen konfigurációkat az üzembe helyezés során kell elkapni. Ha ezek egy konfigurációs frissítés során történnek, a rendszergazdáknak vissza kell állítaniuk a módosításokat. A konfigurációfrissítés rövid külső kimaradást okoz.	Csak külső
Azure Front Door	DDoS-támadás	Közepes	A fennakadás lehetősége. A Microsoft kezeli a DDoS (L3 és L4) védelmét, és az Azure Web Application Firewall blokkolja a legtöbb fenyegetést. Az L7-támadások lehetséges hatásának kockázata.	Részleges kimaradás lehetősége
Azure SQL	Szolgáltatáskimaradás	Low	Teljes számítási feladatkimaradás. A Szervizelés a Microsofttól függ.	Full
Azure SQL	Regionális kimaradás	Nagyon alacsony	Az automatikus feladatátvételi csoport átkerül a másodlagos régióba. Lehetséges kimaradás a feladatátvétel során. A megbízhatósági tesztelés során meghatározandó helyreállítási időkorlátok (RTO-k) és helyreállításipont-célkitűzések (RRP-k).	Lehetséges teljes
Azure SQL	Rendelkezésre állási zóna kimaradása	Low	Nincs effektus	None
Azure SQL	Rosszindulatú támadás (injektálás)	Közepes	Minimális kockázat. Minden Azure SQL-példány virtuális hálózathoz kötött magánvégpontokon keresztül, és a hálózati biztonsági csoportok (NSG-k) további virtuális hálózatvédelmet nyújtanak.	Alacsony kockázat, részleges kimaradás lehetősége
App Service	Szolgáltatáskimaradás	Low	Teljes számítási feladatkimaradás. A Szervizelés a Microsofttól függ.	Full
App Service	Regionális kimaradás	Nagyon alacsony	Minimális hatás. A tényleges régiókban lévő felhasználók késése. Az Azure Front Door automatikusan átirányítja a forgalmat nem érintett régiókba.	None
App Service	Rendelkezésre állási zóna kimaradása	Low	Nincs hatása. Az appszolgáltatások zónaredundánsként lettek üzembe helyezve. Zónaredundancia nélkül lehetséges a hatás.	None
App Service	DDoS-támadás	Közepes	Minimális hatás. A bejövő forgalmat az Azure Front Door és az Azure Web Application Firewall védi.	None

Kapcsolódó hivatkozás

• Rugalmasság és függőségek

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

Tekintse meg a javaslatok teljes készletét.

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