WatchEn 503 har en særlig personlighed blandt HTTP-fejl: det er den, der dukker op på det værst tænkelige tidspunkt. Trafikspidsen fra en vellykket lancering, bølgen når en kampagne går live, belastningen lige efter du kommer i medierne — det er præcis dér, en 503 har for vane at vise sig og gøre din bedste dag til din mest stressende. Det betryggende er, at en 503 ikke er din server, der siger, den er i stykker. Det er din server, der siger, den er overvældet — og det er et helt andet, og mere løseligt, problem.
Hvad 503 faktisk betyder
HTTP 503 Service Unavailable er i klart sprog serverens måde at sige “jeg er her, men jeg kan ikke levere det her lige nu.” Den skelnen betyder noget. Forespørgslen nåede din infrastruktur helt fint — DNS slog op, forbindelsen åbnede, serveren svarede — men noget bag fordøren, applikationen, en backend-tjeneste eller en load balancer, er utilgængeligt til faktisk at udføre arbejdet.
Det hjælper at placere den blandt naboerne, for de tre forveksles konstant. En 500 betyder, at applikationen blev nået og fejlede under behandlingen af forespørgslen. En 502 betyder, at en gateway eller proxy fik et ugyldigt svar, eller slet intet, fra noget upstream. En 503 betyder specifikt, at tjenesten midlertidigt ikke kan håndtere forespørgslen — med den implikation, at den måske er fin igen om et øjeblik. “Midlertidigt” er det mest nyttige ord i hele statussen.
Almindelige årsager
Næsten hver 503 kan spores tilbage til den samme korte liste. Den mest almindelige er overbelastning: serveren modtager mere trafik, end den kan håndtere, og afviser forespørgsler for at holde sig i live. Lige bagefter kommer en backend, der er nede eller genstarter — appen crashede, en pulje af databaseforbindelser er udtømt, en pulje af workers døde under pres.
Så er der de planlagte og halvplanlagte tilfælde. Et deploy er i gang, og den nye version er ikke færdig med at komme op. Siden er bevidst i vedligeholdelsestilstand. Eller en load balancer returnerer 503, fordi den ikke har nogen sunde backends tilbage at sende trafik til — hvilket reelt er overbelastnings- eller crash-tilfældet med en anden hat på. En pludselig trafikspids, der rammer en underdimensioneret pulje af workers, er den klassiske udløser, der binder de fleste af disse sammen.
Sådan fikser du den
Arbejd bagfra og frem. Bekræft først, om backend-applikationen faktisk kører, og genstart den, hvis ikke — et overraskende antal 503'er er simpelthen en crashet proces. Se så på serverbelastning og hukommelse: er du reelt overbelastet, er løsningen kapacitet, så skalér op eller tilføj workers frem for at bekæmpe symptomet.
Er du midt i et deploy, er en kort 503 forventet og bør forsvinde, når den nye version melder sig sund; forsvinder den ikke, fejler dit health-tjek, og den nye version kom aldrig ordentligt op. Når årsagen ikke er oplagt, så lad infrastrukturen indsnævre den: tjek load balancerens backend-sundhed og læs dine fejllogs for at finde præcis, hvilket lag der er det, der siger “utilgængeligt.”
Sådan fanger du den næste tidligt med WatchControl
Her er, hvad der gør 503'er reelt farlige: under belastning kommer og går de. De blinker ind i halvfems sekunder under en spids og forsvinder, før du kan genskabe dem, så de er nemme at afvise — indtil spidsen er stor nok til, at de ikke forsvinder, og du har et fuldt nedbrud på din lanceringsdag.
Måden at være på forkant er at holde øje med dem løbende i stedet for at snuble over dem. Oppetidsovervågning med svartids-måling viser dig præcis, hvornår 503'er begynder at dukke op og hvor ofte, og gør et usynligt blink til en synlig tendens — og alarmerer dig i samme øjeblik, så du kan tilføje kapacitet, før det vælter. WatchControl tjekker dit site hvert minut, markerer statuskode- og svartidsproblemer og alarmerer dig straks på e-mail, SMS eller webhook — gratis at starte — så den næste trafikspids er noget, du så komme, ikke noget, du hørte om på de sociale medier.