Efter lancering: den komplette guide til drift og vedligehold af webapplikationer

Vedligehold af en webapplikation er det arbejde der holder den sikker og i drift efter lanceringen: opdateringer af framework og pakker, overvågning, backup, hjælp når noget går galt, hosting og videreudvikling. En stor del af arbejdet med en webapp kommer først når den er "færdig", og den vigtigste beslutning er hvem der har ansvaret for hvad før noget går ned.

Jeg tilbyder selv vedligehold og videreudvikling, så læs med det forbehold. Jeg har forsøgt at være lige så tydelig om hvornår du kan klare det selv, og hvornår en freelancer som mig ikke er det rigtige valg.

Den korte version: hvad drift og vedligehold dækker

Tabellen er en grov oversigt. Hvert område har sit eget uddybende indlæg som jeg linker til undervejs. Resten af guiden handler om hvorfor arbejdet er nødvendigt, hvordan ansvaret bør fordeles, hvad det koster, og i hvilken rækkefølge du kommer i gang.

Hvorfor en webapp kræver vedligehold selvom ingen ændrer koden

En webapp er ikke færdig fordi den er lanceret. Koden ændrer sig ikke af sig selv, men alt omkring den gør, og gamle versioner mister support efter en fast plan.

PHP giver hver version to års aktiv support og derefter to års sikkerhedsrettelser, altså fire år i alt (PHP's oversigt over understøttede versioner). Laravel giver hver hovedversion 18 måneders fejlrettelser og to års sikkerhedsrettelser (Laravels supportpolitik). En app der blev lanceret på den nyeste Laravel-version, kører altså på en version uden sikkerhedsopdateringer cirka to år senere hvis ingen gør noget.

Derudover sker der ting som du ikke selv styrer:

• Betalingsløsninger, e-mail-udbydere og andre tjenester udfaser gamle versioner af deres API'er, og din integration holder op med at virke.
• Browsere opdateres, og en gammel JavaScript-pakke kan pludselig opføre sig anderledes.
• Hostingudbyderen stopper med at understøtte gamle PHP-versioner og styresystemer og flytter dig, om du er klar eller ej.
• Datamængden vokser. En side der indlæses på et øjeblik med tusind rækker i databasen, kan blive langsom med en million.

Ingen af delene er et problem hvis du tager dem i små bidder. Problemet opstår når appen står stille i 3-4 år, og alle opdateringerne skal tages på én gang. Så bliver et par timers månedligt arbejde til et projekt, og i værste fald til en egentlig modernisering af et gammelt PHP-system. Jeg har skrevet mere om hvad det koster at lade være med at opdatere framework og pakker, og om hvornår din Laravel-version mister sikkerhedsopdateringer.

De seks områder i praksis

Her er hvad hvert område indebærer i en typisk webapp, fx en kundeportal, et bookingsystem eller en SaaS bygget i Laravel. Nogle opgaver er automatiske når de først er sat op. Andre kræver at et menneske tager stilling hver måned.

Opdateringer og sikkerhed

Opdateringer kommer i tre størrelser. Patch-versioner retter fejl og sikkerhedshuller og kan som regel installeres uden ændringer i koden. Minor-versioner tilføjer funktioner uden at ødelægge noget. Major-versioner (hovedversioner) kan kræve ændringer i din kode og skal planlægges.

Jeg anbefaler en fast månedlig rytme for de små opdateringer. Kør composer audit og npm audit, som tjekker pakkerne mod kendte sårbarheder, opdatér, kør de automatiske tests, og tjek resultatet på et staging-miljø (en kopi af appen til test) før det går i produktion. Dependabot på GitHub kan foreslå opdateringer automatisk, men nogen skal stadig vurdere og teste dem.

Hovedversioner behandler jeg som små projekter med et selvstændigt estimat. Den årlige Laravel-udgivelse er et naturligt tidspunkt at se på resten af appens versioner.

Sikkerhed handler også om mere end opdateringer. Adgange skal lukkes når medarbejdere eller leverandører stopper, hemmelige nøgler skal skiftes, og apps med følsomme data fortjener en grundig vurdering udefra. Her kan et code review fra en ekstern udvikler eller en penetrationstest af din webapp være pengene værd, især når en stor kunde eller et udbud stiller krav.

Overvågning og fejlrapportering

Overvågning betyder at du får besked før dine brugere ringer. Der er tre lag:

• Oppetid: en ekstern tjeneste besøger appen hvert minut eller to og slår alarm hvis den ikke svarer. Den samme tjeneste kan holde øje med SSL-certifikater og domæner der er ved at udløbe.
• Fejl i koden: et værktøj til fejlrapportering, fx Sentry eller Flare, samler fejlene op med de oplysninger udvikleren skal bruge for at rette dem.
• Baggrundsjob: mange apps sender mails, laver fakturaer eller synkroniserer data i baggrunden. Stopper de, sker der ofte intet synligt før en kunde opdager at fakturaen aldrig kom.

Den vigtigste beslutning er hvem alarmen går til. En alarm der lander i en fælles indbakke som ingen læser, er det samme som ingen alarm. Se mine anbefalede værktøjer til overvågning og oppetid og forskellen på Sentry, Flare og Ray.

Backup og gendannelse

En backup skal dække databasen, de filer brugerne har uploadet, og den konfiguration der skal til for at starte appen igen. Den skal ligge et andet sted end selve serveren, så den overlever hvis serveren eller hele hostingkontoen forsvinder. Den klassiske 3-2-1-regel siger tre kopier på to forskellige typer lager, hvoraf én ligger et helt andet sted.

Det mange springer over, er testen. En backup du aldrig har gendannet fra, er en antagelse. Gendan til et testmiljø et par gange om året, og tag tid på det. Så ved du også hvor længe appen vil være nede i en rigtig krise.

Behandler appen personoplysninger, er det desuden en del af dine forpligtelser. GDPR artikel 32 nævner blandt andet evnen til rettidigt at genoprette tilgængeligheden af og adgangen til personoplysninger efter en fysisk eller teknisk hændelse, og en procedure for regelmæssigt at teste og vurdere dine sikkerhedsforanstaltninger. Min guide til backup af webapps og 3-2-1-reglen gennemgår hvad du skal teste.

Support og hændelser

Før eller siden går noget galt: en ændring hos en tredjepart, en fuld disk eller en fejl i en ny funktion. Det afgørende er hvor hurtigt nogen reagerer, og om de har adgang til det de skal bruge. Aftal på forhånd:

• hvem der får alarmen, og hvem der tager over ved sygdom og ferie
• hvad der er kritisk (appen er nede, betalinger fejler), og hvad der kan vente til næste arbejdsdag
• hvordan brugere melder fejl, så det ikke sker i fem forskellige mailtråde
• hvem der informerer kunderne mens fejlen bliver rettet

Er der tale om et brud på persondatasikkerheden, skal du som dataansvarlig som udgangspunkt anmelde det til Datatilsynet uden unødig forsinkelse og om muligt inden 72 timer (Datatilsynets side om anmeldelse af sikkerhedsbrud). Den frist er svær at nå hvis ingen ved hvem der skal undersøge sagen. Står du midt i et nedbrud lige nu, så læs hvad du gør når din hjemmeside eller app er nede.

Hosting og infrastruktur

Hosting er mere end en server. Det er også domænet, DNS, certifikater, afsendelse af e-mails, fillager og de abonnementer appen afhænger af. En klassisk og helt undgåelig fejl er et domæne eller et betalingskort der udløber fordi abonnementet står i navnet på en tidligere medarbejder eller på udvikleren.

Valget står typisk mellem administreret hosting, hvor udbyderen holder styresystem og database opdateret, og en server som du eller din udvikler selv har ansvaret for. Administreret hosting koster lidt mere om måneden, men fjerner en hel kategori af opgaver, og for de fleste mindre virksomheder er det min anbefaling. Skal du skifte udbyder, kan det gøres uden nedetid med lidt planlægning. Læs hvordan du flytter en webapp til ny hosting.

Videreudvikling

Når appen er i drift, lærer du hvad brugerne faktisk gør. Det er det bedste grundlag for at prioritere, og det er også her ønskerne hober sig op. Uden en plan ender videreudviklingen med at følge den der råber højest.

Jeg anbefaler at holde vedligehold og videreudvikling adskilt i budgettet. Vedligehold er det der skal til for at appen bliver ved med at virke. Videreudvikling er en investering du vælger til når der er et konkret behov. Blandes de sammen, taber opdateringerne ofte til nye funktioner, og så står du igen med versioner uden support.

Brug data fra rigtige brugere når du vælger. Jeg har skrevet om hvordan du prioriterer en roadmap efter lancering, og om valget mellem GA4, Plausible og PostHog til at måle hvad brugerne gør.

Tre måder at organisere vedligehold på

Der er grundlæggende tre modeller. Ingen af dem passer til alle, og mange virksomheder bruger en blanding.

Fast aftale med en ekstern udvikler

Du betaler et fast beløb eller et antal timer om måneden, og udvikleren står for opdateringer, overvågning og backup efter en aftalt plan. Det passer til de fleste forretningskritiske webapps i virksomheder uden egne udviklere. Fordelen er at arbejdet bliver gjort uden at du skal huske det. Ulempen er at du betaler, også i måneder hvor der ikke sker noget synligt.

Timer efter behov

Du tager kontakt når der er brug for det, og betaler for den tid der går. Det passer til interne værktøjer med få brugere, hvor en dags nedetid ikke er en katastrofe. Risikoen er at ingen tager initiativ til opdateringer fordi ingen har fået opgaven, og at udvikleren skal sætte sig ind i koden igen hver gang.

Egen udvikler

Har du udviklere ansat, er vedligehold en del af deres hverdag. Det passer når softwaren er kernen i forretningen. Giv alligevel opdateringerne en fast plads i planlægningen, så de ikke altid taber til nye funktioner.

Hvornår en freelancer som mig ikke er det rigtige valg

Jeg svarer som udgangspunkt inden for én arbejdsdag. Det er fint til de fleste B2B-systemer, men det er ikke en døgnvagt. Kræver din app at nogen reagerer inden for minutter, også om natten og i weekenden, skal du have et bureau eller en driftsleverandør med vagtordning, eller dit eget team. En enkelt person kan ikke ærligt love det.

Du har heller ikke brug for en fast aftale hvis du har en enkel hjemmeside på en platform hvor udbyderen tager sig af opdateringerne, eller hvis appen alligevel skal lukkes inden for et halvt år. Så er overvågning, backup og sikkerhedsrettelser efter behov nok.

Hvem har ansvaret: dig, udvikleren eller hostingudbyderen?

Drift går sjældent galt fordi opgaverne er svære. Det går galt fordi alle tror at en anden har dem. Hostingudbyderen regner med at udvikleren tager backup, udvikleren regner med at hostingudbyderen gør det, og ejeren tror at det hele er inkluderet. Lav derfor en enkel fordeling som den her, og få den skrevet ind i jeres aftale.

Den præcise fordeling afhænger af jeres opsætning. Det vigtige er at hver række har én ansvarlig, og ikke tre der hver især tror at en anden har den. Fordelingen hører hjemme i en skriftlig aftale med responstider og priser, og jeg har lavet en tjekliste over hvad en serviceaftale med en udvikler skal dække.

Leverer du software til virksomheder der er omfattet af NIS2, kan de også stille krav til dig som leverandør, fx om dokumentation og håndtering af hændelser. Det har jeg samlet i et indlæg om hvad NIS2 betyder for din webapp.

Hvad koster drift og vedligehold?

Prisen afhænger mere af appens tilstand end af dens størrelse. Min tommelfingerregel er at budgettere med 10-20 % af den oprindelige udviklingspris om året til vedligehold, før nye funktioner. Har appen kostet 300.000 kr. at bygge, svarer det til 30.000-60.000 kr. om året. Det er et groft skøn til budgettet, ikke en pris.

Det der trækker op eller ned:

• Hvor langt bagud versionerne er. En app der er holdt opdateret, er billig at holde ved lige. En der er tre hovedversioner bagud, kræver først en oprydning.
• Automatiske tests. Med gode tests kan en opdatering kontrolleres hurtigt. Uden dem skal alt tjekkes i hånden.
• Antal integrationer. Hver forbindelse til et andet system kan ændre sig uden varsel.
• Krav til responstid. Hurtig reaktion uden for arbejdstid koster ekstra, uanset hvem du køber den hos.
• Følsomme data. Persondata og betalinger kræver mere omhyggeligt sikkerhedsarbejde.

Hertil kommer hosting og tredjepartstjenester. En mindre webapp kan ofte køre for nogle hundrede kroner om måneden på administreret hosting, mens apps med mange brugere, baggrundsjob og separate databaser hurtigt koster mere. Sådan bliver regningen typisk sat sammen:

Vil du se en mere detaljeret gennemgang med regneeksempler, har jeg skrevet om hvad drift og vedligehold af en webapp koster om året.

Sådan sætter du drift og vedligehold i system

Her er den rækkefølge jeg anbefaler, også hvis appen har kørt et stykke tid uden en plan.

1. Saml adgange og ejerskab. Domæne, DNS, hosting, repository (kodearkiv) og alle tredjepartstjenester skal stå i virksomhedens navn, med adgangskoderne i en fælles adgangskodemanager.
2. Skriv en kort driftsbeskrivelse. Hvad er appen bygget i, hvilke versioner og integrationer har den, hvor ligger data, og hvordan sættes en ny version i drift? To sider er nok.
3. Sæt overvågning op, og vælg hvem alarmen går til. Dæk oppetid, fejl i koden og baggrundsjob, og udpeg både en ansvarlig og en stedfortræder.
4. Sæt backup op, og test en gendannelse. Notér hvor lang tid det tog. Det er dit realistiske bud på nedetid ved et alvorligt nedbrud.
5. Aftal en fast rytme for opdateringer. Små opdateringer hver måned, og en plan med dato for næste hovedversion af framework og PHP.
6. Skriv ansvaret ned. Brug fordelingen ovenfor, og få den ind i en serviceaftale med responstider, priser og regler for arbejde uden for arbejdstid.
7. Hold et kort statusmøde hvert kvartal. Gennemgå versioner, hændelser, budget og de næste punkter på roadmappen.

Næste skridt

Har du gennemgået tjeklisten og fundet huller, så start med ejerskab og backup. Det er de to ting der er dyrest at mangle, og ingen af dem kræver en stor aftale. Resten kan du tage i den rækkefølge der passer til dit budget.

Vil du have hjælp, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende webapps. Du får direkte kontakt med den udvikler der laver arbejdet, og du ejer koden.

Ofte stillede spørgsmål

Kan en ny udvikler overtage vedligeholdet af min webapp?+

Ja, men det starter med en gennemgang. En ny udvikler skal have adgang til koden, serveren og tredjepartstjenesterne og bruge tid på at forstå hvordan appen hænger sammen. Jo bedre dokumentation og tests, jo hurtigere går det. Forvent at de første timer går til at kortlægge versioner, risici og det der haster mest før de egentlige opdateringer begynder.

Skal jeg have en databehandleraftale med min udvikler?+

Som regel ja, hvis udvikleren har adgang til personoplysninger i din produktionsdatabase eller dine backups. Så behandler udvikleren data på dine vegne, og GDPR artikel 28 kræver en skriftlig aftale. Det samme gælder typisk din hostingudbyder. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme data.

Kan jeg sætte vedligeholdet på pause?+

Videreudvikling kan sagtens sættes på pause, men sikkerhedsrettelser, overvågning og backup bør køre hele tiden. En pause på et par måneder er sjældent et problem. En pause på et par år betyder typisk at næste opdatering bliver et projekt i stedet for en rutineopgave fordi flere hovedversioner skal tages på én gang.

Hvor lang tid tager det at opgradere til en ny Laravel-version?+

Det afhænger af hvor mange versioner du springer over, og hvor mange tredjepartspakker appen bruger. Laravel skriver selv at de stræber efter at en opgradering til næste hovedversion kan klares på en dag eller mindre. Det holder bedst for apps der er opdateret løbende og har automatiske tests. Springer du flere versioner over, tager det længere tid.