Les détails que @Stephen soulève sont vraiment importants. Parce que nous devons comprendre ce qu’est le zéro temps d’arrêt : par exemple, je pourrais contourner une exigence de zéro temps d’arrêt en faisant ce qui suit :
Je définis le zéro temps d’arrêt comme ne jamais répondre à l’utilisateur avec un code autre que HTTP 200 lorsque la requête est valide (en gardant les codes 300 et 400 ouverts si nécessaire). Ensuite, je déploie Discourse sur un droplet à 10 $ dans une solution mono-conteneur et j’ajoute Add an offline page to display when Discourse is rebuilding or starting up pour éviter les erreurs 500. De cette façon, je ne montre pas un site qui est en panne.
Est-ce que, dans un état d’esprit rationnel, je penserais que cela constitue un zéro temps d’arrêt ? Jamais. Est-ce que cela fonctionne comme proposé ? Bien sûr. Et je pourrais même ajouter un serveur de secours dans une autre région pour être encore plus à l’épreuve du zéro temps d’arrêt.
C’est pourquoi la qualification et la sémantique sont importantes. Ce n’est pas la même chose de toujours afficher quelque chose que d’avoir toujours une fonctionnalité sur le site.