Forside · Gennemgået oktober 2026 · Af John Nielsen
Et system, der virker med ti brugere og bryder sammen med tusind, rejser et spørgsmål, som ofte ender i en tvist: er det arkitekturen, der ikke kan bære, eller er det dimensioneringen, konfigurationen eller den måde, systemet bruges på? Svaret afgør, om problemet kan løses med mere hardware og justeringer, eller om dele af løsningen skal bygges om. Teknisk kan det undersøges ved at finde flaskehalsen, vise hvordan den opfører sig, når ressourcerne øges, og holde resultatet op mod de krav til belastning, der var aftalt.
Artiklen handler om arkitekturens rolle. Hvordan IT-projekttvister generelt forløber, står på digitalbevissikring.dk, og kundens egen dokumentation ved brud på serviceniveauer er beskrevet på bevissikring-digitalt.dk.
Skalerbarhed er ikke det samme som ydeevne
Ydeevne er, hvor hurtigt systemet svarer under en given belastning. Skalerbarhed er, hvordan systemet opfører sig, når belastningen vokser, og om kapaciteten kan øges ved at tilføre ressourcer. ISO/IEC 25010 beskriver ydeevne med underkarakteristika for tidsforhold, ressourceforbrug og kapacitet.
Et system kan være hurtigt for få brugere og alligevel skalere dårligt. Det typiske tegn er, at svartiderne er stabile op til et bestemt punkt og derefter stiger kraftigt, og at flere servere eller mere hukommelse kun flytter punktet lidt.
Typiske arkitektoniske flaskehalse
Visse designvalg begrænser skalerbarheden, uanset hvor mange ressourcer der tilføres:
- Én central database, som alle forespørgsler går igennem, uden caching, læsereplikaer eller opdeling af data.
- Låsning, hvor mange samtidige brugere venter på de samme rækker, tabeller eller filer.
- Tilstand i applikationsserveren, fx sessioner gemt i hukommelsen, så trafikken ikke kan fordeles frit på flere servere.
- Synkrone kæder, hvor én brugerhandling kalder flere tjenester efter hinanden, og den langsomste afgør svartiden.
- Ineffektive dataadgangsmønstre, fx én databaseforespørgsel pr. element i en liste frem for én samlet forespørgsel.
- Afhængighed af eksterne tjenester med egne begrænsninger på antal kald.
Andre problemer ligner arkitekturfejl, men er det ikke: for små servere, forkert indstillede forbindelsespuljer, manglende indeks i databasen, logning på et for detaljeret niveau eller en enkelt langsom rapport, der kører i spidsbelastning. De kan ofte rettes uden at ændre løsningens opbygning, og forskellen er central for tvistens udfald og omkostninger.
Arkitekturen på papiret og i virkeligheden
ISO/IEC/IEEE 42010 skelner mellem et systems arkitektur og beskrivelsen af den. I en tvist er forskellen vigtig: arkitekturdokumentet fra projektets start beskriver måske én løsning, mens den leverede kode og det faktiske driftsmiljø viser en anden.
Sammenhold derfor:
- arkitekturbeskrivelsen og eventuelle ændringer undervejs
- den leverede kode, især dataadgang, kald mellem tjenester og håndtering af sessioner
- driftsmiljøets faktiske opsætning: antal instanser, ressourcer, netværk, databaseplan
- hvem der traf de enkelte valg, og hvornår, fx i beslutningslog, mødereferater eller ticketsystemet
Det viser, om flaskehalsen var en del af det aftalte design, en afvigelse fra det, eller en følge af driftsmiljøets dimensionering.
Data fra produktion
De bedste data stammer fra den periode, hvor problemerne opstod:
- Svartider og fejlrater fra webserver- og applikationslogs, opdelt på funktioner; se webserverlogs: felter, tidszoner, proxy og CDN.
- Ressourceforbrug pr. komponent: CPU, hukommelse, disk, netværk og forbindelser.
- Databasens egne målinger: langsomme forespørgsler, ventetider på låse, antal forbindelser.
- Sporing på tværs af tjenester, hvis løsningen har det, så en langsom brugerhandling kan følges gennem systemet.
- Belastningen: antal samtidige brugere, transaktioner eller kald pr. tidsenhed.
Målingerne skal knyttes til tidspunkter og holdes op mod den aftalte belastning. Overvågningsdata opbevares ofte kort og i aggregeret form, så de skal sikres tidligt. Se bevaringsplan for et IT-projekt i krise.
Reproduktion i et testmiljø
Produktionsdata viser, at problemet findes. En kontrolleret belastningstest kan vise hvorfor. Metoden:
- Byg et testmiljø fra den leverede version med en dokumenteret konfiguration; se leverancens tilstand på overdragelsestidspunktet.
- Brug realistiske datamængder. En tom database skalerer næsten altid fint.
- Definér belastningsprofilen ud fra de aftalte krav eller den faktiske brug, ikke ud fra hvad der får systemet til at bryde sammen.
- Øg belastningen trinvis, og mål svartider, fejl og ressourceforbrug for hvert trin.
- Gentag med flere ressourcer, fx dobbelt så mange applikationsservere eller en større database.
Det sidste trin er afgørende. Stiger kapaciteten nogenlunde i takt med ressourcerne, er der tale om dimensionering. Gør den ikke, ligger begrænsningen i designet, og målingerne viser hvor.
Testmiljøet afviger altid fra produktion på nogle punkter. Afvigelserne skal beskrives, og deres mulige betydning for resultatet vurderes.
Krav til belastning i projektets dokumenter
Krav til belastning står sjældent ét sted. Kig efter dem i kravspecifikationen, i tilbuddet, i løsningsbeskrivelsen, i testplaner og i referater fra styregruppemøder. Typiske formuleringer er antal samtidige brugere, transaktioner pr. time, datamængder efter et antal år eller svartider for bestemte funktioner. Notér også, om kravene blev ændret undervejs, og om en ydelsestest indgik i overtagelsesprøven. Blev der testet, er testrapporten og testens forudsætninger centrale: en godkendt test med for små datamængder kan forklare, hvorfor problemet først viste sig i drift.
Faldgruber
- Forkert belastningsprofil. En test med mange samtidige kald til én funktion siger lidt om et system, hvor brugerne fordeler sig på mange funktioner.
- Mål uden krav. Var der ikke aftalt en belastning, må vurderingen bygge på den forventede brug, som den fremgik af projektets dokumenter. Det skal fremgå.
- Ændret brug. Er belastningen steget langt ud over det forventede, fx efter en kampagne eller en ny integration, kan det forklare problemet uden en arkitekturfejl.
- Senere ændringer. Rettelser efter leveringen kan have forbedret eller forværret skalerbarheden. Undersøg den leverede version.
- Cloudomkostninger som skjult krav. En løsning kan skalere teknisk, men kun ved et ressourceforbrug, der ikke står mål med opgaven. Det er et relevant fund, men skal præsenteres som omkostning, ikke som teknisk umulighed.
Rapporten
Rapporten beskriver kravene til belastning, den faktiske og den målte belastning, flaskehalsene med data, resultatet af testene med øgede ressourcer og forskellen mellem det beskrevne og det leverede design. Hvor det er relevant, beskrives, hvilke ændringer der skal til for at nå kravene, og om de kræver omkonstruktion eller kun konfiguration og ressourcer. Grafer over svartid og kapacitet som funktion af belastning gør resultatet forståeligt; se visualiseringer i forensiske rapporter.
Hvad undersøgelsen kan og ikke kan bevise
En teknisk undersøgelse kan vise, hvor flaskehalsen sidder, om den skyldes designet eller dimensioneringen, hvilken belastning løsningen kan bære med givne ressourcer, og om det svarer til det aftalte. Den kan ikke afgøre, hvem der juridisk bærer ansvaret for valget af arkitektur, når kunden har godkendt det undervejs. Den kan heller ikke alene forudsige fremtidig belastning. Den kan dog dokumentere, hvem der traf valgene, og hvad der var kendt, da det skete.
Kilder og versioner
- ISO/IEC/IEEE 42010:2022, Architecture description
- ISO/IEC 25010:2023, Product quality model
- AWS Well-Architected Framework: performance efficiency
Senest gennemgået: oktober 2026.
Næste skridt
- SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte
- GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
- Massesletning efter en tvist er opstået: tekniske tegn
Læs også: Sikkerhedsfejl i leveret software: vurdering som mangel · Softwarepatenter: claim chart, krav holdt op mod implementering
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
