Checklists de Prevenção
Incidentes se repetem quando correções ficam em logs de chat. Estes checklists convertem action items de post-mortem em monitores, gates de CI e drills trimestrais para que transações falhadas, outages RPC e caminhos de exploit sejam detectados antes de usuários tweetarem.
Como Usar Este Checklist
- Execute Tier 1 antes de qualquer promoção de programa ou frontend na mainnet
- Adicione itens Tier 2 em 30 dias de cada incidente Sev-1/2
- Reexecute Tier 3 trimestralmente e após upgrades maiores de Agave ou Anchor
- Registre pass/fail no ticket de release; bloqueie deploy em falhas Tier 1
Tier 1 - Detecção e Monitoramento
-
Velocidade de TVL / saldo de vault: Alerte quando saldo cai > X% em Y minutos em PDAs do programa.
- Owner: Time backend / indexer
- Tool: Indexer customizado ou webhook Helius
-
p95 de pouso de transação: Send sintético a cada 5 minutos; alerte se p95 > 30s por 10 min.
- Owner: SRE
- Tool: Cron job
@solana/kit+ Grafana
-
Taxa de erro de programa: Razão de erros
Customfalhados para total de txs do seu program ID.- Owner: Eng on-call
- Tool: API Explorer ou filtro Geyser
-
Saúde do provedor RPC: Slot lag, taxa 429, contagem de desconexão WS por provedor.
- Owner: Infra
- Tool:
rpc-health.sh+ PagerDuty
-
Sanidade de priority fee: Alerte se lance mediano de fee cai para zero durante janelas conhecidas de alto tráfego.
- Owner: Time de client
- Tool: Métricas do app
-
Mudanças de upgrade authority: Page em qualquer
set-upgrade-authoritypara program IDs de produção.- Owner: Segurança
- Tool: Regra de indexer ou notificação Squads
-
Drill de flag pause: Teste trimestral
set_paused(true)em clone devnet em < 5 min.- Owner: Lead de programa
- Tool: Runbook
incident-pause.sh
Tier 2 - Testes e Gates de CI
-
Regressão LiteSVM / Surfpool: Replay txs de exploit conhecidas contra cada PR de programa.
- CI:
anchor test+ fixture LiteSVM 0.6.x
- CI:
-
Gate de sync IDL: Codegen de client falha se hash IDL difere do programa devnet implantado.
- CI: Comparação de hash em GitHub Actions
-
Build verificável no release: Hash
solana-verifypublicado em release notes.- CI: Artefato obrigatório no tag
-
Smoke de simulação: Top 10 fluxos de usuário simulam sem erro em devnet pré-promoção.
- CI: Nightly + gate manual pré-mainnet
-
Caminho de upgrade multisig: Sem deploy direto de laptop na mainnet; apenas proposta Squads.
- Processo: Sign-off de checklist de release
-
Teste de refresh de blockhash: Teste de integração de client asserta retry usa novo blockhash.
- CI: Jest/Vitest com RPC mockado
-
Orçamento de rate limit: Load test de caminho read em 2x tráfego esperado de launch contra RPC staging.
- Tool: k6 ou locust
Tier 3 - Runbooks e Cultura
- Definições Sev documentadas: Sev-1 inclui perda de fundos; árvore de escalação em Notion/git.
- Links de runbook on-call: Cada alerta vincula a seção de runbook, não página inicial de wiki.
- Template de post-mortem sem culpa: Armazenado no repo; rotação de facilitador agendada.
- Keys break-glass: Localização, custodiantes e revisão de expiração a cada 90 dias.
- Templates de comms: Mensagens pré-escritas de pause, rollback e resolvido para Discord/X.
- Contatos de terceiros: TAM de vendor RPC, linha de emergência de auditor, plataforma de bounty.
- Log de drill de incidente: Data do último drill e lacunas arquivadas como tickets.
- Macros de suporte ao usuário: "Transação presa" e "Simulação falhou" com links do explorer.
- Check de genesis hash no pipeline de deploy: Cluster errado bloqueado em CI.
- RPC backup no bundle do client: Env vars primário/secundário validadas no build.
- SLA de action item pós-incidente: 90% fechados em 30 dias ou revisão executiva.
Aplicando o Checklist em Ordem
- Tier 1 (1-7): Observabilidade - sem detecção, incidentes são reportados por usuários
- Tier 2 (8-14): Prevenção em CI - pegue regressões antes da mainnet
- Tier 3 (15-25): Sistemas humanos - ferramentas falham sem runbooks praticados
FAQs
Quantos alertas é demais?
Se on-call reconhece < 20% como acionáveis, ajuste thresholds. Comece estrito após incidentes, relaxe com dados.
Qual tx sintética deve rodar?
Transfer mínimo ou ix de programa no-op contra RPC de produção com priority fee - mede apenas pouso.
Monitores devnet importam?
Sim para pré-promoção; monitores mainnet são obrigatórios para fundos de usuário.
Quem é owner de atualizações do checklist?
Incident commander atualiza em 48 horas do post-mortem; eng manager revisa trimestralmente.
Checklist deve bloquear hotfix?
Tier 1 pause/mitigação nunca bloqueado; checklist completo aplica antes de reabilitar tráfego.
Como amarrar a métricas DORA?
Change-fail rate e MTTR melhoram quando itens de detecção e rollback passam.
Qual threshold bom de alerta TVL?
Comece 3-5% em 5 minutos para lending; ajuste por tamanho do protocolo e ruído.
RPCs públicos OK para sintéticos?
Use o mesmo tier de provedor que produção usa, ou resultados enganam.
Como documentar falhas de drill?
Arquive ticket por passo falhado; drill falhado conta como near-miss de incidente.
Quando aposentar item de checklist?
Quando substituído por automação com 90 dias de histórico limpo; documente no post-mortem.
Relacionado
- Depurando Transações que Falharam - decode de falhas que alertas revelam
- Post-Mortems Sem Culpa e RCA - fonte de novos itens
- Métricas DORA para Web3 - medir melhoria
Versões do stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.