Share via

Rekommendationer för att utforma en strategi för nödåtgärder

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

OE:08 Utveckla en effektiv metod för nödåtgärder. Se till att din arbetsbelastning genererar meningsfulla hälsosignaler över infrastruktur och kod. Samla in resulterande data och använd dem för att generera åtgärdsbara aviseringar som utför nödåtgärder via instrumentpaneler och frågor. Definiera tydligt mänskliga ansvarsområden, till exempel jourrotationer, incidenthantering, åtkomst till nödsituationsresurser och körning av postmortems.

Den här guiden beskriver rekommendationerna för att utforma en strategi för nödåtgärder. Vissa problem som uppstår under en arbetsbelastnings livscykel är tillräckligt kritiska för att motivera att de deklareras i nödsituationer. Du kan implementera noggrant kontrollerade och fokuserade processer och procedurer som ditt team kan följa för att säkerställa att ett problem hanteras på ett lugnt och ordnat sätt. Nödsituationer höjer naturligtvis allas stressnivåer och kan leda till en kaotisk miljö om ditt team inte är väl förberett. För att minimera stress och förvirring kan du utforma en svarsstrategi, dela svarsstrategin med din organisation och utföra regelbunden utbildning om nödåtgärder.

Viktiga designstrategier

En strategi för nödåtgärder bör vara en ordnad och väldefinierad uppsättning processer och procedurer. Varje process och procedur bör ha skript för att säkerställa att varje steg förlopp ditt team mot att snabbt och säkert lösa ett problem. Om du vill utveckla en strategi för nödåtgärder bör du överväga följande översikt:

  • Förutsättningar
    • Utveckla en observerbarhetsplattform
    • Skapa en plan för incidenthantering
  • Incidentfaser
    • Identifiering
    • Behållare
    • Triage
  • Faser efter incident
    • Rotorsaksanalys (RCA)
    • Efteranalys
  • Pågående aktivitet
    • Nödinsatsövningar

Följande avsnitt innehåller rekommendationer för var och en av dessa faser.

Överskådlighet

För att ha en robust strategi för nödåtgärder måste du ha en robust observerbarhetsplattform på plats. Din observerbarhetsplattform bör ha följande egenskaper:

  • Holistisk övervakning: Se till att du noggrant övervakar din arbetsbelastning ur ett infrastruktur- och programperspektiv.

  • Utförlig loggning: Aktivera utförlig loggning för dina komponenter för att hjälpa till med undersökningar när du sorterar ett problem. Strukturera loggar så att de är enkla att hantera. Skicka automatiskt loggar till datamottagare som ska förberedas för analys.

  • Användbara instrumentpaneler: Skapa hälsomodellbaserade instrumentpaneler som är skräddarsydda för varje team i organisationen. Olika team ansvarar för olika aspekter av arbetsbelastningens hälsa.

  • Åtgärdsbara aviseringar: Skapa aviseringar som är användbara för dina arbetsbelastningsteam. Undvik aviseringar som inte kräver åtgärder från dina team. För många aviseringar av det här slaget kan leda till att personer ignorerar eller blockerar aviseringsaviseringar.

  • Automatiska meddelanden: Se till att lämpliga team automatiskt tar emot aviseringar som kräver åtgärder från dem. Supportteamet på nivå 1 bör till exempel få aviseringar för alla aviseringar, medan säkerhetstekniker bara ska få aviseringar för säkerhetshändelser.

Mer information finns i Rekommendationer för att utforma och skapa ett ramverk för observerbarhet.

Incidenthanteringsplan

Grunden för en strategi för nödåtgärder är en plan för incidenthantering. Precis som en plan för haveriberedskap definierar du tydligt och noggrant roller, ansvarsområden och procedurer för en incidenthanteringsplan. Planen bör vara ett versionskontrollerat dokument som är föremål för regelbundna granskningar som säkerställer att den är uppdaterad.

Definiera tydligt följande komponenter i din plan.

Roller

Identifiera en incidenthanteringshanterare. Den här personen äger incidenten från initiering till reparation till rotorsaksanalysen. En incidenthanteringshanterare ser till att processer följs och att lämpliga parter informeras när svarsteamet utför sitt arbete.

Identifiera en postmortem-ledare. Den här personen ser till att postmortems utförs strax efter att incidenten har lösts. De skapar en rapport som hjälper dig att tillämpa de resultat som kommer från incidenten.

Processer och procedurer

Arbetsbelastningsteamet bör definiera och förstå nödsituationskriterier. När ditt team fastställer att ett ärende är allvarligt kan du deklarera en katastrof och initiera haveriberedskapsplanen. I mindre allvarliga fall kanske problemet inte uppfyller kriterierna för en katastrof. Men du bör fortfarande betrakta problemet som en nödsituation, vilket kräver att man initierar beredskapsplanen. Nödsituationer kan vara problem som är interna för din arbetsbelastning, eller som kan bero på ett problem med ett beroende av din arbetsbelastning. Supportteamet måste kunna avgöra om ett problem som rapporteras av externa användare uppfyller nödsituationskriterierna, även om de inte har någon insyn i det underliggande problemet.

Definiera kommunikation och eskaleringsplaner exakt. Baserat på typen av aviseringsmeddelande som de får kontrollerar du att din nivå 1-support enkelt kan kontakta lämpliga team för att eskalera problem till. Se till att de vet vilken typ av kommunikation som är lämplig för interna och externa parter. I kommunikations- och eskaleringsplaner inkluderar du en lista över jourschemat och personalen.

I den övergripande planen inkluderar du inneslutnings- och sorteringsskript. Teamen följer de här stegvisa procedurerna när de utför sina inneslutnings- och sorteringsfunktioner. Inkludera en beskrivning av vad som definierar en incidentstängning.

Andra objekt som ska inkluderas

Dokumentera alla standardverktyg som kommer att användas under incidenter för intern kommunikation, till exempel Microsoft Teams, och för att spåra aktiviteter under incidentens gång, till exempel biljettverktyg eller planeringsverktyg för kvarvarande uppgifter.

Dokumentera dina autentiseringsuppgifter för nödsituationer, även kallade break-glass-konton. Ta med en stegvis guide som beskriver hur de ska användas.

Skapa instruktioner för beredskapstest och registrera när övningar har utförts.

Dokumentera eventuella juridiska eller regelmässiga åtgärder som krävs, till exempel att kommunicera dataintrång.

Incidentidentifiering

När du har en väl utformad observerbarhetsplattform som övervakar avvikelser och automatiskt aviseringar om dem kan du snabbt identifiera problem och fastställa deras allvarlighetsgrad. Om problemet anses vara en nödsituation kan planen initieras. I vissa fall meddelas inte supportteamet via observerbarhetsplattformen. Kunder kan rapportera problem till supporten med hjälp av kommunikationsvägar för supportteamet. Eller så kan de kontakta personer som de regelbundet arbetar med, till exempel kontoansvariga eller virtuella datorer. Oavsett hur supportteamet meddelas bör de alltid följa samma steg för att verifiera problemet och fastställa allvarlighetsgraden. Avvikelse från svarsplanen kan orsaka stress och förvirring.

Behållare

Det första steget i problemreparationen är att innehålla problemet för att skydda resten av din arbetsbelastning. En inneslutningsstrategi beror på typen av problem, men det innebär vanligtvis att den berörda komponenten tas bort från sökvägarna för arbetsbelastningsflödet. Du kan till exempel stänga av en resurs eller ta bort den från nätverksroutningsvägar. Systemadministratörer, ingenjörer och seniora utvecklare bör samarbeta för att utforma inneslutningsstrategier. Inneslutningen bör begränsa explosionsradien för problem och underhålla arbetsbelastningsfunktioner i ett degraderat tillstånd tills problemet har lösts. Om en berörd komponent måste vara tillgänglig för att utföra sortering är det viktigt att dess åtkomst till resten av arbetsbelastningen blockeras. Så mycket som möjligt bör du bara komma åt komponenten via en sökväg som är separerad från arbetsbelastningen och resten av systemen.

Triage

När du har innehållt problemet kan du börja sortera arbetet. Vilka steg du följer under sortering beror på typen av problem. Teamet för ett visst område av arbetsbelastningsstöd bör skapa procedurer för incidenter som är relaterade till deras team. Säkerhetsteam bör till exempel prioritera säkerhetsproblem och följa skript som de utvecklar. Det är viktigt att teamen följer väldefinierade skript när de arbetar med sina triage-insatser. Dessa skript bör vara stegvisa processer som inkluderar återställningsprocesser för att ångra ändringar som är ineffektiva eller kan orsaka andra problem. Använd verktyg för loggaggregering och analys utanför hyllan för att effektivt undersöka problem som kräver djupgående analys. När problemet har lösts följer du väldefinierade processer för att på ett säkert sätt föra tillbaka den berörda komponenten till sökvägarna för arbetsbelastningsflödet.

RCA-rapportering

Serviceavtalen (SLA) till dina kunder kan kräva att du måste utfärda RCA-rapporter inom en viss tidsperiod efter att incidenten har lösts. Incidentägaren bör skapa RCA-rapporterna. Om det inte är möjligt kan en annan person som har ett nära samarbete med incidentägaren skapa RCA-rapporterna. Den här strategin säkerställer en korrekt redovisning av incidenten. Organisationer har vanligtvis en definierad RCA-mall med riktlinjer för hur information presenteras och vilka typer av information som kan eller inte kan delas. Om du behöver skapa en egen mall och riktlinjer kontrollerar du att de granskas och godkänns av intressenterna.

Incidentpostmortems

En opartisk person bör leda skuldlösa obduktioner. I postmortem-sessioner delar alla sina resultat från en incident. Varje team som var inblandade i incidenthanteringen bör representeras av personer som arbetade med incidenten. Dessa personer bör komma till sessionen som förberetts med exempel på de områden som var framgångsrika och områden som kan förbättras. Sessionen är inte ett forum för att tilldela skulden för incidenten eller problem som kan ha uppstått under svaret. Postmortem-ledaren bör lämna sessionen med en tydlig lista över åtgärdsobjekt som fokuserar på förbättringar, till exempel:

  • Förbättringar av svarsplanen. Processer eller procedurer kan behöva omvärderas och skrivas om för att bättre samla in lämpliga åtgärder.

  • Förbättringar av observerbarhetsplattformen. Tröskelvärden kan behöva omvärderas för att fånga den specifika typen av incident tidigare, eller så kan ny övervakning behöva implementeras för att fånga beteende som inte har redovisats.

  • Förbättringar av arbetsbelastningen. Incidenten kan exponera en säkerhetsrisk i arbetsbelastningen som måste åtgärdas som en permanent reparation.

Överväganden

En alltför aggressiv svarsstrategi kan leda till falska larm eller onödiga eskaleringar.

På samma sätt kan aggressivt implementering av automatisk skalning eller andra självåterställningsåtgärder för att svara på tröskelvärdesöverträdelser leda till onödiga utgifter och hanteringsbörda. Du kanske inte känner till de exakta tröskelvärden som ska anges för aviseringar och automatiska åtgärder som skalning. Utför testning i lägre miljöer och i produktion för att hjälpa dig att fastställa rätt tröskelvärden för dina krav.

Azure-underlättande

Azure Monitor är en omfattande lösning för att samla in, analysera och svara på övervakningsdata från molnmiljöer och lokala miljöer. Den innehåller en robust aviseringsplattform som du kan konfigurera för automatiska meddelanden och andra åtgärder, till exempel automatisk skalning och andra självåterställningsmekanismer.

Använd Monitor för att integrera maskininlärning. Automatisera och optimera incidenttriage och proaktiva åtgärder. Mer information finns i AIOps och maskininlärning i Monitor.

Log Analytics är ett robust analysverktyg som är inbyggt i Monitor. Du kan använda Log Analytics för att köra frågor mot aggregerade loggar och få insikter om din arbetsbelastning.

Microsoft erbjuder Azure-relaterad incidentberedskapsutbildning. Mer information finns i Introduktion till Azure-incidentberedskap och Incidentberedskap.

Checklista för utmärkt drift

Se den fullständiga uppsättningen rekommendationer.

Checklista för utmärkt drift