Skriv en incidentplan för ett litet programvaruteam

En incidentplan ska hjälpa ditt team att hantera avbrutet arbete på ett ordnat sätt. Välj ett viktigt flöde i programvaran och beskriv hur ett fel upptäcks, vem som fattar beslut och vilket underlag som krävs för att återuppta driften.

Beskriv det berörda flödet

I det påhittade exemplet drabbar incidenten I-72 en kundportal. Startsidan svarar, men nya ärenden kan inte sparas fullständigt med en bilaga. Ärendet A-72 och filen F-72 är bara testexempel. Det handlar inte om en driftstörning som observerats här.

I detta fall räcker det inte att startsidan är tillgänglig för att avsluta incidenten. Planen anger hela ärendeflödet, inklusive fillagring, rollkontroll och efterföljande arbete. Den anger också vilka ändringar som är tillåtna under hanteringen.

Gör ett insatskort med roller

Google SRE beskriver tydliga roller, en aktuell arbetsdokumentation och bekräftade överlämningar. Små team kan samla flera roller hos en person. Det måste ändå vara tydligt vem som samordnar, vem som ändrar systemet och vem som delar information.

Tabellen beskriver planerade steg, inte en utförd återställning. Utse en ersättare och en nåbar eskaleringskontakt. Arbetsdokumentet måste vara tillgängligt även när portalen ligger nere.

Planera kommunikation som en egen uppgift

Ange vem som informerar berörda personer och tjänster. En statusuppdatering anger känd påverkan, aktuellt arbetsläge och nästa överenskomna informationstillfälle. En misstänkt orsak markeras som en hypotes; en obestyrkt återställningstid förmedlas inte som ett löfte.

Vid personalbyte under incidenten lämnas det aktuella läget över och övertagandet bekräftas. Även misslyckade åtgärder och öppna kontroller ingår. Ett enbart skickat meddelande säkerställer inte att den nya samordningen har tagits över.

Skilj återupptagen drift från efterarbete

Före återupptagandet kontrollerar teamet det berörda flödet i en lämplig miljö med de överenskomna testfallen. Om det går att återgå till ett tidigare läge beror också på data som ändrats under tiden; en omstart ensam bevisar inte återställning.

Dokumentera vem som godkänner återupptagandet och vilka öppna uppgifter som följs vidare. Den efterföljande orsaksanalysen kan förbättra planen, men behöver inte likställas med den första stabiliseringen. Öva kortet med ett godkänt scenario och rätta saknade kontakter, åtkomster eller kontrollsteg.

Källor

• Google SRE: Managing Incidents