Modèles de Transmission de Garde On-Call

Modèles efficaces pour les transitions de quart de garde on-call, assurant la continuité, le transfert de contexte et une réponse fiable aux incidents entre les quarts.

Quand Utiliser Cette Compétence

• Transférer les responsabilités on-call
• Rédiger des résumés de transmission de quart
• Documenter les enquêtes en cours
• Établir des procédures de rotation on-call
• Améliorer la qualité des transmissions
• Intégrer de nouveaux ingénieurs on-call

Concepts Fondamentaux

1. Composants de la Transmission

2. Timing de la Transmission

Recommandé : 30 min de chevauchement entre les quarts

Sortant :
├── 15 min : Rédiger le document de transmission
└── 15 min : Appel de synchronisation avec le suivant

Entrant :
├── 15 min : Examiner le document de transmission
├── 15 min : Appel de synchronisation avec le sortant
└── 5 min : Vérifier la configuration des alertes

Templates

Template 1 : Document de Transmission de Quart

# Transmission On-Call : Platform Team

**Sortant** : @alice (2024-01-15 à 2024-01-22)
**Entrant** : @bob (2024-01-22 à 2024-01-29)
**Heure de Transmission** : 2024-01-22 09:00 UTC

---

## 🔴 Incidents Actifs

### Aucun actuellement actif

Aucun incident actif au moment de la transmission.

---

## 🟡 Enquêtes en Cours

### 1. Timeouts API Intermittents (ENG-1234)

**Statut** : En investigation
**Début** : 2024-01-20
**Impact** : ~0,1% des requêtes en timeout

**Contexte** :

- Les timeouts correspondent à la fenêtre de sauvegarde de la base de données (02:00-03:00 UTC)
- Soupçon : processus de sauvegarde causant une contention de verrous
- Ajout de logs supplémentaires dans PR #567 (déployé 01/21)

**Prochaines Étapes** :

- [ ] Examiner les nouveaux logs après la sauvegarde de ce soir
- [ ] Envisager de déplacer la fenêtre de sauvegarde si confirmé

**Ressources** :

- Dashboard : [API Latency](https://grafana/d/api-latency)
- Thread : #platform-eng (01/20, 14:32)

---

### 2. Croissance Mémoire dans Auth Service (ENG-1235)

**Statut** : Surveillance
**Début** : 2024-01-18
**Impact** : Aucun pour le moment (proactif)

**Contexte** :

- Utilisation mémoire croissante de ~5% par jour
- Aucune fuite mémoire trouvée en profiling
- Soupçon : pool de connexions ne libérant pas correctement

**Prochaines Étapes** :

- [ ] Examiner le heap dump du 01/21
- [ ] Envisager un redémarrage si usage > 80%

**Ressources** :

- Dashboard : [Auth Service Memory](https://grafana/d/auth-memory)
- Doc d'analyse : [Memory Investigation](https://docs/eng-1235)

---

## 🟢 Résolu Ce Quart

### Panne Payment Service (2024-01-19)

- **Durée** : 23 minutes
- **Cause Racine** : Épuisement des connexions à la base de données
- **Résolution** : Rollback v2.3.4, augmentation de la taille du pool
- **Postmortem** : [POSTMORTEM-89](https://docs/postmortem-89)
- **Tickets de suivi** : ENG-1230, ENG-1231

---

## 📋 Changements Récents

### Déploiements

| Service      | Version | Heure       | Notes                      |
| ------------ | ------- | ----------- | -------------------------- |
| api-gateway  | v3.2.1  | 01/21 14:00 | Correctif pour header parsing |
| user-service | v2.8.0  | 01/20 10:00 | Nouvelles fonctionnalités de profil |
| auth-service | v4.1.2  | 01/19 16:00 | Patch de sécurité           |

### Changements de Configuration

- 01/21 : Augmentation de la limite de débit API de 1000 à 1500 RPS
- 01/20 : Mise à jour du max du pool de connexions DB de 50 à 75

### Infrastructure

- 01/20 : Ajout de 2 nœuds au cluster Kubernetes
- 01/19 : Upgrade Redis de 6.2 à 7.0

---

## ⚠️ Problèmes Connus et Contournements

### 1. Chargement Lent du Dashboard

**Problème** : Dashboards Grafana lents les lundis matin
**Contournement** : Attendre 5 min après 08:00 UTC pour le warm-up du cache
**Ticket** : OPS-456 (P3)

### 2. Flaky Integration Test

**Problème** : `test_payment_flow` échoue de manière intermittente en CI
**Contournement** : Relancer le job échoué (habituellement réussi au retry)
**Ticket** : ENG-1200 (P2)

---

## 📅 Événements à Venir

| Date        | Événement              | Impact              | Contact       |
| ----------- | ---------------------- | ------------------- | ------------- |
| 01/23 02:00 | Maintenance base données | 5 min read-only     | @dba-team     |
| 01/24 14:00 | Release majeure v5.0   | Surveillance étroite | @release-team |
| 01/25       | Campagne marketing     | 2x trafic attendu   | @platform     |

---

## 📞 Rappels d'Escalade

| Type de Problème | Première Escalade        | Deuxième Escalade |
| --------------- | ----------------------- | ----------------- |
| Problèmes paiement | @payments-oncall        | @payments-manager |
| Problèmes auth  | @auth-oncall            | @security-team    |
| Problèmes DB    | @dba-team               | @infra-manager    |
| Inconnu/grave   | @engineering-manager    | @vp-engineering   |

---

## 🔧 Référence Rapide

### Commandes Courantes

```bash
# Vérifier la santé des services
kubectl get pods -A | grep -v Running

# Déploiements récents
kubectl get events --sort-by='.lastTimestamp' | tail -20

# Connexions à la base de données
psql -c "SELECT count(*) FROM pg_stat_activity;"

# Vider le cache (urgence uniquement)
redis-cli FLUSHDB
```

Liens Importants

• Runbooks
• Service Catalog
• Incident Slack
• PagerDuty

Checklist de Transmission

Ingénieur Sortant

• [x] Documenter les incidents actifs
• [x] Documenter les enquêtes en cours
• [x] Lister les changements récents
• [x] Noter les problèmes connus
• [x] Ajouter les événements à venir
• [x] Synchroniser avec l'ingénieur entrant

Ingénieur Entrant

• [ ] Lire ce document
• [ ] Rejoindre l'appel de synchronisation
• [ ] Vérifier que PagerDuty vous route les alertes
• [ ] Vérifier que les notifications Slack fonctionnent
• [ ] Vérifier que VPN/accès fonctionne
• [ ] Examiner les dashboards critiques

### Template 2 : Transmission Rapide (Asynchrone)

```markdown
# Transmission Rapide : @alice → @bob

## TL;DR
- Aucun incident actif
- 1 enquête en cours (timeouts API, voir ENG-1234)
- Release majeure demain (01/24) - soyez prêt pour des problèmes

## Liste de Surveillance
1. Latence API autour de 02:00-03:00 UTC (fenêtre de sauvegarde)
2. Mémoire auth service (redémarrer si > 80%)

## Récent
- Déploiement api-gateway v3.2.1 hier (stable)
- Augmentation des limites de débit à 1500 RPS

## À Venir
- 01/23 02:00 - Maintenance DB (5 min read-only)
- 01/24 14:00 - Release v5.0

## Questions ?
Je serai disponible sur Slack jusqu'à 17:00 aujourd'hui.
```

### Template 3 : Transmission d'Incident (Incident en Cours)

```markdown
# TRANSMISSION D'INCIDENT : Dégradation Payment Service

**Début Incident** : 2024-01-22 08:15 UTC
**Statut Actuel** : Mitigation en cours
**Sévérité** : SEV2

---

## État Actuel

- Taux d'erreur : 15% (baisse de 40%)
- Mitigation en cours : scaling des pods
- ETA résolution : ~30 min

## Ce Que Nous Savons

1. Cause racine : Pression mémoire sur les pods payment-service
2. Déclencheur : Pic de trafic inhabituel (3x normal)
3. Facteur contributif : Requête inefficace dans le checkout flow

## Ce Que Nous Avons Fait

- Scaling payment-service de 5 → 15 pods
- Activation du rate limiting sur l'endpoint checkout
- Désactivation des fonctionnalités non critiques

## Ce Qui Doit Arriver

1. Surveiller le taux d'erreur - devrait atteindre <1% en ~15 min
2. Si pas d'amélioration, escalader vers @payments-manager
3. Une fois stable, commencer l'investigation de cause racine

## Personnes Clés

- Incident Commander : @alice (transmission)
- Comms Lead : @charlie
- Technical Lead : @bob (entrant)

## Communication

- Status page : Mise à jour à 08:45
- Support client : Notifié
- Équipe exec : Au courant

## Troubleshooting

**L'ingénieur entrant manque un problème critique car le document de transmission était incomplet.**
Utiliser le checklist sortant comme gate : ne pas marquer la transmission comme complète jusqu'à ce que chaque section ait au moins une entrée (ou un explicite « aucun »). Faire de la transmission incomplète un action item de postmortem sans culpabilité.

**Un appel de synchronisation de 30 minutes n'est pas possible à cause de décalages horaires.**
Basculer sur le template de transmission rapide asynchrone (Template 2). Compléter avec une courte vidéo Loom ou un message vocal parcourant la liste de surveillance. S'assurer que l'ingénieur entrant a une méthode de contact direct pour les questions de suivi.

**L'ingénieur entrant hérite d'un incident en cours et se sent immédiatement débordé.**
Utiliser le template de transmission d'incident (Template 3) spécifiquement. L'ingénieur sortant doit rester disponible sur Slack pendant 15 minutes après la transmission, même hors-call, pour répondre aux questions de clarification.

**Les documents de transmission on-call sont formatés de manière incohérente entre les équipes.**
Adopter l'organisation de template de transmission de quart à l'échelle de l'organisation et stocker les transmissions complétées dans un emplacement partagé (wiki, Notion, Confluence). Lier chaque transmission depuis l'entrée du planning on-call dans PagerDuty.

**L'ingénieur entrant ne peut pas vérifier que son alerting fonctionne avant que l'ingénieur sortant se déconnecte.**
Ajouter une étape standard : l'ingénieur sortant déclenche une alerte test et confirme que l'ingénieur entrant la reçoit dans PagerDuty et Slack avant de terminer la fenêtre de chevauchement.

## Compétences Associées

- [incident-classification](../../skills/incident-classification/SKILL.md) — Classifier et prioriser les incidents qui doivent être inclus dans le document de transmission
- [postmortem-facilitation](../../skills/postmortem-facilitation/SKILL.md) — Transformer les incidents résolus du quart en postmortems structurés
```