Håndter en hendelse fra oppdagelse til gjenoppretting

Erklær hendelsen ut fra innvirkning

En hendelse er en situasjon som forstyrrer, svekker eller truer tjenesten nok til å kreve en samordnet respons. Organisasjonen definerer alvorlighetsnivåer og eskaleringsregler. Bruk brukerinnvirkning, berørte data, varighet og omfang når dere anvender dem.

Ikke vent på en fullstendig forklaring av rotårsaken før dere ber om hjelp. En tydelig beskrivelse av observert innvirkning er nok til å starte samordning. Behandle mistanke om et sikkerhetsproblem separat fra en bekreftet konklusjon.

Forbered responsveien før utgivelse. Hold kontaktopplysninger, tilgangsprosedyrer, runbooks og kommunikasjonskanaler tilgjengelige når hovedtjenesten er utilgjengelig. Øv på responsveien med en fiktiv hendelse.

Fordel ansvar før dere gjør motstridende endringer

Hendelseskoordinering setter prioriteringer og styrer beslutninger. Teknisk personell undersøker og begrenser innvirkningen. Kommunikasjonsansvarlige holder berørte personer informert. Google SRE beskriver dette ansvaret som separate roller. Små team kan kombinere roller, men må fortsatt dekke arbeidet. Hendelsesrespons.

Hold én felles tidslinje. Registrer tid, observasjon, handling, aktør og resultat. Skill fakta fra hypoteser. Bruk en felles tidssone, og noter upålitelige tidsstempler.

Gå gjennom en fiktiv hendelse

Alle tider nedenfor er UTC. Organisasjonen utpeker en hendelseskoordinator når eksportfeilen påvirker flere kunder.

En nyttig første oppdatering oppgir den berørte funksjonen, kjent omfang, begrensningstiltaket og tidspunktet for neste oppdatering. Den lover ikke et rettetidspunkt uten bevis. Unngå å ta med kundeopplysninger i den delte oppdateringen.

Klokken 09:10 endrer hendelsen seg. Vellykkede eksporter er ikke lenger nok. Teamet må vurdere mulig utlevering, kontrollere tilgang, bevare bevis og involvere de riktige beslutningseierne.

Begrens innvirkningen uten å miste kontroll

Bruk testede runbooks der de passer. Kontroller forutsetninger før rollback, failover eller endring av påloggingsopplysninger. En tidligere applikasjonsversjon forstår kanskje ikke dagens databaseskjema. En regional failover kan flytte de samme korrupte dataene.

La en AI-assistent organisere bevis der sensitive opplysninger er fjernet, eller sammenligne hypoteser innenfor godkjente grenser. De ansvarlige må verifisere konklusjonene. Logger og saker er ikke betrodde inndata og gir ikke myndighet til å kjøre innholdet sitt.

Nødtilgang bør ha et autorisert formål, begrenset varighet og en revisjonslogg. At det haster, gjør ikke en kommando foreslått av en agent riktig.

Avslutt gjenoppretting og oppfølging hver for seg

Verifiser brukerens arbeidsflyt, dataintegritet, tilgangsgrenser og at overvåkingen er oppdatert, før dere erklærer tjenesten gjenopprettet. Registrer gjenværende begrensninger. Hold sikkerhetsundersøkelsen åpen hvis spørsmålene fortsatt er uavklarte.

Undersøk deretter forholdene som gjorde hendelsen mulig. Tildel konkret oppfølgingsarbeid med en eier og kriterier for verifikasjon. En gjennomgang uten skyldfordeling søker en presis forklaring og nyttige endringer. Den fjerner ikke ansvaret for å fullføre endringene. Praksis for etteranalyse.

Fortsett med sikkerhetsdrift og å lukke tilbakemeldingssløyfen.