Que signifie une erreur 503 Service Unavailable et à qui la faute

Une erreur 503 Service Unavailable est la seule erreur serveur qui soit généralement intentionnelle. Quelque chose a décidé que cette requête ne serait pas servie tout de suite, et l’a dit, plutôt que d’essayer et d’échouer.

Cela en fait le cas à part de sa famille. Une 500 est du code qui a cassé pendant son exécution. Une 502 est un proxy qui reçoit une réponse inutilisable de ce qui se trouve derrière lui. Une 504 est ce même quelque chose qui ne répond jamais à temps. Toutes les trois sont des échecs. Une 503 est une décision.

Les quatre choses qui prennent cette décision

Depuis un navigateur elles sont identiques, et elles signifient des choses complètement différentes pour qui exploite le site.

Le mode maintenance. Quelqu’un a délibérément placé le site derrière une page d’attente pendant qu’une migration tourne ou qu’un déploiement arrive. Ici la 503 fonctionne exactement comme prévu, et c’est le seul cas où la bonne réaction est de revenir plus tard.

L’application n’accepte pas de connexions. Tous les workers sont occupés, le pool de connexions est plein, la file devant lui est à sa limite. Le serveur de devant est toujours debout et répond toujours, alors il répond avec la seule chose honnête qu’il ait : pas maintenant.

Un limiteur de débit. Vous, ou le réseau sur lequel vous êtes, avez envoyé plus de requêtes qu’un seuil n’en autorise. Certains services utilisent une 429 pour cela, ce qui est plus précis et plus utile ; beaucoup utilisent une 503, et un CDN placé devant une application transforme souvent l’une en l’autre.

Rien ne tourne. Un autoscaler qui n’a pas rattrapé un pic de trafic, un déploiement dont la nouvelle version n’a pas passé son health check, un conteneur mort et non remplacé. Le répartiteur de charge a des cibles saines vers qui envoyer le trafic, n’en trouve aucune, et renvoie une 503 parce qu’il n’y a nulle part où l’envoyer.

Seule la première est planifiée. Les trois autres sont le système qui dit qu’il est à sa limite ou qu’il a perdu quelque chose, dans la formulation polie réservée à un état temporaire.

L’en-tête que presque personne ne lit

Une 503 est le code de statut auquel une réponse est attachée. La réponse peut porter Retry-After, qui indique soit combien de secondes attendre, soit la date et l’heure exactes auxquelles revenir :

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

C’est le site qui vous dit que ce sera deux minutes. Les pages de maintenance bien configurées le posent, les CDN le laissent passer, et l’envoyer ne coûte rien.

Deux choses en découlent, et elles pointent dans des directions opposées. Si vous écrivez un client, lisez l’en-tête plutôt que d’inventer votre propre backoff : un service qui vous a dit 120 secondes et qui reçoit une nouvelle tentative toutes les deux se voit demander de servir précisément les requêtes qu’il vient de dire ne pas pouvoir servir. Et si vous exploitez le site, posez-le. Une 503 avec un Retry-After, c’est un moteur de recherche qui garde la page au lieu de la traiter comme disparue, et un client qui attend correctement plutôt qu’un qui ajoute à la charge ayant causé le problème.

Si vous êtes le visiteur

Une 503 signifie généralement attendre, et, chose rare pour une erreur, l’attente fonctionne souvent. Rechargez après une ou deux minutes. Si c’est un déploiement ou un pic, cela se règle tout seul, et il n’y a rien dans votre navigateur qui y touche de toute façon.

La seule chose qui vaille la peine d’être vérifiée est de savoir si vous êtes le seul. Une 503 que tout le monde obtient, c’est la capacité du site ou sa fenêtre de maintenance. Une 503 que vous obtenez et qu’un collègue sur un autre réseau n’obtient pas est plutôt un limiteur de débit qui en a après votre adresse, et un téléphone en données mobiles répond à cette question en une dizaine de secondes. Toute la question de distinguer votre bug de leur panne se ramène à cette distinction.

Si le site est le vôtre

La réponse ne vous dit presque rien, mais contrairement à une 500, la cause se trouve généralement devant l’application plutôt qu’à l’intérieur.

Commencez par quelle couche l’a émise. Une 503 de nginx, d’un répartiteur de charge ou d’un CDN est identique pour le navigateur et vient de trois endroits différents avec trois journaux différents. Le corps la trahit souvent, parce que chacun d’eux embarque sa propre page par défaut, et les en-têtes de réponse nomment généralement ce qui les a produits. Si votre application n’a jamais tourné, son journal sera silencieux, et ce silence est un indice et non une impasse.

Ensuite la question évidente, qu’il est facile de sauter quand un site est à terre : le mode maintenance est-il encore actif ? Une page d’attente censée durer dix minutes et qui a survécu au déploiement qui l’avait levée est une 503 assez courante pour être vérifiée en premier, et l’écarter prend quelques secondes.

Si c’est de la capacité, la solution n’est pas sur la page d’erreur. Regardez la saturation des workers, les limites du pool et la profondeur de la file sur toute la fenêtre plutôt que les requêtes qui ont reçu la 503, parce que celles qui ont reçu la 503 sont celles arrivées après le début du problème. Si ce sont les health checks, la question est de savoir si le check a raison de dire l’application malade ou s’il échoue pour une raison qui lui est propre, et ces deux cas appellent des réponses opposées.

Pourquoi une 503 mérite d’être signalée correctement

La plupart des 503 se résorbent. C’est exactement ce qui les rend glissantes : le temps que quelqu’un enquête, le site est revenu et il n’y a rien à regarder. Il reste le souvenir qu’a quelqu’un d’une page d’erreur, et une intuition sur le moment approximatif.

Les problèmes de capacité et les mauvais déploiements ne se rejouent pas sur commande. Ils surviennent au moment où le trafic a franchi une ligne, et la trace qu’ils laissent est une fenêtre dans un graphique que personne ne sait devoir aller regarder si personne n’a noté quand c’est arrivé.

Pour une 503, la partie utile est l’horodatage et les en-têtes de réponse : quelle couche a répondu, quel Retry-After elle a annoncé, et la minute exacte. Cela suffit à retrouver la bonne fenêtre dans un tableau de bord, et c’est là que se trouve réellement la réponse.

En un paragraphe

Une erreur 503 Service Unavailable signifie que quelque chose a choisi de ne pas servir la requête plutôt que d’essayer et d’échouer, ce qui la sépare d’une 500, d’une 502 et d’une 504. Quatre choses font ce choix : le mode maintenance, une application à court de capacité, un limiteur de débit, et un répartiteur de charge sans rien de sain vers quoi envoyer le trafic. Seule la première est planifiée. Si vous êtes de passage, attendez une minute puis vérifiez si quelqu’un d’autre la voit. Si le site est le vôtre, déterminez d’abord quelle couche a répondu, assurez-vous que le mode maintenance n’est pas simplement resté actif, et posez Retry-After pour que les clients qui attendent attendent correctement au lieu d’ajouter à la charge.