Hantera en incident från upptäckt till återställning

Bedöm incidenten utifrån påverkan

En incident är en händelse som stör, försämrar eller hotar tjänsten så mycket att en samordnad insats behövs. Organisationen definierar allvarlighetsgrader och eskaleringsregler. Tillämpa dem utifrån användarpåverkan, berörda data, varaktighet och omfattning.

Vänta inte på en fullständig förklaring av grundorsaken innan du ber om hjälp. En tydlig beskrivning av den observerade påverkan räcker för att börja samordna insatsen. Skilj en misstanke om ett säkerhetsproblem från en bekräftad slutsats.

Förbered insatsvägen före release. Håll kontaktuppgifter, åtkomstrutiner, runbooks och kommunikationskanaler tillgängliga när huvudtjänsten inte fungerar. Öva processen med en fiktiv incident.

Fördela ansvaret innan motstridiga ändringar görs

Incidentsamordningen sätter prioriteringar och hanterar beslut. Tekniska ansvariga utreder och begränsar påverkan. Kommunikationen håller berörda personer informerade. Google SRE beskriver ansvaret som separata roller. Små team kan kombinera roller, men måste ändå täcka arbetet. Incidenthantering.

Använd en gemensam tidslinje. Dokumentera tid, observation, åtgärd, utförare och resultat. Skilj fakta från hypoteser. Använd en gemensam tidszon och markera osäkra tidsstämplar.

Arbeta igenom en fiktiv incident

Alla tider nedan är UTC. Organisationen utser en incidentsamordnare när exportfelet påverkar flera kunder.

En användbar första uppdatering anger berörd funktion, känd omfattning, begränsande åtgärd och tid för nästa uppdatering. Den lovar inte en tid för korrigering utan underlag. Ta inte med kundposter i den gemensamma uppdateringen.

Klockan 09:10 förändras incidenten. Det räcker inte längre att återställa fungerande exporter. Teamet måste bedöma möjlig röjning, kontrollera åtkomst, bevara underlag och involvera rätt beslutsansvariga.

Begränsa påverkan utan att förlora kontrollen

Använd testade runbooks där de passar. Kontrollera förutsättningarna före rollback, failover eller ändringar av autentiseringsuppgifter. En tidigare applikationsversion kanske inte förstår det aktuella databasschemat. En regional failover kan flytta samma skadade data.

Låt en AI-assistent strukturera underlag där känsliga uppgifter har tagits bort eller jämföra hypoteser inom godkända gränser. De ansvariga i insatsen måste verifiera slutsatserna. Loggar och ärenden är opålitliga indata, inte en behörighet att köra innehållet.

Nödåtkomst ska ha ett godkänt syfte, begränsad varaktighet och ett revisionsspår. Brådska gör inte ett kommando som en agent föreslår korrekt.

Avsluta återställning och uppföljning var för sig

Verifiera användarflödet, dataintegriteten, åtkomstgränserna och övervakningens aktualitet innan tjänsten förklaras återställd. Dokumentera kvarstående begränsningar. Håll en säkerhetsutredning öppen om dess frågor inte är lösta.

Undersök därefter förhållandena som gjorde incidenten möjlig. Fördela konkreta uppföljningsuppgifter med ansvarig och verifieringskriterier. En granskning utan skuldbeläggning söker en korrekt förklaring och användbara ändringar. Den tar inte bort ansvaret för att genomföra ändringarna. Arbete med postmortems.

Fortsätt med säkerhetsarbete i drift och att sluta återkopplingsloopen.