Kundaktiviteter krävs
Före incident
För Azure-tjänster
- Bekanta dig med Azure Service Health i Azure Portal. Den här sidan fungerar som "one-stop shop" under en incident.
- Överväg att använda Service Health-aviseringar, som kan konfigureras för att automatiskt skapa meddelanden när Azure-incidenter inträffar.
För Power BI
- Var bekant med Service Health i Administrationscenter för Microsoft 365. Den här sidan fungerar som "one-stop shop" under en incident.
- Överväg att använda Microsoft 365 Admin-mobilappen för att få automatiska aviseringar om tjänstincidenter.
Under incidenten
För Azure-tjänster
- Azure Service Health i azure-hanteringsportalen ger de senaste uppdateringarna.
- Om det finns problem med att komma åt Service Health kan du gå till sidan Azure-status.
- Om det finns problem med att komma åt sidan Status går du till @AzureSupport på X (tidigare Twitter).
- Om påverkan/problem inte matchar incidenten (eller kvarstår efter åtgärd) kontaktar du supporten för att skapa ett supportärende för tjänsten.
För Power BI
- Sidan Service Health i deras Administrationscenter för Microsoft 365 innehåller de senaste uppdateringarna
- Om det finns problem med att komma åt Service Health kan du läsa sidan Microsoft 365-status
- Om påverkan/problem inte matchar incidenten (eller om problemen kvarstår efter åtgärd) bör du skapa ett supportärende för tjänsten.
Efter Microsoft-återställning
Se avsnitten nedan för den här informationen.
Efter incident
För Azure Services
- Microsoft publicerar en PIR till Azure Portal – Service Health för granskning.
För Power BI
- Microsoft publicerar en PIR till Microsoft 365 Admin – Service Health för granskning.
Vänta på Microsoft-processen
Processen "Vänta på Microsoft" väntar helt enkelt på att Microsoft ska återställa alla komponenter och tjänster i den berörda primära regionen. När den har återställts verifierar du bindningen av dataplattformen till delade företagstjänster eller andra tjänster, datauppsättningens datum och kör sedan processerna för att uppdatera systemet till det aktuella datumet.
När den här processen har slutförts kan valideringen av teknisk och affärsämnesexpert slutföras så att intressenterna kan godkänna serviceåterställningen.
Omdistribuera vid haveri
För en strategi för omdistribuering av haveri kan följande processflöde på hög nivå beskrivas.
Återställa Contosos delade företagstjänster och källsystem
- Det här steget är en förutsättning för att dataplattformen ska kunna återställas.
- Det här steget skulle slutföras av de olika contoso-stödgrupperna för drift som ansvarar för delade företagstjänster och system för driftkällor.
Återställa Azure-tjänster Azure Services refererar till de program och tjänster som skapar Azure Cloud-erbjudandet, som är tillgängliga i den sekundära regionen för distribution.
Azure Services refererar till de program och tjänster som gör Azure Cloud-erbjudandet tillgängliga i den sekundära regionen för distribution.
- Det här steget är en förutsättning för att dataplattformen ska kunna återställas.
- Det här steget skulle slutföras av Microsoft och andra PaaS-partner (Plattform som en tjänst)/SaaS-partner (programvara som en tjänst).
Återställa grunden för dataplattformen
- Det här steget är startpunkten för plattformsåterställningsaktiviteterna.
- För omdistributionsstrategin skulle varje nödvändig komponent/tjänst köpas in och distribueras till den sekundära regionen.
- Mer information om komponenter och distributionsstrategier finns i avsnittet Azure-tjänst och -komponent i den här serien.
- Den här processen bör även omfatta aktiviteter som bindningen till företagets delade tjänster, säkerställa anslutning till åtkomst/autentisering och verifiera att loggens avlastning fungerar, samtidigt som anslutningen till både överordnade och underordnade processer säkerställs.
- Data/bearbetning bör bekräftas. Till exempel validering av tidsstämpeln för den återställda plattformen.
- Om det finns frågor om dataintegritet kan beslutet fattas att återställa ytterligare i tid innan den nya bearbetningen körs för att uppdatera plattformen.
- Att ha en prioritetsordning för processer (baserat på affärspåverkan) hjälper till att samordna återställningen.
- Det här steget bör stängas av teknisk validering om inte företagsanvändare interagerar direkt med tjänsterna. Om det finns direkt åtkomst måste det finnas ett affärsverifieringssteg.
- När valideringen har slutförts sker en överlämning till de enskilda lösningsteamen för att starta en egen haveriberedskapsprocess (DR).
- Den här överlämningen bör innehålla en bekräftelse av den aktuella tidsstämpeln för data och processer.
- Om kärndataprocesser för företag ska köras bör de enskilda lösningarna till exempel göras medvetna om detta – inkommande/utgående flöden.
Återställa de enskilda lösningar som hanteras av plattformen
- Varje enskild lösning bör ha en egen DR-runbook. Runbooks bör åtminstone innehålla de nominerade affärsintressenterna som ska testa och bekräfta att tjänståterställningen har slutförts.
- Beroende på resurskonkurration eller prioritet kan viktiga lösningar/arbetsbelastningar prioriteras framför andra – till exempel viktiga företagsprocesser framför ad hoc-labb.
- När valideringsstegen har slutförts sker en överlämning till de underordnade lösningarna för att starta återställningsprocessen för haveriberedskap.
Överlämning till underordnade, beroende system
- När de beroende tjänsterna har återställts är återställningsprocessen för E2E DR klar.
Kommentar
Även om det teoretiskt sett är möjligt att helt automatisera en E2E DR-process, är det osannolikt med tanke på risken för händelsen jämfört med kostnaden för de SDLC-aktiviteter som krävs för att täcka E2E-processen.
Återställning till den primära regionen Återställning är processen att flytta dataplattformstjänsten och dess data tillbaka till den primära regionen, när den är tillgänglig för BAU.
Beroende på källsystemens art och olika dataprocesser kan återställningen av dataplattformen göras oberoende av andra delar av datasystemet.
Kunder rekommenderas att granska sin egen dataplattforms beroenden (både uppströms och nedströms) för att fatta rätt beslut. I följande avsnitt förutsätts en oberoende återställning av dataplattformen.
- När alla nödvändiga komponenter/tjänster har blivit tillgängliga i den primära regionen slutför kunderna ett röktest för att verifiera Microsoft-återställningen.
- Konfigurationen av komponenten/tjänsten verifieras. Deltan åtgärdas via omdistribution från källkontrollen.
- Systemdatumet i den primära regionen skulle upprättas för tillståndskänsliga komponenter. Deltat mellan det etablerade datumet och datum/tidsstämpeln i den sekundära regionen bör åtgärdas genom att omexecuting eller spela upp datainmatningsprocesserna från den punkten framåt.
- Med godkännande från både affärs- och tekniska intressenter skulle ett reservfönster väljas. Helst bör detta ske under en invaggning i systemaktivitet och bearbetning.
- Under återställningen skulle den primära regionen synkroniseras med den sekundära regionen innan systemet växlades över.
- Efter en period av en parallell körning skulle den sekundära regionen tas offline från systemet.
- Komponenterna i den sekundära regionen skulle antingen tas bort eller tas bort, beroende på vilken DR-strategi som valts.
Varm reservprocess
För en "Warm Spare"-strategi är processflödet på hög nivå nära anpassat till det för "Omdistribuera vid katastrof", den viktigaste skillnaden är att komponenter redan har köpts i den sekundära regionen. Den här strategin eliminerar risken för resurskonkurrering från andra organisationer som vill slutföra sin egen dr i den regionen.
Frekvent reservprocess
Strategin "Hot Spare" innebär att plattformstjänster inklusive PaaS- och IaaS-system (infrastruktur som en tjänst) bevaras trots katastrofhändelsen när de sekundära systemen körs tillsammans med de primära systemen. Precis som med strategin "Warm Spare" eliminerar den här strategin risken för resurskonkurrering från andra organisationer som vill slutföra sin egen dr i den regionen.
Hot Spare-kunder skulle övervaka Microsofts återställning av komponenter/tjänster i den primära regionen. När det är klart validerar kunderna de primära regionsystemen och slutför återställningen till den primära regionen. Den här processen skulle likna dr-redundansprocessen, d.v.s. kontrollera den tillgängliga kodbasen och data och distribuera om efter behov.
Kommentar
En särskild anmärkning här bör göras för att säkerställa att alla systemmetadata är konsekventa mellan de två regionerna.
- När återställningen till den primära har slutförts kan systemets lastbalanserare uppdateras för att återställa den primära regionen till systemtopologin. Om det är tillgängligt kan en kanariefrisläppningsmetod användas för att stegvis växla den primära regionen på för systemet.
DR-planstruktur
En effektiv DR-plan visar en stegvis guide för tjänståterställning som kan köras av en teknisk Azure-resurs. I följande listas därför en föreslagen MVP-struktur för en DR-plan.
- Processkrav
- Alla kund-DR-processspecifika detaljer, till exempel rätt auktorisering som krävs för att starta DR, och fatta viktiga beslut om återställningen efter behov (inklusive "definition av klar"), servicesupport DR-biljettreferens och krigsrumsinformation.
- Resursbekräftelse, inklusive säkerhetskopiering av DR-lead och exekutor. Alla resurser ska dokumenteras med primära och sekundära kontakter, eskaleringsvägar och lämna kalendrar. I kritiska DR-situationer kan rostersystem behöva övervägas.
- Bärbar dator, kraftpaket eller reservkraft, nätverksanslutning och mobiltelefoninformation för DR-kören, DR-säkerhetskopiering och eventuella eskaleringspunkter.
- Den process som ska följas om något av processkraven inte uppfylls.
- Kontaktlista
- DR-ledarskap och supportgrupper.
- Små och medelstora företag som kommer att slutföra test-/granskningscykeln för den tekniska återställningen.
- Berörda företagsägare, inklusive godkännare av tjänståterställning.
- Berörda tekniska ägare, inklusive godkännare av teknisk återställning.
- Stöd för små och medelstora företag i alla berörda områden, inklusive viktiga lösningar som hanteras av plattformen.
- Berörda underordnade system – driftstöd.
- Överordnade källsystem – driftstöd.
- Kontakter med delade tjänster för företag. Till exempel stöd för åtkomst och autentisering, säkerhetsövervakning och gatewaystöd
- Externa leverantörer eller tredjepartsleverantörer, inklusive supportkontakter för molnleverantörer.
- Arkitekturdesign
- Beskriv scenariot för slutpunkt (E2E) och bifoga all tillhörande supportdokumentation.
- Beroenden
- Visa en lista över alla komponenters relationer och beroenden.
- DR-krav
- Bekräftelse på att överordnade källsystem är tillgängliga efter behov.
- Utökad åtkomst över stacken har beviljats till DR-körresurserna.
- Azure-tjänster är tillgängliga efter behov.
- Den process som ska följas om någon av förutsättningarna inte har uppfyllts.
- Teknisk återställning – stegvisa instruktioner
- Kör ordning.
- Stegbeskrivning.
- Stegkrav.
- Detaljerade processsteg för varje diskret åtgärd, inklusive URL:er.
- Valideringsinstruktioner, inklusive de bevis som krävs.
- Förväntad tid för att slutföra varje steg, inklusive oförutsedda händelser.
- Den process som ska följas om steget misslyckas.
- Eskaleringspunkterna vid fel eller stöd för små och medelstora företag.
- Teknisk återställning – efterkrav
- Bekräfta systemets aktuella datumtidsstämpel för viktiga komponenter.
- Bekräfta URL:er för DR-systemet och IP-adresser.
- Förbered för granskningsprocessen för affärsintressent, inklusive bekräftelse av systemåtkomst och de små och medelstora företag som slutför valideringen och godkännandet.
- Granskning och godkännande av intressenter för företag
- Kontaktuppgifter för företagsresurser.
- Affärsverifieringsstegen enligt den tekniska återställningen ovan.
- Bevisspåret som krävs från affärsgodkännaren som signerar återställningen.
- Återställning efter krav
- Överlämning till driftsstöd för att köra dataprocesserna för att hålla systemet uppdaterat.
- Överlämning av nedströmsprocesser och lösningar – som bekräftar datum- och anslutningsinformationen för DR-systemet.
- Bekräfta återställningsprocessen slutförd med DR-ledningen – bekräftar bevisspåret och slutförd runbook.
- Meddela säkerhetsteamen att utökade åtkomstbehörigheter kan tas bort från DR-teamet.
Pratbubblar
- Vi rekommenderar att du tar med systemskärmskärmar av varje stegprocess. Dessa skärmbilder hjälper dig att hantera beroendet av system-små och medelstora företag för att slutföra uppgifterna.
- För att hålla jämna steg med snabbt växande molntjänster bör DR-planen regelbundet ses över, testas och köras av resurser med aktuell kunskap om Azure och dess tjänster.
- De tekniska återställningsstegen bör återspegla prioriteten för komponenten och lösningen för organisationen. Till exempel återställs kärndataflöden för företag före ad hoc-dataanalyslabb.
- De tekniska återställningsstegen bör följa ordningen på arbetsflödena (vanligtvis från vänster till höger) när grundkomponenterna eller tjänsten som Key Vault har återställts. Den här strategin säkerställer att överordnade beroenden är tillgängliga och att komponenter kan testas på rätt sätt.
- När den stegvisa planen har slutförts bör en total tid för aktiviteter med beredskap erhållas. Om den här summan överskrider det överenskomna målet för återställningstid (RTO) finns det flera tillgängliga alternativ:
- Automatisera valda återställningsprocesser (där det är möjligt).
- Leta efter möjligheter att köra valda återställningssteg parallellt (där det är möjligt). Observera dock att den här strategin kan kräva ytterligare DR-körresurser.
- Upplyfta viktiga komponenter till högre nivåer av tjänstnivåer, till exempel PaaS, där Microsoft tar större ansvar för service recovery-aktiviteter.
- Utöka RTO med intressenter.
DR-testning
Azure Cloud-tjänstens karaktär ger begränsningar för eventuella scenarier för DR-testning. Därför är vägledningen att stå upp en DR-prenumeration med dataplattformskomponenterna eftersom de skulle vara tillgängliga i den sekundära regionen.
Från den här baslinjen kan DR-plan-runbooken köras selektivt, med särskild uppmärksamhet på de tjänster och komponenter som kan distribueras och valideras. Den här processen kräver en kuraterad testdatauppsättning som gör det möjligt att bekräfta de tekniska och affärsmässiga valideringskontrollerna enligt planen.
En DR-plan bör testas regelbundet för att inte bara se till att den är uppdaterad, utan också för att bygga "muskelminne" för teamen som utför redundans- och återställningsaktiviteter.
- Data- och konfigurationssäkerhetskopior bör också regelbundet testas för att säkerställa att de är "lämpliga för ändamålet" för att stödja återställningsaktiviteter.
Det viktigaste området att fokusera på under ett DR-test är att se till att de normativa stegen fortfarande är korrekta och att de uppskattade tidpunkterna fortfarande är relevanta.
- Om instruktionerna återspeglar portalens skärmar i stället för kod – bör instruktionerna verifieras minst var 12:e månad på grund av förändringens takt i molnet.If the instructions reflect the portal screens rather than code – the instructions should be validated least every 12 months due to the cadence of change in cloud.
Även om ambitionen är att ha en helt automatiserad DR-process kan fullständig automatisering vara osannolik på grund av händelsens sällsynthet. Därför rekommenderar vi att du etablerar återställningsbaslinjen med DSC-infrastrukturen (Desired State Configuration) som kod (IaC) som används för att leverera plattformen och sedan lyfta när nya projekt bygger på baslinjen.
- Med tiden när komponenter och tjänster utökas bör en NFR framtvingas, vilket kräver att pipelinen för produktionsdistribution omstruktureras för att tillhandahålla täckning för dr.
Om dina runbook-tidsinställningar överskrider din RTO finns det flera alternativ:
- Utöka RTO med intressenter.
- Minska den tid som krävs för återställningsaktiviteter, via automatisering, körning av uppgifter parallellt eller migrering till högre molnservernivåer.
Azure Chaos Studio
Azure Chaos Studio är en hanterad tjänst för att förbättra motståndskraften genom att mata in fel i dina Azure-program. Med Chaos Studio kan du samordna felinmatning på dina Azure-resurser på ett säkert och kontrollerat sätt med hjälp av experiment. I produktdokumentationen finns en beskrivning av vilka typer av fel som stöds för närvarande.
Den aktuella iterationen av Chaos Studio omfattar endast en delmängd av Azure-komponenter och -tjänster. Tills fler felbibliotek har lagts till är Chaos Studio en rekommenderad metod för isolerad återhämtningstestning i stället för fullständig system-DR-testning.
Mer information om Chaos Studio finns i Dokumentation om Azure Chaos Studio.
Azure Site Recovery
För IaaS-komponenter skyddar Azure Site Recovery de flesta arbetsbelastningar som körs på en virtuell dator som stöds eller fysisk server
Det finns starka riktlinjer för:
- Köra ett haveriberedskapstest för virtuella Azure-datorer
- Köra en dr-redundansväxling till en sekundär region
- Köra en återställning till den primära regionen
- Aktivera automatisering av en DR-plan
Relaterade resurser
- Arkitektur för återhämtning och tillgänglighet
- Affärskontinuitet och haveriberedskap
- Säkerhetskopiering och haveriberedskap för Azure-program
- Återhämtning i Azure
- Sammanfattning av serviceavtal (SLA)
- Fem metodtips för att förutse fel
Nästa steg
Nu när du har lärt dig hur du distribuerar scenariot kan du läsa en sammanfattning av dr-serien för Azure-dataplattform.