Uptime — le jeu de tri d'astreinte
Vous êtes d'astreinte. Douze alertes, quatre réponses possibles, un budget d'erreur. Gratuit, sans inscription.
- ⏱ Budget d'erreur43/43 min
- 🫂 Équipe▮▮▮▮▮5/5
- 🟢 Disponibilité100.000%
Douze alertes. Lisez les faits, choisissez une réponse. Tout n'est pas une urgence.
Comment jouer
- Aucun impact client ? Mettez en veille. Rien d'interne ne vaut de réveiller quelqu'un.
- Impact client et un déploiement de moins de 30 minutes ? Revenez en arrière : défaire bat diagnostiquer.
- Impact client, aucun déploiement récent, mais un runbook à jour ? Redémarrez en suivant le runbook.
- Impact client et ni l'un ni l'autre ? Appelez le responsable. Méfiez-vous des vieux déploiements et des runbooks périmés : ils ne comptent pas.
Comment ça marche
Vous êtes d'astreinte et la seule chose que vous maîtrisez, c'est ce que vous faites de chaque alerte. Une garde en distribue douze, une par une, et chaque carte énonce ses faits : si un client le voit, quand le service a été déployé pour la dernière fois, et si un runbook couvre le symptôme. De ces trois faits découle exactement une des quatre réponses. La règle est à l'écran dès la première carte et ne change jamais : ce qui change, c'est l'attention qu'il faut y mettre, car un déploiement d'il y a six heures n'est pas le suspect, et un runbook écrit pour l'ancienne architecture n'est pas un runbook. Deux jauges peuvent écourter la garde : le budget d'erreur, qu'un incident visible mis en veille consume à toute allure, et la patience de votre équipe, que chaque appel inutile à 3h du matin entame. Tout tourne sur votre appareil, rien n'est envoyé nulle part, et il n'y a aucun compte à créer.
Un jeu sur le jugement en incident, pas un manuel d'exploitation. La vraie astreinte a plus de quatre options et de bien pires horaires.
Questions fréquentes
Quelle est la règle exactement ?
Si un client ne le voit pas, mettez-le en veille jusqu'aux heures ouvrées. S'il le voit : revenez en arrière quand un déploiement date de moins de trente minutes, redémarrez quand un runbook à jour couvre le symptôme, et appelez le responsable quand ni l'un ni l'autre ne s'applique. L'ordre compte : défaire un changement récent va plus vite que le diagnostiquer, et c'est pourquoi un déploiement frais l'emporte sur le runbook.
Pourquoi la mise en veille est-elle bien plus punie que l'appel ?
Parce que les erreurs ne se valent pas. Dormir sur quelque chose que les clients voient consume du budget d'erreur pendant tout votre sommeil. Réveiller un collègue pour ce qu'un runbook couvre déjà coûte de la bonne volonté et rien d'autre : agaçant, réparable, et ce n'est pas une panne. Le barème est la leçon.
Les alertes sont-elles aléatoires ?
Le paquet est engendré à partir d'une graine, donc une garde est reproductible, mais le mélange est délibéré : aucune réponse n'est correcte plus d'un tiers du temps, si bien qu'aucune habitude ne bat la lecture. Les cartes subtiles — un vieux déploiement, un runbook périmé — arrivent plus tard dans la garde, et c'est là toute la courbe de difficulté.
Que signifie le chiffre de disponibilité ?
Un mois à 99,9 % autorise environ 43 minutes d'indisponibilité, et c'est votre budget d'erreur de départ. Chaque mauvaise décision en dépense une partie, et le pourcentage affiché est ce qu'indiquerait votre tableau de bord SLO en fin de mois. Trois décimales, parce que c'est là que vit un objectif à 99,9 %.