7 min lecture • Guide 756 of 877
Gestion On-Call avec GitScrum
Le on-call ne devrait pas épuiser votre équipe. GitScrum aide à gérer les tâches on-call, suivre les incidents et assurer une rotation équitable des responsabilités.
Fondamentaux On-Call
Pourquoi le On-Call Existe
OBJECTIF ET BUTS ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OBJECTIF: │
│ S'assurer que quelqu'un est toujours disponible pour │
│ répondre aux problèmes production qui affectent les │
│ utilisateurs. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ON-CALL SAIN: │
│ │
│ ✅ Rotation équitable entre l'équipe │
│ ✅ Attentes claires et runbooks │
│ ✅ Compensation appropriée │
│ ✅ Faible taux de fausses alertes │
│ ✅ Charge de travail durable │
│ ✅ Apprentissage des incidents │
│ │
│ ON-CALL NON SAIN: │
│ │
│ ❌ Mêmes personnes toujours on-call │
│ ❌ Fausses alertes constantes (fatigue d'alerte) │
│ ❌ Pas de documentation ou runbooks │
│ ❌ Attendu de tout réparer seul │
│ ❌ Pas de compensation temps │
│ ❌ Burnout et attrition │
│ │
│ PRINCIPE ON-CALL: │
│ Si vous le construisez, vous l'opérez │
│ L'équipe possède ses services de bout en bout │
│ Crée responsabilisation et meilleur design │
└─────────────────────────────────────────────────────────────┘
Setup Rotation
Construire le Planning
DESIGN ROTATION ON-CALL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OPTIONS DE ROTATION: │
│ │
│ ROTATION HEBDOMADAIRE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sem 1: @alex (primary) / @maria (secondary) ││
│ │ Sem 2: @maria (primary) / @jordan (secondary) ││
│ │ Sem 3: @jordan (primary) / @chen (secondary) ││
│ │ Sem 4: @chen (primary) / @alex (secondary) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Meilleur pour: Grandes équipes, faible volume pages │
│ │
│ FOLLOW-THE-SUN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 00:00-08:00 UTC: Équipe APAC ││
│ │ 08:00-16:00 UTC: Équipe EMEA ││
│ │ 16:00-00:00 UTC: Équipe Amériques ││
│ └─────────────────────────────────────────────────────────┘│
│ Meilleur pour: Équipes globales, pas de shifts nuit │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RÈGLES D'ÉQUITÉ: │
│ │
│ • Tourner équitablement (tracker dans spreadsheet) │
│ • Pas de shifts consécutifs sans consentement │
│ • On-call férié/weekend = considération extra │
│ • Permettre échanges de shifts │
│ • Nouveaux membres shadow avant solo │
│ • Compenser de façon appropriée │
└─────────────────────────────────────────────────────────────┘
Chemin d'Escalade
STRUCTURE D'ESCALADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NIVEAU 1: On-Call Primaire │
│ ↓ (si pas de réponse en 15 min) │
│ │
│ NIVEAU 2: On-Call Secondaire │
│ ↓ (si pas de réponse en 15 min) │
│ │
│ NIVEAU 3: Team Lead / Manager │
│ ↓ (si SEV 1 ou impact business) │
│ │
│ NIVEAU 4: VP Engineering / Executive │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RÈGLES D'ESCALADE: │
│ │
│ AUTO-ESCALADE QUAND: │
│ • Pas d'acquittement en 15 minutes │
│ • Durée incident > 30 minutes │
│ • SEV 1 (toujours notifier leadership) │
│ • Problème rapporté par client │
│ │
│ PRIMAIRE DEVRAIT ESCALADER QUAND: │
│ • Hors de son expertise │
│ • Besoin de mains additionnelles │
│ • Impact grandissant │
│ • Incapable de résoudre seul │
│ │
│ NE PAS: │
│ • Hésiter à escalader │
│ • Essayer d'être un héros │
│ • Attendre trop longtemps │
└─────────────────────────────────────────────────────────────┘
Planification Sprint avec On-Call
Ajustement Capacité
CAPACITÉ ON-CALL DANS GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONSIDÉRATION PLANIFICATION SPRINT: │
│ │
│ CAPACITÉ NORMALE: 28 points │
│ │
│ AJUSTEMENTS ON-CALL: │
│ │
│ Semaine complète on-call: │
│ • -25% à -50% capacité selon volume pages │
│ • @jordan: 28 pts → 14-21 pts │
│ │
│ Demi-semaine on-call: │
│ • -10% à -25% capacité │
│ • @alex: 28 pts → 21-25 pts │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VUE SPRINT: │
│ │
│ @alex [██████████████████████░░░] 24 pts (4 pts on-call)│
│ @maria [████████████████████████░] 28 pts │
│ @jordan [██████████████░░░░░░░░░░░] 18 pts (10 pts on-call)│
│ @chen [████████████████████████░] 28 pts │
│ │
│ Total: 98 pts (vs 112 standard) │
│ │
│ TÂCHES ON-CALL: │
│ • Colonne ou label séparé │
│ • Ne comptent pas contre vélocité │
│ • Suivre pour visibilité charge │
└─────────────────────────────────────────────────────────────┘
Passation On-Call
PROCESSUS PASSATION ROTATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AVANT FIN DU SHIFT: │
│ │
│ ON-CALL SORTANT FOURNIT: │
│ │
│ 1. PROBLÈMES ACTIFS │
│ • Incidents ouverts │
│ • Problèmes en cours │
│ • Choses à surveiller │
│ │
│ 2. CHANGEMENTS RÉCENTS │
│ • Déploiements cette semaine │
│ • Changements config │
│ • Nouvelles features lancées │
│ │
│ 3. RISQUES À VENIR │
│ • Maintenance planifiée │
│ • Gros événements client │
│ • Déploiements risqués connus │
│ │
│ 4. APPRENTISSAGES │
│ • Nouvelles entrées runbook │
│ • Pièges découverts │
│ • Tips utiles │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RÉUNION PASSATION (15 min): │
│ │
│ • Appel sync ou passation écrite │
│ • Documenter dans Slack/wiki │
│ • Confirmer que entrant a les accès │
│ • Transférer pager/routage alertes │
│ • Entrant confirme prêt │
└─────────────────────────────────────────────────────────────┘
Durabilité
Prévenir le Burnout
PRATIQUES ON-CALL DURABLES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRIQUES À SURVEILLER: │
│ │
│ Pages par shift: │
│ Cible: < 5 par semaine │
│ Actuel: 8 ⚠️ (investiguer alertes bruyantes) │
│ │
│ Pages hors heures: │
│ Cible: < 2 par semaine │
│ Actuel: 4 ⚠️ (prioriser automation) │
│ │
│ Taux faux positifs: │
│ Cible: < 10% │
│ Actuel: 25% ❌ (corriger alerting) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RÉDUIRE CHARGE ON-CALL: │
│ │
│ CORRIGER ALERTES BRUYANTES: │
│ • Revoir toutes alertes trimestriellement │
│ • Supprimer ou corriger alertes faible valeur │
│ • Ajuster seuils │
│ • Ajouter automation pour fixes courants │
│ │
│ AMÉLIORER FIABILITÉ: │
│ • Corriger causes racines, pas symptômes │
│ • Investir dans infrastructure │
│ • Meilleurs tests et canaries │
│ • Chaos engineering │
│ │
│ SUPPORTER ON-CALL: │
│ • Compenser équitablement │
│ • Permettre récupération après shifts lourds │
│ • Célébrer semaines calmes │
│ • Leadership fait on-call aussi │
└─────────────────────────────────────────────────────────────┘