Operazioni e Gestione → Trasferire il contesto tra i turni

Trasferimento del contesto tra i cambi

1) Perché è necessario

Il turno arriva. Il sistema sta correndo. La qualità dell'hendover influisce direttamente su MTTR, rumore degli alert e stabilità dei rilasci. Un buon hendover è un punto di riferimento rapido, rischi chiari e i prossimi passi comprensibili.

• Escludi la perdita di contesto per incidenti, comunicati e provider.
• Ridurre il tempo di inserimento del nuovo turno a minuti, non ore.
• Stabilizza i percorsi critici SLO (deposito, puntata, avvio del gioco, output).
• Rendere le comunicazioni prevedibili e verificabili.

2) Principi del buon hendover

1. Modulo standardizzato (un modello, una terminologia).
2. Manufatti unici (riferimenti agli stessi dashboard/ticket/runbook 'e).
3. Tymbox (breve «briefing» + «longrid» per iscritto).
4. Actionable: alla fine è un elenco esplicito di operazioni «chi/cosa/quando».
5. Orientamento SLO: stato SLO/Errore, non «Loga eventi».
6. Tracciabilità: qualsiasi fatto è confermato da un artefatto.

3) Ruoli e responsabilità

Lead di turno - Prepara un pacchetto hendover, organizza un briefing.
Lead turno (ricevente) - Registra domande/rischi, conferma l'accettazione.
Gestore dell'incidente: aggiorna la timeline/canale dell'incidente, controlla gli update SLA.
Proprietari di domini (Payments/Bets/Games/KYC): le sezioni forniscono «stato e rischio».
SRE/Observability - Supportano gli artefatti (dashboard, annotazioni di rilascio, alert).

4) Timing e canali

T-30 minuti prima del cambio: il turno in uscita congela lo stato, aggiorna il modello.
T-10 min: briefing rapido (15-20 minuti al massimo) nel canale vocale/video.
T + 0: pubblicazione di un pacchetto di hendover nel canale condiviso «# ops-handover».
T + 15 min - Il turno ricevente conferma il ricevimento e chiarisce le domande aperte.
Tutti i punti rossi sono direttamente nel canale del comando corrispondente.

5) Struttura del pacchetto hendover (modello)

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 hendover

1. Il cambio in uscita aggiorna le annotazioni di rilascio e i dashboard (SLO, provider, code).
2. Controlla gli alert rossi delle ultime ore, registra lo stato/causa.
3. Aggiorna la sezione Rischi e sorveglianza (tendenze/sospetti, non fatti).
4. Riempie Action items con deadline e proprietari.
5. Ha un briefing di 10-15 minuti.
6. Il turno ricevente fa domande; Se necessario, un'escalation immediata per i proprietari.
7. Conferma ricevimento: «ricevuto, domande/no», elenco dei primi passi.

7) Metriche di qualità hendover (KPI)

Handoff Quality Score (HQS) - Compilare il pacchetto (0-100) su un foglio di assegno.
Handoff Time - Durata del briefing (corridoio di destinazione 10-20 min).
Acknowledgement SLA - Conferma ricevimento per 15 minuti.
Missing Text Rate è la percentuale di incidenti con «perdita di contesto» dopo il cambio.
Post-Handoff Incent Spike - aumento degli alert/incidenti nei primi 60 minuti.
Action Items SLA è il numero di attività chiuse dopo il turno.

8) Scontrino di qualità del pacchetto (valutazione HQS)

• Completato con SLO/metriche chiave in 4 ore con trend.
• Tutti gli alert rossi sono elencati con motivi/riferimenti.
• Incidenti: numero, stato, impatto, successivo update (tempo).
• Provider: quote/errori/feelover, modifiche recenti.
• Release/fici: stadio, rischi, gate/canarino.
• Action items: proprietario, scadenza, criterio di preparazione.
• Riferimenti: dashboard, canali, runbook 'e, matrice di escalation.
• Contatti on-call e canali di comunicazione ridondanti.

9) Dashboard «per hendover» (minimo)

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.
Incidents Board: incidenti aperti, update ETA, influenza.
Release & Feature: canarini, confronto prima/dopo, gate automatiche.
Providers Panel: quote, timeout, cost/1k calls, commutazioni.
Dipendency Map - Costole problematiche (latency/errors/retries).

10) Alert sulla qualità degli hendover (idee)

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) Comunicazioni e formato degli 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.

• Senza chat private per punti critici, solo canali comuni.
• Ogni zona rossa è immediata con i proprietari.
• Tutte le soluzioni/compromessi sono scritte, con riferimento ai dati.

12) Caratteristiche dominio (iGaming)

Payments - La priorità è la conversione del deposito e il tempo di autorizzazione, le rotte del feelover PSP, i limiti dei provider.
Bets: aggiornamenti dei coefficienti/cache, carico di streaming/coda, ritardi dei calcoli.
Games/Live: trasmettitori (jackpot/striam), limiti di siti web, degrado UI.
KYC/AML: coda di controlli, provider SLA, sensibilità ai picchi.

13) Anti-pattern

Libera «forma arbitraria» dell'hendover (ognuno scrive come vuole).
Non c'è deadline per confermare il ricevimento.
Pacchetto senza Action items e proprietari.
Hendover si sta trasformando in «leggere i cavi» invece di SLO/rischi.
Le soluzioni segrete nelle chat private sono la mancanza di tracciabilità.
Il modello non contiene riferimenti agli artefatti.

14) Integrazioni e manufatti

Annotazioni di rilascio nei grafici, collegamenti automatici nell'hendover.
Link unfurling - Inserisce riferimenti a dashboard/ticket con la precedenza delle metriche chiave.
Riferimenti Runbook - Ogni zona rossa con riferimento diretto a un runbook specifico.
Matrice di escalation: il modello contiene un unico documento aggiornato.

15) Regole di conservazione e verifica

Hendover - Memorizzati centralmente (Gios, Data/Ora, Autori).
Controllo settimanale dell'HQS e analisi selettiva dei «cattivi» hendover.
Revisione del modello - trimestrale o post mortem.

16) Partenza rapida (30 giorni)

Settimana 1: approva modello, ruoli e timing Eseguire un pilota su una linea (ad esempio Payments).
Settimana 2: accendere i dashboard per l'hendover, gli alert sono pronti.
Settimana 3: immettere il controllo HQS e il controllo del 10% degli hendover.
Settimana 4: estendere a Bets/Games/KYC, eseguire una retrospettiva, aggiornare la SOP.

17) Esempio di «carta di rischio» per il pacchetto

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

E se il briefing durasse?
A: Timbox rigoroso e la regola «dopo il briefing». Il pacchetto deve contenere tutto per una conoscenza asincrona.

Come si combatte contro «versioni diverse della verità»?
A: Unificare gli artefatti: un unico dashboard, annotazioni di rilascio, SSOT per SLA; Solo con loro.

È necessario registrare un briefing?
Sì, per le valigette contese e per l'apprendimento. Ma il record non sostituisce il pacchetto scritto standard.