GH GambleHub

Changement de service et transfert de tâches

1) Pourquoi formaliser le changement de garde

Le changement de garde est un moment critique de risque : le contexte est perdu, le temps de réaction augmente, les actions sont dupliquées. Le processus formalisé réduit le MTTA/MTR, élimine les « résidus oubliés » et assure la conformité (qui et quand a accepté la responsabilité).

2) Rôles et modèle de couverture

Primary on-call (P1) - première réponse, triage, coordination avant l'arrivée d'IC.
Second on-call (P2) - backap, se connecte en cas de surcharge/escalade.
Duty Manager/IC-of-the-day est le leader de l'incident pour SEV-1 +.
Follow-the-sun (multi-temps) ou Follow-the-moon (couverture nocturne dans d'autres régions).
Fenêtres temporelles : évitez les sorties/travaux risqués ± 30 min du poste.

3) Horaires de rotation (exemples)

24/7, 8 heures : matin/jour/nuit, 3 brigades, P1 + P2.
24/7, 12 heures de travail : moins de changements, plus de risque de fatigue - il faut des « fenêtres de compensation ».
5 × 8 (jours ouvrables) + Weekend Pool : couverture de jour primaire par l'équipe du produit, week-end - plateforme/SRE.
Hybride : les jours de « pendant le bureau », les nuits/week-ends - Follow-the-sun.

Règles d'équité : rotation selon le calendrier, comptabilisation des vacances/congés, maximum N quarts de nuit par période.

4) Carte de poste (Shift Handover Card)

Norme minimale de contenu :
  • Quand et qui : 'Date/heure (UTC et local)', transmet → reçoit ; P1/P2 contacts.
  • État des systèmes : résumé SLO/SLA, alertes actives, dégradations connues.
  • Incidents ouverts : ID, SEV, étape actuelle, qui est le propriétaire, prochaine action/ETA.
  • Risques sur la fenêtre de changement : travaux planifiés, sorties, migrations, états limites (quotas des fournisseurs).
  • Tiquets/tâches critiques : priorité, bloqueurs, échéances.
  • Communications impliquées : postes actifs sur la page de statut/apdates clients.
  • Solutions connues : drapeaux de dégradation de fich inclus, limites de temps.
  • Domenica : fournisseurs de paiement/KYC/CDN - leurs statuts et leur routage.
  • Housekeeping : qui est sur l'appel demain, fenêtres d'inaccessibilité des gens (rassemblements/vols).

5) Chèque-feuille « je passe sur le poste » (côté donneur)

  • A mis à jour la carte de poste (tous les champs) et a fixé le lien dans le canal '# oncall-handover'.
  • Traduit la « connaissance orale » en tiquets/notes ; pas de tâches « dans la tête ».
  • Tous les incidents ont : SEV, propriétaire, prochaine étape, heure du prochain update.
  • La page de statut et l'update client correspondent à l'état réel.
  • Désactivé les alertes bruyantes/fausses (selon la procédure) ou noté dans la carte.
  • A vérifié les quotas/limites des fournisseurs externes pour la fenêtre du poste suivant.
  • Synchronisé par la voix/vidéo pendant 5 à 10 minutes (si le SEV-1 + est actif).
  • A enregistré le fait de la transmission (bot/tiquet), a indiqué le récepteur.

6) Checklist « J'accepte le poste » (hôte)

  • J'ai lu la carte, j'ai précisé les questions ouvertes.
  • J'ai vérifié les dashboards SLO/alerta au cours des 2 à 4 dernières heures.
  • Confirmé le rôle du P1/P2 dans le bot (assign) et le son/les canaux du pager.
  • A pris possession des incidents actifs et a mis à jour les minuteries de l'update.
  • J'ai vérifié les travaux/sorties planifiés, annulé les opérations risquées pendant les 30 premières minutes.
  • J'ai fait un "message d'écho" à la chaîne : "Le changement a été accepté, les incidents actifs :..., SL. l'update dans "....

7) Normes de communication

Каналы: `#oncall`, `#incident-warroom-<ID>`, `#statuspage`.
Intervalles d'apdates : SEV-0 : 15 min, SEV-1 : 30 min, SEV-2 + 60 min.
Format d'update : Impact - Diagnostic - Actions - Prochain update (temps).
Escalade : pas de progrès en N minutes → connecter TL/Platform/DB/Sec par matrice.
Clarté de la propriété : chaque action a un artiste et un ETA.

8) Transfert de tâches (non-incidents)

Critères de transfert : la tâche bloque le SLO/sortie/conformité ou expire.
Décoration : ticket avec « définition de l'étape suivante » et le résultat attendu, tous les artefacts (logs/instantanés/graphiques) sont joints.
Priorité : Kanban- swimlane « On-call Handover ».
Délais : les émissions ont une date due ; les retards sont aggravés par le propriétaire du service.

9) Automatisation et intégration

Calendrier des rotations : synchronisation avec le pager ; le bot publie « qui est le garde » au début du quart.
ChatOps : '/handover start ', collecte automatique de la carte à partir des sources (états SLO, incidents ouverts, sorties).
Tiketing : attribution automatique du propriétaire par P1/P2 ; les étiquettes « handover ».
Status Page : Bridge to Public Updates avec des modèles.
Audit : journal de transmission (qui/quand a accepté), communication avec SEV et rapports.

10) Gestion de la fatigue et durabilité (Gestion de la Fatigue)

Limites : Maximum X pages/heure et Y consécutif la nuit - passage à P2/escalade.
Quiet hours pour les alerts non critiques (tickets au lieu de paging).
Après-heures de compensation et après-incident.
Formation et shadowing pour les nouveaux ingénieurs en ligne.
Rétrospectives de postes bruyants → tuning d'alerts et de playbooks.

11) Métriques de qualité des postes et des vitesses

Handover Defect Rate : proportion d'incidents de perte de contexte lors d'un changement.
MTTA autour du changement : médiane/pics à ± 30 min du changement.
Missed/late updates : updates expirés par SEV.
Alert Hygiene :% de fausses pages ; alerte sans runbook/propriétaire.
Load per shift : Page/heure, durée moyenne du travail actif.
Satisfaction : Équipe NPS (sondage on-call), fatigue sur l'échelle.

12) Communication avec la gestion des incidents et RCA

Les incidents actifs ne sont pas fermés au moment du changement ; la responsabilité est clairement transférée et consignée.
Dans la RCA, la section « Impact du changement » est obligatoire : y a-t-il eu une dérive du contexte, un retard de l'update, une prise d'action.
CAPA : amélioration de la carte, chèques-feuilles, automatisation, formation.

13) Sécurité, conformité et confidentialité

Les PII/secrets sont interdits dans le texte libre des cartes ; liens vers des entrepôts sécurisés.
Les accès sont temporaires : les droits d'appel sont émis sur la fenêtre de changement (JIT/JEA), la rotation des clés.
Piste d'audit : logue immuable qui a lu/modifié la carte et la page de statut.
Réglementation : les délais de notification des clients sont surveillés dans la carte de poste.

14) Anti-modèles

« Je le transmettrai oralement » sans carte/tickets.
Sortie exactement au moment du changement sans IC et backup.
Pager est dans un avion/métro sans P2.
Carte comme « drap » sans next step/ETA.
Triage sur les chats personnels - l'information est perdue, l'audit est impossible.
Il n'y a pas de fixation du transfert - le débat « qui répondait ».

15) Modèles

Modèle de carte de poste (compressé)


Shift: 2025-11-01 18: 00-02: 00 UTC (local: Europe/Kyiv 20: 00-04: 00)
P1: @duty-alex      P2: @duty-olga      IC: @ic-of-day
SLO Summary: API ok, Payments p95↑ by 12% (observation)
Active Incidents:
- INC-3421 (SEV-2): KYC's success is falling in the TR region. Owner: @ p1. Trail. step: switch 20% of traffic to provider B, update at 20:30 UTC.
Risks/jobs: 22:00 UTC - index migration to ClickHouse (read-only), owner @ data-ivan.
Providers: PSP-A green, KYC-A partially degrades TR.
Status page: post from 17:50 UTC; next update 20:30 UTC.
Next steps P1: 1) Check KYC switching effect; 2) Prepare canary 5% for v2 payments. 14.

Modèle de message echo à la réception


[Took over shift] 18:02 UTC. Active: INC-3421 (SEV-2). Trail. update 18:30 UTC.
Checked alerts in 2h - no new P1s. Status page availability approx.

16) Intégrer dans la pratique quotidienne

Daily-rituel de changement : 5-10 minutes de synchronisation vocale en cas d'incidents actifs.
Vérification hebdomadaire des cartes : nous vérifions sélectivement l'exhaustivité/la pertinence.
Jeux-jours : simulation de quarts avec de nombreux événements parallèles.
Dossier : modèles de cartes/feuilles de chèque dans le référentiel, je revois comme un code.

17) Résultat

Les changements et les transferts bien organisés sont le « lubrifiant » de toute la machine d'exploitation. La carte de travail, les brèves synchronisations, les chèques stricts, l'automatisation et le souci de stabilité de l'équipe transforment les moments à risque en une routine sans perte de qualité : le contexte est maintenu, le temps de réaction est stable et les utilisateurs ne remarquent pas les changements de garde du tout.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Telegram
@Gamble_GC
Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.