Bot de incidentes e ChatOps

1) Objetivo e valor

• reduz o MTTA/MTTR ao automatizar o trabalho rotineiro;
• cria um circuito único de fatos (SoT) e comunicações;
• garante rastreabilidade (auditoria, linhas do tempo, SLA de atualizações);
• reduz a carga do plantão e o tempo "perdido" em consoles.

2) Papéis e RACI no ChatOps

Incident Commander (IC): responsável pelo incidente: abertura/encerramento, prioridade, decisões.
Comms Lead (CL): textos e cronograma de atualizações (externas/internas).
Domain Leads (Payments/Games/Core/Infra): fatos técnicos e correções.
Scribe: linha do tempo, registro de ações.
Bot Admin: permissões/políticas/integrações do bot.

Regra: cada incidente tem um único IC e um único CL; a troca de papel só acontece por um comando explícito do bot.

3) Cenários básicos (ponta a ponta)

1. Início do incidente: alerta → `/incident new p1 "Deposits EU down"` → o bot cria um card e uma sala de crise, designa IC/CL e define o timer da primeira atualização.
2. Condução: `/incident add-facts`, `/incident status set degraded`, `/incident assign @payments-lead`, `/incident timer 20m`.
3. Comunicações: `/incident publish status` (rascunho do CL), `/incident partners notify`, `/incident regulator draft`.
4. Ações: `/runbook psp-failover PSP1→PSP2`, `/feature toggle replay-center off 60m`, `/traffic shift 30% eu→uk`.
5. Encerramento e post-mortem: `/incident resolve`, coleta automática da linha do tempo, `/postmortem generate`.

4) Comandos do bot (núcleo)

Criação/classificação

`/incident new p{1|2|3|4} "<title>" [components=…] [regions=…]`

`/incident severity set p2`, `/incident tag add payments,psp`

Responsabilidade e papéis

`/incident ic @user`, `/incident comms @user`, `/incident assign @user [domain]`

Timers e SLO de atualizações

`/incident next-update 15m`, `/incident remind` (o bot notifica o CL), `/incident eta set 18: 30`

Fatos e status

`/incident fact "auth-success PSP1 -25% TR/EU"`, `/incident status {investigating|degraded|monitoring|resolved}`

Pacotes de comunicação

`/incident draft public|partners|regulator`, `/incident publish public`

Integrações

`/runbook ` (catálogo de ações automáticas), `/dashboard link `, `/ticket create `

Encerramento/post-mortem

`/incident resolve [reason=…]`, `/postmortem generate`, `/postmortem assign @owner`

5) Integrações (mínimas necessárias)

Monitoramento/observabilidade: alertas, SLI/SLO (burn rate), links para dashboards.
Incident Manager (ITSM): sincronização bidirecional de status e campos.
Página de status: rascunhos e publicação via CL (policy gate).
Provedores (PSP/KYC/estúdios de jogos): diretórios de contatos, e-mails/canais rápidos.
Release/Feature Flags: paradas/rollbacks canary, links para as versões.
Runbooks/autorremediação: catálogo de ações seguras com guardrails.
CMDB/responsáveis: designação automática de líderes de domínio, escalonamentos.
Armazenamento de linhas do tempo: WORM/imutável para auditorias e post-mortems.

6) Arquitetura do bot

Gateway (Chat Adapter): interfaces Slack/Teams/Telegram.
Command Parser + Policy Engine: autorização, validação, SoD e permissões.
Orchestrator: cenários de incidentes, timers, lembretes.
Integrations Layer: clientes para ITSM, monitoramento, página de status, versões e runbooks.
Evidence Store: eventos, fatos, diffs de mensagens, anexos (WORM).
Metrics & Audit: métricas de qualidade, logs de ações, rastreamento de comandos.

7) Políticas, permissões e segurança

RBAC/ABAC: quem pode criar/encerrar incidentes, alterar a severidade e publicar externamente.
SoD: publicar comunicações exige o papel de CL; ações de alto risco (roteamento de PSP, exportação de PII) exigem controle duplo.
Permissões JIT: acesso temporário para líderes de domínio durante o incidente.
Assinatura e criptografia: webhooks/requisições aos sistemas com HMAC/mTLS.
Proteção contra erros de digitação (fat-finger): confirmação de comandos perigosos, dry run e TTL por ação.
Higiene de PII: mascaramento em rascunhos/logs; proibição de PII em canais abertos.

8) Fluxos de automação (exemplo)

Alerta P1 → o bot cria uma sala de crise (`#inc-2025-11-01-001`) e aciona os plantonistas (IC, CL, Payments/Infra).
Vincula dashboards/SLIs, abre um ticket no ITSM e prepara o modelo da primeira atualização pública.
Define timers: "próxima atualização em 15 min" e lembretes para o CL.
Sugere runbooks: "PSP reroute 30% → PSP2", "degrade replay-center", "autoscale settle-workers".
Na publicação, registra a versão do texto e publica na página de status/redes sociais (via CL).
No encerramento, reúne a linha do tempo, as métricas, o rascunho do post-mortem e o envio para VIPs/parceiros.

9) Linhas do tempo e rastreabilidade

Cada evento é registrado: `T+mm: descrição, autor/bot, comando, resultado, links`.
São suportadas edições de mensagens (diff) e vínculos com versões, feature flags e manutenções programadas.
Exportação: PDF/CSV para auditorias e reguladores.

10) Métricas (KPI/KRI de ChatOps)

MTTA (chat): do alerta até `/incident new`.
MTTS (setup): até a sala de crise estar pronta e os papéis atribuídos.
Cadence adherence: cumprimento dos intervalos de atualizações públicas.
Runbook usage rate: proporção de incidentes com ações automatizadas.
Consistency score: a meta é zero divergências entre canais.
Pager fatigue↓: menos acionamentos manuais com o mesmo SLO ou melhor.
Postmortem SLA: proporção de post-mortems concluídos em ≤ D+5.

11) Catálogo de modelos (trechos)

/incident new p1 "Deposits EU down" components=payments,deposits regions=EU

/incident draft public
/incident publish public

/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m

/postmortem generate
/postmortem assign @owner

12) Integração aos processos

Comunicações: ligado a "Comunicação durante incidentes" e "Páginas de status do sistema".
Observabilidade: links rápidos para SLOs/SLIs e testes sintéticos; gráficos anexados automaticamente.
Alertas: criação automática de incidentes para P1/P2; deduplicação de sinais em um único fluxo.
Autorremediação: runbooks de um clique com guardrails e rollbacks.
Workflow Engine: tarefas humanas (4-eyes), timers de escalonamento, checklists.

13) Roteiro de implantação (4–8 semanas)

Semanas 1–2: MVP de comandos: `/incident new`, papéis (IC/CL), sala de crise, timer de atualizações, integração com ITSM e monitoramento.
Semanas 3–4: modelos de mensagens (públicas/parceiros/reguladores), página de status (rascunho→publicação), catálogo de 5–7 runbooks.
Semanas 5–6: policy-as-code (RBAC/SoD/JIT), controle duplo para ações de alto risco, log WORM, dashboard de KPI de ChatOps.
Semanas 7–8: simulações tabletop P1/P2, integração com versões/feature flags, montagem automática do post-mortem, localização.

14) Antipadrões

"Tudo pelo bot" sem guardrails → ações perigosas acidentais.
Publicações na página de status sem o papel de CL/revisão jurídica.
Comandos sem logs/versões → sem rastreabilidade.
Formulários complexos (mais de 20 campos) no chat derrubam a velocidade; comandos curtos + links funcionam melhor.
Sem timers de atualização → "silêncio" durante um P1.
Sem integração com a CMDB/responsáveis → caos nas designações.

15) Conclusão

Um bot de incidentes e o ChatOps não são um "bot com comandos", e sim uma plataforma operacional: início rápido do incidente, disciplina de atualizações, ações automatizadas com limites seguros, observabilidade e rastreabilidade de ponta a ponta. Esse circuito reduz o MTTR de forma previsível, melhora a qualidade das comunicações e protege a receita de um negócio de iGaming nos momentos de pico.