Javaslatok vészhelyzet-elhárítási stratégia kialakításához

Erre az Azure Well-Architected Framework Operational Excellence ellenőrzőlistára vonatkozó javaslatra vonatkozik:

OE:08

Hatékony vészhelyzeti műveleti gyakorlat kidolgozása. Győződjön meg arról, hogy a számítási feladat értelmes állapotjelzéseket bocsát ki az infrastruktúra és a kód között. Gyűjtse össze az eredményként kapott adatokat, és használja fel azokat olyan végrehajtható riasztások létrehozására, amelyek vészhelyzeti válaszokat hoznak létre irányítópultokon és lekérdezéseken keresztül. Egyértelműen definiálja az emberi felelősségeket, például az ügyeleti rotációkat, az incidenskezelést, a vészhelyzeti erőforrások elérését és a postmortemok futtatását.

Ez az útmutató a vészhelyzeti reagálási stratégia kialakítására vonatkozó javaslatokat ismerteti. A számítási feladatok életciklusa során felmerülő egyes problémák kritikus fontosságúak ahhoz, hogy vészhelyzetet nyilvánítsanak. Szigorúan ellenőrzött és koncentrált folyamatokat és eljárásokat valósíthat meg, amelyeket a csapata követhet, hogy a probléma nyugodt, rendezett módon legyen kezelve. A vészhelyzetek természetesen növelik mindenki stresszszintjét, és kaotikus környezethez vezethetnek, ha a csapat nem áll jól felkészülten. A stressz és a zavartság minimalizálása érdekében tervezzen meg egy válaszstratégiát, ossza meg a válaszstratégiát a szervezettel, és végezzen rendszeres vészhelyzeti reagálási képzést.

Fő tervezési stratégiák

A vészhelyzeti reagálási stratégiának a folyamatok és eljárások rendezett, jól meghatározott halmazának kell lennie. Minden folyamatnak és eljárásnak rendelkeznie kell szkriptekkel, amelyek biztosítják, hogy minden lépés a probléma gyors és biztonságos megoldása felé haladjon. Vészhelyzet-elhárítási stratégia kialakításához tekintse át a következő áttekintést:

• Előfeltételek
  • Megfigyelhetőségi platform fejlesztése
  • Incidensmegoldási terv létrehozása
• Incidens fázisai
  • Észlelés
  • Befoglaltság
  • Osztályozás
• Incidens utáni fázisok
  • Alapvető okok elemzése (RCA)
  • Utólagos elemzés
• Folyamatban lévő tevékenység
  • Vészhelyzet-elhárítási próbák

Az alábbi szakaszok az egyes fázisokhoz nyújtanak javaslatokat.

Megfigyelhetőség

Egy robusztus vészhelyzet-elhárítási stratégiához egy robusztus megfigyelhetőségi platformra van szükség. A megfigyelhetőségi platformnak a következő jellemzőkkel kell rendelkeznie:

• Holisztikus monitorozás: Győződjön meg arról, hogy a számítási feladatokat alaposan figyeli az infrastruktúra és az alkalmazás szempontjából.

• Részletes naplózás: Engedélyezze a részletes naplózást az összetevők számára, hogy segítséget nyújtson a problémák osztályozása során végzett vizsgálatokhoz. Strukturálja a naplókat, hogy könnyen kezelhetők legyenek. Automatikusan elküldi a naplókat az adatfogyóknak, hogy felkészüljenek az elemzésre.

• Hasznos irányítópultok: A szervezet minden csapatára szabott állapotmodell-alapú irányítópultokat hozhat létre. A számítási feladatok állapotának különböző aspektusaiért különböző csapatok felelősek.

• Végrehajtható riasztások: Olyan riasztásokat hozhat létre, amelyek hasznosak a számítási feladatokért felelős csapatok számára. Kerülje azokat a riasztásokat, amelyek nem igényelnek műveletet a csapatoktól. Ha túl sok ilyen riasztás van, az azt eredményezheti, hogy a felhasználók figyelmen kívül hagyják vagy letiltják a riasztási értesítéseket.

• Automatikus értesítések: Győződjön meg arról, hogy a megfelelő csapatok automatikusan megkapják azokat a riasztásokat, amelyek beavatkozást igényelnek tőlük. Az 1. szintű támogatási csapatnak például minden riasztásról értesítést kell kapnia, míg a biztonsági mérnököknek csak a biztonsági eseményekre vonatkozó riasztásokat kell kapniuk.

További információ: A megfigyelhetőségi keretrendszer tervezésére és létrehozására vonatkozó javaslatok.

Incidenskezelési terv

A vészhelyzeti reagálási stratégia alapja egy incidenskezelési terv. A vészhelyreállítási tervhez hasonlóan egyértelműen és alaposan definiálhatja az incidenskezelési terv szerepköreit, feladatait és eljárásait. A csomagnak egy verzióalapú dokumentumnak kell lennie, amely rendszeres felülvizsgálatoknak van alávetve, amelyek biztosítják, hogy naprakész legyen.

Egyértelműen definiálja a következő összetevőket a csomagban.

Szerepkörök

Incidenskezelés-kezelő azonosítása. Ez a személy birtokolja az incidenst a kezdeményezéstől a kiváltó okok elemzéséig. Az incidenskezelés-kezelő biztosítja a folyamatok követését és a megfelelő felek tájékoztatását, amint a válaszért felelős csapat elvégzi a munkáját.

Azonosítsa a postmortem vezetőt. Ez az egyén gondoskodik arról, hogy a postmortemok végrehajtása az incidens feloldása után rövidesen befejeződik. Jelentést készítenek, amely segít az incidensből kihozott eredmények alkalmazásában.

Folyamatok és eljárások

A számítási feladatokkal foglalkozó csapatnak meg kell határoznia és meg kell értenie a vészhelyzeti feltételeket. Ha a csapat megállapítja, hogy egy eset súlyos, deklarálhat egy katasztrófát, és elindíthatja a vészhelyreállítási tervet. Kevésbé súlyos esetekben előfordulhat, hogy a probléma nem felel meg a katasztrófa feltételeinek. A problémát azonban továbbra is vészhelyzetnek kell tekintenie, ami szükségessé teszi a vészhelyzeti reagálási terv kezdeményezését. A vészhelyzetek lehetnek a számítási feladat belső problémái, vagy a számítási feladat függőségével kapcsolatos problémák. A támogatási csapatnak meg kell tudnia állapítani, hogy a külső felhasználók által jelentett probléma megfelel-e a vészhelyzeti feltételeknek, még akkor is, ha nem ismerik az alapul szolgáló problémát.

Pontosan definiálja a kommunikációs és eszkalációs terveket. A kapott riasztási értesítések típusától függően győződjön meg arról, hogy az 1. rétegbeli ügyfélszolgálat könnyen kapcsolatba léphet a megfelelő csapatokkal a problémák eszkalálásához. Győződjön meg arról, hogy tudják, milyen típusú kommunikáció megfelelő a belső és külső felek számára. A kommunikációs és eszkalációs tervekben szerepeljen az ügyeleti ütemterv és a személyzet listája.

A teljes tervben tartalmazzon elszigetelési és osztályozási szkripteket. A csapatok ezeket a lépésenkénti eljárásokat követik, amikor elszigetelési és osztályozási függvényeket hajtanak végre. Adjon meg egy leírást arról, hogy mi határozza meg az incidensek lezárását.

Egyéb elemek, amelyek belefoglalhatók

Dokumentálja az incidensek során a belső kommunikációhoz, például a Microsoft Teamshez használt összes szabványos eszközt, valamint az incidens során végzett tevékenységek nyomon követéséhez, például jegykezelési eszközökhöz vagy hátraléktervezési eszközökhöz.

Dokumentálja a segélyhívási hitelesítő adatait, más néven a break-glass fiókokat. Adjon meg egy részletes útmutatót, amely leírja a használatuk módját.

Hozzon létre vészmegoldási részletezési utasításokat, és jegyezze fel, hogy mikor végezték el a részletezéseket.

Dokumentálja a szükséges jogi vagy szabályozási intézkedéseket, például az adatsértések közlését.

Incidensészlelés

Ha van egy jól megtervezett megfigyelhetőségi platformja, amely figyeli az anomáliákat, és automatikusan riasztásokat küld róluk, gyorsan észlelheti a problémákat, és meghatározhatja azok súlyosságát. Ha a probléma vészhelyzetnek minősül, a terv kezdeményezhető. Bizonyos esetekben a támogatási csapat nem kap értesítést a megfigyelhetőségi platformon keresztül. Az ügyfelek a támogatási csoport kommunikációs lehetőségeit használva jelenthetik a támogatási problémákat. Vagy kapcsolatba léphetnek azokkal a személyekkel, akikkel rendszeresen dolgoznak, például fiókvezetőkkel vagy virtuális gépekkel. Függetlenül attól, hogy a támogatási csapat milyen értesítést kap, mindig ugyanazokat a lépéseket kell követnie a probléma érvényesítéséhez és a súlyosság meghatározásához. A választervtől való eltérés stresszt és zavart okozhat.

Befoglaltság

A probléma elhárításának első lépése a probléma megoldása a számítási feladat többi részének védelme érdekében. Az elszigetelési stratégia a probléma típusától függ, de általában magában foglalja az érintett összetevő eltávolítását a számítási feladatok folyamatának útvonalaiból. Például leállíthat egy erőforrást, vagy eltávolíthatja azt a hálózati útválasztási útvonalakról. A rendszergazdáknak, a mérnököknek és a vezető fejlesztőknek együtt kell dolgozniuk az elszigetelési stratégiák kialakításában. Az elszigetelésnek korlátoznia kell a problémák robbanási sugarát, és csökkentett állapotban kell fenntartania a számítási feladatok működését, amíg a probléma meg nem oldódott. Ha egy érintett összetevőnek elérhetőnek kell lennie a osztályozás elvégzéséhez, elengedhetetlen, hogy a számítási feladat többi részéhez való hozzáférése le legyen tiltva. Amennyire csak lehetséges, csak a számítási feladattól és a többi rendszertől elválasztott útvonalon kell elérnie az összetevőt.

Osztályozás

A probléma sikeres megoldása után megkezdheti a triázsmunkát. Az osztályozás során követendő lépések a probléma típusától függenek. A számítási feladatok támogatásának egy bizonyos területének csapatának olyan eljárásokat kell létrehoznia az incidensekhez, amelyek a csapatukhoz kapcsolódnak. A biztonsági csapatoknak például el kell végezniük a biztonsági problémák osztályozását, és követniük kell az általuk fejlesztett szkripteket. Fontos, hogy a csapatok jól definiált szkripteket kövessenek, miközben a triage-erőfeszítéseiken dolgoznak. Ezeknek a szkripteknek lépésről lépésre olyan folyamatoknak kell lenniük, amelyek visszaállítási folyamatokat tartalmaznak a hatástalan vagy egyéb problémákat okozó módosítások visszavonásához. A naplóösszesítési és elemzési eszközökkel hatékonyan kivizsgálhatja a mély elemzést igénylő problémákat. A probléma megoldása után kövesse a jól meghatározott folyamatokat, hogy biztonságosan visszavihesse az érintett összetevőt a számítási feladatok folyamatútvonalaiba.

RCA-jelentéskészítés

Az ügyfeleknek szóló szolgáltatói szerződések (SLA-k) azt diktálhatják, hogy az incidens megoldását követően egy bizonyos időn belül RCA-jelentéseket kell kiadnia. Az incidens tulajdonosának létre kell hoznia az RCA-jelentéseket. Ha ez nem lehetséges, egy másik személy, aki szorosan együttműködik az incidens tulajdonosával, létrehozhatja az RCA-jelentéseket. Ez a stratégia biztosítja az incidens pontos nyilvántartását. A szervezetek általában rendelkeznek egy meghatározott RCA-sablonnal, amely útmutatást tartalmaz az információk megjelenítési módjáról, valamint arról, hogy milyen típusú információk oszthatók meg vagy oszthatók meg. Ha saját sablont és irányelveket kell létrehoznia, győződjön meg arról, hogy az érdekelt felek felülvizsgálják és jóváhagyják őket.

Incidens utáni események

Egy pártatlan egyénnek oktalan utómortemeket kellene vezetnie. A postmortem munkamenetekben mindenki megosztja az incidensből származó megállapításait. Az incidensmegoldásban részt vevő csapatokat olyan személyeknek kell képviselnie, akik az incidensen dolgoztak. Ezeknek az egyéneknek a sikeres és javítható területekre vonatkozó példákkal előkészített ülésre kell érkezniük. A munkamenet nem fórum az incidens vagy a válasz során esetleg felmerülő problémák okának kiosztására. A postmortem vezetőnek el kell hagynia a munkamenetet az olyan műveletelemek egyértelmű listájával, amelyek a fejlesztésre összpontosítanak, például:

• A választerv fejlesztései. A megfelelő műveletek jobb rögzítése érdekében előfordulhat, hogy a folyamatokat vagy eljárásokat újra kell értékelni és újra kell írni.

• A megfigyelhetőségi platform fejlesztései. Előfordulhat, hogy a küszöbértékeket újra kell értékelni az incidens adott típusának korábbi elfogásához, vagy előfordulhat, hogy új figyelést kell végrehajtani a nem elszámolt viselkedés észlelése érdekében.

• A számítási feladat fejlesztései. Az incidens olyan biztonsági rést tehet közzé a számítási feladatban, amelyet állandó szervizelésként kell kezelni.

Megfontolandó szempontok

A túl agresszív reagálási stratégia téves riasztásokhoz vagy szükségtelen eszkalációkhoz vezethet.

Hasonlóképpen, az automatikus skálázás vagy más önjavítási intézkedések agresszív végrehajtása a küszöbérték-túllépésekre való reagálás érdekében szükségtelen kiadásokhoz és felügyeleti terhekhez vezethet. Előfordulhat, hogy nem tudja, hogy pontosan milyen küszöbértékeket kell beállítani a riasztásokhoz és az automatikus műveletekhez, például a skálázáshoz. Végezzen tesztelést alacsonyabb környezetekben és éles környezetben, hogy segítsen meghatározni a követelményeknek megfelelő küszöbértékeket.

Azure-beli segítségnyújtás

Az Azure Monitor egy átfogó megoldás a felhőből és a helyszíni környezetekből származó monitorozási adatok gyűjtésére, elemzésére és megválaszolására. Tartalmaz egy robusztus riasztási platformot, amelyet automatikus értesítésekhez és egyéb műveletekhez, például automatikus skálázáshoz és más önjavító mechanizmusokhoz konfigurálhat.

A Monitorral integrálhatja a gépi tanulást. Az incidensek osztályozásának és a proaktív intézkedések automatizálása és optimalizálása. További információ: AIOps és gépi tanulás a Monitorban.

A Log Analytics egy robusztus elemzési eszköz, amely a Monitor beépített része. A Log Analytics használatával lekérdezéseket futtathat az összesített naplókon, és betekintést nyerhet a számítási feladatba.

A Microsoft Azure-jal kapcsolatos incidens-előkészítési képzést kínál. További információkért lásd: Bevezetés az Azure-incidensek készültségi állapotába és az incidensek felkészültségbe.

Kapcsolódó hivatkozások

• Javaslatok a megfigyelhetőségi keretrendszer kialakításához és létrehozásához
• Javaslatok megbízható monitorozási és riasztási stratégia kialakításához
• Javaslatok az önjavításhoz és az önmegőrzéshez

Működési kiválósági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Működési kiválósági ellenőrzőlista