Den dyreste feilen i en liten nettbutikk er sjelden en krasj. Det er en stille feil: siden laster, forsiden ser fin ut, og betalingsknappen gjør ingenting. Ingen feilmelding, ingen alarm, bare ingen salg. Du oppdager det når en kunde sender e-post, eller verre, når du ikke gjør det.

Du trenger ikke bli systemadministrator for å unngå det. Du trenger å vite hva du faktisk måler.

Tre ting som ligner hverandre, men ikke er det #

1. Siden svarer. Serveren returnerer HTTP 200 for en adresse. Det er det enkleste og det billigste. Det betyr kun at noe svarte, ikke at det som svarte var riktig.

2. Tjenesten virker. Du sjekker at innholdet er det du forventer: at siden inneholder teksten «Til kassen», at API-et svarer med gyldig data, eller at en betalingsøkt faktisk kan opprettes. Dette fanger feil som en ren statuskode går glipp av.

3. Betalingsflyten virker. Hele veien fra handlekurv til bekreftet bestilling. Dette er det du egentlig vil vite, og det er også det som er vanskeligst å teste uten å gjøre ting du ikke bør.

Mange stopper på nummer 1 og tror de har dekning for 3. Det er en misforståelse som koster penger.

Hvorfor HTTP 200 ikke betyr at kunden kan betale #

Fordi suksesskoden kommer fra serveren din, ikke fra hele kjeden. Disse feilene gir fortsatt 200:

  • En JavaScript-feil gjør at betalingsknappen ikke reagerer. Selve HTML-siden er helt fin.
  • Du har byttet nøkler hos betalingsleverandøren, og siden din bruker fortsatt de gamle.
  • Betalingsskjemaet laster fra en tredjepart som har problemer. Siden din er oppe, skjemaet er blankt.
  • Kassesiden viser en vennlig feilmelding med statuskode 200 fordi noen skrev den slik.
  • Bekreftelsesmelding og e-post henger på en webhook som ikke lenger blir levert.

I alle disse tilfellene er monitoren din grønn og kassen din død.

Start med én eller to sjekker #

Ikke begynn med ti. Begynn med de to tingene som stopper penger:

  1. Kassesiden inneholder det den skal. En såkalt nøkkelordsjekk: monitoren henter siden og varsler hvis en bestemt tekst mangler, for eksempel teksten på betalingsknappen. Mange overvåkingstjenester har dette. UptimeRobot, for eksempel, oppgir nøkkelordsmonitorering på gratisplanen, men ikke SSL- og domeneutløpsvarsler. Dobbeltsjekk planbeskrivelsen selv, siden den kan endres (UptimeRobot, priser).
  2. Noe forteller deg at salg faktisk skjer. Se på ordresiden og ikke bare serveren. Hvis du normalt får minst én bestilling om dagen og det har gått 48 timer uten, er det verdt et varsel, uavhengig av hvor grønne monitorene er. Dette er den grovkornede sjekken som fanger feil ingen tenkte på.

Det er nok til å begynne. Alt annet kan vente til du har sett hvor det faktisk svikter.

Hva med å teste betaling automatisk? #

Fristende, men ikke slik mange tror. Det finnes to forskjellige ting her.

Testmodus. De fleste betalingsleverandører har et sandkasse- eller testmiljø der du kan bruke testkort uten at penger flyttes. Stripe, som eksempel, beskriver sandkasser som et isolert miljø der kort fra deres testlister kan brukes uten ekte belastning (Stripe, testing). Men objekter i testmodus og live-modus er adskilt, og testnøkler er ikke de samme som live-nøkler. En vellykket testbetaling bekrefter at koden din virker mot testmiljøet. Den bekrefter ikke at live-oppsettet er friskt.

Ekte transaksjoner. Å la en robot kjøpe noe ekte hver time høres ut som den ærligste testen. Det har tre problemer:

  • Kostnad. Hver transaksjon kan gi gebyrer, og refusjoner returnerer ikke nødvendigvis alt.
  • Sikkerhet. Du må lagre et ekte betalingsmiddel i en automatisert jobb. Det er en ny angrepsflate du ikke trenger.
  • Regler. Stripe skriver direkte at tjenesteavtalen forbyr testing i live-modus med ekte betalingsmiddeldetaljer (Stripe, testing). Sjekk avtalen hos leverandøren din, ikke anta.

Min anbefaling er derfor å la ekte transaksjoner være en manuell sjekk du gjør sjelden og bevisst, for eksempel etter en endring, og la de automatiske sjekkene dekke det som kan dekkes uten betaling.

Reduser de falske alarmene #

En monitor som roper ulv hver tredje dag blir slått av. Fem enkle grep:

  • Krev to feil på rad. Varsle først når to sjekker etter hverandre feiler. De fleste tilfeldige blipper forsvinner da.
  • Sett fornuftig tidsavbrudd. For stramt, og trege men friske sider utløser alarm. For løst, og du ser ikke problemet.
  • Varsle på det som koster penger. Kassen og betalingsstien. Ikke bloggen, ikke «om oss».
  • Skill varsel fra alarm. En treg side kan vente til morgenen. En død kasse kan ikke.
  • Planlagt vedlikehold er ikke en alarm. Bruk vedlikeholdsvindu der verktøyet har det, ellers pauser du monitoren manuelt.

Og sjekk at varselet faktisk kommer frem. En gratisplan har ofte færre varslingskanaler enn du tror. UptimeRobots prisside lister bestemte integrasjoner for gratisplanen og sier ikke tydelig noe om e-post, så test kanalen din selv før du stoler på den.

En enkel egen sjekk #

Vil du ikke bruke en ekstern tjeneste, holder et lite skript. Dette er et eksempel for Linux eller macOS med curl, og må tilpasses adresse og tekst:

bash 
#!/usr/bin/env bash
# Sjekker at kassen svarer OG inneholder knappeteksten.
URL="https://eksempel.no/kasse"
FORVENTET="Til betaling"

for forsok in 1 2 3; do
  svar=$(curl -s -m 10 -w "\n%{http_code}" "$URL")
  kode=$(echo "$svar" | tail -n 1)
  tekst=$(echo "$svar" | sed '$d')
  if [ "$kode" = "200" ] && echo "$tekst" | grep -q "$FORVENTET"; then
    exit 0
  fi
  sleep 20
done

echo "Kassen svarer ikke som forventet: $URL" >&2
exit 1

Kjør det fra en planlagt jobb og la en feil gi deg et varsel du faktisk ser. Den biten, hvor varselet havner, er den som oftest mangler. Og husk at et skript på samme maskin som nettstedet ikke varsler deg hvis hele maskinen er nede. Kjør det et annet sted.

Hva du kan hoppe over #

  • Dashbord med fargerike grafer. Du trenger ett svar: virker kassen?
  • Sekunders sjekkintervaller for en liten butikk. Et par minutter holder for de fleste.
  • Tjenester du ikke forstår rollen til. Hver ny monitor er en ting til å vedlikeholde.

Start med kasseteksten og ordretelleren. Sjekk om varselet kommer frem. Kom tilbake når du har sett hva som faktisk svikter, og legg til en sjekk til når du har en grunn.