Mudança de serviço e transferência de tarefas

1) Por que formalizar a mudança de serviço

A mudança de serviço é um momento crucial de risco: perde-se o contexto, cresce o tempo de reação e duplica-se as ações. O processo formalizado reduz o MTTA/MTTR, exclui «caudas esquecidas» e fornece uma complicação (quem e quando aceitou a responsabilidade).

2) Papéis e modelo de revestimento

Primary on-call (P1) - primeira resposta, triagem, coordenação antes do IC chegar.
O Secundary on-call (P2) é um backap que se conecta quando sobrecarregado/escalado.
Duty Gerente/IC-of-the-day é o líder do incidente para o SEC-1 +.
Follow-the-sun (multi-timzon) ou Follow-the-moon (revestimento noturno em outras regiões).
Janelas de tempo: evitar lançamentos/trabalhos de risco de £30 min do turno.

3) Gráficos de rotações (exemplos)

24/7, turnos de 8 horas: manhã/dia/noite, 3 brigadas, P1 + P2.
24/7, turnos de 12 horas: menos mudanças, mais risco de cansaço - é preciso «janelas de compensação».
5 x 8 (dias úteis) + Week Pool: revestimento primário diurno pela equipe do produto, fim de semana - plataforma/SRE.
Híbrido: semana em horário de escritório, noite/fim de semana - Follow-the-sun.

Regras de justiça: rotatividade de calendário, registro de feriados/férias, máximo N turnos noturnos por período.

4) Cartão de troca (Shift Handover Card)

• Quando e quem: «Data/hora (UTC e local)», transmite → aceita; contatos P1/P2.
• Estado dos sistemas: resumo SLO/SLA, alertas ativas conhecidas de degradação.
• Incidentes abertos: ID, SEV, o passo atual, quem é o dono, a ação seguinte/ETA.
• Os riscos para a janela de mudança são: trabalho programado, lançamentos, migrações, estados limitados (quotas de provedores).
• Tíquetes/tarefas críticos: prioridade, bloqueadores, prazo limite.
• Comunicações envolvidas: posts ativos na página de status/updates de clientes.
• Os caminhos de volta conhecidos incluem as bandeiras de degradação, os limites de tempo.
• Domenica: provedores de pagamentos/KYC/CDN - seus estados e rotação.
• Housekeeping: quem on-call amanhã, janelas de indisponibilidade de pessoas (manifestações/voos).

5) Folha de cheque «Troco de turno» (doador)

• Atualizou o cartão de mudança (todos os campos) e fixou o link no canal '# oncall-handover'.
• Traduziu «conhecimento oral» em tíquetes/notas; não há tarefas na cabeça.
• Todos os incidentes têm SEV, proprietário, próximo passo, hora do próximo update.
• O status da página e os updates do cliente correspondem ao estado real.
• Desativou alertas ruidosas/falsas (pelo procedimento) ou marcou no cartão.
• Verificou as quotas/limites dos provedores externos na janela seguinte.
• Sincronizado voz/vídeo por 5 a 10 minutos (se o V-1 + estiver ativo).
• Registrou a transferência (bot/tíquete), indicou o receptor.

6) Folha de cheque «Aceito turno» (receptor)

• Leu o cartão e definiu as perguntas abertas.
• Verifiquei os dashboards SLO/alert nas últimas 2-4 horas.
• Confirmou o papel P1/P2 no bot (assign) e o som/canal do pager.
• Tomou posse de incidentes ativos e atualizou os horários dos updates.
• Cruzou os trabalhos/lançamentos programados, cancelou as operações arriscadas nos primeiros 30 minutos.
• Fez uma mensagem de eco no canal: "A mudança foi tomada, os incidentes são ativos:..., o seio. update em "...

7) Padrões de comunicação

Каналы: `#oncall`, `#incident-warroom-<ID>`, `#statuspage`.

Intervalos de update: V-0: 15 min, SEC-1: 30 min, IV-2 +: 60 min

Formato de update: Impacto - Diagnóstico - Ação - Próxima apdate (hora).
Escalação: Não há avanços em N minutos → ligar TL/Plataforma/DB/Sec pela matriz.
Clareza de posse: cada ação tem um executor e ETA.

8) Transferência de tarefas (não incidentes)

Critérios de transferência: a tarefa bloqueia SLO/lançamento/complacência ou expira.
Aparência: tíquete com «definition of next step» e resultado esperado, todos os artefatos (logs/instantâneos/gráficos) estão anexados.
Prioridade: Kanban- swimlane «On-call Handover».
Prazo: As transmissões têm dê-data; atrasos são escalados para o dono do serviço.

9) Automação e integração

Calendário de rotações: sincronização com o pager; O bot publica «quem é de serviço» no início do turno.
ChatOps: '/handover start ', cartão automático de origem (estados SLO, incidentes abertos, lançamentos).
Tiketing: atribuição automática do proprietário por P1/P2; tags «handover».
Página de status, bridge para updays públicos com modelos.
Auditoria: Registro de transmissão (quem/quando aceitou), comunicação com o SEC e relatórios.

10) Gerenciamento de fadiga e sustentabilidade (Fatige Management)

Limites: máximo X page/hora e Y à noite - ir para P2/escalação.
Quiet hours para alertas não ríticas (tíquetes em vez de paging).
After-hours compensação e post-invident rest.
Treinamento e shadowing para novos engenheiros on-call.
Retrospectivas de turnos ruidosos → sintonizações de alertas e playbooks.

11) Métricas de qualidade de turno e de transmissão

Handover Defect Rate: proporção de incidentes com perda de contexto na mudança.
MTTA em torno da mudança: mediana/picos a £30 min da mudança.
Missed/late updates: updates vencidos por SEC.
Alert Hygiene:% falsos pages; alertas sem runbook/proprietário.
Load per shift: pagie/hora, duração média do trabalho ativo.
Sensation: NPS mudança (pesquisa on-call), fadiga na escala.

12) Comunicação com gerenciamento de incidentes e RCA

Incidentes ativos não se encerram na hora do turno; a responsabilidade é claramente transmitida e registada.
No RCA, a seção «Influência do turno» é obrigatória: se houve deriva do contexto, atraso no update, e medidas tomadas.
CAPA: melhoria de cartão, folha de cheque, automação, treinamento.

13) Segurança, complacência e privacidade

PII/segredos são proibidos no texto livre dos cartões; links de armazenamento seguro.
Permissões de tempo: permissões on-call para a janela de turno (JIT/JEA), rotação de chaves.
Pista de auditoria: imutável-logista que leu/mudou cartão e status-página.
Regulação: os prazos de notificação do cliente são controlados no cartão de mudança.

14) Anti-pattern

«Passar verbalmente» sem cartão/tíquete.
O lançamento é na hora do turno, sem IC ou Bacap.
Pager em um homem «no avião/metro» sem P2.
Cartão como «lençol» sem next step/ETA.
Triagem em bate-papo pessoal - as informações perdem-se, não é possível verificar.
Não há registo da transmissão. A discussão é «quem respondeu».

15) Modelos

Modelo de cartão de troca (comprimido)

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.

Modelo de mensagem eco ao receber

[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) Incorporação à prática diária

O ritual de mudança de Daily é de sincronização de voz durante 5-10 minutos.
Auditoria semanal de cartões: Verificamos de forma seletiva a abrangência/relevância.
Game-days: simulação de turnos com muitos eventos paralelos.
Pasta: modelos de cartão/cheque no repositório, revirando como código.

17) Resultado

Os turnos bem organizados e as transmissões são o «lubrificante» de toda a máquina de operação. O cartão de turno, as sincronias curtas, as folhas de cheque rigorosas, a automação e a preocupação com a estabilidade da equipe transformam os momentos de risco em uma rotina sem perda de qualidade: o contexto é preservado, o tempo de reação é estável e os usuários não se dão conta da mudança de serviço.