Opérations et Gestion → Transfert du contexte entre les postes

Transfert du contexte entre les postes

1) Pourquoi est-ce nécessaire

Le changement arrive - le système est déjà « en cours ». La qualité du hendover affecte directement MTTR, le bruit des alertes et la stabilité des sorties. Un bon hendover est un point de repère rapide, des risques clairs et des prochaines étapes compréhensibles.

• Éliminer la perte de contexte par incident, version et fournisseur.
• Réduire le « temps d'entrée » de la nouvelle équipe à des minutes, pas des heures.
• Stabiliser le SLO des chemins critiques (dépôt, pari, lancement du jeu, retrait).
• Rendre les communications prévisibles et vérifiables.

2) Les principes d'un bon hendover

1. Formulaire normalisé (un modèle, une terminologie).
2. Artefacts uniques (références aux mêmes dashboards/tickets/runbook 'et).
3. Tymbox (bref « briefing » + « longrid » par écrit).
4. Activable : à la fin, une liste explicite des tâches « qui/quoi/quand ».
5. Orientation SLO : statut par SLO/erreurs, pas « journal des événements ».
6. Traçabilité : tout fait est confirmé par un artefact.

3) Rôles et responsabilités

Lead quart (sortant) : prépare un paquet de hendover, donne une réunion d'information.
Lead quart (hôte) : enregistre les questions/risques, confirme l'acceptation.
Responsable de l'incident : met à jour la ligne temporelle/le canal de l'incident, surveille les updates SLA.
Les propriétaires de domaines (Payments/Bets/Games/KYC) : par leurs sections donnent « statut et risque ».
SRE/Observability : supporte les artefacts (dashboards, annotations de sortie, alertes).

4) Temporisation et canaux

T-30 min avant le changement : Le changement sortant gèle le statut, met à jour le modèle.
T-10 min : briefing rapide (15-20 minutes maximum) dans la chaîne vocale/vidéo.
T + 0 : publication du paquet hendover sur le canal commun « # ops-handover ».
T + 15 min : l'équipe d'accueil confirme la réception et clarifie les questions ouvertes.
Escalade : tous les points « rouges » à la fois dans le canal de l'équipe correspondante.

5) Structure du paquet hendover (modèle)

Handoff - <date, time, TZ>
Shift: <outgoing> → <receiving>
Overall SLO status (last 4h):
- API p95/p99: <values/trends>
- Error rate: <values/trends>
- Queue lag/DB connections/Cache: <brief>
Critical incidents:
- <INC-123>: status, impact, next update ETA, links (ticket, channel, postmortem draft)
Providers (PSP/KYC/studios):
- PSP-X: quotas/errors/fake <links>
- KYC-A: Webhook delays <links>
Releases/Features:
- In progress: <service>, stage (canary X%), gate/metrics, risk
- Scheduled: windows/locks/dependencies
Risks and observations:
- <briefly, with links and graphs>
Action items (before <time>):
- [Owner] <task>, readiness criterion
Useful links:
- Dashboard Overview, dependency map, escalation matrix, runbook 'and
On-call contacts:
- Domains/Names/Channels

6) Mini-SOP hendovera

1. Le poste sortant met à jour les annotations de sortie et de dashboard (SLO, fournisseurs, files d'attente).
2. Vérifie les alertes rouges au cours des 4 dernières heures, enregistre le statut/la cause.
3. Actualise la section « Risques et observations » (tendances/soupçons, non faits).
4. Remplit les items d'action avec les deadlines et les propriétaires.
5. Donne un briefing de 10 à 15 minutes, strictement selon le modèle.
6. L'hôte pose des questions ; si nécessaire, une escalade instantanée pour les propriétaires.
7. Confirmation d'admission : « reçu, questions/non », liste des premières étapes.

7) Métriques de qualité hendover (KPI)

Handoff Quality Score (HQS) - Scoring du paquet (0-100) par chèque.
Handoff Time - Durée de l'exposé (corridor cible 10-20 min).
Acknowledgement SLA - Confirmation de réception ≤ 15 minutes.
Missing Context Rate est la proportion d'incidents de « perte de contexte » après un changement.
Post-Handoff Incident Spike - augmentation des alertes/incidents dans les 60 premières minutes.
Action Items SLA est la proportion de tâches fermées à temps après le changement.

8) Chèque qualité du paquet (évaluation HQS)

• Plein SLO/métriques clés en 4 heures avec tendances.
• Toutes les alertes « rouges » sont énumérées avec des motifs/références.
• Incidents : nombre, statut, influence, prochain update (heure).
• Fournisseurs : quotas/erreurs/faussaires, modifications récentes.
• Communiqués/fiches : stade, risques, gates/canaris.
• Éléments d'action : propriétaire, délai, critère de disponibilité.
• Références : dashboards, canaux, runbook 'et, matrice d'escalade.
• Contacts sur appel et voies de communication redondantes.

9) Dashboards « pour hendover » (minimum)

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.
Commission des incidents : incidents ouverts, ETA des mises à jour, impact.
Release & Feature : canaris, comparaison « avant/après », auto-gays.
Providers Panel : quotas, temporisations, cost/1k calls, commutation.
Dependency Map : côtes problématiques (latency/errors/retries).

10) Alert sur la qualité des hendovers (idées)

ALERT HandoffNotPublished
IF handoff_published == 0 AND within(10m, shift_change) == true
LABELS {severity="warning", team="ops"}

ALERT HandoffAckSLA
IF handoff_ack_minutes > 15
LABELS {severity="warning", team="ops"}

ALERT MissingActionOwners
IF count_over_time(handoff_action_items{owner=""}[1h]) > 0
LABELS {severity="warning", team="ops"}

ALERT PostHandoffIncidentSpike
IF incidents_rate_60m_after_shift > baseline_14d 1. 5
LABELS {severity="info", team="ops"}

11) Communications et format d'update

[HH: MM] Handoff published. SLO OK/Degraded. Incidents: INC-123 (ETA 18:30), releases: bets-api canary 10%. Risks: PSP-X 85% quota. Action items: @ squad-payments until 7pm to check out the feilover.

• Sans chat privé pour les points critiques - seulement les canaux communs.
• Toute zone « rouge » est un problème immédiat avec les propriétaires.
• Toutes les décisions/compromis sont par écrit, avec référence aux données.

12) Caractéristiques des domaines (iGaming)

Paiements : priorité : conversion du dépôt et du temps d'autorisation, itinéraires de faussaire PSP, limites par fournisseur.
Bets : mises à jour des coefficients/caches, charge de streaming/file d'attente, retard de calcul.
Jeux/Live : events de diffusion (jackpots/strims), limites des sites Web, dégradation de l'IU.
KYC/AML : file d'attente de vérification, SLA des fournisseurs, sensibilité aux pics.

13) Anti-modèles

La « forme arbitraire » libre de Hendover (tout le monde écrit comme il veut).
Il n'y a pas de date limite pour confirmer la réception.
Pack sans items d'action et les propriétaires.
Hendover se transforme en « lecture des loges » au lieu de SLO/risques.
Les solutions secrètes dans les chats privés sont l'absence de traçabilité.
Le modèle ne contient aucune référence aux artefacts. Il n'y a rien à vérifier.

14) Intégrations et artefacts

Annotations de sortie sur les graphiques, liens automatiques vers hendover.
Link unfurling : insère des liens vers des dashboards/tickets avec un aperçu des mesures clés.
Références de runbook : chaque zone « rouge » avec une référence directe à un runbook particulier.
Matrice d'escalade : dans le modèle, un seul document à jour.

15) Politique de conservation et d'audit

Hendovers - stockés centralement (geos, date/heure, auteurs).
Vérification hebdomadaire du HQS et analyse sélective des « mauvais » hendovers.
Révision du modèle - trimestrielle ou postmortem.

16) Démarrage rapide (30 jours)

Semaine 1 : approuver le modèle, les rôles et les délais ; lancer le pilote sur la même ligne (par exemple, Payments).
Semaine 2 : inclure les dashboards « for hendover », alertes HandoffNotPublished/AckSLA.
Semaine 3 : Entrez le scoop HQS et vérifiez 10 % des hendovers.
Semaine 4 : agrandir sur Bets/Games/KYC, faire une rétrospective, mettre à jour SOP.

17) Exemple de « carte de risque » pour un paquet

Risk: PSP-X hits 90% quota in prime time
Impact: rise in deposit refusals, SLO payments at risk
Signals: outbound_error_rate, quota_usage_ratio
Mitigation: raise PSP-Y up to 20% of traffic in advance, enable token cache
Owner/ETA: integrations@oncall / до 18:00

18) FAQ

Q : Et si le briefing était retardé ?
R : Le tymbox strict et la règle « dans le trade après l'exposé ». Il doit y avoir tout dans le paquet pour une lecture asynchrone.

Q : Comment faire face aux « différentes versions de la vérité » ?
R : Unifier les artefacts : dashboards uniques, annotations de sortie, SSOT pour SLA ; Lier seulement sur eux.

Q : Dois-je enregistrer mon exposé ?
R : Oui, pour les cas controversés et la formation. Mais l'enregistrement ne remplace pas le paquet écrit normalisé.