# 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: ```text 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: ```text [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: ```text Device bliver DOWN ``` eller: ```text Internetforbindelse bliver DOWN ``` ### Statuscheck Eksempel: ```text Er Gateway-01 UP? ``` ### Kombination Eksempel: ```text Gateway = UP OG Switch-01 = DOWN OG Switch-02 = UP ``` ### Timer Eksempel: ```text Har forbindelsen været nede i 15 minutter? ``` ### Impact Eksempel: ```text Markér Bygning 1 som berørt ``` ### Intern handling Eksempel: ```text Opret driftssag ``` ### Intern notification Eksempel: ```text Send SMS til driftsteam ``` ### Godkendelse Eksempel: ```text Kræver kundens godkendelse før hardwareudskiftning ``` ### Kommunikation Eksempel: ```text 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: ```text Internet │ Gateway │ ┌─┴─────────┐ │ │ Switch 1 Switch 2 │ │ Bygning 1 Bygning 2 ``` Hvis: ```text Internet monitor = DOWN Gateway = UP Switch 1 = DOWN Switch 2 = UP ``` kan Hub konkludere: ```text 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: ```text Gateway = UP Switch = UP Kunde A router = DOWN Kunde B router = UP Kunde C router = UP ``` skal Hub kunne konkludere: ```text 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: ```text 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: ```text 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: ```text Observeret: Switch B1 svarer ikke. Vurdering: Fejlen ser ud til at være lokaliseret til Bygning 1. ``` Ikke: ```text Switch B1 er defekt. ``` medmindre det faktisk kan konstateres. --- # 12. Driftssag / Eskaleringssag Når et relevant flow trigges, skal Hub kunne: ```text 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: ```text INFO WARNING MAJOR CRITICAL ``` Eksempel: BMC Hostingcenter nede: ```text CRITICAL ``` En enkelt AP hos en kunde: ```text WARNING ``` Severity skal kunne defineres i flow-builderen. --- # 14. BMC's egen hosting BMC's egen infrastruktur skal kunne have meget aggressive eskaleringsplaner. Eksempel: ```text 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: ```text 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: ```text Må BMC fejlrette uden godkendelse? JA / NEJ ``` Eksempel: ```text 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: ```text Kunde A ``` men også eksempelvis: ```text Internetforbindelse 047 ``` eller: ```text Bygning 1 ``` eller: ```text Office 365 ``` eller: ```text 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: ```text Internetforbindelse #1028 ``` benyttes af: ```text Kunde A Kunde B Kunde C Kunde D ``` Hub skal derfor kunne beregne: ```text Berørte kunder: 4 Potentielle modtagere: 12 ``` --- # 19. Impact engine Systemet skal kunne beregne påvirkningen ud fra diagrammet. Eksempel: ```text Internetforbindelsen ↓ Gateway ↓ Switch Bygning 1 ↓ Kunde A Kunde B Kunde C ``` Hvis Switch Bygning 1 går ned: ```text 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: ```text GODKEND OG SEND ``` --- # 21. AI / automatisk tekstforslag Hub kan eksempelvis foreslå: ```text 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: ```text Driftsforstyrrelse Opdatering Planlagt vedligehold Forlænget nedetid Drift normaliseret ``` --- # 23. Foreslå kommunikation Flow-builderen skal kunne have en node: ```text Foreslå kundekommunikation ``` Eksempel: ```text Hvis nedetid > 15 minutter ↓ Foreslå driftbesked ``` Dette åbner eksempelvis: ```text Der er 17 relevante modtagere. Vil du oprette en driftsbesked? ``` Ikke automatisk sende den. --- # 24. Maintenance mode Der skal være en sagstype: ```text Drift / Vedligehold ``` I sagen kan man vælge: ```text Sæt devices i maintenance ``` Eksempel: ```text Gateway-01 Switch-01 Switch-02 AP-01 ``` Mens sagen er aktiv: ```text Maintenance = aktiv ``` Når sagen lukkes: ```text Maintenance = automatisk fjernet ``` --- # 25. Maintenance slutdato Ved maintenance kan man sætte: ```text Start: 24-09-2026 22:00 Forventet slut: 25-09-2026 01:00 ``` Hvis maintenance stadig er aktiv efter sluttidspunktet: ```text 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: ```text Event registreret ``` men eksempelvis: ```text 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: ```text UPS batterifejl Brandalarm Temperatur kritisk Hosting cluster helt nede ``` De kan markeres: ```text Ignore maintenance = YES ``` --- # 28. Timeline Driftssagen skal have én samlet timeline. Eksempel: ```text 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: ```text 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: ```text Mistanke: Netværk Bygning 1 ``` Tekniker kan ændre til: ```text 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: ```text Standard internetkunde Standard UniFi-site Delt erhvervsforbindelse Hostingkunde Microsoft 365 kunde ``` Ved oprettelse af ny kunde kan man eksempelvis vælge: ```text Anvend: Standard internetkunde ``` og derefter blot tilknytte de rigtige devices. --- # 32. Regelversionering Hvis en eskaleringsplan ændres, må historiske driftssager ikke ændre sig. Eksempel: ```text 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: ```json { "source": "uptime_kuma", "resource_id": 812, "event": "down", "timestamp": "...", "metadata": {} } ``` Hub behandler eventet gennem: ```text 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: ```text UP DOWN DEGRADED UNKNOWN MAINTENANCE ``` Så samme flow kan bruge: ```text Uptime Kuma UniFi Prometheus UISP andet ``` --- # 35. UI – kundens stamdata Fanen: ```text Eskaleringsplan ``` kunne have undermenuerne: ```text OVERSIGT RESSOURCER FLOW KONTAKTER SLA GODKENDELSER HISTORIK ``` --- # 36. UI – live flow Når en driftssag er aktiv, skal diagrammet kunne vises live. Eksempel: ```text [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: ```text Status Sidste check Datakilde Device Regel Resultat ``` --- # 37. Drift dashboard På Hub's eksisterende **Drift**-side bør aktive eskaleringssager vises. Eksempel: ```text CRITICAL 1 MAJOR 2 WARNING 4 ``` Kort kan eksempelvis vise: ```text 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å: ```text 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: ```text 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å: ```text foreslå besked foreslå modtagere generere tekst ``` men et menneske skal altid godkende udsendelsen. **2. Automatiske vurderinger skal kunne forklares.** Man skal altid kunne se: ```text Hvorfor nåede systemet frem til dette resultat? ``` **3. Observation og konklusion skal adskilles.** Eksempel: ```text 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 ```text 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: ```text 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.