Operações e Gerenciamento: Transferência de contexto entre turnos

Transferência de contexto entre os turnos

1) Por que é necessário

O turno está a chegar. O sistema já está a correr. A qualidade do hendover afeta diretamente MTTR, ruídos de alertas e estabilidade de lançamentos. Um bom hendover é uma referência rápida, riscos claros e os próximos passos compreensíveis.

• Excluir a perda de contexto de incidentes, comunicados e provedores.
• Reduzir o tempo de entrada do novo turno para minutos, em vez de horas.
• Estabilizar caminhos críticos SLO (depósito, aposta, lançamento de jogo, conclusão).
• Tornar as comunicações previsíveis e verificáveis.

2) Princípios do bom hendover

1. Formulário padrão (um modelo, uma terminologia).
2. Artefatos unificados (referências aos mesmos dashboards/tíquetes/runbook 'i).
3. Tymbox (breve «briefing» + «longrid» por escrito).
4. Actionable: ao final, uma lista clara de tarefas «quem/o/quando».
5. Orientação SLO: Status de SLO/Erro, em vez de «logos de evento».
6. Rastreabilidade: Qualquer facto é confirmado pelo artefacto.

3) Papéis e responsabilidades

Lead de turno: prepara um pacote de hendover, faz um briefing.
Lead turno (receptor): registra perguntas/riscos, confirma a aceitação.
Gerente de incidentes, atualiza o tempo/canal do incidente, vigia o SLA dos updates.
Donos de domínios (Payments/Bets/Games/KYC): As suas secções oferecem status e risco.
SRE/Observabilidade: suportam artefatos (dashboards, anotações de lançamentos, alertas).

4) Timing e canais

T-30 min antes do turno: o turno de saída congela o status, atualiza o modelo.
T-10 min: reunião rápida (15-20 minutos no máximo) no canal de voz/vídeo.
T + 0: publicação de um pacote de hendover no canal compartilhado «# ops-handover».
T + 15 min: O turno de recepção confirma a recepção e especifica as perguntas abertas.
Escalações: Todos os itens vermelhos no canal do comando apropriado.

5) Estrutura do pacote hendover (modelo)

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. O turno de saída atualiza as anotações de lançamento e dashboard (SLO, provedores, filas).
2. A verificar as alertas vermelhas nas últimas 4 horas, o status/causa.
3. Atualiza a seção «Riscos e Observações» (tendências/suspeitas, não factos).
4. Preenche o Action items com deadline e proprietários.
5. Faz um briefing de 10 a 15 minutos.
6. O turno receptor faz perguntas; se for preciso, uma escalada instantânea para os proprietários.
7. Confirmação de recepção: «recebido, perguntas/não», lista os primeiros passos.

7) Métricas de qualidade hendover (KPI)

Handoff Quality Score (HQS) - Compilação de pacote (0-100) em folha de cheque.
Handoff Time - duração do briefing (corredor de destino de 10 a 20 min).
Acknowledgement SLA - confirmação de recepção ≤ 15 minutos.
Missing Context Rate - proporção de incidentes com «perda de contexto» após a mudança.
Post-Handoff Invident Spike - aumento de alertas/incidentes nos primeiros 60 minutos.
Action Items SLA - número de tarefas encerradas após o turno.

8) Folha de cheque de qualidade do pacote (avaliação HQS)

• Preenchidos com SLO/métricas-chave em 4 horas com tendências.
• Todas as alertas «vermelhas» estão listadas com razões/referências.
• Incidentes: número, status, influência, próxima apdate (hora).
• Provedores: quotas/erros/feedback, alterações recentes.
• Lançamentos/fici: estágio, riscos, gates/canário.
• Action items: proprietário, prazo, critério de preparação.
• Links: dashboards, canais, runbook 'e, matriz de escalações.
• Contatos on-call e canais de comunicação de reserva.

9) Dashboard «para hendover» (mínimo)

Operations Overview: p95/p99, error rate, capacity headroom, queue lag.
Invidents Board: incidentes abertos, updates ETA, influência.
Release & Função: Canários, comparação antes/depois, auto-gates.
Provers Painel: quotas, temporizações, vale/1k calls, alternações.
Dependency Map: costelas problemáticas (latency/errors/retries).

10) Alertas para a qualidade dos hendowers (ideias)

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) Comunicações e formato de updates

[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.

• Sem bate-papos privados para pontos críticos, apenas canais comuns.
• Qualquer zona vermelha é um trade imediato com os proprietários.
• Todas as decisões/compromissos são por escrito, referindo-se aos dados.

12) Características de domínio (iGaming)

Payments: prioridade: conversão de depósito e hora de permissão, rotas de feedback PSP, limites de provedores.
Bets: atualizações de coeficientes/dinheiro, carga de streaming/filas, atraso nos cálculos.
Games/Live: Ivents de transmissão (jackpots/striptease), limites de websites, degradação da UI.
KYC/AML: fila de verificações, provedores SLA, sensibilidade aos picos.

13) Anti-pattern

Livre «forma arbitrária» hendover (cada um escreve o que quiser).
Não há deadline para confirmação de admissão.
Pacote sem Action items e proprietários.
O Hendover transforma-se em "leitura de logs' em vez de SLO/riscos.
Soluções secretas em chats privados - falta de rastreabilidade.
O modelo não faz referência a artefatos. Não há nada para verificar.

14) Integração e artefatos

Anotações de lançamento nos gráficos, ligações automáticas ao hendover.
Link unfurling: insere referências a dashboards/tíquetes com a supremacia de métricas-chave.
Links: cada zona «vermelha» com referência direta a um runbook específico.
Matriz de escalações: O modelo tem um único documento relevante.

15) Política de armazenamento e auditoria

Hendowers - armazenados centralmente (gays, data/hora, autores).
Auditoria semanal de HQS e análise seletiva de hendowers «maus».
A revisão do modelo é trimestral ou pós-mortem.

16) Início rápido (30 dias)

Semana 1: aprovar o gabarito, os papéis e o timing; executar um piloto na mesma linha (por exemplo, Payments).
Semana 2: Ligar os dashboards para hendover, alertas HandoffNotPublished/AckSLA.
Semana 3: Introduza o controle HQS e a auditoria de 10% dos hendowers.
Semana 4: expandir para Bets/Games/KYC, realizar retrospectiva, atualizar SOP.

17) Exemplo de «cartão de risco» para o pacote

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

O que fazer se a reunião se prolongar?
A: Timbox rigoroso e regra para «trade pós-briefing». O pacote deve ter tudo para consulta assíncrona.

Como lutar contra «versões diferentes da verdade»?
A: Unificar artefatos: dashboards unificados, anotações de lançamento, SSOT para SLA; É só para eles.

Precisamos de gravar um briefing?
Sim, para malas disputadas e treinamento. Mas a gravação não substitui o pacote escrito normalizado.