Nettsiden er nede – finn feilen uten å gjøre den større

Når nettsiden er nede, er det fristende å endre DNS, restarte serveren og gjenopprette backup samtidig. Da kan en liten feil bli en større hendelse, og sporene som viste årsaken forsvinner.

Begynn rolig: Bekreft hvem som er berørt, kopier den nøyaktige feilen og finn laget som svikter. En nettlesermelding, DNS-status eller HTTP-kode kan redusere leteområdet fra hele nettløsningen til én komponent.

Sjekk dette først

Gjør disse fire kontrollene før dere endrer noe:

1. Åpne den nøyaktige URL-en på mobilnett, ikke bare samme trådløse nettverk.
2. Test både forsiden og en kjent underside.
3. Noter tidspunkt med tidssone, feilmelding og hva som sist ble endret.
4. Sjekk statussiden til hosting-, DNS-, CDN- og publiseringsleverandøren.

Hvis siden virker på mobilnett, men ikke på kontornettet, er det ikke bevis for at alt er friskt. Feilen kan være lokal DNS-cache, nettverksfilter, IPv6, bedriftsproxy eller en blokkering som bare rammer enkelte adresser. Hvis siden feiler fra flere uavhengige nettverk, er hendelsen bredere.

De første 15 minuttene

Minutt 0–3: Bekreft omfanget

Finn ut om feilen gjelder:

• alle brukere eller bare ett nettverk
• hele domenet eller én URL
• både www og domenet uten www
• bare innlogging, skjema eller betaling
• IPv4, IPv6 eller begge
• én region eller flere

Ikke bruk søkemotorens cache som oppetidstest. Den kan vise en gammel kopi selv om nettstedet er nede nå.

Minutt 3–7: Sikre bevis

Ta skjermbilde og kopier:

• hele URL-en
• nettleserens nøyaktige feilkode
• HTTP-status hvis den vises
• eventuell forespørsels-ID, Ray ID eller sporings-ID
• tidspunkt og tidssone
• IP-adressen eller nettverket testen kom fra hvis relevant
• siste publisering, DNS-endring, oppdatering eller konfigurasjonsendring

Lagre relevante logger før omstart. Ikke del passord, private nøkler, sesjonskapsler eller personopplysninger i en vanlig supportsak.

Minutt 7–12: Finn laget

Gå i rekkefølge: domene, DNS, TLS, CDN/proxy, webserver og applikasjon. Tabellen under peker mot riktig sted.

Minutt 12–15: Velg én trygg handling

Rull tilbake en kjent endring når sammenhengen er sterk og tilbakeføringen er testet. Eskaler til riktig leverandør når feilen ligger utenfor deres kontroll. Publiser en kort statusmelding hvis kundene er berørt. Endre bare én ting om gangen og noter resultatet.

Symptomkart: hva betyr feilen?

HTTP-standarden definerer blant annet 502 som et ugyldig svar fra en oppstrøms server, 503 som midlertidig utilgjengelighet og 504 som manglende svar innen rimelig tid fra oppstrøms tjeneste. Se RFC 9110 om HTTP-statuskoder når en leverandør bruker kodene annerledes.

1. Kontroller domenet og DNS

Et utløpt eller suspendert domene kan se ut som en hostingfeil. Kontroller først at domenet fortsatt er registrert og at navnetjenerne er de forventede.

På macOS eller Linux kan en teknisk ansvarlig gjøre en enkel kontroll:

dig +short eksempel.no NS
dig +short eksempel.no A
dig +short eksempel.no AAAA

Bytt eksempel.no med eget domene. Manglende A- og AAAA-svar er ikke alltid feil; noen oppsett bruker CNAME eller andre mekanismer. Det viktige er å sammenligne svaret med dokumentert oppsett.

Test deretter via mer enn én rekursiv resolver. Ulike svar kan bety at en endring fortsatt ligger i cache, at navnetjenerne gir inkonsistente svar, eller at feilen bare rammer enkelte resolvere.

NXDOMAIN betyr at navnet oppgis som ikke-eksisterende. Kontroller registrering, delegering og riktig vertsnavn. SERVFAIL betyr at resolveren ikke kunne levere et gyldig svar. En ødelagt DNSSEC-kjede, utilgjengelige autoritative servere eller feil delegering kan være årsaken.

Google Public DNS har en detaljert veiledning for domenefeil som viser hvordan flere resolvere og autoritative svar kan sammenlignes. Les også Vymos guide til vanlige DNS-feil .

Ikke bytt navnetjenere i panikk. Et navnetjenerbytte innfører et nytt oppsett og mer cache akkurat når situasjonen allerede er uklar.

2. Kontroller HTTPS og sertifikatet

Hvis DNS virker, men nettleseren viser et sertifikatvarsel, les den nøyaktige meldingen. Vanlige årsaker er:

• sertifikatet er utløpt
• sertifikatet dekker ikke vertsnavnet som åpnes
• serveren leverer feil sertifikat
• sertifikatkjeden er ufullstendig
• CDN eller proxy får ikke opprettet TLS-forbindelse til origin
• enhetens klokke er feil

Kontroller både domenet med og uten www hvis begge skal virke. En vellykket test på forsiden beviser ikke at et separat API- eller innloggingsdomene har gyldig sertifikat.

Ikke omgå nettleservarselet på en produksjonstjeneste der brukere skal sende inn data. Rett sertifikat, vertsnavn eller proxyoppsett. Vymos guide til vanlige SSL-feil går gjennom symptomene mer detaljert.

3. Finn HTTP-statusen

Når DNS og TLS virker, kan dere hente bare svarhodene:

curl -I --max-time 15 https://eksempel.no/

En 200 på forsiden betyr bare at akkurat den forespørselen fikk et vellykket HTTP-svar. Test den kritiske URL-en som faktisk feiler. En 301 eller 302 kan være riktig, men følg med på om videresendingen går i sirkel eller til feil domene.

Ta vare på svarhoder som forespørsels-ID, cache-status og Retry-After. De kan hjelpe leverandøren med å finne riktig forespørsel i loggene.

4. Skill CDN-feil fra origin-feil

Et CDN eller en reverse proxy står mellom brukeren og opprinnelsesserveren. Feilen kan ligge i kanten, forbindelsen videre eller selve origin.

For Cloudflare betyr en 522-feil at forbindelsen til origin fikk tidsavbrudd. En 524-feil betyr at forbindelsen ble opprettet, men at origin ikke leverte HTTP-svar innen grensen. Cloudflares feilsøking for 502- og 504-svar anbefaler å finne ut om svaret kommer fra Cloudflare eller origin før tiltak velges.

Kontroller:

• om origin svarer på riktig vertsnavn
• om brannmur eller ratebegrensning blokkerer proxyens adresser
• om serveren er overbelastet
• om en database eller ekstern tjeneste venter
• om DNS hos proxyen peker til riktig origin
• om en nylig regel, Worker eller omdirigering påvirker ruten

Ikke slå av proxy eller sikkerhet permanent bare for å få grønn skjerm. En midlertidig diagnostisk endring må være autorisert, tidsavgrenset og rulles tilbake.

5. Kontroller applikasjonen og databasen

Hvis webserveren svarer, kan nettstedet fortsatt være funksjonelt nede. Test den viktigste brukerreisen: innlogging, produktsøk, handlekurv, betaling eller innsending av skjema.

Se etter:

• feil i applikasjonsloggen ved samme tidspunkt
• full disk eller ressursgrense
• brudd i databaseforbindelsen
• feil etter plugin-, tema- eller PHP-oppdatering
• manglende miljøvariabel eller hemmelighet
• utløpt API-nøkkel eller tredjepartstjeneste
• køer eller bakgrunnsjobber som har stoppet
• feil ved siste deploy

Rull helst tilbake en konkret kode- eller konfigurasjonsendring før dere gjenoppretter hele databasen. En gammel databasekopi kan fjerne nye ordre, brukere eller skjemadata.

Når bør dere restarte?

En kontrollert restart kan være riktig når en prosess har låst seg, og dere har samlet nok data til videre analyse. Den bør ikke være første refleks.

Før restart bør dere vite:

• hvilken tjeneste som startes på nytt
• hvilken brukertrafikk som avbrytes
• om prosessen kommer opp automatisk
• om køer, låser eller midlertidige data går tapt
• hvor logger og minnedata bevares
• hvordan dere går tilbake hvis restart ikke hjelper

Hvis restarten løser symptomet, er årsaken fortsatt ukjent. Opprett en oppfølgingsoppgave i stedet for å lukke hendelsen som «fikset».

Rollback, failover eller restore?

Velg tiltak etter hva som faktisk feiler:

• Rollback passer når en nylig publisering eller konfigurasjon utløste feilen.
• Failover passer bare når reserve, data, DNS, sertifikater og prosedyre er testet på forhånd.
• Restore passer når data eller filer er korrupte eller slettet, og dere kjenner tidspunkt og konsekvens for nyere endringer.
• Vedlikeholdsside kan begrense forvirring mens kritisk funksjon repareres.

Dokumenter tidspunktet for tiltaket og kontroller mer enn forsiden etterpå. Skjema, betaling, e-postutsendelse og administrative funksjoner kan fortsatt være nede.

Slik melder dere saken til leverandøren

En god supportsak gjør det mulig å begynne feilsøkingen uten en lang spørsmålsrunde. Send:

• berørt domene og full URL
• starttidspunkt og om feilen fortsatt pågår
• omfang: alle, noen nettverk eller én funksjon
• nøyaktig feilkode og skjermbilde
• forespørsels-ID eller Ray ID
• siste kjente endring
• tester som er gjort og resultatene
• forretningskonsekvens, for eksempel at betaling er stoppet

Ikke send bare «nettsiden virker ikke». Ikke send passord eller hemmeligheter med mindre leverandøren tilbyr en avtalt sikker kanal og faktisk trenger dem.

Kommuniser mens dere retter

Ved en synlig hendelse bør én person eie statusoppdateringene. En kort melding kan inneholde:

• hva som er berørt
• når feilen startet
• hva kundene eventuelt kan gjøre i mellomtiden
• tidspunkt for neste oppdatering

Unngå å love et rettetidspunkt før årsaken og tiltaket er kjent. Etter hendelsen bør dere skrive ned tidslinje, årsak, hvorfor overvåkingen reagerte eller ikke reagerte, og ett konkret forebyggende tiltak. Se beredskapsplanen for domene, DNS og nettside for en varig arbeidsflyt.

Hvis nettsiden ligger hos Vymo

Vymos standardtilbud er én enkel bedriftsside som Vymo setter opp og leverer gjennom Cloudflare. Hvis siden viser ukjent innhold, sertifikatfeil eller ikke svarer, send Vymo en feilmelding med URL, tidspunkt, skjermbilde, nettverk og eventuell feilkode eller Ray ID.

Har dere bare domenet hos Vymo, mens nettstedet ligger hos en annen leverandør, kan Vymo hjelpe med å kontrollere registrering og DNS-oppsett. Feil i serveren eller applikasjonen må rettes av hostingleverandøren.

Vymo publiserer foreløpig ikke en døgnbemannet hendelsestjeneste, garantert responstid, RTO, RPO eller automatisk backupfrekvens for standardnettsiden. Virksomheter med slike krav må avklare beredskap og servicenivå skriftlig før bestilling.

Den raskeste veien tilbake er sjelden å gjøre mest mulig. Bekreft omfanget, bevar sporene, finn laget og gjør én kontrollert endring.