Ügyféltevékenységek szükségesek
Incidens előtti
Azure-szolgáltatások esetén
- Ismerkedjen meg az Azure Service Health szolgáltatással az Azure Portalon. Ez az oldal "egyablakos üzletként" fog működni egy incidens során
- Fontolja meg a Service Health-riasztások használatát, amelyek úgy konfigurálhatók, hogy automatikusan értesítéseket készítsenek azure-incidensek esetén
Power BI esetén
- Ismerkedjen meg a Service Health szolgáltatással a Microsoft 365 Felügyeleti központ. Ez az oldal "egyablakos üzletként" fog működni egy incidens során
- Fontolja meg a Microsoft 365 Felügyeleti központ mobilalkalmazás használatát az automatikus szolgáltatásesemény-riasztási értesítések lekéréséhez
Az incidens során
Azure-szolgáltatások esetén
- Az Azure Service Health az Azure felügyeleti portálján biztosítja a legújabb frissítéseket
- Ha problémák merülnek fel a Service Health elérésekor, tekintse meg az Azure Állapot oldalát
- Ha bármikor problémák lépnek fel az Állapot lap elérésekor, lépjen az @AzureSupport X (korábbi nevén Twitter) oldalra.
- Ha az érintett/problémák nem egyeznek az incidenssel (vagy a kockázatcsökkentés után is fennállnak), forduljon az ügyfélszolgálathoz egy szolgáltatástámogatási jegy létrehozásához
Power BI esetén
- A Service Health lap a Microsoft 365 Felügyeleti központ a legújabb frissítéseket fogja biztosítani
- Ha problémák merülnek fel a Service Health elérésében, tekintse meg a Microsoft 365 állapotoldalát
- Ha az ütközés/problémák nem egyeznek az incidenssel (vagy ha a problémák a kockázatcsökkentés után is fennállnak), akkor szolgáltatástámogatási jegyet kell létrehoznia.
A Microsoft helyreállításának közzététele
A részletekért tekintse meg az alábbi szakaszokat.
Incidens utáni
Azure Services esetén
- A Microsoft közzé fog tenni egy PIR-t az Azure Portalon – Service Health felülvizsgálatra
Power BI esetén
- A Microsoft közzé fog tenni egy PIR-t a Microsoft 365 Felügyeleti központ – Service Health áttekintésre
Várakozás a Microsoft-folyamatra
A "Várakozás a Microsoftra" folyamat egyszerűen arra vár, hogy a Microsoft helyreállítsa az érintett elsődleges régió összes összetevőjét és szolgáltatását. A helyreállítást követően ellenőrizze az adatplatform vállalati megosztott vagy más szolgáltatásokhoz való kötését, az adathalmaz dátumát, majd hajtsa végre a rendszer aktuális dátumra történő felhozatásának folyamatait.
A folyamat befejezése után a műszaki és üzleti tárgyú szakértő (SME) ellenőrzése befejezhető, lehetővé téve az érdekelt fél számára a szolgáltatás helyreállítására vonatkozó jóváhagyást.
Vészhelyreállítás ismételt üzembe helyezése
A "Vészhelyreállítás újratelepítése" stratégiához a következő magas szintű folyamat írható le.
Contoso helyreállítása – Vállalati megosztott szolgáltatások és forrásrendszerek
- Ez a lépés előfeltétele az adatplatform helyreállításának
- Ezt a lépést a vállalati megosztott szolgáltatásokért és operatív forrásrendszerekért felelős különböző Contoso operatív támogatási csoportok hajtanák végre
Az Azure-szolgáltatások helyreállítása Az Azure Services azOkat az alkalmazásokat és szolgáltatásokat jelenti, amelyek az Azure Cloud-ajánlatot teszik elérhetővé a másodlagos régióban üzembe helyezés céljából.
Az Azure Services azOkat az alkalmazásokat és szolgáltatásokat jelenti, amelyek az Azure Cloud-ajánlatot teszik elérhetővé a másodlagos régióban üzembe helyezés céljából.
- Ez a lépés előfeltétele az adatplatform helyreállításának
- Ezt a lépést a Microsoft és más szolgáltatásként nyújtott platform (PaaS)/software as a service (SaaS) partnerek hajtanák végre
Az adatplatform alapjainak helyreállítása
- Ez a lépés a platform-helyreállítási tevékenységek belépési pontja
- Az újratelepítési stratégia esetében minden szükséges összetevő/szolgáltatás beszerezhető és üzembe helyezhető a másodlagos régióban
- Ennek a folyamatnak olyan tevékenységeket is tartalmaznia kell, mint a vállalati megosztott szolgáltatásokhoz való kötés, a hozzáféréshez/hitelesítéshez való kapcsolódás biztosítása, valamint a napló-kiszervezés működésének ellenőrzése, valamint a felső és az alsóbb rétegbeli folyamatokhoz való kapcsolódás biztosítása
- Az adatokat/feldolgozást meg kell erősíteni. Például a helyreállított platform időbélyegének ellenőrzése
- Ha az adatintegritással kapcsolatos kérdések merülnek fel, a döntés az új feldolgozás végrehajtása előtt a platform naprakész állapotba hozása érdekében későbbre kerülhet.
- A folyamatok prioritási sorrendje (az üzleti hatás alapján) segít a helyreállítás vezénylésében
- Ezt a lépést technikai ellenőrzéssel kell lezárni, kivéve, ha az üzleti felhasználók közvetlenül használják a szolgáltatásokat. Ha van közvetlen hozzáférés, akkor egy üzleti érvényesítési lépésre lesz szükség
- Miután az ellenőrzés befejeződött, az egyes megoldáscsoportoknak átadást kell végeznie saját vészhelyreállítási (DR) helyreállítási folyamat elindításához
- Az átadásnak tartalmaznia kell az adatok/folyamatok aktuális időbélyegének megerősítését
- Ha az alapvető vállalati adatfolyamatok végrehajtása folyamatban van, az egyes megoldásokat figyelembe kell venni– például a bejövő/kimenő folyamatokat
A platform által üzemeltetett egyes megoldások helyreállítása
- Minden egyes megoldásnak saját DR runbookot kell készítenie. A runbookoknak tartalmazniuk kell legalább a kijelölt üzleti érdekelt feleket, akik tesztelik és megerősítik, hogy a szolgáltatás helyreállítása befejeződött
- Az erőforrás-versengéstől vagy a prioritástól függően a legfontosabb megoldások/számítási feladatok rangsorolása lehet másokkal szemben – alapvető vállalati folyamatok az alkalmi tesztkörnyezeteken keresztül, például
- Az érvényesítési lépések elvégzése után a dr. helyreállítási folyamat elindításához átadás történik az alsóbb rétegbeli megoldásoknak
Átadás alsóbb rétegbeli, függő rendszereknek
- A függő szolgáltatások helyreállítása után az E2E DR helyreállítási folyamata befejeződött
Feljegyzés
Bár elméletileg teljesen automatizálható egy E2E DR folyamat, az esemény kockázata és az E2E-folyamat lefedéséhez szükséges SDLC-tevékenységek költsége nem valószínű.
Az elsődleges régióra való visszalépés a tartalék az adatplatform-szolgáltatás és adatainak az elsődleges régióba való visszahelyeztetése, amint az elérhető a BAU számára.
A forrásrendszerek jellegétől és a különböző adatfolyamoktól függően az adatplatform visszaesése az adat-ökorendszer más részeitől függetlenül is elvégezhető.
Az ügyfeleknek javasoljuk, hogy a megfelelő döntés meghozatala érdekében tekintse át saját adatplatformja függőségeit (a felsőbb rétegben és az alsóbb rétegben egyaránt). Az alábbi szakasz feltételezi az adatplatform független helyreállítását.
- Miután az összes szükséges összetevő/szolgáltatás elérhetővé vált az elsődleges régióban, az ügyfelek füsttesztet végeznek a Microsoft-helyreállítás ellenőrzéséhez
- Az összetevő-/szolgáltatáskonfiguráció érvényesítve lesz. A különbözeteket a forrásvezérlőből történő újbóli üzembe helyezéssel oldanák meg
- Az elsődleges régió rendszerdátuma az állapotalapú összetevők között lesz meghatározva. A megállapított dátum és a másodlagos régióban a dátum/időbélyeg közötti eltérést az adatbetöltési folyamatoknak az ettől a ponttól való újrakivágásával vagy ismételt megismétlésével kell kezelni.
- Mind az üzleti, mind a műszaki érdekelt felek jóváhagyásával tartalékkeretet választanak ki. Ideális esetben a rendszertevékenység és a feldolgozás során
- A tartalék időszakban az elsődleges régió szinkronizálva lesz a másodlagos régióval, mielőtt a rendszer át lett kapcsolva
- Párhuzamos futtatás után a másodlagos régió offline állapotba kerül a rendszerből
- A másodlagos régióban lévő összetevőket a kiválasztott DR-stratégiától függően elvetik vagy eltávolítják
Meleg tartalék folyamat
A "Meleg tartalék" stratégia esetében a magas szintű folyamat szorosan igazodik a "Vészhelyreállítás" folyamatához, a fő különbség az, hogy az összetevőket már beszerezték a másodlagos régióban. Ez a stratégia kiküszöböli az erőforrás-versengés kockázatát más szervezetektől, akik saját dr.
Gyakori elérésű tartalék folyamat
A "Gyakori elérésű tartalék" stratégia azt jelenti, hogy a platformszolgáltatások, köztük a PaaS és az infrastruktúra szolgáltatásként (IaaS) továbbra is megmaradnak a vészesemény ellenére, mivel a másodlagos rendszerek az elsődleges rendszerekkel párhuzamosan futnak. A "Warm Spare" stratégiához hasonlóan ez a stratégia is kiküszöböli az erőforrás-versengés kockázatát más szervezetektől, akik saját dr.
A gyakori elérésű tartalék ügyfelek az elsődleges régióban figyelnék az összetevők/szolgáltatások Microsoft-helyreállítását. A befejezés után az ügyfelek ellenőrzik az elsődleges régió rendszereit, és elvégzik a tartalékot az elsődleges régióra. Ez a folyamat hasonló lenne a dr. feladatátvételi folyamathoz, vagyis ellenőrizze a rendelkezésre álló kódbázist és adatokat, és szükség szerint újra üzembe helyezze azokat.
Feljegyzés
Itt külön megjegyzést kell tenni annak biztosítására, hogy a rendszer metaadatai konzisztensek legyenek a két régió között.
- Az elsődlegesre való visszalépés után a rendszer terheléselosztói frissíthetők, hogy az elsődleges régió ismét bekerüljön a rendszer topológiájába. Ha elérhető, a kanári kiadási megközelítéssel növekményesen kapcsolhatja be a rendszer elsődleges régióját.
DR-tervstruktúra
Egy hatékony DR-terv részletes útmutatót nyújt a szolgáltatás-helyreállításhoz, amelyet egy Azure-beli műszaki erőforrás hajthat végre. A következőkben egy dr. terv javasolt MVP-struktúráját soroljuk fel.
- Folyamatkövetelmények
- Az ügyfél dr. folyamatspecifikus részletei, például a DR elindításához szükséges megfelelő engedélyezés, és szükség esetén a helyreállítással kapcsolatos legfontosabb döntések meghozatala (beleértve a "kész definícióját"), a szolgáltatástámogatási dr. jegy-referenciát és a hadiszoba részleteit
- Erőforrás megerősítése, beleértve a dr. érdeklődőt és a végrehajtó biztonsági mentését. Minden erőforrást dokumentálni kell elsődleges és másodlagos partnerekkel, eszkalációs útvonalakkal, és meg kell hagyni a naptárakat. Kritikus DR-helyzetekben előfordulhat, hogy figyelembe kell venni a névsorrendszereket
- Laptop, tápegységek vagy biztonsági mentési tápellátás, hálózati kapcsolat és mobiltelefon adatai a DR-végrehajtóhoz, a dr. biztonsági mentéshez és az esetleges eszkalációs pontokhoz
- A követendő folyamat, ha a folyamat egyik követelménye sem teljesül
- Partnerlista
- DR vezetői és támogatási csoportok
- Üzleti kkv-k, akik elvégzik a műszaki helyreállítás tesztelési/felülvizsgálati ciklusát
- Érintett üzlettulajdonosok, beleértve a szolgáltatás-helyreállítási jóváhagyókat
- Érintett műszaki tulajdonosok, beleértve a műszaki helyreállítási jóváhagyókat
- A kkv-k támogatása az összes érintett területen, beleértve a platform által üzemeltetett kulcsfontosságú megoldásokat is
- Alsóbb rétegbeli rendszerek hatása – működési támogatás
- Felsőbb rétegbeli forrásrendszerek – működési támogatás
- Vállalati megosztott szolgáltatások névjegyei. Például a hozzáférés/hitelesítés támogatása, a biztonsági monitorozás és az átjáró támogatása
- Bármely külső vagy külső gyártó, beleértve a felhőszolgáltatók támogatási kapcsolattartóit is
- Architektúratervezés
- Ismertesse az E2E-forgatókönyv teljes körű leírását, és csatolja az összes kapcsolódó támogatási dokumentációt
- Függőségek
- Az összetevők kapcsolatainak és függőségeinek listázása
- DR előfeltételek
- Annak megerősítése, hogy szükség szerint elérhetők a felsőbb rétegbeli forrásrendszerek
- Emelt szintű hozzáférést kapott a veremhez a DR-végrehajtói erőforrások
- Az Azure-szolgáltatások igény szerint elérhetők
- A követendő folyamat, ha valamelyik előfeltétel nem teljesül
- Technical Recovery – Részletes utasítások
- Futtatási sorrend
- Lépés leírása
- Lépés előfeltétele
- Részletes folyamatlépések minden különálló művelethez, beleértve az URL-címeket is
- Érvényesítési utasítások, beleértve a szükséges bizonyítékokat
- Az egyes lépések végrehajtásának várható ideje, beleértve a vészhelyzetet is
- A lépés meghiúsulása esetén követendő folyamat
- Az eszkalációs pontok meghibásodás vagy kkv-támogatás esetén
- Technical Recovery – Előfeltételek utáni állapot
- Ellenőrizze a rendszer aktuális dátum-időbélyegét a kulcsösszetevők között
- A DR rendszer URL-címeinek és IP-címeinek megerősítése
- Felkészülés az üzleti érdekelt felek felülvizsgálati folyamatára, beleértve a rendszerek hozzáférésének megerősítését és az ellenőrzést és jóváhagyást befejező üzleti kkv-kat
- Üzleti érdekelt felek áttekintése és jóváhagyása
- Üzleti erőforrás kapcsolattartási adatai
- Az üzleti érvényesítési lépések a fenti műszaki helyreállításnak megfelelően
- Az üzleti jóváhagyó által a helyreállításról való kijelentkezéshez szükséges bizonyíték
- Recovery Post-követelmények
- Átadás a működési támogatásnak az adatfeldolgozás végrehajtásához a rendszer naprakészentartása érdekében
- Az alsóbb rétegbeli folyamatok és megoldások átadása – a DR rendszer dátumának és csatlakozási adatainak megerősítése
- A helyreállítási folyamat megerősítése a dr. érdeklődővel – a bizonyítékok nyomvonalának megerősítése és a kész runbook
- A biztonsági felügyelet értesítése arról, hogy az emelt szintű hozzáférési jogosultságok eltávolíthatók a DR-csapatból
Ábrafeliratok
- Javasoljuk, hogy minden lépés folyamatáról mellékelje a rendszer képernyőképeit. Ezek a képernyőképek segítenek kezelni a rendszer-kkv-któl való függőséget a feladatok elvégzéséhez
- A gyorsan fejlődő felhőszolgáltatások kockázatának mérséklése érdekében a dr. csomagot rendszeresen újra kell vizsgálni, tesztelni és végrehajtani az Azure és szolgáltatásainak jelenlegi ismeretével rendelkező erőforrásoknak
- A műszaki helyreállítási lépéseknek tükrözniük kell az összetevő és a megoldás prioritását a szervezet számára. Például az alapvető vállalati adatfolyamok helyreállítása az alkalmi adatelemzési tesztkörnyezetek előtt
- A technikai helyreállítási lépéseknek követniük kell a munkafolyamatok sorrendjét (általában balról jobbra), miután az alapösszetevők/szolgáltatás, például a Key Vault helyreállt. Ez a stratégia biztosítja, hogy a felsőbb rétegbeli függőségek elérhetők legyenek, és az összetevők megfelelően tesztelhetők legyenek
- A lépésenkénti terv befejezése után a vészhelyzettel rendelkező tevékenységek teljes idejét meg kell szerezni. Ha ez az összeg meghaladja a jóváhagyott helyreállítási időkorlátot (RTO), több lehetőség is rendelkezésre áll:
- A kiválasztott helyreállítási folyamatok automatizálása (ahol lehetséges)
- Keresse meg a lehetőségeket a kiválasztott helyreállítási lépések párhuzamos futtatására (ahol lehetséges). Megjegyzendő azonban, hogy ehhez a stratégiához további dr. végrehajtói erőforrásokra lehet szükség.
- A kulcsösszetevők magasabb szolgáltatási szintekre, például a PaaS-be való emelése, ahol a Microsoft nagyobb felelősséget vállal a szolgáltatás-helyreállítási tevékenységekért
- Az RTO kiterjesztése az érdekelt felekkel
DR-tesztelés
Az Azure Cloud service-ajánlat természete korlátozásokat eredményez a DR tesztelési forgatókönyveihez. Ezért az útmutató egy DR-előfizetés felállása az adatplatform-összetevőkkel, mivel azok elérhetők a másodlagos régióban.
Ebből az alapkonfigurációból a DR-terv runbookja szelektíven végrehajtható, különös figyelmet fordítva az üzembe helyezhető és érvényesíthető szolgáltatásokra és összetevőkre. Ehhez a folyamathoz egy válogatott tesztadatkészletre lesz szükség, amely lehetővé teszi a műszaki és üzleti ellenőrzési ellenőrzések megerősítését a terv szerint.
A DR-terveket rendszeresen tesztelni kell, hogy ne csak naprakészek legyenek, hanem az "izommemória" kiépítésére is a feladatátvételi és helyreállítási tevékenységeket végző csapatok számára.
- Az adatokat és a konfigurációs biztonsági mentéseket is rendszeresen tesztelni kell annak érdekében, hogy a helyreállítási tevékenységek támogatása érdekében "megfelelőek legyenek a célhoz".
A DR-teszt során a legfontosabb terület annak biztosítása, hogy az előíró lépések továbbra is helyesek legyenek, és a becsült időzítések továbbra is relevánsak legyenek.
- Ha az utasítások kód helyett a portál képernyőit tükrözik, az utasításokat legalább 12 havonta ellenőrizni kell a felhőben bekövetkező változás miatt.
Bár az a törekvés, hogy teljesen automatizált dr. folyamat legyen, a teljes automatizálás valószínűleg nem valószínű az esemény ritkasága miatt. Ezért javasoljuk, hogy a helyreállítási alapkonfigurációt a Desired State Configuration (DSC) infrastruktúrával hozza létre kódként (IaC) a platform biztosításához, majd az alapkonfigurációra épülő új projektekben.
- Az összetevők és szolgáltatások kibővítése során egy NFR-t kell kikényszeríteni, amely megköveteli az éles üzembehelyezési folyamat újrabontását, hogy lefedettséget biztosítson a dr.
Ha a runbook időzítése meghaladja az RTO-t, több lehetőség is van:
- Az RTO kiterjesztése az érdekelt felekkel
- Csökkentse a helyreállítási tevékenységekhez szükséges időt automatizálással, a feladatok párhuzamos futtatásával vagy a magasabb felhőkiszolgálói szintekre való migrálással
Azure Chaos Studio
Az Azure Chaos Studio egy felügyelt szolgáltatás, amely a hibák Azure-alkalmazásokba történő injektálásával javítja a rugalmasságot. A Chaos Studio lehetővé teszi az Azure-erőforrások hibainjektálásának biztonságos és ellenőrzött módon, kísérletek használatával történő vezénylésére. A jelenleg támogatott hibák típusainak leírását a termékdokumentációban találja.
A Chaos Studio jelenlegi iterációja csak az Azure-összetevők és -szolgáltatások egy részhalmazát fedi le. Amíg több hibakódtárat nem ad hozzá, a Chaos Studio ajánlott módszer az izolált rugalmassági teszteléshez a teljes rendszerszintű DR-tesztelés helyett.
A Chaos Studióval kapcsolatos további információk az Azure Chaos Studio dokumentációjában találhatók.
Azure Site Recovery
Az IaaS-összetevők esetében az Azure Site Recovery a támogatott virtuális gépen vagy fizikai kiszolgálón futó legtöbb számítási feladatot védi
A következőhöz van erős útmutatás:
- Azure-beli virtuális gép vészhelyreállítási gyakorlatának végrehajtása
- DR-feladatátvétel végrehajtása másodlagos régióba
- DR-tartalék végrehajtása az elsődleges régióba
- DR-terv automatizálásának engedélyezése
Kapcsolódó erőforrások
- Rugalmasság és rendelkezésre állás kiépítése
- Üzletmenet-folytonosság és vészhelyreállítás
- Azure-alkalmazások biztonsági mentése és vészhelyreállítása
- Rugalmasság az Azure-ban
- szolgáltatásiszint-szerződések (SLA-k) összegzése
- Öt ajánlott eljárás a hibák előrejelzéséhez
Következő lépések
Most, hogy megismerte a forgatókönyv üzembe helyezését, elolvashatja a DR for Azure adatplatform-sorozatának összegzését .