Javaslatok a hibamód-elemzés végrehajtásához
Erre az Azure Well-Architected Framework megbízhatósági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
| RE:03 | A hibamód-elemzés (FMA) használatával 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 fő 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 hibatípusnak vannak kitéve. Ennek a valóságnak megfelelően az FMA lehetővé teszi a számítási feladatok tervezését, hogy ellenálljanak a legtöbb hibatípusnak, és zökkenőmentesen helyreálljanak 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 kiszámíthatatlan viselkedésnek és a nem optimális kialakítás által okozott esetleges kimaradásoknak.
Definíciók
| Időszak | Definíció |
|---|---|
| Hibaállapot | Olyan problématípus, amely miatt egy vagy több számítási feladat-összetevő leromlott vagy súlyosan érintett a elérhetetlenségig. |
| Kockázatcsökkentés | A problémák proaktív vagy újraaktív megoldásához azonosított tevékenységek. |
| Észlelés | Az infrastruktúra, az adatok és az alkalmazásfigyelési és riasztási folyamatok és eljárások. |
Fő tervezési stratégiák
Előfeltételek
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 rangsorította 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ú.
FMA-megközelítés
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 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), valamint a kimenő forgalom vezérlését. A tervezési munka ezen szakaszában előfordulhat, hogy nem ismeri az üzembe helyezni kívánt technológiákat, í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 diszkrét ö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. Vegye figyelembe, 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 feladat felbontása és a folyamatok túlterhelése betekintést nyújt a számítási feladat belső és külső függőségeibe.
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/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 a számítási feladat hatókörén kívül eső szükséges összetevők, 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
A számítási feladat kritikus folyamataiban vegye figyelembe az egyes összetevőket, és határozza meg, hogy az összetevőt és függőségeit hogyan érintheti egy meghibásodási mó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 egynél több meghibásodási mód is érinthet egy adott időpontban. 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ációja.
Operátorhiba.
Tervezett karbantartás kimaradása.
Ö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árt eredményét. Ha például egy e-kereskedelmi alkalmazással rendelkezik, és az ügyfélfolyamatot elemzi, egy adott hibamód hatása egy vagy több összetevőre az 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 kockázatcsökkentési tervezés redundancia utáni hozzáadása nem jó erőforrás- és időhasználat.
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 csökkentett teljesítmény é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 a tartósságra vonatkozó ajánlott eljárásokat kövesse, például a monolitikus alkalmazásokat elkülönített alkalmazásokra és mikroszolgáltatásokra bontsa. További információt a redundanciára vonatkozó javaslatok és az önmegőrzésre vonatkozó javaslatok című témakörben talál.
A csökkentett teljesítmény kialakításához azonosítsa azokat a lehetséges meghibásodási pontokat, amelyek letilthatják a folyamat egy vagy több összetevőjét, de nem tiltják le teljesen 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 meghibásodott ö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 elérhetetlenné teheti a javaslati motort, de az ügyfelek továbbra is kereshetnek termékeket, és végrehajthatják a tranzakciójukat.
A függőségekkel kapcsolatos kockázatcsökkentést is meg kell terveznie. Az erős függőségek kritikus szerepet játszanak az alkalmazásfüggvényben és a rendelkezésre állásban. Ha hiányoznak, vagy hibás működést tapasztalnak, jelentős hatása lehet. A gyenge függőségek hiánya csak bizonyos funkciókat érinthet, és nem befolyásolja a teljes rendelkezésre állást. Ez a különbségtétel 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. Sorolja be a függőségeket erősnek vagy gyengenek, hogy megállapíthassa, mely összetevők szükségesek 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 igazodniuk kell az alkalmazás céljaihoz. A függőségek minimalizálása az alkalmazás 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 az összefüggésben 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. Automatizálja a lehető legnagyobb mértékben az észlelést, és építsen redundanciát az üzemeltetési folyamatokba, 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ót a Figyelési javaslatok című témakörben talál.
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őivel és kockázatcsökkentésével kapcsolatos döntéseket, valamint a hiba hatását a számítási feladatra.
Az elemzésben 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őek ahhoz, hogy időt, energiát és erőforrásokat költsenek a kockázatcsökkentési stratégiák megtervezésére. Előfordulhat például, hogy vannak olyan hibamódok, amelyek előfordulása vagy észlelése nagyon ritka. 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 a létrehozott 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.
Azure-beli facilitálás
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 káosztechnikát használja 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 FMA-alapelvek gyakori Azure-szolgáltatásokra való alkalmazásáról az Azure-alkalmazások meghibásodási módelemzése című témakörben olvashat bővebben.
Példa
Az alábbi táblázat egy FMA-példát mutat be egy olyan e-kereskedelmi webhelyre, amely Azure App Service Azure SQL adatbázisokkal rendelkező példányokon üzemel, és amelyet az Azure Front Door előtérként 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ége | Hatás/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. | Összes |
| 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ásért felelős csapatnak. | None |
| 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 üzemkimaradá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 | Hibás konfiguráció | Közepes | A helytelen konfigurációkat az üzembe helyezés során kell észlelni. Ha ezek konfigurációfrissítés közben történnek, a rendszergazdáknak vissza kell adnia 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 | 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 hatásának lehetséges 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. | Összes |
| Azure SQL | Regionális üzemkimaradás | Nagyon alacsony | Az automatikus feladatátvételi csoport feladatátvétele 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ási pontcélok (RPO-k). | Lehetséges teljes |
| Azure SQL | Rendelkezésre állási zóna kimaradása | Alacsony | Nincs hatás | None |
| Azure SQL | Rosszindulatú támadás (injektálás) | Közepes | Minimális kockázat. Minden Azure SQL példány a privát végpontokon keresztüli virtuális hálózatra van kötve, és a hálózati biztonsági csoportok (NSG-k) további virtuális hálózatokon belüli védelmet nyújtanak. | Potenciálisan 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. | Összes |
| App Service | Regionális üzemkimaradá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 | 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. | 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ások
Megbízhatósági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: