Kundaktiviteter krävs
Före incident
För Azure-tjänster
- Var bekant med Azure Service Health i Azure-portalen. 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 på Azure-portalen – 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 den tekniska valideringen av små och medelstora företag slutföras så att intressenterna kan godkänna tjänstå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 Contoso – Delade tjänster och källsystem för företag
- 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ödgrupper 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/SaaS-partner
Återställa grunden för dataplattformen
- Det här steget är startpunkten för plattformsåterställningsaktiviteter
- 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 Om Azure-tjänsten och -komponenten i den här serien
- Den här processen bör även omfatta aktiviteter som bindningen till företagets delade tjänster, säkerställande av anslutning till åtkomst/autentisering och validering av att loggens avlastning fungerar, samtidigt som anslutningen till både överordnade och nedströmsprocesser 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 DR-återställningsprocess
- Den här överlämningen bör innehålla en bekräftelse av den aktuella tidsstämpeln för data/processer
- Om kärndataprocesser för företag ska köras bör de enskilda lösningarna göras medvetna om detta – inkommande/utgående flöden, till exempel
Å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 – viktiga företagsprocesser framför ad hoc-labb, till exempel
- När valideringsstegen har slutförts sker en överlämning till de underordnade lösningarna för att starta dr-återställningsprocessen
Ö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 köra om eller spela upp datainmatningsprocesserna från och med den tidpunkten framåt
- Med godkännande från både affärs- och tekniska intressenter skulle ett reservfönster väljas. Helst, 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änsterna, inklusive PaaS- och IaaS-systemen, kommer att finnas kvar trots haverihä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"), tjänstsupport 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 och/eller säkerhetskopieringskraft, 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 stödgrupper
- Små och medelstora företag som ska slutföra test-/granskningscykeln för den tekniska återställningen
- Påverkade företagsägare, inklusive godkännare av tjänståterställning
- Påverkade 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
- Påverkan på nedströmssystem – driftstöd
- Överordnade källsystem – driftsstöd
- Kontakter med delade tjänster för företag. Till exempel stöd för åtkomst/autentisering, säkerhetsövervakning och gatewaystöd
- Externa leverantörer eller tredjepartsleverantörer, inklusive supportkontakter för molnleverantörer
- Arkitekturdesign
- Beskriv detaljerna i scenariot från slutpunkt till E2E och bifoga all tillhörande supportdokumentation
- Beroenden
- Visa en lista över alla komponentens 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ågot av förutsättningarna inte har uppfyllts
- Technical Recovery – stegvisa instruktioner
- Körningsordning
- Stegbeskrivning
- Krav för steg
- Detaljerade processsteg för varje diskret åtgärd, inklusive URL:ens
- Valideringsinstruktioner, inklusive de bevis som krävs
- Förväntad tid för att slutföra varje steg, inklusive beredskap
- 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 genomför valideringen och godkännandet
- Granskning och godkännande av affärsintressent
- Kontaktuppgifter för företagsresurser
- Affärsverifieringsstegen enligt den tekniska återställningen ovan
- Bevisspåret som krävs från business-godkännaren som signerar återställningen
- Recovery Post-krav
- Överlämna till driftsstöd för att köra dataprocesserna för att hålla systemet uppdaterat
- Överlämna nedströmsprocesserna och lösningarna – bekräfta datum- och anslutningsinformationen för DR-systemet
- Bekräfta återställningsprocessen slutförd med DR-ledningen – bekräfta bevisspåret och slutförd runbook
- Meddela säkerhetsadministration att utökade åtkomstbehörigheter kan tas bort från DR-teamet
Bildtexter
- Vi rekommenderar att du tar med systemskärmskärmar av varje stegprocess. Dessa skärmbilder hjälper till att åtgärda beroendet av system-SMF för att slutföra uppgifterna
- För att minska risken från 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 de grundläggande komponenterna/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 är över den överenskomna rto-metoden 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.
- Lyfta upp viktiga komponenter till högre nivåer av tjänstnivåer, till exempel PaaS, där Microsoft tar större ansvar för serviceåterställningsaktiviteter
- 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 upprättar återställningsbaslinjen med DSC 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öra uppgifter parallellt eller migrera 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 här
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
- 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.