Contexte Un simple appui sur un écran mobile peut déclencher un certain nombre d'événements en arrière-plan — des appels d'API vers des microservices, l'envoi de messages/événements via des files d'attente, des écritures dans des bases de données et des tentatives de relance en cas d'échecs transitoires — tout cela avant de renvoyer une confirmation de réussite… ou une notification d'erreur. L'utilisateur ne voit pas cette complexité. Il n'est pas au courant de votre politique d'autoscaling, des taux de réussite du cache ou des graphes de dépendances. Il sait seulement si sa course a été commandée, si son paiement a été effectué ou si sa commande de nourriture a été confirmée. Et quand les choses tournent mal, c'est cette complexité cachée qui détermine la façon dont votre système se rétablit. C'est pourquoi la fiabilité ne peut plus être uniquement le travail de l'équipe SRE. C'est une responsabilité partagée — une responsabilité qui doit être intégrée aux décisions quotidiennes de chaque ingénieur back-end. De la façon dont nous concevons les systèmes à la façon dont nous écrivons les alertes, déployons le code et gérons les incidents, la fiabilité est conçue — elle ne se souhaite pas.