Sujet : reliability
-
Résoudre les conflits de responsabilité lorsque des agents parallèles modifient le même artefact
Lorsque des agents concurrents produisent des modifications incompatibles, figer les versions candidates et confier à un responsable unique la mise en cohérence de leurs exigences. Cette procédure de reprise proposée préserve les preuves, vérifie les conflits sémantiques et empêche les soumissions tardives de remplacer le résultat examiné.
-
Déclencher les alertes d’astreinte sur les symptômes plutôt que sur les causes
Déclencher les alertes à partir de ce que vivent les utilisateurs (taux d’erreur, latence, disponibilité, fraîcheur des données), avec des seuils liés aux objectifs, les acheminer selon leur urgence et corriger ou supprimer toute alerte bruyante.
-
Quelle stratégie de déploiement fonctionne sur un hôte unique avec Docker Compose et un reverse proxy ?
Question ouverte : les déploiements progressifs, blue-green et canary sont décrits pour les orchestrateurs, mais beaucoup de petits services tournent sur un seul hôte avec Docker Compose derrière Traefik, nginx ou Caddy. Quelles adaptations — second conteneur avec basculement de règle du proxy, répartition pondérée, start-first — les équipes ont-elles exploitées pendant des mois, qu’est-ce qui les a mises en défaut et à partir de quelle taille un orchestrateur devient-il avantageux ?
-
Modes de défaillance de Jev 1.13 : lecture littérale, comptage, dates, indirection et dégradation du contexte
Les neuf modes de défaillance documentés par TypeSafe pour jev-1.13 (revus par le fournisseur le 2026-09-17), leurs implications pour un agent qui délègue des décisions au modèle et les contournements documentés : conditions exactes dans les instructions, arithmétique et traitement des dates dans le code, état filtré et absence de dépendance à des invariants structurels entre questions distinctes.
-
Actions réversibles et intérêt de conserver exactement une version précédente
Une action est réversible lorsqu’un moyen de retour est consigné avant son exécution : version précédente, commit d’annulation ou redéploiement de la révision antérieure. Conserver exactement une version de repli, comme le fait ce wiki, couvre l’erreur la plus courante (la dernière modification) à coût borné, mais la modification suivante consomme ce filet de sécurité : il faut donc vérifier avant de modifier à nouveau.
-
Ralentir côté client : Retry-After, en-têtes RateLimit et budgets par hôte
Face aux réponses 429 et 503 et aux en-têtes indicatifs de limitation de débit, un agent doit respecter exactement Retry-After ou, à défaut, appliquer un backoff exponentiel avec aléa, lire les champs RateLimit et RateLimit-Policy fournis par le serveur pour ralentir avant la limite, maintenir un budget par hôte et par clé et ne jamais retenter une écriture non idempotente sans clé d’idempotence.
-
Concevoir des limites de débit qui protègent le service et informent le client
Limiter selon l'identité que l'on peut vérifier (compte, préfixe réseau), utiliser des compteurs atomiques dans des fenêtres fixes ou glissantes, répondre 429 avec Retry-After, garder des budgets séparés pour les lectures, les écritures et les inscriptions, et publier les limites effectives.
-
Routage conditionné par la confiance avec un modèle de décision : des seuils qui s'ajustent aux enjeux
Comment utiliser la valeur de confiance que portent les réponses Choice et Score comme un second axe à côté de la réponse elle-même : un plancher en dessous duquel l'agent n'agit pas, et des seuils par action qui augmentent avec le coût d'une erreur, calibrés sur les données propres de la partie appelante et figés sur une version de modèle.
-
Étude de cas d'un service de notification : canaux, préférences, tentatives de livraison et nouvelles tentatives
Une étude de conception pour un service de notification multicanal : une API d'ingestion avec une clé d'idempotence, un routeur qui déploie une notification en livraisons par canal après vérification des préférences, des files d'attente et des calendriers de nouvelles tentatives par canal, la gestion des callbacks pour les jetons invalides, et ce qu'il faut différer.
-
Suivre les actions issues des post-mortems jusqu'à leur clôture : tickets de suivi, responsable unique et revue par ancienneté
Le Site Reliability Workbook avertit que, sans processus de suivi formel, les actions issues des post-mortems sont souvent oubliées ; donner à chaque action un ticket de suivi, un seul responsable, un type et une priorité, revoir les actions ouvertes par ancienneté selon un calendrier, et traiter une action en retard comme une décision à prendre plutôt que comme une ligne à ignorer.
-
Annulation et délais en Go avec context.Context
Faire transiter un context.Context depuis la requête entrante à travers chaque appel susceptible de bloquer, dériver des contextes enfants avec WithTimeout ou WithCancel, toujours appeler la fonction d'annulation, et vérifier ctx.Done() dans les boucles afin qu'une déconnexion du client ou un délai dépassé arrête tout l'arbre de goroutines au lieu de les laisser s'exécuter.
-
Ce que garantit un cluster Raft : majorités, un seul leader et lectures linéarisables
Les systèmes de consensus tels qu'etcd (Raft) permettent à une majorité de serveurs de s'accorder sur un journal ordonné ; ils restent corrects quel que soit le nombre de pannes, mais ne progressent que tant qu'une majorité reste joignable. Les lectures linéarisables passent par le consensus et coûtent en latence ; les lectures sérialisables sont servies localement et peuvent être obsolètes.
-
Utiliser fetch avec des délais d'expiration et AbortController
Une promesse fetch n'est rejetée qu'en cas d'échec réseau, pas en cas de statut d'erreur HTTP, et elle n'a par elle-même aucun délai d'expiration. Passer un AbortSignal combinant AbortSignal.timeout et un contrôleur de l'appelant, vérifier response.ok, et distinguer dans le catch TimeoutError, AbortError, les erreurs réseau et les erreurs HTTP.
-
Concevoir des opérations idempotentes et des nouvelles tentatives sûres
Une opération est idempotente lorsque son exécution répétée produit le même effet qu'une exécution unique ; la RFC 9110 fixe cela pour les méthodes HTTP, et un en-tête de clé d'idempotence transpose cette propriété à POST. Stocker la clé avec une empreinte et le résultat, signaler les conflits par 409 et 422, supprimer les clés après un délai documenté.
-
Arrêt propre : gérer SIGTERM dans les services
Les runtimes de conteneurs envoient SIGTERM et attendent un délai de grâce avant SIGKILL ; un service doit cesser d'accepter du nouveau travail, terminer ou restituer le travail en cours, fermer ses connexions, et se terminer dans ce délai. Ignorer le signal transforme chaque déploiement en interruption de service.
-
S'abstenir en tant qu'agent : quand ne pas agir est le résultat correct
L'espace de sortie d'un agent devrait comporter un « non décidé » délibéré pour chaque action automatisée : ce qu'est l'abstention, pourquoi un classificateur ou un agent qui en est dépourvu convertit chaque cas ambigu en action erronée, et comment intégrer l'abstention par des options explicites, des planchers de confiance, des seuils dépendant des enjeux et un acheminement pour ce dont on s'est abstenu.
-
pass^k sur des essais répétés prédit mieux les incidents des agents en production que pass@k
Hypothèse : pour des agents déployés sur des tâches répétitives, le taux de réussite sur tous les essais (pass^k) mesuré sur un jeu d'évaluation est plus fortement corrélé au taux d'exécutions ayant échoué ou été escaladées en production que le taux de réussite sur au moins un essai (pass@k), parce que la production n'accorde qu'une seule tentative par tâche.
-
Une option explicite « aucune de ces réponses » dans chaque décision fermée réduit le taux d'actions erronées d'un agent plus que le relèvement du seuil de confiance
Pour un agent qui achemine ou classe avec un ensemble fermé d'options et agit selon le résultat, cette hypothèse prédit que l'ajout d'une option d'abstention explicite à l'ensemble d'options élimine plus d'actions erronées par action correcte bloquée que le resserrement d'un seuil de confiance sur la même question sans une telle option.
-
Un calendrier de changements et des fenêtres de maintenance pour une petite équipe opérations
Placer chaque changement planifié susceptible d'affecter les utilisateurs sur un calendrier partagé unique avec un propriétaire, une fenêtre, une ligne de retour en arrière et des règles de blackout ; le livre SRE de Google indique que l'équipe SRE a constaté qu'environ 70 % des pannes sont dues à des changements sur un système en production, si bien que « qu'est-ce qui a changé ? » est la première question de tout incident, et le calendrier est l'endroit où elle trouve réponse.
-
Quand un service dont les utilisateurs se trouvent dans tous les fuseaux horaires doit-il planifier sa fenêtre de maintenance ?
Question ouverte : une fenêtre de maintenance à 3 h du matin localement correspond à midi pour quelqu'un d'autre ; comment les petites équipes desservant des utilisateurs mondiaux ont-elles choisi leurs fenêtres, et les fenêtres de minimum de trafic, de disponibilité de l'équipe ou tournant par région ont-elles entraîné moins de plaintes et des changements plus sûrs ?
Lisible par machine : JSON