bmc_hub/fremtidige planer/eskaleringsplan-drift.md

PLAN – Eskaleringsplan / Drift i BMC Hub

Status: Fremtidig plan – ikke implementeret.

Denne plan er en udvidelse af den eksisterende Drift-funktion. Den må ikke fjerne, omdøbe eller ændre eksisterende Drift-adfærd uden udtrykkelig, bagudkompatibel migrering.

1. Formål

Der skal bygges et nyt modul i The Hub, som styrer:

• overvågning af kunders og BMC's driftsressourcer
• eskaleringsplaner
• fejlsituationer og driftsalarmer
• automatisk analyse af hvilke dele af infrastrukturen der sandsynligvis er berørt
• oprettelse af driftssager
• maintenance mode
• forslag til kundekommunikation
• intern eskalering
• SLA-regler
• historik og dokumentation

Systemet skal ikke kun vise, at noget er nede.

Det skal også kunne forklare:

Hvad er nede?
Hvem er berørt?
Hvor tror vi fejlen ligger?
Hvorfor tror systemet det?
Hvad skal vi gøre nu?
Hvem skal kontaktes?
Må vi selv fejlrette?
Kræver noget godkendelse?
Skal kunden informeres?

---

2. Placering i Hub

Under kundens stamdata oprettes et nyt, selvstændigt faneblad:

Eskaleringsplan

Fanen supplerer den eksisterende Drift-fane. Drift-fanen bevarer dens nuværende alarmoversigt og historik. Den nye fane viser og administrerer kun eskaleringsplanens ressourcer, flows, SLA, kontaktregler, godkendelser og historik for eskaleringer.

Herfra skal man kunne se kundens:

• driftsressourcer
• overvågede devices
• services
• eskaleringsflows
• kontaktpersoner
• kommunikationsregler
• SLA-regler
• godkendelsesregler
• aktuelle og tidligere driftsproblemer

Men selve en driftsressource må ikke nødvendigvis eje én kunde.

En internetforbindelse, switch, firewall eller anden ressource kan være delt mellem flere kunder.

---

3. Driftsressourcer

Der skal oprettes et generelt objekt:

Driftsressource

Eksempler:

• Internetforbindelse
• Gateway
• Firewall
• Switch
• Access Point
• Server
• VM
• Hosting cluster
• UPS
• WAN
• LAN
• Kundens router
• SaaS-service
• VPN
• DNS
• Microsoft 365
• Datacenter
• Bygning
• Etage
• Netværkssegment

En ressource skal kunne tilknyttes:

• én eller flere kunder
• andre driftsressourcer
• en eller flere overvågningskilder
• kontaktpersoner
• services
• eskaleringsplaner

---

4. Ressourcehierarki

Driftsressourcer skal kunne forbindes hierarkisk.

Eksempel:

Internetforbindelse
        │
        ▼
     Gateway
     /     \
    ▼       ▼
Switch 1   Switch 2
    │         │
    ▼         ▼
Bygning 1  Bygning 2
    │
 ┌──┴─────┐
 ▼        ▼
Kunde A   Kunde B

Dette hierarki bruges til at analysere, hvor fejlen sandsynligvis ligger.

---

5. Visuel eskalerings-/flow-builder

Eskaleringsplanen skal bygges grafisk.

Det skal ligne eksempelvis:

• Power Automate
• Node-RED
• n8n
• workflow builder

Brugeren skal kunne trække blokke ind på et canvas og forbinde dem.

Eksempel:

[Internet nede]
       |
       v
[Gateway oppe?]
   /          \
 JA            NEJ
 |              |
 v              v
[Check        [Mistanke:
Switches]      udbyder]
 |
 v
[Switch 1 oppe?]
 /          \
NEJ          JA
|             |
v             v
Bygning 1     Check næste gren
berørt

---

6. Typer af blokke i flow-builderen

Systemet skal bl.a. have følgende node-typer:

Trigger

Eksempel:

Device bliver DOWN

eller:

Internetforbindelse bliver DOWN

Statuscheck

Eksempel:

Er Gateway-01 UP?

Kombination

Eksempel:

Gateway = UP
OG
Switch-01 = DOWN
OG
Switch-02 = UP

Timer

Eksempel:

Har forbindelsen været nede i 15 minutter?

Impact

Eksempel:

Markér Bygning 1 som berørt

Intern handling

Eksempel:

Opret driftssag

Intern notification

Eksempel:

Send SMS til driftsteam

Godkendelse

Eksempel:

Kræver kundens godkendelse før hardwareudskiftning

Kommunikation

Eksempel:

Foreslå driftsbesked

Må aldrig automatisk sende besked til kunden.

---

7. Overvågningsintegrationer

Eksisterende integrationer, der allerede leverer Drift-events, skal fortsætte uændret. Første nye integrationer eller udvidelser:

Uptime Kuma

Bruges eksempelvis til:

• ping
• HTTP
• TCP
• serverstatus
• internetforbindelser
• gateway-status

UniFi

Bruges eksempelvis til:

• gateways
• switches
• access points
• sites
• internetstatus
• device-status

Den eksisterende UISP-integration bevares som en separat eksisterende kilde; UniFi tilføjes uden at ændre UISP- eller Uptime Kuma-events, deres synkronisering eller deres nuværende visning.

Arkitekturen skal være generisk, så senere integrationer kan tilføjes, eksempelvis:

• Prometheus
• UISP
• PRTG
• Zabbix
• SNMP
• Azure Monitor
• Microsoft Graph
• VMware
• Proxmox
• custom API

Overvågningssystemerne skal primært levere events og status.

Hubben skal selv afgøre, hvad eventet betyder.

---

8. Eksempel – internetforbindelse

Antag:

Internet
   │
Gateway
   │
 ┌─┴─────────┐
 │           │
Switch 1   Switch 2
 │           │
Bygning 1  Bygning 2

Hvis:

Internet monitor = DOWN
Gateway = UP
Switch 1 = DOWN
Switch 2 = UP

kan Hub konkludere:

Internetforbindelsen er sandsynligvis OK.

Problemet ser ud til at være omkring:
Bygning 1 / Switch 1.

Det betyder ikke nødvendigvis:

Switch 1 er defekt.

Systemet skal i stedet kunne skrive:

Fejlen er lokaliseret til området omkring Switch 1 / Bygning 1.

Mulige årsager kunne være:

• switch
• strøm
• fiber/kabel
• uplink
• lokalt netværk

---

9. Eksempel – kun én kunde berørt

Hvis:

Gateway = UP
Switch = UP
Kunde A router = DOWN
Kunde B router = UP
Kunde C router = UP

skal Hub kunne konkludere:

Fejlen ser ud til kun at påvirke Kunde A.

Systemet må ikke automatisk konkludere, at BMC's udstyr er defekt.

---

10. Hvorfor-visning

Dette er en vigtig funktion.

Når Hub har vurderet et problem, skal teknikeren kunne trykke:

Hvorfor?

Så vises hele beslutningsstien.

Eksempel:

07:42 Internet monitor: DOWN

07:42 Gateway-01: UP

07:42 Switch-B1: DOWN

07:42 Switch-B2: UP

07:43 Router Kunde A: DOWN

07:43 Router Kunde B: DOWN

--------------------------------

Regel:
Gateway UP
+
Switch B1 DOWN
+
Switch B2 UP

Resultat:
Sandsynligt problem i Bygning 1.

Den aktive vej gennem diagrammet skal visuelt markeres.

Eksempel:

Internet DOWN
      ↓
Gateway UP ✓
      ↓
Switch B1 DOWN ✕
      ↓
Bygning 1 berørt

---

11. Systemets sikkerhed omkring konklusioner

Hub må gerne lave en teknisk vurdering.

Men der skal skelnes mellem:

Observeret

og

Vurderet

Eksempel:

Observeret:
Switch B1 svarer ikke.

Vurdering:
Fejlen ser ud til at være lokaliseret til Bygning 1.

Ikke:

Switch B1 er defekt.

medmindre det faktisk kan konstateres.

---

12. Driftssag / Eskaleringssag

Når et relevant flow trigges, skal Hub kunne:

Opret driftssag

Driftssagen kan være:

• automatisk oprettet
• manuelt oprettet

Den skal indeholde:

• starttidspunkt
• berørte ressourcer
• berørte kunder
• berørte services
• nuværende status
• severity
• eskaleringsplan
• ansvarlig
• events
• timeline
• vurderet årsag
• hvorfor-visning
• SLA
• notifications
• kundekommunikation
• maintenance status

---

13. Severity

Forslag:

INFO
WARNING
MAJOR
CRITICAL

Eksempel:

BMC Hostingcenter nede:

CRITICAL

En enkelt AP hos en kunde:

WARNING

Severity skal kunne defineres i flow-builderen.

---

14. BMC's egen hosting

BMC's egen infrastruktur skal kunne have meget aggressive eskaleringsplaner.

Eksempel:

Hosting cluster DOWN
        ↓
CRITICAL
        ↓
Opret driftssag
        ↓
SMS til alle relevante medarbejdere
        ↓
Push notification
        ↓
Start eskaleringsplan straks

Det må godt ske automatisk internt.

Begrænsningen omkring manuel godkendelse gælder kundekommunikation.

---

15. SLA

Eskaleringsplaner skal understøtte SLA.

Eksempel:

0 min:
Registrér event

5 min:
Verificér fejlen

15 min:
Opret driftssag

30 min:
Kontakt ansvarlig

60 min:
Eskalér til senior tekniker

4 timer:
SLA-grænse

Der skal kunne være:

• responstid
• løsningstid
• tidsfrister
• advarsler
• escalation deadlines

---

16. Godkendelsesregler

Under kunden skal det være muligt at definere:

Må BMC fejlrette uden godkendelse?
JA / NEJ

Eksempel:

Fejlsøgning:
Tilladt

Genstart:
Tilladt

Firmware-opdatering:
Kræver godkendelse

Hardwareudskiftning:
Kræver godkendelse

Omkostninger over 2.500 kr:
Kræver godkendelse

Der skal kunne angives hvem der må godkende.

---

17. Kontaktpersoner og driftstilmelding

Kontaktpersoner skal kunne abonnere på drift.

Ikke kun:

Kunde A

men også eksempelvis:

Internetforbindelse 047

eller:

Bygning 1

eller:

Office 365

eller:

Hovedkontorets netværk

En kontakt kan dermed være tilmeldt flere driftsressourcer.

---

18. Delte forbindelser

En internetforbindelse kan være delt mellem flere kunder.

Eksempel:

Internetforbindelse #1028

benyttes af:

Kunde A
Kunde B
Kunde C
Kunde D

Hub skal derfor kunne beregne:

Berørte kunder: 4

Potentielle modtagere: 12

---

19. Impact engine

Systemet skal kunne beregne påvirkningen ud fra diagrammet.

Eksempel:

Internetforbindelsen
        ↓
Gateway
        ↓
Switch Bygning 1
        ↓
Kunde A
Kunde B
Kunde C

Hvis Switch Bygning 1 går ned:

Berørt:
Kunde A
Kunde B
Kunde C

Ikke berørt:
Kunde D
Kunde E

---

20. Driftsbeskeder

Fra en driftssag skal der være:

Generér driftsbesked

Hub kan automatisk foreslå:

• modtagere
• emne
• tekst
• hvilke kunder der er berørt
• hvilken bygning/service der er berørt
• kendt status

Men:

Kundekommunikation må ALDRIG sendes automatisk.

Der skal altid være et menneskeligt klik:

GODKEND OG SEND

---

21. AI / automatisk tekstforslag

Hub kan eksempelvis foreslå:

Driftsforstyrrelse – Bygning 1

Vi oplever i øjeblikket problemer med netværksforbindelsen
i Bygning 1.

Vores overvågning viser, at øvrige dele af forbindelsen
fungerer normalt, og problemet ser derfor ud til at være
lokaliseret til netværket i Bygning 1.

Vi undersøger fejlen og sender en ny status, når der er
yderligere information.

Brugeren kan redigere teksten før udsendelse.

---

22. Beskedtyper

Systemet bør have mindst:

Driftsforstyrrelse

Opdatering

Planlagt vedligehold

Forlænget nedetid

Drift normaliseret

---

23. Foreslå kommunikation

Flow-builderen skal kunne have en node:

Foreslå kundekommunikation

Eksempel:

Hvis nedetid > 15 minutter
        ↓
Foreslå driftbesked

Dette åbner eksempelvis:

Der er 17 relevante modtagere.

Vil du oprette en driftsbesked?

Ikke automatisk sende den.

---

24. Maintenance mode

Der skal være en sagstype:

Drift / Vedligehold

I sagen kan man vælge:

Sæt devices i maintenance

Eksempel:

Gateway-01
Switch-01
Switch-02
AP-01

Mens sagen er aktiv:

Maintenance = aktiv

Når sagen lukkes:

Maintenance = automatisk fjernet

---

25. Maintenance slutdato

Ved maintenance kan man sætte:

Start:
24-09-2026 22:00

Forventet slut:
25-09-2026 01:00

Hvis maintenance stadig er aktiv efter sluttidspunktet:

ADVARSEL

Maintenance skulle være afsluttet for 38 minutter siden.

---

26. Events under maintenance

Events skal ikke slettes.

Hvis et device går ned under maintenance:

Event registreret

men eksempelvis:

Alarm undertrykt:
Device er i maintenance via sag #1842

Så historikken stadig er komplet.

---

27. Kritiske undtagelser

Nogle alarmer må aldrig ignoreres under maintenance.

Eksempel:

UPS batterifejl

Brandalarm

Temperatur kritisk

Hosting cluster helt nede

De kan markeres:

Ignore maintenance = YES

---

28. Timeline

Driftssagen skal have én samlet timeline.

Eksempel:

07:41 Uptime Kuma meldte Internet DOWN

07:42 Hub kontrollerede Gateway-01

07:42 Gateway-01 svarede

07:42 Switch-B1 svarede ikke

07:42 Switch-B2 svarede

07:43 Hub vurderede:
Problem sandsynligvis Bygning 1

07:44 Driftssag #1932 oprettet

07:46 Christian åbnede sagen

07:48 Driftsbesked genereret

07:49 Driftsbesked godkendt af Christian

07:50 14 modtagere informeret

---

29. Audit log

Alle automatiske beslutninger skal kunne spores.

Gem eksempelvis:

regel-id
regel-version
input-data
status på devices
resultat
beslutningssti
timestamp
handlinger
brugerhandlinger

Det skal være muligt bagefter at forstå præcis:

Hvorfor gjorde Hub dette?

---

30. Overstyring

Teknikeren skal kunne overstyre systemets vurdering.

Eksempel:

Hub siger:

Mistanke: Netværk Bygning 1

Tekniker kan ændre til:

Bekræftet årsag:
Fiberbrud mellem hovedbygning og Bygning 1

Den oprindelige automatiske vurdering skal dog stadig gemmes i historikken.

---

31. Skabeloner

Der skal kunne bygges templates.

Eksempel:

Standard internetkunde

Standard UniFi-site

Delt erhvervsforbindelse

Hostingkunde

Microsoft 365 kunde

Ved oprettelse af ny kunde kan man eksempelvis vælge:

Anvend:
Standard internetkunde

og derefter blot tilknytte de rigtige devices.

---

32. Regelversionering

Hvis en eskaleringsplan ændres, må historiske driftssager ikke ændre sig.

Eksempel:

Eskaleringsplan v3

blev brugt på hændelsen.

Selv hvis planen senere bliver v4, skal sagen stadig kunne vise den regelversion, der faktisk blev brugt.

---

33. Systemarkitektur

Overvågningskilder bør sende normaliserede events til Hub.

Eksempel:

{
  "source": "uptime_kuma",
  "resource_id": 812,
  "event": "down",
  "timestamp": "...",
  "metadata": {}
}

Hub behandler eventet gennem:

Monitoring Event
      ↓
Resource Mapping
      ↓
Escalation Engine
      ↓
Impact Engine
      ↓
Rule Flow
      ↓
Actions

---

34. Central event-model

Hub skal ikke være afhængig af et bestemt overvågningssystem.

Normaliser eksempelvis status til:

UP
DOWN
DEGRADED
UNKNOWN
MAINTENANCE

Så samme flow kan bruge:

Uptime Kuma
UniFi
Prometheus
UISP
andet

---

35. UI – kundens stamdata

Fanen:

Eskaleringsplan

kunne have undermenuerne:

OVERSIGT
RESSOURCER
FLOW
KONTAKTER
SLA
GODKENDELSER
HISTORIK

---

36. UI – live flow

Når en driftssag er aktiv, skal diagrammet kunne vises live.

Eksempel:

          [Internet DOWN]
                 ↓
            [Gateway]
              UP ✓
                 ↓
        ┌────────┴────────┐
        ↓                 ↓
 [Switch B1]        [Switch B2]
    DOWN ✕               UP ✓
        ↓
 [BYGNING 1]
    BERØRT

Aktive nodes skal fremhæves.

Teknikeren skal kunne klikke på en node og se:

Status
Sidste check
Datakilde
Device
Regel
Resultat

---

37. Drift dashboard

På Hub's eksisterende Drift-side bør aktive eskaleringssager vises.

Eksempel:

CRITICAL  1
MAJOR     2
WARNING   4

Kort kan eksempelvis vise:

Norva24

Netværk – Bygning 1

Start: 07:42
Varighed: 28 min

3 kunder berørt
14 kontaktpersoner

Mistanke:
Lokalt netværk Bygning 1

---

38. MVP – første version

Første version bør fokusere på:

Driftsressourcer

Kunde ↔ ressource relationer

Delte ressourcer

Uptime Kuma integration

UniFi integration

Visuel flow-builder

UP/DOWN conditions

AND / OR conditions

Tidsbetingelser

Opret driftssag

Impact analyse

Hvorfor-visning

Timeline

Maintenance mode

Kontaktperson ↔ driftsressource

Generér driftsbesked

MANUEL godkendelse og send

Audit log

---

39. Version 2

Efter MVP:

Avancerede SLA-regler

SMS

Push

Telefoneskalering

Webhook actions

Flere overvågningssystemer

AI-genereret statusbesked

Automatisk root-cause forslag

Dependencies mellem services

Service maps

Statistik

Rapportering

SLA-performance

---

40. Absolutte regler

Disse regler skal overholdes:

1. Kundebeskeder må aldrig sendes automatisk.

Hub må:

foreslå besked
foreslå modtagere
generere tekst

men et menneske skal altid godkende udsendelsen.

2. Automatiske vurderinger skal kunne forklares.

Man skal altid kunne se:

Hvorfor nåede systemet frem til dette resultat?

3. Observation og konklusion skal adskilles.

Eksempel:

Observation:
Switch svarer ikke.

Vurdering:
Problemet ser ud til at være lokaliseret omkring switchen.

4. En driftsressource kan deles af flere kunder.

5. Alle beslutninger og ændringer skal logges.

6. Arkitekturen må ikke være låst til Uptime Kuma eller UniFi.

---

41. Eksempel på komplet hændelse

07:40
Internet monitor melder DOWN.

07:41
Gateway responderer stadig.

07:41
Hub følger eskaleringsdiagrammet.

07:41
Switch Bygning 1 = DOWN.

07:41
Switch Bygning 2 = UP.

07:42
Hub beregner impact.

Berørt:
Kunde A
Kunde B
Kunde C

Ikke berørt:
Kunde D
Kunde E

07:42
Hub vurderer:

"Problemet ser ud til at være lokaliseret til
netværket i Bygning 1."

07:42
Driftssag oprettes.

07:43
Teknikeren kan åbne "Hvorfor?"

Internet DOWN
→ Gateway UP
→ Switch B1 DOWN
→ Switch B2 UP
→ Bygning 1 berørt

07:45
Hub foreslår:

"Der er 8 kontaktpersoner tilmeldt de berørte
driftsressourcer.

Opret driftsbesked?"

Teknikeren trykker JA.

Hub genererer teksten.

Teknikeren retter evt. teksten.

Teknikeren trykker:

GODKEND OG SEND

---

42. Målet

Det færdige system skal gøre, at en tekniker ved en alarm ikke kun ser:

Device DOWN

men i stedet får:

HVAD SKER DER?

Netværksproblem Bygning 1


HVEM ER BERØRT?

3 kunder
8 kontaktpersoner


HVORFOR TROR HUB DET?

Gateway = UP
Switch B1 = DOWN
Switch B2 = UP


HVAD SKAL VI GØRE?

1. Kontrollér Switch B1
2. Kontrollér uplink
3. Kontakt onsite person hvis nødvendigt


KRÆVER DET GODKENDELSE?

Fejlsøgning: NEJ
Hardwareudskiftning: JA


KUNDEN INFORMERET?

NEJ

[ GENERÉR DRIFTSBESKED ]

Det er den retning, jeg ville bygge hele Eskaleringsplan / Drift-funktionen efter.

---

43. Sameksistens og bagudkompatibilitet – bindende krav

43.1 Eksisterende Drift-funktioner

Følgende skal bevares under hele implementeringen:

• Drift-siden med aktive alarmer, filtre, tællere og alarmhistorik
• kundens eksisterende fane Drift
• Uptime Kuma- og UISP-events og deres synkronisering
• eksisterende monitor-til-kunde-koblinger
• blacklist af driftsenheder
• godkendelse af alarmer
• eksisterende oprettelse og sammenkædning af sager fra driftsevents
• eksisterende API-endpoints og deres svar til nuværende klienter

Den nye fane Eskaleringsplan må ikke erstatte eller omdøbe Drift-fanen.

43.2 Data og migrering

Nye driftsressourcer, ressourceforbindelser, eskaleringsflows og abonnements- relationer oprettes som nye tabeller eller additive felter. De eksisterende drift_events, drift_devices, drift_customer_mappings og links til sager må ikke slettes, nulstilles eller have betydning ændret.

En eksisterende monitor-kobling til én kunde skal fortsat virke. Delte ressourcer modelleres i den nye ressource-relation, så én ressource kan have flere kunder uden at ændre betydningen af den eksisterende monitor-kobling.

Alle migreringer skal være additive og reversible. Før produktionsmigrering skal der være en læseprøve, som dokumenterer antal eksisterende events, mappings, blacklists og sagslinks før og efter migreringen.

43.3 Status og API-kompatibilitet

Den eksisterende Drift-statusmodel fortsætter uændret for eksisterende endpoints og skærme. Den nye eskaleringsmotor kan arbejde med normaliserede observationer som UP, DOWN, DEGRADED, UNKNOWN og MAINTENANCE, men skal oversætte dem ved grænsen til den eksisterende Drift-model.

Eksisterende filtrering, tællere og historik må derfor fortsat forstå aktive, løste og godkendte alarmer. Nye API’er lægges under nye endpoints; eksisterende Drift-endpoints ændres ikke i første version.

43.4 Sager og maintenance

Når et flow opretter en driftssag, skal det genbruge den eksisterende sag-oprettelse og bevare linket mellem driftsevent og sag. En ny eskaleringssag må have ekstra metadata om ressourcer, impact, flow-version og beslutningssti, men må ikke miste sagens kunde, status, historik eller eksisterende sagslinks.

Maintenance på ressourcer er en ny, sagstyret undertrykkelse af eskalerings- handlinger. Den holdes helt adskilt fra Hubs eksisterende system-maintenance. Ressource-maintenance må ikke ændre systemets maintenance-status, og system- maintenance må ikke automatisk ændre en ressources maintenance.

43.5 Implementeringsrækkefølge

1. Kortlæg og test eksisterende Drift-data, endpoints og visninger.
2. Tilføj den additive ressource- og relationsmodel uden at ændre eksisterende Drift-data.
3. Tilføj fanen Eskaleringsplan under kunden.
4. Tilføj læsning, impact, audit og hvorfor-visning.
5. Tilføj flow-handlinger og sag-oprettelse med dubletbeskyttelse.
6. Tilføj resource-maintenance og kundekommunikationsforslag.

Hver fase frigives først, når eksisterende Drift-visning, events, monitor-koblinger og sagslinks er verificeret uændrede.