Resposta a Incidentes em Detalhe
Produtos Solana em produção falham de formas que parecem similares para usuários (wallets presas, saldos vazios, envios falhados) mas exigem primeiras ações opostas dos engenheiros.
Provedor RPC com rate limit não é exploit de vault. Erro Custom de programa após upgrade ruim não é expiração de blockhash. Tratar todo dashboard vermelho como "retry mais forte" queima minutos e às vezes fundos.
Esta página é o guarda-chuva da seção: como classificar incidentes, reunir evidências, conter dano, mitigar sem reescrever história e fechar o loop com prevenção e RCA sem culpa para programas Solana, dApps e backends.
Resumo
- Resposta a incidentes Solana é disciplina que separa classe de sintoma (tx falhada, outage RPC, exploit on-chain, deploy ruim, UX de client) de contenção (pause, failover, feature flag) e mitigação prospectiva (redeploy, compensar, comunicar), depois trava aprendizado em monitores e runbooks.
- Por Que Importa: State finalizado do ledger não pode ser revertido; pause ou retry errado pode amplificar perda; RPC multi-provedor e upgrade authority fazem parte do produto, não ops lateral. Um mapa compartilhado impede on-call de adivinhar sob pressão.
- Conceitos-Chave: severidade, incident commander, cadeia de evidências (signature, slot, program id, provedor RPC), simulação, pause switch, upgrade authority, failover multi-provedor, rollback verificável, feature flag, postmortem sem culpa, RCA.
- Quando Usar: Primeira orientação para on-call de produção; escrever runbooks antes da mainnet; triagem durante Sev-1/2; design de revisão pós-incidente; alinhar owners de programa, client e infra em uma linguagem de playbook.
- Limitações / Trade-offs: Runbooks não substituem design de segurança; flags de pause devem ser pré-implantadas; failover multi-provedor tem custo e trade-offs de consistência; cultura sem culpa exige buy-in de liderança, não apenas template markdown.
- Tópicos Relacionados: Depurar transações falhadas, outages RPC e infraestrutura, resposta a incidentes on-chain, rollback e mitigação, checklists de prevenção e postmortems sem culpa com RCA.
Fundamentos
Produtos Solana atravessam state de chain imutável e sistemas off-chain mutáveis.
On-chain: programas, contas, mints, vaults PDA e upgrade authority vivem em cluster sob consenso Agave. Uma vez que transação é finalizada, o ledger não oferece API de "undo". Mitigação é pause, freeze, redeploy, migrar ou compensar.
Off-chain: provedores RPC, indexers, frontends, backends, wallets e tooling de ops decidem o que usuários podem ver e submeter. A maioria dos "outages" que usuários reportam começa aqui.
Um incidente é qualquer degradação inesperada de segurança, controle de fundos, correção ou disponibilidade que precisa de resposta coordenada além de debug normal. Severidade geralmente rastreia fundos de usuário em risco, duração e raio de explosão:
| Sev | Sinal típico | Exemplo |
|---|---|---|
| 1 | Perda ativa de fundos ou pause crítico necessário | Drenagem de exploit, authority comprometida |
| 2 | Caminho principal de produto quebrado, fundos não drenando ativamente | Pico de erros de programa após deploy ruim |
| 3 | Degradação parcial com workaround | Lag RPC de região única, uma instruction falhando |
| 4 | Localizado ou cosmético | Mismatch de explorer, UI não crítica |
Papéis vencem heroísmo. Nomeie incident commander (decide sequência), comms lead (usuários e stakeholders recebem fatos, não especulação) e domain leads (programa, client, infra). Um canal para decisões; uma timeline em UTC com signatures e slots.
Evidências são a cola Solana-específica entre classes de falha. Capture cedo:
- Sintoma visível ao usuário e cluster (mainnet-beta vs outros).
- Signature de transação (se houver), slot e classe de erro.
- Program id e nome de instruction (do IDL ou logs).
- RPC URL / provedor e caminho HTTP vs WebSocket.
- Versão de deploy, feature flags e atividade recente de upgrade authority.
- Se fundos moveram e para quais endereços.
Sem essa cadeia, pessoas debatem anedotas enquanto atacante ou tempestade 429 continua.
As páginas irmãs da seção possuem cada face da máquina:
- Transações falhadas e que não pousam: decode antes de retry.
- RPC e infraestrutura: trate provedores como caminho crítico.
- Exploits on-chain: pause, authority, upgrade sob pressão.
- Rollback e mitigação: redeploy de bytes verificados anteriores e flags de client.
- Prevenção: monitores, drills e checklists.
- Postmortems sem culpa: correções de sistema com owners e datas.
Esta página mantém o loop inteiro em vista.
Mecânica e Interações
Detecção até classificação
Incidentes entram por alertas (velocidade TVL, taxa de erro, slot lag, 429s), reports de usuário, mensagens whitehat ou anomalias de explorer. Primeiro trabalho é classificar, não corrigir:
Sintoma
|
v
Pacote de evidências (sig, slot, programa, RPC, fundos?)
|
+-- Tx / sim / Custom / CU / contas --> caminho tx falhada
+-- 429, lag, drop WS, UI vazia multi-usuário --> caminho RPC
+-- Outflows inesperados, abuso CPI, txs authority --> caminho on-chain
+-- Pico de erro pós-deploy, program id errado --> caminho deploy/client
Transações falhadas deixam logs, output de simulação e códigos de erro Anchor ou nativos. Simule com @solana/kit 7.0.0 (simulateTransaction, logs, unitsConsumed) antes de rebroadcast. Atualize blockhash; mapeie Custom: N para enum do programa; separe erro de usuário de bug de programa de compute budget. Retry cego com mesma mensagem obsoleta multiplica ruído e fees.
Outages RPC e de infraestrutura aparecem como saldos vazios, "account not found", confirmações presas ou desconexões WebSocket em massa. Ações primárias: health-check de provedores (slot lag, genesis hash, error budgets), fail over reads e writes, abrir circuit breakers para retries não cascatearem, e evitar declarar exploit on-chain quando chain está bem e sua borda não.
Incidentes on-chain (exploits, comprometimento de authority, bugs críticos de lógica) exigem caminhos pause pré-construídos, upgrade authority multisig ou fria e preservação de evidências. Transações de drenagem não podem ser revertidas; contenção é parar sangramento, snapshot de endereços e preparar patch verificado ou rotação de authority. Assuma exploração ativa até logs provarem o contrário.
Deploys ruins e mismatches de client ficam entre programa e frontend: env de cluster errado, feature flag ligada para instruction quebrada ou upgrade que passa testes mas falha sob shapes de conta mainnet. Kill-switches de frontend são frequentemente mais rápidos que rollback de programa; ambos podem ser necessários.
Contenção e mitigação (apenas prospectiva)
"Rollback" Solana é metáfora de produto, não rewind de ledger. Alavancas práticas:
| Alavanca | Velocidade | Escopo | Notas |
|---|---|---|---|
| Feature flag / kill switch de client | Rápido | Novos fluxos de usuário | Para novos caminhos ruins |
| Failover RPC multi-provedor | Rápido | Disponibilidade | Não corrige bugs de programa |
| Pause / flag de modo de programa | Médio | Ix mutantes | Deve existir antes da crise |
| Rotação de authority | Médio | Plano de controle | Multisig break-glass |
Redeploy .so verificado anterior | Médio-lento | Lógica de programa | Hash de build verificável |
| Migração de state / compensação | Lento | Saldos, claims | Precisa design e comms |
Ordem de operações sob pressão:
- Segurança: proteger fundos e keys restantes (pause, freeze, authority).
- Estabilidade: restaurar UX verdadeira (failover RPC, desabilitar caminhos UI quebrados).
- Correção: implantar bytes de programa conhecidamente bons ou fix revisado.
- Verdade: comunicar o que aconteceu, o que usuários devem fazer e o que ainda é desconhecido.
- Aprendizado: congelar timeline para RCA; não debater culpa na bridge.
Upgrade authority e admin de pause são features de produção. Se vivem apenas em laptop hot sem runbook, você não tem resposta a incidentes; tem esperança.
Comunicação sob carga
Bridge interna: timestamps UTC, hashes de signature, program ids, decisões e owners. Externa: updates curtos factuais (impacto, status de mitigação, ações do usuário). Não publique teorias de exploit não confirmadas ou private keys em screenshots de "debug". Para Sev-1, planeje resumo voltado ao cliente em janela fixa após contenção (página irmã RCA detalha o template).
Considerações Avançadas e Aplicações
Arquitetura de produto que sobrevive às 3h
Construa para resposta, não apenas happy path:
- Flags de pause e modo verificadas em cada instruction mutante (padrões
GlobalConfigAnchor 0.32.1 e equivalentes nativos). - Upgrade authority em multisig com runbooks break-glass; alerte em qualquer mudança de authority.
- Builds verificáveis para "roll back para v1.2.3" significar hash conhecido, não binário misterioso.
- Design de SLO RPC: endpoints read, write e WebSocket separados; checks sintéticos de pouso; error budgets de provedor em PagerDuty.
- Caminho send de client: simule, defina compute budget e priority fees com cuidado, confirme através de commitment, classifique erros antes de retry.
- Indexers e webhooks para velocidade TVL e CPI anômalo, não apenas refresh de explorer.
Times que entregam apenas feature work sem esses controles eventualmente os inventam durante incidente, com custo máximo.
Matriz de decisão para primeira hora
| Pergunta | Se sim | Playbook primário |
|---|---|---|
| Fundos saindo inesperadamente? | Sev-1 conter | Resposta a incidentes on-chain |
| Muitos usuários falhando em um provedor apenas? | Failover | Outages RPC e infraestrutura |
| Simulação mostra Custom / CU / contas? | Decode | Depurando transações falhadas |
| Taxa de erro pulou logo após deploy? | Mitigar | Rollback e mitigação |
| Caminho instável apenas sob carga? | Fees / pouso / RPC | Páginas tx falhada + RPC |
Execute a matriz em ordem; paralelize apenas após classificação para eng e segurança não se atropelarem.
Fechando o loop
Quando a bridge termina, trabalho não acabou. Postmortem sem culpa separa causa imediata de fatores contribuintes, registra o que foi bem e atribui action items com owners e datas. Checklists de prevenção convertem esses itens em gates Tier-1 de deploy, correções Tier-2 em 30 dias e drills Tier-3 trimestrais (drills de pause, pouso sintético, monitoramento de authority).
Maturidade de resposta a incidentes é mensurável: tempo médio para classificar, tempo médio para pause ou failover, fração de Sev-1s com action items completos e taxa de pass de drill. Versões do stack importam para drills também: re-valide scripts contra Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0 após bumps de toolchain para runbooks não apodrecerem.
Adjacência de segurança e jurídico
Reports whitehat, autoridades, seguradoras e auditores podem precisar do mesmo pacote de evidências que seus engenheiros usam. Preserve logs, signatures e histórico de authority; não "limpe" explorers ou rotacione keys sem registrar o que foi comprometido. Design de segurança de programa (checks de conta, higiene CPI) reduz frequência de incidentes; resposta a incidentes reduz severidade quando design falha. Ambos são necessários.
Equívocos Comuns
- "sendTransaction retornou signature, então usuário está bem." Signature é handle; durabilidade é commitment. Incidentes frequentemente começam com UI otimista que nunca confirmou.
- "Se app está quebrado, programa deve estar explorado." Lag RPC, 429s, cluster errado e flags de frontend produzem pânico idêntico do usuário. Classifique evidências primeiro.
- "Podemos reverter transação mainnet ruim." State finalizado não é revertido. Mitigação é pause, redeploy, migrar ou compensar.
- "Retry com priority fees maiores corrige toda falha." Fees ajudam pouso sob congestionamento; não corrigem erros Custom de programa, contas faltando ou RPC morto.
- "Pause pode ser adicionado após primeiro exploit." Se caminho de instruction não existe on-chain antes da crise, você não pode inventá-lo a tempo.
- "Sem culpa significa sem responsabilidade." Sem culpa significa corrigir sistemas e processo; action items ainda têm owners e prazos.
- "Um provedor RPC premium é suficiente." Pontos únicos de falha viram Sev-2s em dias de manutenção do provedor. Failover e health checks são requisitos de produto.
- "Postmortems são opcionais se já patchamos." Sem RCA e prevenção, mesma classe de falha retorna sob nova lista de signatures.
FAQs
O que é resposta a incidentes de produção Solana em uma frase?
É a prática coordenada de classificar falhas de chain e off-chain, conter dano a fundos e UX com alavancas pré-construídas, mitigar adiante sem rewind de ledger e transformar cada evento em prevenção durável.
Como transação falhada difere de outage?
Transação falhada tem signature ou resultado de simulação e classe de erro de programa ou runtime; outage é frequentemente indisponibilidade multi-usuário causada por RPC, rede ou infraestrutura dependente sem causa raiz única de programa.
O que on-call deve capturar nos primeiros cinco minutos?
Cluster, sintoma, signatures e slots, program id, provedor RPC, se fundos moveram e deploys ou mudanças de authority recentes; depois atribua papéis de commander, eng e comms.
Quando pausar programa versus apenas fail over RPC?
Pause quando fundos ou state crítico estão em risco por lógica on-chain ou exploração; fail over RPC quando evidências apontam saúde de provedor, rate limits ou slot lag com saldos on-chain saudáveis.
Posso fazer rollback de programa Solana como deploy de servidor web?
Você pode redeploy binário verificado anterior no mesmo program id se detém upgrade authority; não pode apagar mudanças de conta finalizadas que já executaram sob versão ruim.
Por que simulação importa durante incidentes?
Simulação revela logs e uso de compute sem gastar fees mainnet em retries cegos, e separa bugs detectáveis em preflight de problemas de pouso e confirmação.
Como setups RPC multi-provedor ajudam incidentes?
Permitem rotear em torno de 429s, falhas regionais e manutenção de vendor único; health checks e circuit breakers impedem retries em cascata que pioram outages.
O que pertence a playbook de exploit on-chain?
Pause pré-implantado, keys admin break-glass ou multisig, procedimento de upgrade authority, captura de evidências para endereços de explorador, templates de comms e caminho para patch verificado sob pressão de auditoria.
Quão cedo devemos escrever postmortem?
Rascunhe timeline enquanto memória está fresca (mesmo dia quando possível); complete RCA sem culpa com action items após contenção e publique fatos voltados ao cliente em SLA Sev-1 fixo.
O que torna postmortem sem culpa?
Explica condições de sistema e processo que tornaram falha provável, sem envergonhar indivíduos, e ainda atribui correções concretas com owners e datas.
Como checklists de prevenção se relacionam a incidentes?
Cada Sev significativo deve deixar monitores, gates de CI ou drills em checklist para próximo release provar que lacuna foi fechada antes de usuários redescobrirem.
Onde feature flags se encaixam?
Flags de client e backend desabilitam caminhos de instruction quebrados mais rápido que upgrades on-chain; pareie com pause on-chain quando fundos ainda podem mover por outros clients.
@solana/kit muda resposta a incidentes?
Kit 7.0.0 melhora RPC tipado, simulação e caminhos send, mas classificação, commitment, failover e pause authority permanecem preocupações operacionais e de design de programa.
Qual toolchain runbooks devem assumir?
Fixe scripts e exemplos em Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0, e re-drill após upgrades.
Onde ir depois desta página?
Use Depurando Transações que Falharam e Outages de RPC e Infraestrutura para os dois caminhos não-exploit mais comuns; abra Resposta a Incidentes On-Chain e Rollback e Mitigação para eventos de risco a fundos; feche o loop com Checklists de Prevenção e Post-Mortems Sem Culpa e RCA.
Relacionado
- Depurando Transações que Falharam - logs, simulação, erros Custom e disciplina de retry segura
- Outages de RPC e Infraestrutura - failover multi-provedor, health checks e tempestades de rate limit
- Resposta a Incidentes On-Chain - pause, lockdown de authority e upgrade sob pressão
- Rollback e Mitigação - redeploy verificável, flags de client e comunicações com usuários
- Checklists de Prevenção - monitores, drills e gates de deploy de Sevs passados
- Post-Mortems Sem Culpa e RCA - timeline, causa raiz e action items com owners
Versões do stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.