Interação de comandos em operações
1) Porquê
A plataforma iGaming é uma dúzia de domínios (Payments, Games/Core, Risk/KYC, Data, Infra/SRE, Apoio, Compliance). Sem interação formalizada, o MTTR, o CFR e os riscos operacionais crescem. O objetivo é transformar funções separadas em um único sistema operacional, como contatos previsíveis, filas transparentes, sinais compartilhados e prioridade negociada.
2) Princípios
1. SLO-first: soluções compartilhadas em SLO/orçamento de erros.
2. Uma única fonte de verdade, dashboards comuns, estatais e artefactos.
3. Limites e interfaces claros: cada par de comandos tem o contrato descrito (OLA/Runbook/API).
4. Pequenos batches e reversibilidade: alterações através de ficheflags/canarela, rápido rollback.
5. No blame - yes data: análise de factos, melhorias - parte obrigatória do ciclo.
6. Privilégios e SoD mínimos necessários: separação de papéis para operações sensíveis.
7. Automatiza a rotina, normaliza o resto.
3) Rolos e RACI (transbordantes)
Head of Ops/SRE Lead é o dono do sistema operacional, KPI/KRI. A
Service Owners (Payments/Games/KYC/Data) - objetivos de domínio, alterações, riscos. A/R
Plataforma/Infra - disponibilidade, performance, lançamentos/canários. R
Risk/Compliance/Security - SoD, RG/KYC/PII, auditorias. C/A
Suporte/CRM - frente de queixas, comunicações aos jogadores. R/C
On-call IC/CL - gestão de incidentes e updates externos. R
Release Gerente - Calendário, FAB, status de alterações. R
Data/Analytics - métricas de alimentação e operação, suporte RCA. R/C
4) Contratos de interação (OLA/SLx)
A OLA é um acordo interno entre equipes (não SLA externo). Incluem:- Áreas de responsabilidade: que a área (por exemplo, routing PSP - Payments; dinheiro/BD - Infra).
- Alvos/métricas liminares: MTTA incidente, tempo de resposta a escalação, janela de monitoramento pós.
- Filas e prioridades: P1-P4, criticidade de negócios, janelas freeze.
- Interfaces: canais, comandos de bota, API/Runbook, diretórios de proprietários.
- Artefactos: quais documentos/logs/dashboards são obrigados a acompanhar o evento.
5) Canais e protocolos de comunicação
Bate-papo de operações: updates diários, mini-rituais, handover.
Ruma de incidentes, criados por um bote; os papéis IC/CL são atribuídos por um comando.
Canal FAB/Mudança: discussão sobre mudanças, riscos, calendário de lançamento.
Canal de status (read-only): resumos SLO/incidentes/trabalho programado.
Escalações: modelos de comando '/page ', '/escalate', SLA relatórios.
Um único protocolo de mensagens: «Fato → influência → ETA/ETR → próxima janela de update → proprietário».
6) Hendowers entre mudanças e regiões
Modelo de 10 a 15 minutos:1. SLO/SLI: Onde está o risco de queimar o orçamento.
2. Incidentes abertos/escalada e seus ETA.
3. Trabalhos/lançamentos programados nos próximos dias 24-48 h.
4. Provedores (PSP/KYC/estúdios): tíquetes ativos, expectativas.
5. Composição on-call e contatos (IC/CL/domins).
6. Watchlist - Áreas de atenção (filas/replicação/dinheiro).
O Hendover é registado em um registo de turno, referências a rum e dashboards.
7) Colaboração em incidentes
Início: alert-bot cria cartão '# inc-YYYY-MM-DD-XXX', atribui IC/CL e lides de domínios.
Regra de um voto: IC - solução final; Comunicações CL.
Factos e hipóteses: Separamos; os sinais vermelhos são prioritários.
Guardrails: ficheflags/PSP routing só mudam através de runbook com SoD/dual-control.
Comunicações: rascunhos de updates públicos via CL, associados com metas.
Encerramento: pós-monitorização, geração de pós-mortem e tarefas de melhorias com proprietários/prazos.
8) Colaboração para alterações
Calendário de lançamentos: público, com períodos freeze e slots on-call.
Gates de qualidade unit/contract/e2e, segurança, SLO-gate staging.
Lançamentos canários: passo a passo 5%→25%→100% em GEO/tenentes/bancos.
Auto-retrocesso: Políticas de SLI/KRI chave, WORM.
Pacotes comm: rascunhos de update acordados com o CL/Legal.
Alterações RM (A/R), SO (A/R), SRE (R), Sec/Compliance (C/A), FAB (A), IC/CL (R/C).
9) Telemetria unificada e artefactos
Catálogo geral de métricas: SLI/SLO, métricas de negócios, KRI (filas, PSP, replicação).
Dashboard Mapa de Operações - Resumo de domínios, regiões, estado de ocorrência/trabalho.
Timeline: formato único (tempo, autor, ação, resultado, links).
Pós-mortem, modelo sem acusações, prevenção, data de revisão.
Runbooks/Checklists: versioned; link de alertas e cartões de incidentes.
10) Priorização e planejamento
Plano Ops semanal (30-45 min): alinhamento de alto risco, lançamentos, limites, melhorias pós-mortem.
As colunas 'Backlog' Ready In Progress Validate Done ', limites WIP.
Critérios de prioridade: impacto sobre SLO/receita/complacência, tamanho/reversibilidade, dependência dos provedores.
11) Matriz de escalações (estourado)
12) Políticos e SoD
SoD/4-eyes: conclusões/bónus/routing PSP/exportação de PII - somente com aprovação dupla.
Direito JIT: escalação temporária de privilégios para ações de runbook.
Políticas de dados: proibição do PII em canais abertos/dashboards; geo-limite.
Auditoria: registros de ação inválidos (WORM), revisões de políticas.
13) Ferramentas de interação
Incidente-bot: '/invent new ', papéis, temporizadores de update, comm-rascunho, '/runbook', '/flag ', '/config'.
API Metrics: Visualização SLO compartilhada e KRI, exemplars (trace _ id) para RCA.
Portal Release: manifestos, gates, status de abertura/reversão.
Manual de proprietários/CMDB: domínios, contatos, canais de reserva.
14) Métricas de colaboração (KPI/KRI)
MTTA/MTTR em domínios e slots (dia/noite), número de incidentes capturados antes das queixas.
Handover Quality: defeitos de transferência (itens da folha de cheque não fechados a tempo).
Mudança Participation:% de lançamentos com pacotes de comm prontos e sem reembolso.
Guardrail Discipline: Taxa de violação de SoD/políticas (alvo: 0).
Comms Cadence: Cumpre os intervalos dos updates públicos em P1/P2.
Post-mortem SLA: proporção de pós-mortem ≤ D + 5, acção.
Fair-share Load: distribuição de noites/picos por pessoas/comandos.
Customer Sinal Lead: uma liga entre a degradação objetiva e as primeiras queixas.
15) Mapa de trânsito de implementação (6-10 semanas)
Ned. 1-2: inventário de domínios/proprietários; modelos OLA; iniciar um canal de substituição e uma folha de cheque hendover; matriz básica de escaladas.
Ned. 3-4: incidente-bot (MVP), canal de status geral, cartão único SLO/SLI/KRI; catálogo de runbooks.
Ned. 5-6: ABC/calendário de lançamento, pacotes comm e janelas freeze; Para operações sensíveis.
Ned. 7-8: roteiros canários e auto-revezamento como padrão; pós-mortem modelo, Exec/Ops-dashboard colaborações.
Ned. 9-10: exercício P1, hendowers cruzados-regionais, auditoria WORM, relatórios KPI/KRI, ajustamento OLA.
16) Modelos (fatias)
16. 1 OLA (Payments ↔ Infra/SRE)
yaml ola:
scope: "Payments-Auth & Routing"
contacts:
payments_so: "@pay-so"
infra_oncall: "@sre-oncall"
objectives:
mtta_p1: "≤5m"
rollback_ttr: "≤10m canary"
interfaces:
runbooks: ["psp-failover", "reroute", "auth-throttle"]
dashboards: ["auth_success", "psp_latency", "queue_lag"]
escalation:
p1: ["IC","Payments Lead","SRE L2"]
p2: ["Payments OnCall","SRE OnCall"]
artifacts:
status_templates: ["public","partners"]
postmortem_due: "D+5"
16. 2 Folha de cheque Hendover (10 pontos)
1. Estados SLO de domínios
2. Incidentes abertos (ETA/proprietários)
3. Trabalhos/lançamentos programados + janelas de vigilância
4. Provedores (PSP/KYC/estúdios) - riscos/espera
5. Filas/replicação/dinheiro - lag/anomalias
6. Alterações nos limites/fichiflags
7. Queixas/tíquetes e liminares de carga
8. Planos e status de rascunho
9. Composição on-call e reserva
10. «Watchlist» em slot
17) Antipattern
«Alguém vai tratar disso?» sem RACI e dono.
Incidentes sem IC/CL e times de update.
Alterações ocultas (cliques manuais), sem Git/Auditoria.
Telemetria fora de contacto, números diferentes em diferentes equipas.
Lançamentos sem pacotes de coma ou canais.
Violações SoD para a velocidade.
Os Hendowers são orais, sem registos ou folhas de cheque.
Pós-Mortems sem acções ou prazos.
Resultado
A interação de equipes em operações é uma colaboração contratual: OLA/SLx, canais e papéis claros, disciplina de hendowers, telemetria geral, lançamentos concordados e processos de incidente. Esse esqueleto reduz o MTTR e o CFR, alinha prioridades, protege o SLO, a receita e a complacência - e torna o trabalho diário previsível e sustentável.