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 går fel, så vi behöver en plan för att begränsa effekten på våra slutanvändare och returnera åtgärder 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 "time to recover", "time to remediate" eller "time to restore". Alla dessa varianter refererar till samma idé: hur lång tid det tar att få tillbaka en tjänst till ett tillstånd där den återigen uppfyller kundernas förväntningar.

Olika ramverk använder olika namn för det här konceptet. DORA:s aktuella vägledning avser misslyckad återställningstid för distribution, ett av dess fem prestandamått för programvaruleverans. Den mäter hur snabbt ett team kan återställa från en misslyckad distribution som orsakar ett produktionsproblem, vilket gör det till en av de starkaste indikatorerna för incidenthanteringskapacitet.

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 tjänsten, desto mindre påverkan har avbrott eller degraderad tjänst på användarna.

Det är viktigt att veta hur väl din organisation hanterar incidenthantering. DORA:s forskning fortsätter att visa ett starkt samband mellan återställningsprestanda och övergripande prestanda för programvaruleverans. I stället för att behandla benchmark-band som fasta mål använder du återställningstid för att jämföra tjänster över tid, identifiera flaskhalsar i svarsprocessen och mäta om dina förbättringar fungerar.

Team med starka metoder för incidenthantering återhämtar sig snabbare än lågpresterande jämnåriga och tenderar att kombinera den takten med starkare leveransprestanda överlag. Bra övervakning, tydligt ägarskap, övade svarsplaner och automatisering bidrar alla till att minska återställningstiden.

Varför återhämtar sig team med starka incidenthanteringsmetoder 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 lär du dig om egenskaperna och livscykeln för en incident och hur du använder den kunskapen för att skapa en egen grundläggande plan.