Håndtér en hændelse fra opdagelse til gendannelse

Erklær hændelsen ud fra påvirkningen

En hændelse forstyrrer, forringer eller truer tjenesten så meget, at en koordineret indsats er nødvendig. Organisationen definerer alvorlighedsniveauer og eskaleringsregler. Anvend dem ud fra brugerpåvirkning, berørte data, varighed og omfang.

Vent ikke på en fuldstændig forklaring af grundårsagen, før du beder om hjælp. En klar beskrivelse af den observerede påvirkning er nok til at starte koordinering. Skeln mellem mistanke om et sikkerhedsproblem og en bekræftet konklusion.

Forbered beredskabets arbejdsgang før release. Hold kontaktoplysninger, adgangsprocedurer, runbooks og kommunikationskanaler tilgængelige, når hovedtjenesten er utilgængelig. Afprøv forløbet med en fiktiv hændelse.

Fordel ansvar, før ændringer kommer i konflikt

Hændelseskoordinering fastlægger prioriteter og styrer beslutninger. Tekniske deltagere undersøger og afhjælper. Kommunikation holder berørte personer orienteret. Google SRE beskriver ansvaret som særskilte roller. Små teams kan kombinere roller, men skal stadig dække arbejdet. Hændelseshåndtering.

Bevar én fælles tidslinje. Registrér tidspunkt, observation, handling, aktør og resultat. Skeln mellem fakta og hypoteser. Brug samme tidszone, og markér upålidelige tidsstempler.

Gennemgå en fiktiv hændelse

Alle tidspunkter nedenfor er UTC. Organisationen udpeger en hændelseskoordinator, når eksportfejlen berører flere kunder.

En nyttig første statusmeddelelse beskriver den berørte funktion, det kendte omfang, afhjælpningen og tidspunktet for næste opdatering. Den lover ikke et rettelsestidspunkt uden belæg. Medtag ikke kundeposter i den fælles opdatering.

Kl. 09:10 ændrer hændelsen karakter. Det er ikke længere tilstrækkeligt at gendanne fungerende eksporter. Teamet skal vurdere mulig videregivelse, kontrollere adgang, bevare beviser og inddrage de rette beslutningstagere.

Afhjælp uden at miste kontrollen

Brug afprøvede runbooks, hvor de passer. Kontrollér forudsætninger før rollback, failover eller ændringer af adgangsoplysninger. En tidligere applikationsversion forstår måske ikke det aktuelle databaseskema. En regional failover kan flytte de samme korrupte data.

Lad en AI-assistent organisere renset dokumentation eller sammenligne hypoteser inden for godkendte grænser. Beredskabet skal verificere dens konklusioner. Logs og tickets er input, der ikke er betroet, og giver ingen bemyndigelse til at udføre deres indhold.

Nødadgang bør have et godkendt formål, begrænset varighed og et auditspor. Hastværk gør ikke en agents foreslåede kommando korrekt.

Afslut gendannelse og opfølgning hver for sig

Verificér brugerens arbejdsgang, dataintegritet, adgangsgrænser og overvågningens aktualitet, før tjenesten erklæres gendannet. Registrér resterende begrænsninger. Hold sikkerhedsundersøgelsen åben, hvis spørgsmål stadig er uløste.

Undersøg bagefter de forhold, der gjorde hændelsen mulig. Fordel konkret opfølgning med en ansvarlig og kriterier for verifikation. Et review uden skyldplacering søger en præcis forklaring og nyttige ændringer. Det fjerner ikke ansvaret for at gennemføre ændringerne. Postmortem-praksis.

Fortsæt med sikkerhedsdrift og at lukke feedbacksløjfen.