Skalering og drift af produktet

Et produkt, der virker fint for ti kunder, opfører sig anderledes for hundrede. Siderne bliver langsommere, en udgivelse går galt en fredag, og cloudregningen vokser uden, at nogen helt kan forklare hvorfor. Er produktet nede lige nu, så gå direkte til beskeden til kunderne, og læs resten bagefter. Siden her samler artiklerne om driften af produktet: hvordan I ser problemerne komme, håndterer dem, når de sker, og hvem der har ansvaret. Det handler om driftshændelser. Sikkerhedshændelser følger et andet forløb, som er beskrevet under beredskab.

Det, der går igen

Tre spørgsmål kan besvares af de fleste ledelser på få minutter, og svarene siger meget. Hvem får besked, når produktet er nede klokken tre om natten? Hvornår har I sidst prøvet at genskabe produktet fra backup? Og hvem ejer driften, hvis alle peger på hinanden? Kan I ikke svare, har I det første punkt på jeres liste. Driften er det sted, hvor en lille virksomhed tit lever på én persons hukommelse, og det kan hurtigt rettes med få faste rutiner.

Flere kunder, mere data

• Når kunderne bliver flere: skalering før det går galt Varsler i data og drift, belastningstest, og hvilke flaskehalse der kommer først.
• Produktet er blevet langsomt: hvor leder I først? Mål før I køber større servere, og hyppige årsager i database og forespørgsler.
• Cloudregningen vokser hurtigere end kunderne Forbrug pr. kunde og funktion, hvem der bestiller ressourcer, og hvorfor økonomiafdelingen ikke kan styre det alene.

Hverdagens rutiner

• Overvågning, vagt og driftshændelser i produktet Hvem der vækkes, hvad der logges, og hvordan en hændelse følges op uden skyld.
• Hver release er en risiko: mindre og hyppigere udgivelser Sammenhængen mellem store udgivelser og fejl, og de vaner, der gør dem mindre farlige.
• Hvem ejer driften: udviklerne, en driftsperson eller en leverandør? Tre modeller for et lille team, og hvordan support holdes fra at afbryde udviklerne.

Når det går galt

• Hvad skriver I til kunderne under et nedbrud? Statusside, hyppighed, sprog og hvem der skriver, med skabelon i tekst.
• Produktet var nede: dagen efter Sådan gennemgår I forløbet uden at pege på nogen, og sådan svarer I de vigtigste kunder.
• Backup af et SaaS-produkt: kan I faktisk genskabe det? Gendannelsesøvelse af hele produktet og af én enkelt kunde, med tid på.

Hvor I begynder

Mange små softwarevirksomheder kan få meget ud af tre skridt. Begynd med at få overvågning af det, kunderne faktisk oplever, frem for serverens egne tal. Lav derefter en gendannelsesøvelse, så I ved, hvor lang tid det tager. Skriv så ned, hvem der har vagten, og hvad de må beslutte. Først derefter giver det mening at bruge tid på større skalering. Hvis I får spørgsmål om oppetid fra kunder, skal svaret bygge på de samme målinger, og det står under SLA og oppetid. Viser driften sig at være begrænset af grundlaget i produktet, ligger næste skridt under arkitektur og teknologivalg. Nedbrud, der skyldes hastværk og gæld, hører også hjemme i teknisk køreplan og teknisk gæld.

Det skal I lade være med

• At opgradere serverne uden at have målingerne · så flytter I problemet og betaler for det.
• At lede efter en skyldig efter et nedbrud · folk holder op med at fortælle, hvad der skete.
• At stole på en backup, I aldrig har gendannet · kopien er først brugbar, når I har prøvet den.
• At lade kunderne opdage nedbruddet før jer · det koster mere tillid end selve hændelsen.

Det skal I kræve af den eksterne

• ☐ En klar fordeling af ansvaret for driften, også uden for arbejdstid.
• ☐ En plan for gendannelsesøvelser med tid på.
• ☐ Faste skabeloner til kundebesked og opfølgning efter hændelser.
• ☐ Overblik over, hvad cloudforbruget går til pr. funktion og kunde.

Senest gennemgået: november 2026.

Næste skridt

• Når kunderne bliver flere: skalering før det går galt
• Sådan foregår et forløb

Læs også: Artikler om CTO as a Service · Når kunderne stiller krav til produktet

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT