Resposta a Incidentes em Detalhe

Produtos Solana em produção falham de maneiras que parecem semelhantes para os usuários (carteiras travadas, saldos zerados, envios falhados), mas exigem ações iniciais opostas dos engenheiros.

Um provedor de RPC com limite de taxa não é um exploit de cofre. Um erro Custom de programa após uma atualização incorreta não é uma expiração de blockhash. Tratar cada dashboard vermelho como "tentar mais forte" consome minutos e, às vezes, fundos.

Esta página é o guarda-chuva da seção: como classificar incidentes, coletar evidências, conter danos, mitigar sem reescrever o histórico e fechar o ciclo com prevenção e Análise de Causa Raiz (RCA) sem culpa para programas Solana, dApps e backends.

Resumo

• A resposta a incidentes Solana é uma disciplina que separa a classe de sintoma (transação falhada, interrupção de RPC, exploit on-chain, deploy incorreto, UX do cliente) da contenção (pausar, failover, feature flag) e mitigação prospectiva (reimplantar, compensar, comunicar), e então consolida o aprendizado em monitores e runbooks.
• Insight: O estado finalizado do ledger não pode ser revertido; uma pausa incorreta ou uma tentativa de reexecução errada podem amplificar perdas; RPC multi-provedor e autoridade de atualização são parte do produto, não operações secundárias. Um mapa compartilhado impede que a equipe de plantão adivinhe sob pressão.
• Conceitos-Chave: severidade, comandante de incidente, cadeia de evidências (assinatura, slot, ID do programa, provedor RPC), simulação, chave de pausa, autoridade de atualização, failover multi-provedor, rollback verificável, feature flag, postmortem sem culpa, RCA.
• Quando Usar: Primeira orientação para plantão de produção; escrita de runbooks antes da mainnet; triagem durante Sev-1/2; design de revisão pós-incidente; alinhamento de proprietários de programa, cliente e infraestrutura em uma linguagem de playbook unificada.
• Limitações/Trade-offs: Runbooks não substituem o design de segurança; flags de pausa devem ser pré-implantadas; failover multi-provedor tem custos e trade-offs de consistência; cultura sem culpa exige adesão da liderança, não apenas um template markdown.
• Tópicos Relacionados: Depuração de transações falhadas, interrupções de 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 abrangem estado imutável da chain e sistemas mutáveis off-chain.

On-chain: programas, contas, mints, PDAs de cofres e autoridade de atualização residem em um cluster sob o consenso Agave. Uma vez que uma transação é finalizada, o ledger não oferece uma API de "desfazer". A mitigação envolve pausar, congelar, reimplantar, migrar ou compensar.

Off-chain: provedores RPC, indexadores, frontends, backends, carteiras e ferramentas de operação decidem o que os usuários podem ver e submeter. A maioria das "interrupções" que os usuários relatam começa aqui.

Um incidente é qualquer degradação inesperada de segurança, controle de fundos, correção ou disponibilidade que requer uma resposta coordenada além da depuração normal. A severidade geralmente acompanha os fundos do usuário em risco, a duração e o raio de impacto:

Papéis superam heroísmo. Nomeie um comandante de incidente (decide a sequência), um líder de comunicação (usuários e stakeholders recebem fatos, não especulação) e líderes de domínio (programa, cliente, infraestrutura). Um canal para decisões; uma linha do tempo em UTC com assinaturas e slots.

Evidências são o elo específico do Solana entre as classes de falha. Capture cedo:

1. Sintoma visível ao usuário e cluster (mainnet-beta vs outros).
2. Assinatura da transação (se houver), slot e classe de erro.
3. ID do programa e nome da instrução (do IDL ou logs).
4. URL/provedor RPC e caminho HTTP vs WebSocket.
5. Versão do deploy, flags de recursos e atividade recente da autoridade de atualização.
6. Se os fundos se moveram e para quais endereços.

Sem essa cadeia, as pessoas debatem anedotas enquanto o atacante ou a tempestade de 429 continuam.

As páginas irmãs da seção cobrem cada aspecto da máquina:

• Transações falhadas e que não chegam ao destino: decodifique antes de tentar novamente.
• RPC e infraestrutura: trate os provedores como caminho crítico.
• Exploits on-chain: pausa, autoridade, atualização sob pressão.
• Rollback e mitigação: reimplantar bytes verificados anteriores e flags de cliente.
• Prevenção: monitores, simulações e checklists.
• Postmortems sem culpa: correções de sistema com proprietários e datas.

Esta página mantém todo o ciclo em vista.

Mecânicas e Interações

Detecção à classificação

Incidentes entram por meio de alertas (velocidade de TVL, taxa de erro, latência de slot, 429s), relatórios de usuários, mensagens de whitehat ou anomalias no explorador. O primeiro trabalho é classificar, não corrigir:

  Sintoma
     |
     v
  Pacote de evidências (sig, slot, programa, RPC, fundos?)
     |
     +-- Tx / sim / Custom / CU / contas  --> caminho de tx falhada
     +-- 429, latência, desconexão WS, UI em branco para múltiplos usuários --> caminho RPC
     +-- Saídas inesperadas, abuso de CPI, transações de autoridade --> caminho on-chain
     +-- Pico de erro pós-deploy, ID de programa incorreto --> caminho de deploy/cliente

Transações falhadas deixam logs, saída de simulação e códigos de erro Anchor ou nativos. Simule com @solana/kit 7.0.0 (simulateTransaction, logs, unitsConsumed) antes de reenviar. Atualize o blockhash; mapeie Custom: N para o enum do programa; separe o erro do usuário do bug do programa e do limite de computação. Tentar novamente cegamente com a mesma mensagem desatualizada multiplica o ruído e as taxas.

Interrupções de RPC e infraestrutura se manifestam como saldos zerados, "conta não encontrada", confirmações travadas ou desconexões em massa do WebSocket. Ações primárias: verificar a saúde dos provedores (latência de slot, hash de genesis, orçamentos de erro), failover de leituras e escritas, abrir disjuntores para que as novas tentativas não causem cascata, e evitar declarar um exploit on-chain quando a chain está bem e sua borda não está.

Incidentes on-chain (exploits, comprometimento de autoridade, bugs críticos de lógica) exigem caminhos de pausa pré-construídos, autoridade de atualização multisig ou fria e preservação de evidências. Transações de drenagem não podem ser revertidas; a contenção é parar o sangramento, tirar um snapshot dos endereços e preparar um patch verificado ou rotação de autoridade. Assuma exploração ativa até que os logs provem o contrário.

Deploys incorretos e incompatibilidades de cliente ficam entre o programa e o frontend: ambiente de cluster errado, feature flag ativada para uma instrução quebrada, ou uma atualização que passa nos testes, mas falha sob os formatos de conta da mainnet. Kill switches de frontend são frequentemente mais rápidos que o rollback do programa; ambos podem ser necessários.

Contenção e mitigação (apenas prospectiva)

"Rollback" no Solana é uma metáfora de produto, não um retrocesso do ledger. Alavancas práticas:

Ordem das operações sob pressão:

1. Segurança: proteger fundos e chaves restantes (pausar, congelar, autoridade).
2. Estabilidade: restaurar UX verdadeira (failover RPC, desativar caminhos de UI quebrados).
3. Correção: implantar bytes de programa conhecidamente bons ou uma correção revisada.
4. Verdade: comunicar o que aconteceu, o que os usuários devem fazer e o que ainda é desconhecido.
5. Aprendizado: congelar a linha do tempo para RCA; não debater culpa na comunicação interna.

A autoridade de atualização e a administração da pausa são funcionalidades de produção. Se elas residem apenas em um laptop quente sem um runbook, você não tem resposta a incidentes; você tem esperança.

Comunicação sob carga

Canal interno: timestamps UTC, hashes de assinatura, IDs de programa, decisões e proprietários. Externo: atualizações factuais curtas (impacto, status da mitigação, ações do usuário). Não publique teorias de exploit não confirmadas ou chaves privadas em capturas de tela de "debug". Para Sev-1, planeje um resumo voltado ao cliente dentro de uma janela fixa após a contenção (a página irmã de RCA detalha o template).

Considerações Avançadas e Aplicações

Arquitetura de produto que sobrevive às 3 da manhã

Construa para resposta, não apenas para o caminho feliz:

• Flags de pausa e modo verificadas em cada instrução mutante (padrões GlobalConfig do Anchor 0.32.1 e equivalentes nativos).
• Autoridade de atualização em multisig com runbooks de emergência; alerte sobre qualquer mudança de autoridade.
• Builds verificáveis para que "reverter para v1.2.3" signifique um hash conhecido, não um binário misterioso.
• Design de SLO RPC: endpoints de leitura, escrita e WebSocket separados; verificações sintéticas de pouso; orçamentos de erro do provedor no PagerDuty.
• Caminho de envio do cliente: simule, defina o orçamento de computação e as taxas de prioridade criteriosamente, confirme através do commit, classifique os erros antes de tentar novamente.
• Indexadores e webhooks para velocidade de TVL e CPI anômalo, não apenas atualização do explorador.

Equipes que entregam apenas trabalho de funcionalidade sem esses controles eventualmente os inventam durante um incidente, com custo máximo.

Matriz de decisão para a primeira hora

Execute a matriz em ordem; paralelize apenas após a classificação para que engenharia e segurança não se atrapalhem.

Fechando o ciclo

Quando o canal de comunicação interno termina, o trabalho não acabou. Um postmortem sem culpa separa a causa imediata dos fatores contribuintes, registra o que funcionou bem e atribui itens de ação com proprietários e prazos. Checklists de prevenção convertem esses itens em portões de deploy de Nível 1, correções de Nível 2 em 30 dias e simulações de Nível 3 trimestrais (simulações de pausa, pouso sintético, monitoramento de autoridade).

A maturidade da resposta a incidentes é mensurável: tempo médio para classificar, tempo médio para pausar ou fazer failover, fração de Sev-1s com itens de ação concluídos e taxa de aprovação de simulações. As versões do stack também importam para as simulações: revalide 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 atualizações da toolchain para que os runbooks não se deteriorem.

Adjacência de segurança e jurídica

Relatórios de whitehat, autoridades policiais, seguradoras e auditores podem precisar do mesmo pacote de evidências que seus engenheiros usam. Preserve logs, assinaturas e histórico de autoridade; não "limpe" exploradores ou rotacione chaves sem registrar o que foi comprometido. O design de segurança do programa (verificações de conta, higiene de CPI) reduz a frequência de incidentes; a resposta a incidentes reduz a severidade quando o design falha. Ambos são necessários.

Equívocos Comuns

• "sendTransaction retornou uma assinatura, então o usuário está bem." Uma assinatura é um identificador; a durabilidade é o commit. Incidentes frequentemente começam com uma UI otimista que nunca confirmou.
• "Se o aplicativo está quebrado, o programa deve ter sido explorado." Latência de RPC, 429s, cluster errado e flags de frontend produzem pânico idêntico no usuário. Classifique as evidências primeiro.
• "Podemos reverter uma transação incorreta na mainnet." O estado finalizado não é revertido. A mitigação é pausar, reimplantar, migrar ou compensar.
• "Tentar novamente com taxas de prioridade mais altas corrige todas as falhas." Taxas ajudam no pouso sob congestionamento; elas não corrigem erros de programa Custom, contas ausentes ou RPC inativo.
• "A pausa pode ser adicionada após o primeiro exploit." Se o caminho da instrução não existir on-chain antes da crise, você não pode inventá-lo a tempo.
• "Sem culpa significa sem responsabilidade." Sem culpa significa corrigir sistemas e processos; os itens de ação ainda têm proprietários e prazos.
• "Um provedor RPC premium é suficiente." Pontos únicos de falha se tornam Sev-2s em dias de manutenção do provedor. Failover e verificações de saúde são requisitos do produto.
• "Postmortems são opcionais se já corrigimos." Sem RCA e prevenção, a mesma classe de falha retorna sob uma nova lista de assinaturas.

FAQs