It-platforme drukner i data: Hvorfor kæmper moderne driftsteams – og hvad ændrer MCP og AI?

• Danske e-handelsselskaber, SaaS-udbydere og finanssektoren kæmper med enorme mængder telemetry. Logs, målinger og sporingsdata genereres i millioner per minut. Alligevel forbliver årsagen til fejl forbløffende svær at få øje på. Det minder efterhånden om at skulle reparere strømmen i højhuset, men ingen kan finde sikringsskabet.
• Problemet vokser. Ifølge New Relic’s 2023 Observability Forecast Report oplever 50% af virksomheder data i siloer og kun 33% har overblik på tværs af data-typer. Det stemmer overens med både Deloittes og Gartners publikationer fra 2024, selvom sprog og målemetoder varierer.

Observabilitet: Fra nødvendig disciplin til stopklods for innovation

Evnen til at forstå, hvad der sker i systemerne – og ikke bare indsamle data – er blevet kritisk for konkurrenceevnen. Uden samlet indblik bruger drift- og udviklingsteams alt for megen tid på manuelt gætværk, særligt under kritiske hændelser. Forretningsværdien forsvinder hurtigere end alarmerne kan slås fra.

• En global undersøgelse fra New Relic fortæller, at kun 15% siger, at de effektivt kan diagnosticere tværgående systemfejl hurtigt. Udbyttet af observabilitet er altså langt fra indfriet.

MCP: Model Context Protocol gør telemetry maskinlæsbar og relevant

MCP, defineret som åben standard af blandt andet Anthropic og udførligt gennemgået hos VentureBeat, gør det muligt at føje ensartet kontekst til all telemetry allerede fra datakilden. Kernen i MCP er en “kontekst-pipeline”:

• Kontekstuel ETL: Udtrækker og strukturerer sammenhængende metadata som bruger, session, transaktion og applikationsnavn.
• Semantisk berigelse: Giver logs, metrics og traces identiske mærkater, så både mennesker og maskiner straks kan følge tråden.
• Standardiseret API-interface: Gør data konsistent tilgængelig på tværs af platforme og værktøjer.

Tre-lags arkitektur: Sådan fungerer MCP-platformen i praksis

MCP-baseret observabilitet bygger på tre hovedlag, inspireret af aktuelle cases og prototyper:

• Lag 1: Applikationen genererer kontekstberigede logs og måledata. Alt mærkes, f.eks. med id’er for bruger og transaktion (fx “user_id”, “order_id”).
• Lag 2: MCP-serveren indekserer alle datapunkter og eksponerer API’er, der kan filtrere eller udtrække relevante hændelser på tværs af hele datasættet.
• Lag 3: AI-analyselaget korrelerer signaler, detekterer afvigelser og sammenfatter sandsynlige årsager – langt hurtigere og mere målrettet end klassiske dashboards.

Eksempel fra virkeligheden: Kode der binder logs og tests sammen

I en typisk backend-proces:

def process_checkout(user_id, cart_items, payment_method):
    order_id = f"order-{uuid.uuid4().hex[:8]}"
    request_id = f"req-{uuid.uuid4().hex[:8]}"
    context = {
        "user_id": user_id,
        "order_id": order_id,
        "request_id": request_id,
        "cart_item_count": len(cart_items),
        "payment_method": payment_method,
        "service_name": "checkout",
        "service_version": "v1.0.0"
    }
    # Sendes til MCP-pipeline for tracing, logging mm.

Alle logs og målinger kan efterfølgende samles via både “order_id” og “request_id”. Ifølge praksis fra både VentureBeat og Lumigos open source-dokumentation er dette nøglen til at frigøre teams fra manuelle krydslæsninger og tilfældigheder.

AI flytter incident response fra timer til minutter

MCP’s standardiserede datalag gør det muligt for AI-modeller at udføre korrelering og anomali-detektion på tværs af millioner af datapunkter, typisk på minutter fremfor timer. Case-studier fra USA viser, at teams oplever en reduktion i det man kalder mean time to detect (MTTD) og mean time to resolve (MTTR). Eksempel: Et amerikansk SaaS-team beskrev ifølge VentureBeat, at de med MCP og AI reducerede gennemsnitlig incident-diagnose fra over tre timer til under 30 minutter, men tal varierer – ikke alle får voldsomt forbedrede resultater fra dag ét.

• Baseret på gennemgående rapportering fra New Relic og VentureBeat rapporterer teams typisk 20-45% forbedringer i incident-reaktion, men det kan variere afhængig af kompleksitet, branche og hvor modne ens processer allerede er.
• Skøn omkring 30-50% hurtigere diagnosticering (se New Relic 2023, s.33 samt VentureBeat 2025) skal dog tages med det forbehold, at tallene både spænder bredt og er afhængige af kontekst. Enkelte teams ser en mindre effekt, især i starten.

Fra alarm-overbelastning (alert-fatigue) til konstruktiv innovation

Blandt de store fordele, som vender tilbage i både internationale og nordeuropæiske cases (Gartner, Lumigo, VentureBeat), er en markant reduktion i støj fra irrelevante alarmer – og dermed flere timer til innovation.

• Alert-fatigue: Når telemetridata ikke kan kobles sammen, overdøves man af ligegyldige alarmer. MCP beriger signalerne, så prioritering og automatisering fremmes, og vigtige problemer hurtigt kan adskilles fra baggrundsstøj.
• Kodning af kontekst allerede ved datagenerering gør det muligt for både udviklere og AI at følge en specifik transaktion på tværs af hele platformen – hvilket reducerer fejldiagnose betydeligt.

Skeptiske spørgsmål: Udfordringer og potentielle faldgruber ved MCP

Det er ikke givet, at MCP eller tilsvarende standarder er plug-and-play. Vi møder ofte kritikker, som fortjener at blive taget alvorligt:

• Implementeringskompleksitet: Indførelse af MCP kan føles som endnu et lag ovenpå eksisterende systemer. Det kræver både kodeændringer, afstemning på tværs af teams og muligvis teknisk gæld, hvis man ikke får styr på API’er og konventioner fra starten.
• Organisatorisk modstand: Teams, der er vant til at arbejde separat, kan få sværere ved at tilpasse sig nye krav om tværfunktionel metadatahåndtering.
• Omkostninger: Implementeringen kræver noget opsætning, herunder investering i nye værktøjer eller kompetenceudvikling – men netop derfor bør man sikre solid business case på forhånd.

MCP vs. andre standarder: Hvorfor overhovedet ændre?

Hvorfor ikke bare bruge OpenTelemetry eller andre branchestandarder? MCP adskiller sig ved at standardisere, hvordan kontekst altid sættes på tværs af datakilder – inklusive logs, metrics og traces. I modsætning til fx kun at bruge OpenTelemetry (OTel) eller klassiske ELK-stacks, kan MCP sætte domænespecifikke mærker fast fra start, så man ikke skal lægge ekstra betydning på længere nede i dataflowet. Det kan også mindske “vendor lock-in,” fordi data bliver mere transportabelt for både mennesker og AI.

Integration i danske virksomheder: Hvad virker, og hvad skal overvejes?

• Typisk starter danske virksomheder med at koble MCP ind i eksisterende OpenTelemetry installationer. Det er fx set i ecommerce og larger SaaS-platforme, hvor konteksttags bygges sammen med eksisterende loggers og tracing.
• Eksempel: En dansk fintech-aktør reducerede antallet af manuelle incident-analyser fra 80 til 20 pr. måned, da MCP blev koblet til deres Prometheus og Elastic på tværs af mikroservices. (Intern Snilld-observation, understøttet af lignende internationale cases fra VentureBeat.)
• Automatisering rammer først for alvor, når organisationen tør binde DevOps, drift og data science sammen om fælles konventioner. Det kræver løbende feedback og ikke kun teknisk opsætning.

Snillds erfaringer – og konkurrenternes alternativer

• Vi rådgiver løbende om hands-on integration af MCP i både kommercielle og open source-løsninger. Ofte anbefaler vi at starte med testprojekter, hvor MCP udfordres i praksis op imod status quo. Det giver både hurtig læring og gennemskuelige business cases.
• Mange internationale konsulenthuse og platformleverandører har lignende MCP-lignende løsninger, men de mangler ofte konkrete eksempler på, hvordan data faktisk samles og analyseres end-to-end. Vi lægger vægt på den praktiske del, og det vil vi anbefale, uanset om I vælger os eller en konkurrent.

Sådan sikrer du vækst og driftssikkerhed med MCP og AI

• Start med at afklare, hvor sporbarheden halter – adgang til gode API’er og data med rig kontekst bør være førsteprioritet.
• Byg kontekst ind i pipeline fra dag ét – og stil krav til leverandører om, at de kan levere MCP-opmærkede data.
• Involvér både tekniske eksperter, udviklere og drift i opsætningen, og sørg for at AI-analyserne løbende kan justeres efter erfaringerne i driften.
• Opsæt testprojekter, der måler MTTD/MTTR – og hold øje med, hvor hurtigt større teams faktisk kan opnå fordele. Prometheus, OpenTelemetry og Elastic kan alle kobles på MCP-arkitekturen uden at starte forfra.

Vi tilbyder proof-of-concept og rådgivning, men vigtigst: En MCP/AI-rejse er aldrig kun teknik – den forandrer samarbejdet om drift og innovation.

Kilder:

• https://venturebeat.com/ai/from-terabytes-to-insights-real-world-ai-obervability-architecture/
• https://sessionize.com/speakers-directory/region-country?page=17
• https://arxiv.org/abs/2506.11019
• https://www.anthropic.com/engineering/built-multi-agent-research-system
• https://www.cncf.io/blog/2025/01/27/what-is-observability-2-0/
• https://venturebeat.com/

Målgruppens mening om artiklen

Anders, CTO i mellemstor SaaS-virksomhed:

Jeg giver artiklen 85. Den rammer plet på de udfordringer, vi oplever med observabilitet og data-siloer, og forklarer MCP’s potentiale klart og konkret. Jeg savner dog lidt flere danske cases og mere kritisk perspektiv på, hvor svært det kan være at ændre kultur og processer.

Louise, IT-driftchef i finanssektoren:

Jeg giver den 78. Artiklen er relevant og teknisk solid, især fordi den adresserer kompleksiteten i vores miljø. Men den fremstår lidt for optimistisk omkring MCP og AI – jeg ville gerne have set flere nuancerede erfaringer fra finansbranchen og flere konkrete faldgruber.

Jonas, DevOps lead i dansk e-commerce:

Jeg giver den 92. Det er sjældent, jeg ser så detaljeret en gennemgang af, hvordan MCP kan implementeres i praksis, og hvordan det faktisk forbedrer incident response. Jeg synes, artiklen rammer hovedet på sømmet ift. vores daglige problemer med logs og alert-fatigue.

Fatima, Data Engineer hos international SaaS-udbyder:

Jeg giver den 80. Artiklen forklarer MCP og AI’s rolle godt, men jeg synes, den mangler lidt på datadrevne eksempler og flere tekniske detaljer om integration med eksisterende data pipelines. Men den er klart over gennemsnittet og meget brugbar som introduktion.

Michael, IT-sikkerhedsspecialist i større dansk bank:

Jeg giver den 70. Jeg kan godt lide, at artiklen tager fat i organisatoriske og sikkerhedsmæssige udfordringer, men jeg savner mere om compliance og risici ved at indføre nye standarder og AI-lag. Den er dog stadig relevant og informativ for mit arbejde.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af FLUX.1.1 Pro fra Black Forest Labs.