Dela 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 i 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änskligt ansvar, 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 utformar du en svarsstrategi, delar svarsstrategin med din organisation och utför regelbunden utbildning om nödåtgärder.

Viktiga designstrategier

En strategi för nödåtgärder bör vara en ordnad, 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. Tänk på följande översikt för att utveckla en strategi för nödåtgärder:

  • Förhandskrav
    • Utveckla en observerbarhetsplattform
    • Skapa en plan för incidenthantering
  • Incidentfaser
    • Detection
    • Inneslutning
    • Sortera
  • Faser efter incident
    • Rotorsaksanalys (RCA)
    • Efteranalys
  • Pågående aktivitet
    • Nödfallstest

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

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 aviseringar.

  • 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 dina säkerhetstekniker endast bör få aviseringar för säkerhetshändelser.

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

Skapa en plan för incidenthantering

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 ska vara ett versionsstyrt dokument som omfattas av 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

Ditt arbetsbelastningsteam 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 beredskapsplanen initieras. 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å vilken typ av aviseringsmeddelande 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 kommunikation och eskaleringsplaner innehåller du en lista över jourschemat och personalen.

I den övergripande planen inkluderar du inneslutnings- och sorteringsskript. Teamen följer dessa stegvisa procedurer när de utför sina inneslutnings- och triagefunktioner. Ta med 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.

Agera på observerbarhetsutlösare

När du har en väl utformad observerbarhetsplattform som övervakar avvikelser och automatiskt aviseringar på 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 att stödja 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 öka stress och förvirring.

Definiera inneslutningsprocedurer

Det första steget i problemreparation är att innehålla problemet för att skydda resten av arbetsbelastningen. En inneslutningsstrategi beror på typen av problem, men det innebär vanligtvis att den berörda komponenten tas bort från arbetsbelastningsflödessökvägarna. 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.

Definiera triage-procedurer

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 med 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 aggregerings- och analysverktyg utanför hyllan för att effektivt undersöka problem som kräver djupanalys. 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 arbetsbelastningsflödesvägarna.

Generera RCA-incidentrapporter

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 arbetade nära 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 dina riktlinjer kontrollerar du att de granskas och godkänns av intressenter.

Hold incident postmortems

En opartisk person bör leda oskyldiga obduktioner. I postmortemsessioner 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 individer bör komma till sessionen förberedda med exempel på de områden som lyckades 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 upp 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.

Att tänka på

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

På samma sätt kan aggressiv 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 driftskvalitet

Se den fullständiga uppsättningen rekommendationer.

Checklista för driftskvalitet