INCIDENT MANAGEMENT

1. Hvad er Incident Management?

Incident Management (IM) er processen for at håndtere uforudsete driftsforstyrrelser og fejl i en organisation – især i IT-miljøer – på en hurtig, struktureret, sporbar og forretningskritisk måde.

Målet er at sikre, at et incident:

✔ Bliver opdaget og triageret hurtigt
✔ Minimerer forstyrrelse af drift og kunder
✔ Bliver tildelt korrekt severity og prioritet
✔ Håndteres af rette personer og teams
✔ Dokumenteres med fuld sporbarhed

IM-processer fokuserer på:

• Detection → Hvordan opdages incidentet?
• Classification → Severity, kategori, påvirkning, forretningskritikalitet
• Assignment → Hvem tager ejerskab?
• Resolution → Hvad gøres for at løse situationen?
• Communication → Hvem skal informeres, hvornår og hvordan?
• Post-Incident Review → Hvad lærte vi, og hvad skal forbedres?

Det er vigtigt at forstå:

Incident Management handler primært om respons, governance og kommunikation – ikke om logindsamling eller fejludbedringsværktøjer.
Den tekniske fejlfindingsproces foregår i overvågningssystemer, logging-frameworks og driftsmiljøer – men incident-processen skaber struktur, prioritet, ansvarlighed og transparens.

2. Incident-modning kræver CMDB, relationer og servicekontekst

Effektiv Incident Management kræver indsigt i:

• Hvilke systemer, services og Configuration Items (CI’er) der er påvirket
• Hvem der bruger eller er afhængige af disse komponenter
• Hvordan upstream/downstream dependencies påvirker forretningen
• Hvilken severity der faktisk er korrekt

CMDB’en er derfor kernen i moderne IM.

Eksempel:

Et incident på en database-node påvirker ikke kun databasen.
Det kan påvirke:

• API-services
• Authentication flows
• Tenant-isolation
• Workflows der bruger databasen
• Overvågning og autoscaling
• Downstream dashboards og rapportværktøjer

Dette kortlægges ikke via manuelle noter, men gennem CMDB-relationer og dependencies, som automatisk viser impact-scope.

3. Affected Items – nøglen til severity, governance og audit

Incident Management skal kunne svare på:

• Hvad er påvirket?
• Hvem er påvirket?
• Hvorfor er de påvirket?
• Hvor stort er impact?
• Hvilken severity er korrekt?
• Hvor er årsagen?

IM-processen binder teknisk information sammen med governance og forretningskritikalitet.

4. Severity-modeller, standarder og triage

Moderne organisationer arbejder med standardiserede severity-modeller, f.eks.:

Standard Severity-modeller giver:

✔ Forventningsafstemning
✔ Klar prioritet
✔ Accelereret handling fra rette team
✔ Korrekt kommunikation til ledelse og kunder

Practicle understøtter severity som en del af:

• Klassifikation
• Governance
• Kommunikation
• SLA-behandling
• KPI’er og rapportering

5. Task Management og Incident Workflows

Incident Management bliver stærkest når den:

• Understøtter real-time kommunikation og kommentarer
• Bryder opgaver ned i konkrete hændelsestrin
• Viser incident-livscyklus i timeline eller kalender
• Dokumenterer alle handlinger for audit
• Giver klar ansvarlighed via Incident Owner

Workflows i Incident Management handler om:

• Samarbejde
• Hurtighed
• Prioritet
• Transparens

Ikke om automatisk remediations – det tager overvågnings- eller automatiseringssystemer sig af.

6. Samspil med overvågning, logging og automatisering

Et moderne Incident Management-værktøj skal kunne:

• Modtage incidents automatisk via API/webhook fra overvågningssystemer
• Vise kontekst gennem CMDB-dependencies
• Integrere med Knowledge Base for troubleshooting guides
• Koordinere kommunikation og statusopdateringer
• Lade tekniske værktøjer stå for fejludbedring og automationsflows

Incidents løses ikke i IM-værktøjet.
De organiseres, prioriteres og dokumenteres i IM-værktøjet.

Løsningen på problemerne lever i:

• Observability-stack (Wazuh, Prometheus, Elastic, OpenSearch, Grafana m.fl.)
• DevOps-/automation scripts
• Infrastruktur- og applikationslogs

Incident-værktøjets rolle er governance, kommunikation, struktur og sporbarhed.

7. Audit & revision – hvad skal en revisor kunne se?

En revisor skal kunne åbne et incident og se:

• Hvem oprettede incidentet
• Hvem tog ejerskab
• Hvilken severity blev tildelt – og hvorfor
• Hvilke CI’er i CMDB’en var påvirket
• Hvilke services blev påvirket
• Hvornår det blev opdaget, eskaleret og løst
• Hvilke handlinger, kommentarer og kommunikation der fandt sted
• Relation til ændringer, opgaver, releases eller SOP’er

Practicle gemmer hele incidentets tidslinje og historik:

• Statusændringer
• Severity-ændringer
• Tildelte teams og ejere
• Kommentarer
• Relationer til tickets, tasks og changes
• Hændelsesforløb og timestampet handlinger

Dette gør revisors arbejde nemt, og organisationens governance stærkere.

8. Practicle v4 – en komplet Incident Management-løsning

Practicle v4 tilbyder en fuld incidentplatform med:

9. Genialiteten i Practicle

Practicle adskiller sig på samme måde ved at forene:

• Hurtig registrering og triage
• CMDB-drevet impact clarity
• Affected Items baseret på relationer
• Severity-modeller med governance
• Tasks, kommentarer, ansvar & samarbejde
• Timeline, historik og audit-parathed
• Integration med overvågning, CI/CD og automationssystemer

Det gør Practicle til et afbalanceret, moderne og samarbejdsfokuseret Incident Management-værktøj, der styrker:

✔ Drift
✔ Governance
✔ Compliance
✔ Stabilitet
✔ Synlighed
✔ Problemforebyggelse