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.