Din hjemmeside eller app er nede: hvad gør du nu?

Er din hjemmeside nede, så find først ud af om den er nede for alle eller kun for dig. Derefter handler det om at læse fejlbeskeden og kontakte den rigtige: domæneudbyderen, hostingfirmaet eller udvikleren. De fleste nedbrud skyldes en håndfuld kendte årsager, og de første 15 minutter kan du klare uden at kunne kode.

Guiden gælder både en almindelig hjemmeside, en webshop og en webapp med login. Jeg er freelanceudvikler og arbejder selv med vedligehold af eksisterende systemer, så læs afsnittet om serviceaftaler med det i baghovedet. Resten virker uanset hvem du ringer til.

Den korte version: hvad betyder fejlen?

Det du ser i browseren, fortæller ofte hvor problemet sidder. Brug tabellen til at finde ud af hvem du skal kontakte først.

Beslutningsreglen er enkel. Drejer det sig om domæne eller server, starter du hos udbyderen. Drejer det sig om noget siden gør (fejl, login, betaling), starter du hos udvikleren.

Guiden her handler om de første timer. Hvordan du undgår nedbruddet i første omgang, gennemgår jeg i den komplette guide til drift og vedligehold af webapps.

Nødplanen: de første 15 minutter

De første minutter afgør ofte, om nedbruddet bliver kort eller langt. Du skal ikke rette fejlen selv, men du kan give den der skal rette den, et forspring.

1. Bekræft at siden er nede for alle. Åbn den på din telefon med wifi slået fra, og prøv en anden browser på computeren. Brug også en gratis nedetidstjekker, fx downforeveryoneorjustme.com. Virker siden andre steder, sidder problemet lokalt hos dig, og så kan du spare et opkald.
2. Skriv ned hvad du ser. Tag et skærmbillede af fejlen, og notér klokkeslættet og hvilke sider der fejler: forsiden, kassen, login eller det hele. Skriv også hvad der er ændret for nylig: en opdatering, et nyt plugin, en kampagne der sender mange besøgende, et skift af hosting eller et betalingskort der er udløbet.
3. Tjek de kedelige ting. Log ind hos din domæneudbyder og dit hostingfirma, og se efter ubetalte fakturaer, udløbne abonnementer og mails om driftsforstyrrelser. De fleste hostingfirmaer har en statusside, hvor kendte nedbrud står. Et udløbet domæne eller et afvist betalingskort er en banal, men almindelig årsag, og den kan ofte løses på få minutter.
4. Kontakt den rigtige med det samme. Brug tabellen ovenfor, og send det du skrev ned i trin 2. "Siden er nede" er svært at handle på. "Kassen giver 500-fejl siden kl. 9.40, lige efter opdateringen af betalingsmodulet" kan en udvikler gå direkte i gang med.

Mens fejlen bliver rettet: trin 5-7

Når den rigtige person er i gang, er din opgave at holde styr på resten. Her går det oftest galt fordi alle gerne vil hjælpe på én gang.

5. Lad være med at gøre det værre. Undgå at genstarte serveren igen og igen, slette filer eller gendanne en backup før nogen ved hvad der er galt. En backup fra i nat kan slette dagens ordrer og nye brugere, og en genstart kan fjerne logfilerne (systemets dagbog over hvad der er sket), som udvikleren har brug for. Lad kun én person arbejde i systemet ad gangen. Om dine backups overhovedet kan gendannes, skal du vide før det går galt, og det gennemgår jeg i guiden til backup af webapps.
6. Fortæl kunder og kolleger hvad der sker. En kort besked på mail, sociale medier eller i appen er bedre end tavshed. Skriv at I kender problemet, at det bliver løst, og hvornår næste opdatering kommer. Kundeservice skal have den samme besked, så kunderne ikke får tre forskellige svar. Lov ikke et tidspunkt for løsningen, før udvikleren har givet dig et.
7. Få en kort opsummering bagefter. Når siden kører igen, så bed om et par linjer på skrift: hvad skete, hvorfor, hvad blev gjort, og hvad forhindrer at det sker igen. Det tager kort tid at skrive og er det dokument, du får mest ud af ved næste nedbrud. Skyldtes nedbruddet en opdatering, er det også et godt tidspunkt at spørge hvor langt bagud resten af systemet er, og hvad det koster at lade framework og pakker sakke bagud.

Hvorfor nogle nedbrud tager 20 minutter og andre tre dage

Selve rettelsen er sjældent det, der tager tid. Det gør alt det før: at finde ud af hvem der har adgang til hvad, at finde koden, at forstå hvordan serveren er sat op, og at finde ud af om der findes en brugbar backup. En udvikler der ser dit system for første gang, bruger ofte det meste af den første tid på at orientere sig.

Fire ting gør den største forskel:

• Adgang. Logins til domæne, hosting, kode og tredjepartstjenester ligger samlet i en password manager, som virksomheden ejer.
• Overvågning. Et værktøj opdager nedbruddet, før dine kunder gør, og giver besked til den der kan gøre noget ved det. Jeg sammenligner mulighederne i oversigten over værktøjer til overvågning og oppetid.
• Kendskab til systemet. En udvikler der allerede kender koden og serveren, kan gå direkte til den sandsynlige årsag i stedet for at starte forfra.
• Testede backups. En backup er først noget værd, når nogen har prøvet at gendanne den.

Det er præcis det en serviceaftale skal sikre. Det vigtigste i aftalen er ikke timeprisen, men at det på forhånd er afklaret hvem du kontakter, hvor hurtigt vedkommende reagerer, og at adgang og overblik allerede er på plads. Hvad en god aftale skal dække punkt for punkt, finder du i tjeklisten til en serviceaftale med en udvikler.

Hvis du mistænker at siden er hacket

Tegnene er typisk fremmede sider eller links, omdirigering til spam, en advarsel i Google eller i browseren eller administratorbrugere du ikke kender. Her gælder trin 5 dobbelt: slet ikke noget, og geninstallér ikke siden selv. Sporene viser hvordan angriberen kom ind, og uden dem kommer vedkommende ofte ind igen ad samme vej.

Bed udvikleren om at lukke adgangen, skifte adgangskoder og nøgler og gemme logfilerne før der bliver ryddet op. Skift selv adgangskoden til din mail hvis den bruges til at nulstille adgangen til hosting eller domæne.

Indeholder systemet persondata, fx kundekonti, ordrer eller nyhedsbrevslister, kan der være tale om et brud på persondatasikkerheden. Så skal du som dataansvarlig anmelde bruddet til Datatilsynet uden unødig forsinkelse og om muligt inden for 72 timer efter at du er blevet opmærksom på det. Undtagelsen er hvis det er usandsynligt at bruddet udgør en risiko for de personer det handler om. Anmeldelsen sker via Virk.dk, og fremgangsmåden står på Datatilsynets side om anmeldelse af sikkerhedsbrud. Husk at 72 timer også løber hen over en weekend.

Hvornår du ikke skal ringe til en freelanceudvikler

En udvikler som mig er ikke altid den hurtigste vej ud af et nedbrud. I de her situationer er der bedre steder at starte:

• Kører din side på Shopify, Wix, Squarespace eller en anden færdig platform, ejer platformen serveren. Kontakt deres support, og tjek deres statusside. En ekstern udvikler kan ikke rette et nedbrud hos dem.
• Har dit hostingfirma et kendt nedbrud, kan ingen udvikler gøre det hurtigere. Så er opgaven at informere dine kunder og vente.
• Har du allerede et bureau eller en udvikler med en aftale, så kontakt dem først, også selvom du er utilfreds. En ny udvikler skal først have adgang og overblik, og det koster tid midt i et nedbrud. Skift bagefter når der er ro på.
• Har du brug for garanteret døgndækning, også om natten og i weekenden, er en udbyder med en fast vagtordning et bedre valg end en enkelt freelanceudvikler, mig inklusive.
• Er domænet udløbet, kan du som regel forny det selv hos udbyderen på få minutter.

Jeg passer bedst til specialudviklede systemer i Laravel/PHP eller JavaScript, især når ingen længere kender koden, eller når du vil have tingene sat op, så det næste nedbrud bliver kort.

Næste skridt: lav nødplanen før næste nedbrud

Det bedste tidspunkt at lave en nødplan er en almindelig tirsdag, hvor alt virker. Brug en time på tjeklisten nedenfor, og læg resultatet et sted hvor flere end dig kan finde det.

Kan du ikke krydse de fleste punkter af, er drift og vedligehold reelt overladt til tilfældighederne. Vil du have hjælp til at få dem på plads, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende systemer.

Ofte stillede spørgsmål

Hvor længe kan min hjemmeside være nede før det skader min placering i Google?+

Et nedbrud på nogle timer skader sjældent din placering mærkbart. Serverfejl får Googles crawler til at sænke tempoet, og sider der fejler vedvarende, bliver med tiden fjernet fra indekset. Skal siden lukkes akut i 1-2 dage, anbefaler Googles vejledning om at sætte et website på pause en informativ fejlside med statuskode 503 i stedet for det normale indhold. Jo kortere nedetid, desto bedre.

Kan jeg få erstatning fra mit hostingfirma når siden er nede?+

Som regel kun i begrænset omfang. Mange hostingfirmaer lover en bestemt oppetid i en SLA (serviceniveauaftale), men kompensationen er typisk en rabat på hostingregningen og ikke dækning af mistet omsætning. Læs vilkårene før du vælger hosting, og regn med at det er din egen forberedelse der begrænser tabet. Vil du dække tabt omsætning, er det et spørgsmål om forsikring og kontrakter, som en rådgiver bør se på.

Hvorfor virker siden på min computer, men ikke på min telefon?+

Oftest fordi de to enheder ikke slår siden op samme sted. Er domænet eller hostingen lige blevet ændret, kan det tage fra minutter til et døgn eller mere før alle netværk kender den nye adresse. Telefonen kan også bruge mobildata, en ældre browser eller gemte data. Prøv telefonen på både wifi og mobildata, og send resultatet til din udvikler. Fejler siden kun på bestemte enheder, er det et andet problem end et nedbrud.

Er en serviceaftale pengene værd hvis siden sjældent går ned?+

Det afhænger af hvad en dag uden siden koster dig. Til en lille præsentationsside kan det være nok at have en udvikler du kan ringe til og betale efter regning. Til en webshop, en kundeportal eller en SaaS hvor nedetid betyder tabte ordrer og utilfredse kunder, er en aftale med overvågning og kendt responstid typisk billigere end ét langt nedbrud. Regn på det: omsætning pr. time gange de timer et uforberedt nedbrud kan tage.