Javaslatok a hibamód-elemzés végrehajtásához
Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslat:
| RE:03 | Hibamód-elemzéssel (FMA) azonosíthatja és rangsorolhatja a megoldás összetevőiben előforduló lehetséges hibákat. Végezze el az FMA-t az egyes meghibásodási módok kockázatának és hatásának felméréséhez. Határozza meg, hogy a számítási feladat hogyan reagál és hogyan helyreáll. |
|---|
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 köszönhető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 zökkenőmentesen helyreálljon meghibásodás esetén.
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.
Meghatározások
| Időszak | Definíció |
|---|---|
| Hibaállapot | 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. |
| Kockázatcsökkentés | 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. |
Főbb tervezési stratégiá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. Ezek 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.
Kockázatcsökkentés
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.
Eredmény
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 naprakészek 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.
Az Azure Chaos Studio egy felügyelt szolgáltatás, amely a chaos engineering segítségével méri, értelmezi és javítja a felhőalkalmazások és szolgáltatások rugalmasságát.
Az FMA-alapelvek általános Azure-szolgáltatásokra való alkalmazásával kapcsolatos információkért tekintse meg az Azure-alkalmazások hibamódjának elemzését.
Példa
Az alábbi táblázat egy FMA-példát mutat be egy olyan e-kereskedelmi webhelyre, amely az Azure SQL-adatbázisokkal rendelkező Azure-alkalmazás szolgáltatáspéldányokon fut, é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 | Valószínűség | Effektus/Kockázatcsökkentés/Megjegyzés | Szolgáltatáskimaradás |
|---|---|---|---|---|
| Microsoft Entra ID | Szolgáltatáskimaradás | Alacsony | Teljes számítási feladatkimaradás. A Szervizelés a Microsofttól függ. | Teljes |
| Microsoft Entra ID | Hibás konfiguráció | Közepes | A felhasználók nem tudnak bejelentkezni. Nincs alsóbb rétegbeli hatás. Az ügyfélszolgálat a konfigurációs problémát jelenti az identitáscsoportnak. | Egyik sem |
| Azure Front Door | Szolgáltatáskimaradás | Alacsony | 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. | Egyik sem |
| Azure Front Door | Hibás konfiguráció | 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 | Alacsony | Teljes számítási feladatkimaradás. A Szervizelés a Microsofttól függ. | Teljes |
| 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 | Alacsony | Nincs hatás | Egyik sem |
| 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. | Lehetséges alacsony kockázat |
| App Service | Szolgáltatáskimaradás | Alacsony | Teljes számítási feladatkimaradás. A Szervizelés a Microsofttól függ. | Teljes |
| 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. | Egyik sem |
| App Service | Rendelkezésre állási zóna kimaradása | Alacsony | Nincs hatás. Az appszolgáltatások zónaredundánsként lettek üzembe helyezve. Zónaredundancia nélkül lehetséges a hatás. | Egyik sem |
| 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. | Egyik sem |
Kapcsolódó hivatkozások
Megbízhatósági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.