Resposta a Incidentes

10h03, sábado. O celular do engenheiro de on-call vibra: CheckoutErrorBudgetFastBurn. Dois milhões de fãs estão na sala de espera, o provedor de pagamentos está respondendo em segundos e as redes sociais da empresa já estão pegando fogo. O que acontece nos próximos trinta minutos decide se isso vira uma manhã ruim ou uma notícia de jornal. Uma boa telemetria diz o que está errado; ela não decide quem faz o quê, quem fala com o mundo lá fora, nem quando parar de investigar e começar a mitigar. Isso é resposta a incidentes — uma prática emprestada de bombeiros e serviços de emergência, adaptada para software¹.

O que conta como incidente

Um incidente é um evento não planejado que degrada ou ameaça um serviço do qual os usuários dependem, e que precisa de uma resposta coordenada. Nem todo alerta é um incidente; um incidente é declarado quando a resposta precisa de mais de uma pessoa trabalhando do jeito normal. Níveis de severidade tornam essa decisão rápida e consistente — ninguém deveria discutir a definição às 3 da manhã.

On-call

On-call significa que uma pessoa nomeada é responsável, por um período, por responder aos pages de um conjunto de serviços. É um requisito de produção, não um ato heroico, e precisa ser sustentável.

• Escalas (rotations): um primário e um secundário (escalonamento se o primário não confirmar em poucos minutos), geralmente em turnos de uma semana com uma passagem de turno (handoff) escrita — problemas em aberto, deploys arriscados, silêncios em vigor.
• Follow-the-sun: times em fusos horários diferentes dividem o dia para que ninguém seja acionado de madrugada; exige pelo menos duas sedes.
• Carga sustentável: a prática de SRE do Google limita o trabalho de on-call para que os engenheiros passem a maior parte do tempo em engenharia, e mira em no máximo cerca de dois incidentes por turno de 12 horas — um incidente consome horas de acompanhamento, não só a resposta². Mais do que isso significa que o alerting ou o sistema precisa de trabalho, não de mais resistência.
• You build it, you run it: o time dono de um serviço carrega o pager dele. É o incentivo mais forte para construir software operável.
• Preparação: runbooks, acessos já concedidos (nunca "estou esperando acesso à produção"), dashboards nos favoritos e prática em game days (Engenharia do caos).

O ciclo de vida do incidente

stateDiagram-v2
    [*] --> Detectado : alerta, relato de cliente ou um engenheiro percebe
    Detectado --> Triado : on-call confirma, avalia o impacto
    Triado --> Declarado : severidade definida, commander e canal atribuídos
    Triado --> Encerrado : alarme falso ou sem impacto (ajuste o alerta)
    Declarado --> Mitigando : estancar o sangramento
    Mitigando --> Monitorando : impacto acabou, SLIs se recuperando
    Monitorando --> Mitigando : o impacto volta
    Monitorando --> Resolvido : estável, correção definitiva agendada
    Resolvido --> Revisado : postmortem blameless, ações
    Revisado --> [*]
    Encerrado --> [*]

Cada transição tem um timestamp, e os intervalos entre elas são as métricas que importam:

Os usuários só sentem o impacto: o tempo até a mitigação é o número que molda a disponibilidade (lembre de Confiabilidade que disponibilidade = MTTF / (MTTF + MTTR)). A causa raiz pode ser corrigida na segunda-feira.

Papéis

O jeito mais comum de um incidente dar errado não é a falta de uma ferramenta — são cinco engenheiros depurando a mesma coisa em paralelo, ninguém decidindo e ninguém contando aos clientes o que está acontecendo. O Incident Command System (ICS), criado para o combate a incêndios florestais nos anos 1970, resolveu isso com papéis explícitos; Google, PagerDuty e outros o adaptaram para software¹³.

Num time pequeno, uma pessoa pode acumular vários papéis; o IC e o líder de operações ainda devem ser pessoas diferentes sempre que possível. Os papéis são passados explicitamente ("agora eu sou o IC") quando os turnos mudam ou o incidente escala.

Execute os primeiros quinze minutos do incidente da venda relâmpago:

sequenceDiagram
    autonumber
    participant AM as Alertmanager
    participant OC as On-call (primário)
    participant IC as Incident commander
    participant OPS as Líder de ops (pagamentos)
    participant COM as Líder de comunicação
    participant ST as Página de status
    AM->>OC: page: CheckoutErrorBudgetFastBurn
    OC->>OC: confirma, abre o dashboard: 504s em /checkout, abertura em andamento
    OC->>IC: declara SEV1, abre o canal inc-onsale-0313
    IC->>OPS: você lidera a mitigação, o on-call de pagamentos entra
    IC->>COM: você cuida das atualizações, a cada 15 min
    COM->>ST: "Alguns fãs veem erros no checkout. Estamos trabalhando nisso."
    OPS->>OPS: trace de exemplar: 7,9 s em payment pool.acquire
    OPS->>IC: provedor lento, proposta: trocar para o provedor secundário
    IC->>OPS: aprovado, pode ir
    OPS->>OPS: flag payment.provider=secondary, sala de espera estrangulada
    OPS->>IC: razão de erros de volta abaixo de 0,5%, p99 1,4 s
    IC->>COM: mitigado, monitorando
    COM->>ST: "O checkout voltou a funcionar. Monitorando."

Mitigar primeiro

Durante um incidente, o objetivo é parar o impacto, não entendê-lo. O entendimento vem depois, com o postmortem — e é muito mais fácil quando a pressão passou. As melhores mitigações são genéricas: funcionam qualquer que seja a causa exata, e são ensaiadas com antecedência.

Comunicação

Silêncio durante um incidente é lido como incompetência ou indiferença. As atualizações têm uma cadência fixa (para um SEV1, a cada 15–30 minutos), mesmo quando não há nada novo, e um formato fixo:

[SEV1] Checkout errors during the 10:00 on-sale — update #3, 10:21
Impact:   since 10:02, ~12% of checkout attempts failed; fans in the waiting room were not affected.
Status:   MITIGATED at 10:14 — traffic moved to the secondary payment provider.
Next:     monitoring until 10:45; the primary provider is investigating on their side.
Next update: 10:45 or earlier if anything changes.
IC: @ana   Ops: @bruno   Comms: @carla

Para fora da empresa, a página de status informa impacto e progresso, nunca nomes internos, palpites ou culpados ("nosso provedor falhou").

O incidente do BoxOffice, em números

O page chegou um minuto depois do início do impacto só porque a abertura das vendas tem seu próprio SLO, com alertas em janelas de 5 minutos e de 1 minuto (Alertas). Com 12% de falhas, a regra geral de 28 dias — 14,4× numa janela de 1 hora — levaria cerca de 60 min × 1,44% / 12% ≈ 7 minutos para disparar: mais da metade do tempo até a mitigação, perdido antes de alguém olhar.

Quanto isso custou em termos de SLO? Com números ilustrativos — 200 tentativas de checkout por segundo durante a abertura e uma média de 12% de falhas nos 12 minutos de impacto:

Se o BoxOffice processa cerca de 2 milhões de checkouts numa janela normal de 28 dias (a janela de SLO usada em Confiabilidade), um SLO de 99,9% permite 2.000 falhas. Este único incidente gastou mais de oito budgets de 28 dias — mais de sete meses — em doze minutos. A política de error budget agora se aplica: o trabalho em funcionalidades do checkout pausa até que as ações de confiabilidade sejam feitas. Esse é o error budget cumprindo seu papel — transformar uma manhã ruim numa prioridade de engenharia com recursos garantidos.

Postmortems

Um postmortem (também chamado de incident review ou retrospectiva) é uma análise escrita de um incidente, feita depois que ele foi resolvido, com um único objetivo: reduzir a chance e o impacto do próximo. Escreva um para todo SEV1/SEV2, toda perda de dados, todo gasto significativo de budget — e para quase-incidentes interessantes.

Blameless

Um postmortem é blameless (sem culpados)⁴: ele assume que todos agiram de forma razoável com o que sabiam no momento, e pergunta como o sistema tornou o erro fácil, não quem errou. Não se trata de ser gentil. Se as pessoas são punidas por relatos honestos, elas param de fazê-los, e a organização perde a única fonte precisa de informação sobre como seus sistemas realmente falham. "O engenheiro rodou o comando errado" vira "a ferramenta permitiu um comando destrutivo contra a produção sem confirmação, e o runbook o mostrava ao lado de um comando inofensivo".

Causa raiz — ou fatores contribuintes?

Sistemas complexos raramente falham por um motivo; incidentes precisam que vários fatores se alinhem⁵. No incidente do BoxOffice:

• o provedor ficou lento (gatilho externo, fora do controle do BoxOffice);
• o adaptador de pagamentos não tinha timeout menor que o do próprio provedor, e um pool de 20 conexões compartilhado por todas as chamadas;
• o provedor secundário existia, mas a troca era um passo manual e não documentado;
• os alertas gerais de SLO de 28 dias não foram projetados para uma abertura de vendas de 30 minutos;
• o teste de carga antes da abertura usou um mock do provedor que sempre respondia em 100 ms.

Perguntar "cinco porquês" ao longo de uma única cadeia teria parado em "o provedor estava lento" — o único fator que o BoxOffice não consegue corrigir. Procurar todos os fatores contribuintes encontra quatro que ele consegue.

Modelo

# Postmortem: checkout errors during the 13 March on-sale (SEV1)

**Status**: final · **Authors**: … · **Reviewed**: …

## Summary
Two to four sentences: what happened, impact, how it was mitigated.

## Impact
Users affected, duration, failed checkouts, revenue and SLO budget consumed, support tickets.

## Timeline (UTC-3)
10:02 provider latency rises … 10:03 page … 10:14 mitigated … 10:40 resolved.

## Contributing factors
Technical, process and organisational factors — no names, no blame.

## What went well / what went poorly / where we got lucky

## Action items
| Action | Type (prevent / detect / mitigate) | Owner | Due | Ticket |
|---|---|---|---|---|
| Timeout 800 ms + bulkhead on the provider client | prevent | payments | 27/03 | PAY-312 |
| Automatic failover to the secondary provider | mitigate | payments | 10/04 | PAY-313 |
| On-sale SLO with 1 min / 5 min burn-rate alerts | detect | SRE | 20/03 | OBS-88 |
| Provider latency injected in the pre-sale load test | prevent | performance | 27/03 | PERF-41 |

As ações são a única parte de um postmortem que muda alguma coisa. Cada uma é específica, tem um dono e uma data, e é acompanhada como qualquer outro trabalho. Um postmortem cujas ações nunca são feitas é uma história, não uma correção.

Fechando o ciclo

• Reunião de revisão: os autores apresentam o documento ao time; as perguntas são sobre o sistema, não sobre as pessoas.
• Compartilhe amplamente: outros times têm o mesmo pool, o mesmo timeout faltando.
• Procure tendências: muitos incidentes vindos de deploys → invista em canaries e rollbacks (Entrega); muitos vindos de uma dependência → bulkheads e fallbacks.
• Pratique: transforme o incidente num cenário de game day — injete latência no provedor com o Toxiproxy e verifique se o novo timeout, o breaker e o alerta se comportam (Hands-on 9).
• Meça a saúde da entrega: as métricas DORA change failure rate e failed deployment recovery time⁶ mostram se os incidentes causados por mudanças estão ficando mais raros e mais curtos.

echo "$(date +%T) experiment $1"
case "$1" in
  1) toxic payment '{"name":"gd","type":"latency","stream":"downstream","attributes":{"latency":2000,"jitter":300}}' ;;
  2) toxic psp '{"name":"gd","type":"timeout","stream":"downstream","attributes":{"timeout":0}}' ;;
  3) toxic payment '{"name":"gd","type":"reset_peer","toxicity":0.4,"attributes":{"timeout":0}}' ;;
  4) curl -s -X POST "$API/proxies/payment" -d '{"enabled":false}' > /dev/null ;;
  5) docker compose pause db ;;
  6) toxic payment '{"name":"gd","type":"bandwidth","stream":"downstream","attributes":{"rate":1}}' ;;
  reset) curl -s -X POST "$API/reset" > /dev/null; docker compose unpause db 2> /dev/null || true ;;
  *) echo "unknown experiment"; exit 1 ;;

Trade-offs

Como se conecta

flowchart LR
    AL["burn-rate page<br/>→ Alerting"] --> TRI["triage: severity<br/>SEV1 to SEV4"]
    TRI --> ROLES["IC, ops lead,<br/>comms lead, scribe"]
    ROLES --> MIT["mitigate first"]
    MIT --> RB["rollback, flag off<br/>→ Cloud-native delivery"]
    MIT --> FO["failover, shed load,<br/>degrade → Reliability"]
    MIT --> BLK["block bad traffic<br/>→ Edge (WAF)"]
    MIT -->|"timestamps"| MTT["MTTD, MTTM, MTTR<br/>→ availability"]
    MTT --> BUD["error budget spent<br/>→ SLO policy"]
    MIT --> PM["blameless postmortem,<br/>action items"]
    PM --> GD["game day<br/>→ Chaos engineering"]

Componentes da paleta: alerting (o page que o inicia) · tracing (o trace do exemplar que achou o pool.acquire) · payment (failover para o provedor secundário) · queue (a sala de espera, estrangulada para descartar carga) · waf (bloqueio de tráfego abusivo) · app (rollback ou scale-out de um serviço). Cenários: flash-sale (o incidente da abertura de vendas), cascading-failure (um provedor lento sem timeouts). Continua em: Confiabilidade (disponibilidade = MTTF / (MTTF + MTTR)), SLIs, SLOs e error budgets, Confiabilidade — engenharia do caos, Cloud-native — entrega (rollbacks, canaries, DORA), Projeto — game day, Preparação para entrevistas.

Pontos-chave