Playbooks de operações

1) O que é um playbook e o que é diferente do runbook

Runbook é uma instrução linear passo a passo para uma operação típica/alert («faça um, dois, três»).
O playbook é uma árvore de soluções para cenários de bifurcação, sintomas diferentes → hipóteses diferentes → diferentes ramos de ação. Inclui critérios de seleção, condições de gate e ramais fallback.
A atribuição do playbook é reduzir o MTTA/MTTR e o nível de improviso na incerteza.

2) Onde os playbooks são necessários primeiro

Incidentes: queda do SLO (availability/latency/sucess), fracasso do SLI empresarial (conversão/sucesso de pagamentos).
Mudanças: lançamentos, migrações, bandeiras de fich, configs (canary/rollback).
Janelas de serviço: upgrade BD/corretores, rotações de certificados.
Provedores PSP/KYC/CDN/IDP - degradação e swich-over.
Segurança, chave comprometida, atividade suspeita.
O atraso na frescura, a deriva do circuito, a degradação do pipline.

3) Padrões de playbook (composição mínima)

1. Cartão: ID, Versão/Data, Proprietário (comando/papel), Serviços/regiões/tenentes, Políticas/padrões relacionados.
2. Propósito e condições de lançamento: Quais SLO/SLI protegemos quais alertas/desencadeadores são aplicáveis.
3. Sintomas ↔ Hipóteses: tabela de correspondência, como cortar rapidamente as hipóteses erradas.
4. Árvore de soluções: bifurcações, gates de segurança, critérios para parar/continuar.
5. Ações: blocos passo a passo com comandos/links de runbook 'i.
6. Comunicações: modelo de update (Impakt→Diagnostika→Deystviya→Sled. update), canais e frequências.
7. Retrocesso/folback: plano de backout claro, limites e bandeira de degradação UX.
8. Critérios de conclusão: métricas, janelas de observação temporárias.
9. Evidence: o que salvar (logs, gráficos, capturas de tela, ID de tíquetes).
10. Histórico de alterações: changelog, conhecidos limites.

4) Taxonomia de playbooks (exemplo de catálogo)

INC- - Incidentes (SLO/SLI, provedores, infraestrutura).
REL- - lançamentos, revezamentos, configs/bandeiras.
MW- janelas de serviço (DB/queue/cert/OS).
SEC- segurança (disponíveis, chaves, ações suspeitas).
DATA- frescura/qualidade/padrão.
PROV- Provedores externos (PSP/KYC/CDN/Email/SMS).

5) Ciclo de vida e posse

1. Iniciação: resultado de incidente/simulação/alteração.
2. Rascunho: autor = dono do serviço; revezamento: SRE/segurança/dados (domínio).
3. Piloto: tabletop/game-day; a fixação de tempo e defeitos.
4. Publicação: Em Repo (Docs-as-Code), versão, marcas de formatação, links de dashboards.
5. Atualização: RCA/CAPA, pelo menos uma vez por trimestre; O SLA é fresco.
6. Arquivo/despoluição: ao substituir/perder a relevância.

6) Integração com ferramentas

Alert → Playbook: Cada regra Page faz referência a exatamente um playbook básico.
ChatOps: '/play start <id> 'abre o cartão, registra a evidência, coloca os horários dos updates.
CMDB/catálogo: O serviço tem uma lista de playbooks relevantes, proprietários, SLO, dashboard.
GitOps: playbooks e runbook 'e vivem em Git, passam por revezamento PR e lentes.

7) Métricas de qualidade de playbooks

Activability: ≥ 90% dos lançamentos resultam em ações específicas sem escalar «ignorância».
Time-to-first-action: minuto-dois de Page até o primeiro passo.
Coverage:% de alertas Page com playbook amarrado (alvo 100%).
Freshness: a proporção de playbooks é mais recente que 90 dias.
Defect rate: observações no revezamento/simulação de 100 playbooks.
Reuse: Quantas vezes o playbook foi realmente usado (e quais foram os resultados).

8) Anti-pattern

«Enciclopédia Playbook» em 20 páginas sem árvore de soluções.
Equipes sem expectativas de resultados («executar X» - o que deve mudar?).
Nenhum plano backout ou limite - risco de escalar o problema.
Nenhum canal/intervalo de comunicação especificado - aumento de risco PR.
Playbook sem dono/data de atualização - ninguém acredita na sua relevância.
Dezenas de playbooks parecidos em vez de um parametrizável.

9) Mini-modelo de playbook (ideia YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Exemplos prontos (fatias)

A) Pagamentos: «O provedor está degradado em uma região»

Sintomas: redução de sucess _ ratio TR, crescimento de temporizações PSP-A.
Soluções: reduzir o peso de PSP-A para TR, incluir degrade-UX, reforçar os retais com orçamento ≤ SLA e preparar update de clientes.
Backout - recuperar o peso com um SLI verde de 60 minutos.

B) BD: «Crescimento p99 e conexion errors»

Sintomas: p99↑, erros de conexion reset, crescimento wait events.
Soluções: ativar o cenário read-only, limitar a carga write, dimensionar o pool/réplica, se necessário, o faulover quente.
Backout: reversão de parâmetros, réplica-nobre.

C) Cash: «Miss rate ↑ → carga de BD»

Sintomas: miss rate> 40%, crescimento CPU BD.
Soluções: equilibrar evition policy, aumentar memória/charding, ativar temporariamente o read-through, limitar RPS em chaves quentes.
Backout: recuperar a política, reencontrar um shard problemático.

D) CDN: «Degradação regional de conteúdo»

Sintomas: crescimento latency/timeout em um país, queixas RUM.
Soluções: Alterar o roting map/GSLB, contornar POP problemático, reduzir TTL, incluir origin-shield.
Um status-update com uma geografia de influência.

E) KYC: «Falhando identificações»

Sintomas: queda do approve rate, crescimento do vendor _ erro.
Soluções: mudar parte do tráfego para um provedor alternativo, reduzir o rigor das regras (como parte da política), iniciar review manual para VIP.
Compliance: logs de todas as alterações, notificações Risk/Legal, se necessário.

11) Comunicações (modelo de update)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Folha de cheque do autor do playbook

• São especificados alvos, proprietários, SLO/SLI e desencadeadores.
• Há uma tabela «Sintomas ↔ Hipótese» e uma árvore de soluções.
• Passos em andamento com os resultados esperados e gates de segurança.
• Os termos de retorno são backout/fallback.
• Modelo de comunicação e frequência de updates.
• Referências a dashboards/alertas/logs-busca/trailers.
• Seção de evidence obrigatória e critérios de conclusão.
• Versão, data, SLA recente, histórico de mudanças.

13) Folha de cheque do revezador

• Playbook reproduzido em tabletop/game-day.
• Os passos são seguros (limites/canário/auto-recall), e os segredos não são revelados.
• Os papéis e escalações são claros; IC/Comms são especificados.
• Sem duplicação com playbooks vizinhos; parâmetros concluídos.
• Está claro quando parar e ir para fallback/rollback.
• O documento está disponível a partir de um alert de 1 clique.

14) Configuração e reutilização

Leve as variáveis (região, provedor, liminares) para 'values.'.
Os passos gerais (por exemplo, «reduzir o peso do provedor», «incluir degrade-UX») são personalizados com runbook 'ami.
Suporte aos geradores de modelos: 'plb new -type = INC --service = payments'.

15) Mapa de trânsito de implementação (4-6 semanas)

1. O inventário de alertas de Page → corresponder a cada playbook básico.
2. Modelos: aprovar estrutura YAML/Markdown, folha de cheque e lentes.
3. Top 5 (pagamentos/BD/CDN/KYC/dinheiro) → escrever/reverter para tabletop.
4. Integração: links de alertas, ChatOps comandos, evidence-bot.
5. Exercício: mini-drill semanal de um playbook; AAR→uluchsheniya.
6. SLA frescura e ciúmes trimestrais; Relatório de métricas de qualidade.

16) Resultado

Os playbooks são cenários operacionais com bifurcações e corrimãos que traduzem o caos do «o que fazer?!» numa previsível sequência de decisões. Quando os playbooks são normalizados, integrados com alertas e treinados regularmente, a equipe reage mais rapidamente, os riscos são controlados e o negócio vê estabilidade e maturidade operacional.