Et SaaS-produkt bryder sjældent sammen over natten på grund af flere kunder. Det bliver gradvist tungere, supporten får flere klager om langsomhed, natjobbet tager længere tid, og en dag falder det hele sammen på den travleste morgen i måneden. Varslerne ligger i data og drift længe forinden, hvis nogen kigger. Skalering er at få dem aflæst, finde den første flaskehals og rette den, mens I stadig har tid. Her er rækkefølgen for en virksomhed, der vokser og ikke har et stort driftsteam.
De varsler, der kommer først
Skalering (at produktet kan bære mere, uden at brugerne mærker det) knækker sjældent, hvor man forventer. Nogle af de tidlige tegn kan en direktør selv spørge til:
- De vigtigste handlinger bliver langsommere i de travle timer, mens de er fine resten af dagen.
- Natlige job, fx eksport eller fakturering, slutter senere og senere.
- Databasen fylder mere, og kurven er stejlere end kundetilvæksten.
- Der kommer flere fejl, som forsvinder af sig selv, når man prøver igen.
- Udviklerne genstarter en tjeneste “for en sikkerheds skyld”.
- Cloudregningen vokser hurtigere end kundetallet, se cloudregningen vokser.
Alle disse kan måles, og der er tale om en enkel oversigt med udviklingen over de seneste måneder. Se på tendensen. Et enkelt tal siger lidt, tolv måneders kurve siger meget mere.
Find ud af, hvad der vokser
Skriv ned, hvad der driver belastningen hos jer. Det er sjældent antal kunder alene. Det kan være antal dokumenter pr. kunde, antal integrationer, der henter data hvert minut, eller antal brugere, der logger på klokken ni. Giv dem et navn, fx vækstdrivere, så bliver de nemmere at tale om. Når salget lander en ny type kunde, kan I spørge, hvad den gør ved vækstdriverne, før den går i luften.
De flaskehalse, der plejer at komme først
Rækkefølgen varierer, men nogle mønstre går igen:
Databasen. Den almindeligste. Forespørgsler, der var hurtige med lidt data, bliver langsomme med meget. Manglende indeks (opslagsstrukturer, der gør søgning hurtig) og tunge rapporter er de typiske årsager. Hvor I leder først, står i produktet er blevet langsomt.
Baggrundsjob. Eksport, import og integrationer, der kører samtidig og sluger de samme ressourcer. Ofte løses det med en kø, så arbejdet fordeles over tid.
En stor kunde. Når én kunde er langt større end de andre, kan den bremse alle. Det kræver adskillelse, begrænsninger eller et andet design.
Afhængigheder. Betalingstjenesten, mailudsendelsen eller sprogmodellen har egne grænser for, hvor mange kald I må lave. De rammer pludseligt og uden forvarsel, hvis ingen har læst vilkårene.
Sessionsdata og filer på den enkelte server. Så kan I ikke uden videre sætte flere servere på. Det er en lille ombygning tidligt og en stor senere.
Belastningstesten
En belastningstest er en prøve, hvor I med et værktøj sender mange kunstige brugere gennem produktet og måler, hvad der sker. Den svarer på to spørgsmål: Hvor meget kan produktet bære nu, og hvad giver sig først?
Fire ting afgør, om testen er værd at bruge:
- Testmiljøet ligner produktion i størrelse og opsætning.
- Datamængden ligner virkeligheden, og den er ikke rigtige kunders data, medmindre det er vurderet.
- Testen følger de flows, brugerne faktisk bruger, og den travleste time af måneden.
- I øger belastningen trinvis, til noget går galt, og noterer, hvad det var.
Hold testen i gang som en fast del af rutinerne, fx før større releases og når nye kundetyper er på vej. En test fra for to år siden siger intet om produktet i dag.
Hvad I skal gøre, og hvad der kan vente
Når flaskehalsen er fundet, er der en trappe af løsninger:
- Ret forespørgsler og indeks. Ofte den billigste løsning og den, der giver mest.
- Mellemlagring (cache) af det, der læses tit. Virker godt, men giver nye fejlkilder, når data skal være friske.
- Større maskiner. Enkelt og hurtigt, og en fin midlertidig løsning. Men det udskyder kun et problem, der vokser.
- Flere maskiner og kopier af databasen. Kræver, at produktet er bygget til det.
- Ombygning af arkitekturen. Sidste trin, og sjældent det første, I behøver.
Hop ikke til trin 5, fordi det lyder ordentligt. Mange små teams har bygget avanceret arkitektur til en belastning, de aldrig fik, og betaler for det i tempo hver dag. Samme afvejning gælder valget mellem monolit og microservices.
Sådan får det plads i køreplanen
Skaleringsarbejde taber altid til nye funktioner, hvis det skal kæmpe om pladsen uge for uge. Afsæt en fast del af kapaciteten, og lad den, der ejer arkitekturen, præsentere de tre vigtigste flaskehalse for ledelsen hvert kvartal i et sprog uden fagord: hvad vi ser, hvad der sker, hvis vi lader det ligge, og hvad det kræver. Så bliver det et valg, ledelsen har truffet. Den er også grundlaget for at svare, når en kunde spørger, om produktet kan klare ti gange så meget.
Har I ikke nogen, der kan tage det ansvar, er det et naturligt sted at hente en ekstern CTO ind. Hos Nielco IT handler sådan et forløb om prioritering, teknologivalg, leverandører og team, mens selve kodearbejdet bliver hos jeres egne udviklere eller leverandør.
Det skal I lade være med
· At købe større servere, før nogen har målt, hvor tiden går.
· At bygge til en belastning, I måske aldrig når.
· At vente med at teste, til en stor kunde er på vej ind.
· At overlade kapacitet til mavefornemmelsen hos den udvikler, der kender systemet bedst.
Det skal I kræve af den eksterne
- ☐ En oversigt over varsler og vækstdrivere med udviklingen over tid.
- ☐ En belastningstest med en skriftlig konklusion.
- ☐ En prioriteret liste over de næste tre flaskehalse.
- ☐ En anbefaling om, hvad der kan købes, og hvad der kræver udvikling.
- ☐ En fast plads til arbejdet i køreplanen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvem ejer driften? · Teknisk køreplan ved siden af produktkøreplanen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
