503 Service Unavailable: Überlastung, Wartung, Retry-After

Lebendig, und die Arbeit ablehnend

Um überhaupt einen 503 zurückzugeben, muss etwas laufen: Es hat die TCP-Verbindung angenommen, die Anfrage geparst und eine Antwort erzeugt. Diese eine Tatsache schließt eine ganze Klasse von Problemen aus. Der Host ist erreichbar, der Netzwerkpfad funktioniert, TLS wurde terminiert, und der Webserver oder Proxy funktioniert. Was fehlt, ist Kapazität oder Bereitschaft.

RFC 9110 fügt einen Vorbehalt hinzu: Ein Server ist nicht verpflichtet, bei Überlastung 503 zu verwenden. Manche lehnen die Verbindung einfach stattdessen ab. Ein 503 ist also die höfliche Form der Überlastung. Bekommen Sie eine abgelehnte Verbindung oder ein Timeout statt eines 503, sehen Sie einen anderen und meist schlimmeren Fehlschlag.

Zwei Nachbarn lassen sich leicht verwechseln. Ein 504 Gateway Timeout bedeutet, das Backend wurde angenommen und hat dann nie rechtzeitig geantwortet; die Anfrage wurde versucht. Ein 503 bedeutet, die Anfrage wurde abgelehnt, bevor echte Arbeit begann. Die gesamte Familie wird im 5xx-Überblick verglichen.

Retry-After, und warum Sie es immer senden sollten

RFC 9110 erlaubt einem 503, einen Retry-After-Header zu tragen, in einer von zwei Formen: eine Anzahl Sekunden zu warten, oder ein absolutes HTTP-Datum.

HTTP/1.1 503 Service Unavailable
Retry-After: 300
Content-Type: text/html

Es kostet nichts. Wohlerzogene Clients und Bibliotheken weichen für das genannte Intervall zurück, statt auf einen bereits kämpfenden Server einzuhämmern. Suchmaschinen-Crawler behandeln die URL als vorübergehend nicht verfügbar und kommen später wieder, statt den Ausfall als Inhaltsentfernung zu behandeln. Ihr eigenes Monitoring und Ihre Status-Werkzeuge bekommen eine explizite erwartete Erholungszeit zum Anzeigen.

Ein 503 ist standardmäßig nicht cachefähig, Vermittler liefern ihn also nicht weiter aus, nachdem sich der Dienst erholt hat.

Was einen 503 verursacht

• Überlastung. Alle Worker-Threads, Prozesse oder Verbindungs-Slots sind beschäftigt, neue Anfragen werden also abgelehnt statt unbegrenzt in die Warteschlange gestellt. Startet typischerweise sporadisch zu Spitzenzeiten und wird konstant, während die Last wächst.
• Wartungsmodus. Ein absichtlicher Schalter, von einem Framework-Flag, einer Wartungsdatei oder einer Proxy-Regel. Das ist ein 503, der genau das tut, was er soll.
• Eine Abhängigkeit ist ausgefallen. Eine gut geschriebene Anwendung, die ihre Datenbank, ihren Cache oder ihre Queue nicht erreichen kann, sollte 503 zurückgeben statt eines Stack-Trace, denn der Zustand ist vorübergehend und nicht die Schuld der Anfrage.
• Keine gesunden Backends. Ein Load Balancer, bei dem jedes Mitglied seinen Health-Check nicht besteht, hat nichts, wohin er weiterleiten kann, und viele geben in diesem Zustand 503 zurück.
• Deploys und Neustarts. Das Fenster zwischen dem Entleeren des alten Prozesses und dem Bereitwerden des neuen.
• Absichtliches Abwerfen. Circuit Breaker und Admission Control geben absichtlich 503 zurück, um die noch funktionierenden Teile des Systems zu schützen.
• Ressourcenerschöpfung auf Host-Ebene. Kein Speicher mehr, keine Dateideskriptoren mehr oder eine volle Festplatte, was den Start neuer Arbeit verhindert.

Das 503-während-Deploy-Muster

Das ist der häufigste 503, der kein echter Vorfall ist, und er hat eine erkennbare Form: ein kurzer Ausbruch von 503ern, Sekunden bis ein paar Minuten lang, der genau bei einem Release beginnt und von selbst endet. Gleichen Sie die Zeitstempel mit Ihrer Deployment-Historie ab, bevor Sie sonst etwas untersuchen.

Gut gehandhabt sollte ein Wartungs-503:

1. Den echten Statuscode zurückgeben. Eine mit 200 ausgelieferte Wartungsseite sagt Crawlern, Ihr Inhalt sei jetzt ein Wartungshinweis, was das schlechtestmögliche Ergebnis für ein geplantes Fenster ist.
2. Retry-After einschließen mit einer realistischen Schätzung des Fensters.
3. Statisch und günstig bleiben. Die Wartungsseite sollte nicht von der Datenbank oder Anwendung abhängen, die Sie gerade offline genommen haben.
4. Ihre eigenen Adressen durchlassen, damit das Team das neue Release prüfen kann, bevor wieder geöffnet wird.
5. Im Monitoring als Wartungsfenster geplant sein, damit ein geplanter Ausfall nicht die Bereitschaftsperson alarmiert.

Die Lösung für ungeplante Deploy-503er ist ein health-gegatetes Rolling Update: den neuen Prozess starten, auf einen bestandenen Readiness-Check warten, dann den alten entleeren und stoppen. Richtig gemacht, gibt es kein Fenster, in dem nichts bedienen kann.

So beheben Sie einen ungeplanten 503

1. Bestätigen Sie den Code und lesen Sie die Header, einschließlich ob ein Retry-After gesendet wurde und welche Komponente die Antwort gezeichnet hat:

   curl -sS -o /dev/null -D - https://example.com/

2. Schließen Sie zuerst den Wartungsmodus aus. Prüfen Sie auf ein Wartungs-Flag oder eine nach einem Release übrig gebliebene Datei. Das passiert öfter, als irgendjemand zugibt.
3. Prüfen Sie die Backend-Gesundheit. Schauen Sie an einem Load Balancer, wie viele Mitglieder ihre Checks bestehen. Null gesunde Mitglieder ist eine sofortige Antwort.
4. Schauen Sie sich die Sättigung an. Nutzung von Worker- und Verbindungspool, Speicher, Datenbankverbindungen und Queue-Tiefe. Ein 503 unter Last mit allem an der Obergrenze ist Kapazität, kein Bug.
5. Prüfen Sie Abhängigkeiten. Ist die Datenbank, der Cache oder eine kritische API ausgefallen, beheben Sie das statt der Web-Schicht.
6. Entlasten Sie, dann finden Sie die Ursache. Horizontal skalieren oder Limits erhöhen stellt den Dienst wieder her, aber ein 503, der ohne Traffic-Anstieg auftauchte, verbirgt meist eine langsame Abfrage oder ein Leck, das wiederkehrt.

Spitzenzeit-503er und geplante Wartungsfenster

Überlastungs-503er sind meist lange sporadisch, bevor sie konstant werden, tauchen zu Spitzenzeiten auf und lösen sich von selbst. Diese frühe Phase ist von einem Browser aus leicht zu übersehen und in einer kontinuierlichen Aufzeichnung offensichtlich. Eine geplante HTTP-Prüfung, die den erwarteten Statuscode bestätigt, macht aus diesen verstreuten Fehlschlägen einen sichtbaren Trend mit angehängten Zeiten, sodass Sie handeln können, bevor die sporadische Phase zu einem Ausfall wird. Wartungsfenster im selben Werkzeug zu planen hält geplante 503er davon ab, Alarme zu erzeugen.