Alarmering og hændelseshåndtering

Når en alarm udløses, signalerer den ofte en hændelse. En hændelse er en uplanlagt afbrydelse af en tjeneste eller en forringelse af en tjenestes kvalitet.

Eksempler omfatter et servernedbrud, en database, der ikke svarer, eller en pludselig stigning i en applikations fejlrate.

Alarmer konfigureres ud fra forskellige målepunkter eller logge. Her er nogle almindelige udløsere:

• Grænseværdier: CPU-forbrug > 90 % i 5 minutter.
• Fejlrate: HTTP 500-fejl > 1 % af forespørgslerne.
• Tilgængelighed: Tjenesten svarer ikke.
• Logmønstre: Bestemte fejlmeddelelser optræder i loggene.

Alle alarmer haster ikke lige meget. Vi kategoriserer dem efter alvorlighed for at prioritere reaktionerne:

• Kritisk: Tjenesten er nede eller alvorligt forringet. Der skal handles med det samme.
• Advarsel: Et muligt problem er under udvikling og kræver snart opmærksomhed.
• Information: En ikke-hastende hændelse, kun til orientering.

Når en alarm udløses, skal den nå frem til de rigtige personer. Almindelige underretningskanaler omfatter:

• E-mail: Til mindre hastende advarsler eller informationsalarmer.
• Chat (f.eks. Slack): God til at holde teamet orienteret og stille en fælles diagnose.
• SMS/telefonopkald: Til kritiske alarmer, der kræver øjeblikkelig opmærksomhed, ofte via værktøjer som PagerDuty til tilkaldevagter.

Hændelseshåndtering er den strukturerede proces til håndtering og løsning af hændelser. Et typisk forløb omfatter:

1. Registrering: En alarm udløses.
2. Prioritering: Vurder alvorlighed og påvirkning.
3. Diagnose: Identificer den grundlæggende årsag.
4. Løsning: Løs problemet.
5. Gendannelse: Gendan den fulde funktionalitet.
6. Evaluering: Lær af hændelsen.

En runbook er en detaljeret vejledning, der beskriver trinnene til at løse almindelige hændelser. Runbooks er afgørende for:

• Konsistens: At sikre, at hændelser håndteres ensartet.
• Hastighed: At forkorte tiden til diagnose og løsning.
• Vidensoverførsel: At sætte nye teammedlemmer i stand til at reagere effektivt.

Efter en hændelse er løst, er en evaluering efter hændelsen (eller en evaluering) vigtig. Det er en analyse uden fokus på skyld, som fokuserer på:

• Hvad skete der?
• Hvorfor skete det?
• Hvad kunne have forhindret det?
• Hvilke handlinger kan vi iværksætte for at forhindre, at det sker igen?

Målet er løbende forbedring, ikke at placere skyld.

Vi har undersøgt, hvordan alarmer fungerer som systemets alarm og udløses af bestemte betingelser. Vi har lært om forskellige alvorlighedsniveauer og underretningskanaler.

Det er afgørende at forstå forløbet for håndtering af hændelser og bruge runbooks for at håndtere problemer effektivt. Endelig fremmer evalueringer efter hændelser løbende læring og forbedring af systemet.