Vikten av incidenthantering
Genom att bygga vidare på de principer och metoder för övervakning som beskrivs i en annan modul från den här utbildningsvägen får du nu lära dig vad du ska göra när övervakningen avslöjar ett problem. Om du får en åtgärdsavisering som meddelar dig att dina system inte fungerar som förväntat är det utlösaren för ett svar för att hantera problemet.
Vad är en incident?
Incidenthantering handlar om de åtgärder du vidtar när en incident inträffar, men vad exakt utgör en incident? Svaret kan vara subjektivt; inte ens alla tekniker är överens om vad en incident är. Om du ställer frågan i olika branscher och organisationer får du många olika svar.
Vissa märker alla störningar som incidenter, oavsett om kunderna påverkas eller inte. I den här modulen kan vi komma överens om att en incident definieras som en tjänststörning: en förekomst eller ett villkor som påverkar användarens möjlighet att använda de tjänster som de förlitar sig på. Exempel är när systemen är nere eller inte fungerar på ett sätt som påverkar kunderna.
Vad är incidenthantering?
Att förhindra alla problem är ett berömvärt, men omöjligt mål. Saker kommer att gå fel, så vi behöver en plan för att begränsa påverkan på våra slutanvändare och återställa driften till det normala så snabbt som möjligt.
Nyckeln är att svara snabbt i stället för att reagera. En reaktion tenderar att vara mer impulsiv och baserad i nuet, utan hänsyn till långsiktiga effekter. Ett svar är väl genomtänkt, organiserat och informationsbaserat.
Din incidenthanteringsmetod avgör din effektivitet på:
- Förstå vad som händer (diagnostisera problemet).
- Triagering (fastställa hur brådskande det är) och prioritera problemet.
- Använda rätt resurser för att åtgärda problemet.
- Kommunicera med intressenter om problemet.
När du har åtgärdat problemet kan du sedan lära dig av incidenten genom en granskningsprocess efter incidenten. Det är ett viktigt ämne som har en helt separat modul värd att diskutera.
Mäta prestanda för incidenthantering
Du kanske känner till förkortningen TTR, som definieras som "tid att återställa", "tid att reparera" eller "tid att återställa". Alla dessa varianter refererar till samma sak: den totala tid det tar för dig att få tillbaka tjänster till en plats där de kan återgå till att uppfylla kundernas förväntningar.
Det här måttet är ett sätt att mäta hur bra teamen presterar när de svarar på incidenter. Ju snabbare du återställer/reparerar/återställer tjänsten, desto mindre påverkas avbrotten eller den försämrade tjänsten.
Det är viktigt att veta hur väl din organisation hanterar incidenthantering. Varje år släpper Organisationen DevOps Research and Assessment (DORA) en State of DevOps-rapport. Några viktiga resultat i 2019-rapporten fokuserade på incidenthanteringsprestanda.
- Rapporten klassificerade teknikteam som kan identifiera, svara och åtgärda tjänststörningar på mindre än en timme som "elit eller högpresterande".
- De som kunde återhämta sig från incidenter på under 24 timmar klassificerades som "medelstora artister".
- "Låg presterande" är de som tar mellan en vecka och en månad att återhämta sig från tjänststörningar.
Skillnaden mellan dessa nivåer är betydande. Studien fann att elit-/högpresterande team återhämtar sig från incidenter 2 604 gånger snabbare än sina "lågpresterande" kamrater. Elite/high performers distribuerar också till produktion 208 gånger oftare.
Varför och hur svarar och återhämtar sig elitartister så mycket snabbare än resten? Det beror åtminstone delvis på att de förstår vikten av att ha en bra grundläggande svarsplan som redan finns när saker oundvikligen går fel.
När du går igenom den här modulen får du lära dig mer om egenskaperna och livscykeln för en incident och hur du använder den kunskapen för att skapa en egen grundläggande plan.