503 Service Unavailable: sovraccarico, manutenzione e Retry-After

Vivo, e rifiuta il lavoro

Per restituire affatto un 503, qualcosa deve essere in esecuzione: ha accettato la connessione TCP, analizzato la richiesta e generato una risposta. Questo singolo fatto esclude un'intera classe di problemi. L'host è attivo, il percorso di rete funziona, il TLS si è concluso, e il server web o il proxy stanno funzionando. Ciò che manca è capacità o disponibilità.

L'RFC 9110 aggiunge un avvertimento: un server non è obbligato a usare 503 quando è sovraccarico. Alcuni semplicemente rifiutano la connessione invece. Un 503 è quindi la forma educata del sovraccarico. Se ottieni una connessione rifiutata o un timeout invece di un 503, stai guardando un guasto diverso e di solito peggiore.

Due vicini sono facili da confondere. Un 504 Gateway Timeout significa che il backend è stato accettato e poi non ha mai risposto in tempo; la richiesta è stata tentata. Un 503 significa che la richiesta è stata rifiutata prima che iniziasse il lavoro reale. L'intera famiglia è confrontata nella panoramica 5xx.

Retry-After, e perché dovresti sempre inviarlo

L'RFC 9110 permette a un 503 di portare un'intestazione Retry-After, in una di due forme: un numero di secondi da aspettare, oppure una data HTTP assoluta.

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

Non costa nulla. I client e le librerie ben educati aspettano l'intervallo indicato invece di martellare un server già in difficoltà. I crawler dei motori di ricerca trattano l'URL come temporaneamente non disponibile e tornano più tardi invece di trattare l'interruzione come rimozione del contenuto. Il tuo stesso monitoraggio e i tuoi strumenti di stato ottengono un tempo di recupero atteso esplicito da mostrare.

Un 503 non è memorizzabile in cache per impostazione predefinita, quindi gli intermediari non continueranno a servirlo dopo che il servizio si è ripreso.

Cosa causa un 503

• Sovraccarico. Tutti i thread worker, i processi o gli slot di connessione sono occupati, quindi le nuove richieste vengono rifiutate invece di essere messe in coda indefinitamente. Tipicamente inizia in modo intermittente al picco e diventa costante man mano che il carico cresce.
• Modalità manutenzione. Un interruttore intenzionale, da un flag del framework, un file di manutenzione o una regola proxy. Questo è un 503 che fa esattamente quello che dovrebbe.
• Una dipendenza è giù. Un'applicazione ben scritta che non può raggiungere il proprio database, cache o coda dovrebbe restituire 503 invece di uno stack trace, perché la condizione è temporanea e non colpa della richiesta.
• Nessun backend sano. Un load balancer con ogni membro che fallisce il proprio controllo di salute non ha nulla verso cui instradare, e molti restituiscono 503 in quello stato.
• Deployment e riavvii. La finestra tra lo svuotamento del vecchio processo e il nuovo che diventa pronto.
• Scarico deliberato. Circuit breaker e controllo di ammissione restituiscono 503 di proposito per proteggere le parti del sistema che funzionano ancora.
• Esaurimento delle risorse a livello host. Memoria esaurita, descrittori di file esauriti o un disco pieno, il che impedisce l'avvio di nuovo lavoro.

Lo schema del 503 durante un deployment

Questo è il 503 più comune che non è un vero incidente, e ha una forma riconoscibile: un breve picco di 503, da pochi secondi a un paio di minuti, che inizia esattamente a una release e finisce da solo. Correla i timestamp con la tua cronologia di deployment prima di indagare qualsiasi altra cosa.

Gestito bene, un 503 di manutenzione dovrebbe:

1. Restituire il codice di stato reale. Una pagina di manutenzione servita con 200 dice ai crawler che il tuo contenuto ora è un avviso di manutenzione, il che è il peggior esito possibile per una finestra pianificata.
2. Includere Retry-After con una stima realistica della finestra.
3. Restare statica ed economica. La pagina di manutenzione non dovrebbe dipendere dal database o dall'applicazione che hai appena messo offline.
4. Lasciar passare i tuoi stessi indirizzi così il team può verificare la nuova release prima di riaprire.
5. Essere pianificato nel monitoraggio come una finestra di manutenzione, così un'interruzione pianificata non avvisa chi è di turno.

La correzione per i 503 di deployment non pianificati è un rolling update controllato dalla salute: avvia il nuovo processo, aspetta che superi un controllo di prontezza, poi svuota e ferma il vecchio. Fatto correttamente, non c'è finestra in cui nulla può servire.

Come correggere un 503 non pianificato

1. Conferma il codice e leggi le intestazioni, incluso se è stato inviato un Retry-After e quale componente ha firmato la risposta:

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

2. Escludi prima la modalità manutenzione. Controlla un flag o un file di manutenzione rimasto in posto dopo una release. Succede più spesso di quanto chiunque ammetta.
3. Controlla la salute del backend. Su un load balancer, guarda quanti membri stanno superando i controlli. Zero membri sani è una risposta immediata.
4. Guarda la saturazione. L'utilizzo dei worker e del pool di connessioni, la memoria, le connessioni al database e la profondità della coda. Un 503 sotto carico con tutto al proprio limite è capacità, non un bug.
5. Controlla le dipendenze. Se il database, la cache o un'API critica sono giù, correggi quello invece del livello web.
6. Allevia il carico, poi trova la causa. Scalare o alzare i limiti ripristina il servizio, ma un 503 apparso senza un aumento di traffico di solito nasconde una query lenta o una perdita che tornerà.

I 503 delle ore di punta e le finestre di manutenzione pianificate

I 503 da sovraccarico sono di solito intermittenti molto prima di diventare costanti, comparendo nelle ore di punta e risolvendosi da soli. Quella fase iniziale è facile da perdere da un browser e ovvia in un registro continuo. Un controllo HTTP pianificato che fa un assert sul codice di stato atteso trasforma quei fallimenti sparsi in una tendenza visibile con orari allegati, così puoi agire prima che la fase intermittente diventi un'interruzione. Pianificare le finestre di manutenzione nello stesso strumento evita che i 503 pianificati generino avvisi.