Javaslatok vészhelyreállítási stratégia kialakításához

  • Cikk

Erre az Azure Well-Architected Framework megbízhatósági ellenőrzőlistára vonatkozó javaslatra vonatkozik:

RE:09 Strukturált, tesztelt és dokumentált üzletmenet-folytonossági és vészhelyreállítási (BCDR) terveket implementál, amelyek megfelelnek a helyreállítási céloknak. A terveknek az összes összetevőre és a rendszer egészére ki kell terjedniük.

Ez az útmutató a számítási feladatok megbízható vészhelyreállítási stratégiájának kialakítására vonatkozó javaslatokat ismerteti. A belső szolgáltatásiszint-célkitűzések (SLO-k) vagy akár az ügyfelek számára garantált szolgáltatásiszint-szerződés (SLA) teljesítéséhez robusztus és megbízható vészhelyreállítási stratégiával kell rendelkeznie. Hibák és egyéb jelentős problémák várhatók. Az ilyen incidensek kezelésére való felkészülése határozza meg, hogy az ügyfelek mennyire bízhatnak abban, hogy az ön vállalkozása megbízhatóan teljesítsen számukra. A vészhelyreállítási stratégia a nagyobb incidensek előkészítésének gerince.

Definíciók

Időszak Definíció
Feladatátvétel Az éles számítási feladatok forgalmának automatizált és/vagy manuális áthelyezése egy nem elérhető régióból egy nem érintett földrajzi régióba.
Feladat-visszavétel Az éles számítási feladatok forgalmának automatikus és/vagy manuális áthelyezése feladatátvételi régióból az elsődleges régióba.

Fő tervezési stratégiák

Ez az útmutató feltételezi, hogy a megbízhatósági tervezés részeként már elvégezte a következő feladatokat:

A megbízható vészhelyreállítási (DR) stratégia egy megbízható számítási feladatarchitektúra alapjaira épül. A számítási feladat létrehozásának minden fázisában kezelje a megbízhatóságot, hogy az optimalizált helyreállításhoz szükséges elemek rendelkezésre álljon, mielőtt elkezdené megtervezni a DR-stratégiát. Ez az alap biztosítja, hogy a számítási feladat megbízhatósági céljai, például a helyreállítási időkorlát (RTO) és a helyreállítási pont célkitűzése (RPO) reálisak és elérhetőek legyenek.

Vészhelyreállítási terv karbantartása

A számítási feladatok megbízható DR-stratégiájának sarokköve a DR-terv. A tervnek egy olyan élő dokumentumnak kell lennie, amelyet rendszeresen felülvizsgálnak és frissítenek a környezet fejlődésével. Rendszeresen (például hathavonta) mutassa be a tervet a megfelelő csapatoknak (üzemeltetés, technológiavezetés és üzleti érdekelt felek). Tárolja magas rendelkezésre állású, biztonságos adattárban, például OneDrive Vállalati verzió.

Kövesse az alábbi javaslatokat a DR-csomag fejlesztéséhez:

  • Egyértelműen határozza meg, hogy mi minősül katasztrófának, és ezért a DR-terv aktiválását igényli.

    • A katasztrófák nagy léptékű problémák. Ezek lehetnek regionális kimaradások, szolgáltatáskimaradások, például Microsoft Entra azonosító vagy Azure DNS, vagy súlyos rosszindulatú támadások, például zsarolóprogramok vagy DDoS-támadások.

    • Azonosíthatja azokat a hibamódokat, amelyek nem minősülnek katasztrófának, például egyetlen erőforrás meghibásodását, hogy az operátorok ne hívhassák meg tévesen a vészhelyreállítási eszkalációkat.

  • Hozza létre a DR-csomagot az FMA dokumentációjában. Győződjön meg arról, hogy a DR-csomag rögzíti a vészhelyreállítási módokat és a vészhelyreállítási stratégiákat. Frissítse párhuzamosan a DR-csomagot és az FMA-dokumentumokat is, hogy pontosak legyenek, amikor a környezet megváltozik, vagy amikor a tesztelés váratlan viselkedéseket fed fel.

    • Az üzleti követelményektől és a költségek hatásaitól függ, hogy nem éles környezetekhez fejleszt-e DR-terveket. Ha például minőségbiztosítási (minőségbiztosítási) környezeteket kínál bizonyos ügyfeleknek az előzetes teszteléshez, érdemes lehet ezeket a környezeteket beépíteni a DR-tervezésbe.

  • Egyértelműen definiálhat szerepköröket és felelősségeket a számítási feladatokkal foglalkozó csapaton belül, és megismerheti a szervezeten belüli kapcsolódó külső szerepköröket. A szerepköröknek a következőkre kell kiterjednie:

    • A katasztrófa bejelentéséért felelős fél.

    • Az incidens lezárásának bejelentéséért felelős fél.

    • Műveleti szerepkörök.

    • Tesztelési és érvényesítési szerepkörök.

    • Belső és külső kommunikációs szerepkörök.

    • Visszamenőleges és kiváltó okok elemzése (RCA) érdeklődői szerepkörök.

  • Határozza meg azokat az eszkalációs útvonalakat, amelyeket a számítási feladatért felelős csapatnak követnie kell annak biztosításához, hogy a helyreállítási állapot kommunikáljon az érdekeltekkel.

  • Rögzítse az összetevőszintű helyreállítási eljárásokat, az adattulajdon-szintű helyreállítást és az egész számítási feladatra kiterjedő helyreállítási folyamatokat. Adjon meg egy előírt műveleti sorrendet annak biztosítása érdekében, hogy az összetevők a legkevésbé hatásosabb módon legyenek helyreállítva. Az alkalmazás helyreállítása előtt például helyreállíthatja és ellenőrizheti az adatbázisokat.

    • Részletes útmutatóként részletezheti az egyes összetevőszintű helyreállítási eljárásokat. Ha lehetséges, adjon meg képernyőképeket.

    • Határozza meg a csapat feladatait és a felhőszolgáltató feladatait. A Microsoft feladata például egy PaaS (szolgáltatásként nyújtott platform) visszaállítása, de Ön felel az adatok rehidratálásáért és a konfiguráció szolgáltatásra való alkalmazásáért.

    • Adja meg az eljárás futtatásának előfeltételeit. Sorolja fel például az összegyűjtendő szkripteket vagy hitelesítő adatokat.

    • Rögzítse az incidens kiváltó okát, és végezze el a kockázatcsökkentést a helyreállítás megkezdése előtt. Ha például az incidens oka egy biztonsági probléma, mérsékelje ezt a problémát, mielőtt helyreállítja az érintett rendszereket a feladatátvételi környezetben.

  • A számítási feladat redundanciatervétől függően előfordulhat, hogy jelentős feladatátvétel utáni munkát kell végeznie, mielőtt ismét elérhetővé tenné a számítási feladatot az ügyfelek számára. A feladatátvétel utáni munka magában foglalhatja a DNS-frissítéseket, az adatbázis-kapcsolati karakterlánc-frissítéseket és a forgalomirányítási módosításokat. Rögzítse a feladatátvétel utáni összes munkát a helyreállítási eljárásokban.

    Megjegyzés

    A redundancia kialakítása lehetővé teszi a nagyobb incidensek teljes vagy részleges helyreállítását, ezért győződjön meg arról, hogy a terv folyamatokat és eljárásokat tartalmaz az ilyen forgatókönyvek körül. Ha például a rendelkezésre állási zónákra vagy régiókra kiterjedő teljesen aktív-aktív kialakítással rendelkezik, előfordulhat, hogy egy rendelkezésre állási zóna vagy regionális kimaradás után transzparens módon automatikusan feladatátvételt hajthat végre, és minimalizálhatja a dr. Hasonlóképpen, ha üzembehelyezési bélyegek használatával tervezte meg a számítási feladatot, előfordulhat, hogy csak részleges kimaradást szenved, ha a bélyegek zónaszerűen vannak üzembe helyezve. Ebben az esetben a DR-csomagnak ki kell terjednie a bélyegek nem érintett zónákban vagy régiókban történő helyreállítására.

  • Ha újra üzembe kell helyeznie az alkalmazást a feladatátvételi környezetben, az eszközök használatával a lehető legnagyobb mértékben automatizálhatja az üzembe helyezési folyamatot. Győződjön meg arról, hogy a DevOps-folyamatok előre üzembe lettek helyezve és konfigurálva lettek a feladatátvételi környezetekben, hogy azonnal megkezdhesse az alkalmazástelepítéseket. A konzisztens és hatékony üzembe helyezési folyamat érdekében szükség esetén manuális jóváhagyási kapukkal rendelkező, automatizált, végpontok közötti üzembe helyezéseket használhat. A teljes üzembe helyezési időtartamnak igazodnia kell a helyreállítási célokhoz.

    • Ha az üzembehelyezési folyamat egy szakasza manuális beavatkozást igényel, dokumentálja a manuális lépéseket. Egyértelműen definiálja a szerepköröket és a felelősségeket.

  • Automatizálja a lehető legtöbb eljárást. A szkriptekben deklaratív programozást használjon, mert lehetővé teszi az idempotencia használatát. Ha nem tudja használni a deklaratív programozást, ügyeljen az egyéni kód fejlesztésére és futtatására. Használja az újrapróbálkozási logikát és az áramkör-megszakító logikát, hogy elkerülje a megszakadt feladaton elakadt szkriptek időtúllépését. Mivel ezeket a szkripteket csak vészhelyzetekben futtatja, nem szeretné, hogy a helytelenül fejlesztett szkriptek nagyobb kárt okozzanak vagy lelassítják a helyreállítási folyamatot.

    Megjegyzés

    Az automatizálás kockázatot jelent. A betanított operátoroknak gondosan monitorozniuk kell az automatizált folyamatokat, és közbe kell avatkozniuk, ha bármilyen folyamat problémákba ütközik. Annak érdekében, hogy minimálisra csökkentse annak kockázatát, hogy az automatizálás reagáljon a hamis pozitívokra, alaposnak kell lennie a DR-próbákon. Tesztelje a terv összes fázisát. Szimulálja az észlelést a riasztások létrehozásához, majd haladjon végig a teljes helyreállítási folyamaton.

    Ne feledje, hogy a DR-próbáknak ellenőriznie vagy tájékoztatniuk kell a helyreállítási célmetrikák frissítéseit. Ha azt tapasztalja, hogy az automatizálás érzékeny a téves pozitív értékekre, előfordulhat, hogy növelnie kell a feladatátvételi küszöbértékeket.

  • Válassza el a feladat-visszavételi tervet a DR-tervtől, hogy elkerülje a DR-eljárásokkal való esetleges félreértéseket. A feladat-visszavételi tervnek követnie kell a DR-terv fejlesztési és karbantartási javaslatait, és ugyanúgy kell strukturálni. A feladatátvételhez szükséges manuális lépéseket tükrözni kell a feladat-visszavételi tervben. A feladat-visszavétel gyorsan megtörténhet a feladatátvétel után, vagy napokig vagy hetekig is eltarthat. Fontolja meg a feladat-visszavételt a feladatátvételtől elkülönítve.

    • A feladat-visszavétel szükségessége helyzetszerű. Ha teljesítménybeli okokból irányítja át a forgalmat a régiók között, fontos, hogy a feladatátvételi régióban eredetileg meghiúsult terhelés vissza legyen állítva. Más esetekben előfordulhat, hogy a számítási feladatot úgy tervezte meg, hogy teljes mértékben működjön, függetlenül attól, hogy melyik éles környezetben található.

Vészhelyreállítási próbák végrehajtása

A DR tesztelési gyakorlat ugyanolyan fontos, mint egy jól kidolgozott DR-terv. Számos iparág rendelkezik olyan megfelelőségi keretrendszerekkel, amelyekhez meghatározott számú DR-próbát kell rendszeresen elvégezni. Az iparágtól függetlenül a rendszeres DR-próbák a sikerhez elengedhetetlenek.

Kövesse az alábbi javaslatokat a sikeres DR-próbákhoz:

  • Évente legalább egy éles dr. próbát hajthat végre. A tabletop (száraz üzemű) vagy a nem éles üzemű fúrók biztosítják, hogy az érintett felek ismerik a szerepköreiket és a felelősségeiket. Ezek a gyakorlatok a helyreállítási folyamatok követésével segítenek az operátoroknak az ismertség ("izommemória") kialakításában. De csak az éles próbák tesztelik valóban a DR-terv érvényességét, valamint az RTO- és RPO-metrikákat. Az éles próbákkal időtúllépési folyamatokat végezhet az összetevők és folyamatok esetében, így biztosítva, hogy a számítási feladathoz meghatározott RTO- és RPO-célok elérhetők legyenek. Az Ön által nem vezérelhető függvények, például a DNS-propagálás esetében győződjön meg arról, hogy az RTO és az RPO azokat a folyamatokat célozza, amelyek ezen függvényeket magukban foglalják, az ön által nem befolyásolható esetleges késéseket okoznak.

  • Az asztali részletezésekkel nemcsak a tapasztalt operátorok ismereteit fejlesztheti, hanem új operátorokat is taníthat a DR-folyamatokról és eljárásokról. A vezető piaci szereplőknek időt kell szánniuk arra, hogy az új üzemeltetők elvégezzék a szerepüket, és watch a fejlesztési lehetőségek érdekében. Ha egy új operátor tétovázik vagy összezavarodik egy eljárás egy lépésével, tekintse át ezt az eljárást, hogy biztosan meg legyen írva.

Megfontolandó szempontok

  • A DR-próbák éles környezetben történő végrehajtása váratlan katasztrofális hibákat okozhat. A kezdeti üzembe helyezés során mindenképpen tesztelje a helyreállítási eljárásokat nem éles környezetekben.

  • A lehető legtöbb karbantartási időt adja a csapatnak a próbák során. A karbantartási idő tervezésekor a tesztelés során rögzített helyreállítási metrikákat használja minimálisan szükséges időpontként .

  • A dr. részletezési gyakorlat érettségével megtanulhatja, hogy mely eljárásokat futtathatja párhuzamosan, és melyeket kell egymás után futtatnia. A részletezési eljárások korai szakaszában feltételezzük, hogy minden eljárást egymás után kell futtatni, és hogy minden lépésben több időre van szükség a váratlan problémák kezeléséhez.

Azure-beli facilitálás

Számos Azure-termék rendelkezik beépített feladatátvételi képességekkel. Ismerkedjen meg ezekkel a képességekkel, és vegye fel őket a helyreállítási eljárásokba.

Az IaaS-rendszerek (szolgáltatott infrastruktúra) esetében az Azure Site Recovery használatával automatizálhatja a feladatátvételt és a helyreállítást. A gyakori PaaS-termékekről a következő cikkekben olvashat:

Példa

Az Azure-beli dr. adatplatform-sorozatban útmutatást talál a vállalati adattulajdonok dr. számára történő előkészítéséhez.

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

Tekintse meg a javaslatok teljes készletét.

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