Respuesta a Incidentes en Profundidad
Los productos de producción de Solana fallan de maneras que parecen similares a los usuarios (carteras atascadas, saldos vacíos, envíos fallidos) pero que requieren movimientos iniciales opuestos por parte de los ingenieros.
Un proveedor de RPC con límite de tasa no es una explotación de bóveda. Un error de programa Custom después de una actualización errónea no es una expiración de bloque. Tratar cada panel rojo como "reintentar con más fuerza" quema minutos y, a veces, fondos.
Esta página es el paraguas de la sección: cómo clasificar incidentes, recopilar evidencia, contener daños, mitigar sin reescribir la historia y cerrar el ciclo con prevención y RCA sin culpa para programas, dApps y backends de Solana.
Resumen
- La respuesta a incidentes de Solana es una disciplina que separa la clase de síntoma (transacción fallida, interrupción de RPC, exploit en cadena, despliegue erróneo, UX del cliente) de la contención (pausa, failover, feature flag) y la mitigación solo hacia adelante (re-despliegue, compensación, comunicación), y luego bloquea el aprendizaje en monitores y runbooks.
- Por qué Importa: El estado finalizado del ledger no se puede revertir; una pausa incorrecta o un reintento incorrecto pueden amplificar la pérdida; RPC multi-proveedor y la autoridad de actualización son parte del producto, no operaciones secundarias. Un mapa compartido evita que el personal de guardia adivine bajo presión.
- Conceptos Clave: severidad, comandante de incidente, cadena de evidencia (firma, slot, id de programa, proveedor RPC), simulación, interruptor de pausa, autoridad de actualización, failover multi-proveedor, rollback verificable, feature flag, postmortem sin culpa, RCA.
- Cuándo Usar: Primera orientación para el personal de guardia de producción; redacción de runbooks antes de mainnet; triaje durante Sev-1/2; diseño de revisión post-incidente; alineación de propietarios de programas, clientes e infraestructura en un lenguaje de playbook común.
- Limitaciones / Compensaciones: Los runbooks no reemplazan el diseño de seguridad; las banderas de pausa deben ser pre-desplegadas; el failover multi-proveedor tiene compensaciones de costo y consistencia; la cultura sin culpa requiere la aprobación del liderazgo, no solo una plantilla de markdown.
- Temas Relacionados: Depuración de transacciones fallidas, interrupciones de RPC e infraestructura, respuesta a incidentes en cadena, rollback y mitigación, listas de verificación de prevención, y postmortems sin culpa con RCA.
Fundamentos
Los productos de Solana se encuentran entre el estado inmutable de la cadena y los sistemas mutables fuera de la cadena.
En cadena: programas, cuentas, mentas, PDAs de bóveda y autoridad de actualización viven en un clúster bajo el consenso Agave. Una vez que una transacción se finaliza, el ledger no ofrece una API de "deshacer". La mitigación es pausar, congelar, re-desplegar, migrar o compensar.
Fuera de cadena: proveedores de RPC, indexadores, frontends, backends, billeteras y herramientas de operaciones deciden qué pueden ver y enviar los usuarios. La mayoría de las "interrupciones" que reportan los usuarios comienzan aquí.
Un incidente es cualquier degradación inesperada de la seguridad, control de fondos, corrección o disponibilidad que requiere una respuesta coordinada más allá de la depuración normal. La severidad generalmente rastrea los fondos de los usuarios en riesgo, la duración y el radio de explosión:
| Sev | Señal Típica | Ejemplo |
|---|---|---|
| 1 | Pérdida activa de fondos o pausa crítica necesaria | Drenaje por exploit, autoridad comprometida |
| 2 | Ruta de producto principal rota, fondos no drenando activamente | Pico de errores de programa por despliegue erróneo |
| 3 | Degradación parcial con solución alternativa | Latencia de RPC en una sola región, una instrucción fallando |
| 4 | Localizado o cosmético | Desajuste del explorador, UI no crítica |
Los roles superan a los héroes. Nombrar un comandante de incidente (decide la secuencia), un líder de comunicaciones (usuarios y partes interesadas reciben hechos, no especulaciones) y líderes de dominio (programa, cliente, infraestructura). Un canal para decisiones; una línea de tiempo en UTC con firmas y slots.
La evidencia es el pegamento específico de Solana entre las clases de fallas. Capturar temprano:
- Síntoma visible para el usuario y clúster (mainnet-beta vs otros).
- Firma de la transacción (si la hay), slot y clase de error.
- ID del programa y nombre de la instrucción (de IDL o logs).
- URL/proveedor RPC y ruta HTTP vs WebSocket.
- Versión de despliegue, feature flags y actividad reciente de la autoridad de actualización.
- Si los fondos se movieron y a qué direcciones.
Sin esa cadena, la gente discute anécdotas mientras el atacante o la tormenta 429 continúan.
Las páginas hermanas de la sección cada una poseen una cara de la máquina:
- Transacciones fallidas y no aterrizadas: decodificar antes de reintentar.
- RPC e infraestructura: tratar a los proveedores como ruta crítica.
- Exploits en cadena: pausa, autoridad, actualización bajo fuego.
- Rollback y mitigación: re-despliegue de bytes verificados anteriores y flags de cliente.
- Prevención: monitores, simulacros y listas de verificación.
- Postmortems sin culpa: correcciones de sistemas con propietarios y fechas.
Esta página mantiene todo el ciclo a la vista.
Mecánicas e Interacciones
Detección a clasificación
Los incidentes entran a través de alertas (velocidad de TVL, tasa de error, latencia de slot, 429s), informes de usuarios, mensajes de whitehat o anomalías del explorador. El primer trabajo es clasificar, no arreglar:
Síntoma
|
v
Paquete de evidencia (firma, slot, programa, RPC, ¿fondos?)
|
+-- Tx / sim / Custom / CU / cuentas --> ruta de tx fallida
+-- 429, latencia, caída WS, UI en blanco multi-usuario --> ruta RPC
+-- Flujos de salida inesperados, abuso de CPI, tx de autoridad --> ruta en cadena
+-- Pico de error post-despliegue, id de programa incorrecto --> ruta de despliegue/cliente
Las transacciones fallidas dejan logs, salida de simulación y códigos de error nativos o de Anchor. Simular con @solana/kit 7.0.0 (simulateTransaction, logs, unitsConsumed) antes de retransmitir. Actualizar el blockhash; mapear Custom: N al enum del programa; separar el error del usuario del bug del programa del presupuesto de cómputo. Reintentar ciegamente con el mismo mensaje obsoleto multiplica el ruido y las tarifas.
Las interrupciones de RPC e infraestructura se presentan como saldos vacíos, "cuenta no encontrada", confirmaciones atascadas o desconexiones masivas de WebSocket. Acciones primarias: verificar el estado de los proveedores (latencia de slot, hash de génesis, presupuestos de error), hacer failover de lecturas y escrituras, abrir disyuntores para que los reintentos no se cascada, y evitar declarar un exploit en cadena cuando la cadena está bien y tu borde no lo está.
Los incidentes en cadena (exploits, compromiso de autoridad, bugs críticos de lógica) exigen pausas pre-construidas, multisig o autoridad de actualización en frío, y preservación de evidencia. Las transacciones de drenaje no se pueden revertir; la contención es detener la hemorragia, tomar una instantánea de las direcciones y preparar un parche verificado o una rotación de autoridad. Asumir explotación activa hasta que los logs demuestren lo contrario.
Los malos despliegues y desajustes de cliente se sitúan entre el programa y el frontend: entorno de clúster incorrecto, feature flag activado para una instrucción rota, o actualización que pasa las pruebas pero falla bajo las formas de cuenta de mainnet. Los interruptores de apagado del frontend son a menudo más rápidos que el rollback del programa; ambos pueden ser necesarios.
Contención y mitigación (solo hacia adelante)
El "rollback" de Solana es una metáfora de producto, no una reversión del ledger. Palancas prácticas:
| Palanca | Velocidad | Alcance | Notas |
|---|---|---|---|
| Feature flag / kill switch del cliente | Rápida | Nuevos flujos de usuario | Detiene nuevos caminos erróneos |
| Failover RPC multi-proveedor | Rápida | Disponibilidad | No soluciona bugs de programa |
| Pausa de programa / flag de modo | Media | Instrucciones mutantes | Debe existir antes de la crisis |
| Rotación de autoridad | Media | Plano de control | Runbooks de "romper cristal" |
| Re-despliegue de binarios verificados anteriores | Medio-lento | Lógica de programa | Hash de compilación verificable |
| Migración de estado / compensación | Lenta | Saldos, reclamos | Requiere diseño y comunicaciones |
Orden de operaciones bajo presión:
- Seguridad: proteger fondos y claves restantes (pausa, congelación, autoridad).
- Estabilidad: restaurar UX veraz (failover RPC, deshabilitar rutas de UI rotas).
- Corrección: desplegar bytes de programa conocidos como buenos o una corrección revisada.
- Verdad: comunicar qué sucedió, qué deben hacer los usuarios y qué sigue siendo desconocido.
- Aprendizaje: congelar la línea de tiempo para RCA; no debatir culpas en el puente.
La autoridad de actualización y la administración de pausa son características de producción. Si solo viven en una laptop caliente sin runbook, no tienes respuesta a incidentes; tienes esperanza.
Comunicación bajo carga
Puente interno: marcas de tiempo UTC, hashes de firma, IDs de programa, decisiones y propietarios. Externo: actualizaciones fácticas cortas (impacto, estado de mitigación, acciones del usuario). No publiques teorías de exploit no confirmadas ni claves privadas en capturas de pantalla de "depuración". Para Sev-1, planifica un resumen para el cliente dentro de una ventana fija después de la contención (la página RCA hermana detalla la plantilla).
Consideraciones Avanzadas y Aplicaciones
Arquitectura de producto que sobrevive a las 3 a.m.
Construye para la respuesta, no solo para el camino feliz:
- Pausas y flags de modo verificados en cada instrucción mutante (patrones
GlobalConfigde Anchor 0.32.1 y equivalentes nativos). - Autoridad de actualización en multisig con runbooks de "romper cristal"; alerta ante cualquier cambio de autoridad.
- Compilaciones verificables para que "volver a v1.2.3" signifique un hash conocido, no un binario misterioso.
- Diseño de SLO de RPC: puntos finales separados de lectura, escritura y WebSocket; verificaciones sintéticas de aterrizaje; presupuestos de error del proveedor en PagerDuty.
- Ruta de envío del cliente: simular, establecer el presupuesto de cómputo y las tarifas de prioridad cuidadosamente, confirmar a través del compromiso, clasificar errores antes de reintentar.
- Indexadores y webhooks para velocidad de TVL y CPI anómalos, no solo para refrescar el explorador.
Los equipos que solo envían trabajo de funciones sin estos controles eventualmente los inventan durante un incidente, al máximo costo.
Matriz de decisión para la primera hora
| Pregunta | Si sí | Playbook principal |
|---|---|---|
| ¿Se están yendo fondos inesperadamente? | Contener Sev-1 | Respuesta a incidentes en cadena |
| ¿Muchos usuarios fallan solo en un proveedor? | Failover | Interrupciones de RPC e infraestructura |
| ¿La simulación muestra Custom / CU / cuentas? | Decodificar | Depuración de transacciones fallidas |
| ¿La tasa de error aumentó justo después del despliegue? | Mitigar | Rollback y mitigación |
| ¿La ruta es inestable solo bajo carga? | Tarifas / aterrizaje / RPC | Páginas de transacciones fallidas + RPC |
Ejecuta la matriz en orden; paraleliza solo después de la clasificación para que ingeniería y seguridad no se pisoteen.
Cerrando el ciclo
Cuando el puente termina, el trabajo no ha concluido. Un postmortem sin culpa separa la causa próxima de los factores contribuyentes, registra lo que salió bien y asigna elementos de acción con propietarios y fechas de vencimiento. Las listas de verificación de prevención convierten esos elementos en puertas de despliegue de Nivel 1, correcciones de 30 días de Nivel 2 y simulacros trimestrales de Nivel 3 (simulacros de pausa, aterrizaje sintético, monitoreo de autoridad).
La madurez de la respuesta a incidentes es medible: tiempo medio para clasificar, tiempo medio para pausar o hacer failover, fracción de Sev-1 con elementos de acción completados, y tasa de aprobación de simulacros. Las versiones de stack importan para los simulacros también: revalidar scripts contra Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0 después de las actualizaciones de la cadena de herramientas para que los runbooks no se deterioren.
Adyacencia de seguridad y legal
Los informes de whitehat, las fuerzas del orden, las aseguradoras y los auditores pueden necesitar el mismo paquete de evidencia que usan tus ingenieros. Conserva logs, firmas e historial de autoridad; no "limpies" exploradores ni rotas claves sin registrar qué se comprometió. El diseño de seguridad del programa (verificaciones de cuenta, higiene de CPI) reduce la frecuencia de incidentes; la respuesta a incidentes reduce la severidad cuando el diseño falla. Ambos son necesarios.
Conceptos erróneos comunes
- "sendTransaction devolvió una firma, así que el usuario está bien." Una firma es un identificador; la durabilidad es el compromiso. Los incidentes a menudo comienzan con una UI optimista que nunca se confirmó.
- "Si la aplicación está rota, el programa debe haber sido explotado." La latencia de RPC, los 429, el clúster incorrecto y las flags del frontend producen un pánico de usuario idéntico. Clasifica la evidencia primero.
- "Podemos revertir una transacción errónea de mainnet." El estado finalizado no se revierte. La mitigación es pausar, re-desplegar, migrar o compensar.
- "Reintentar con tarifas de prioridad más altas soluciona todas las fallas." Las tarifas ayudan a aterrizar bajo congestión; no solucionan errores de programa Custom, cuentas faltantes o RPC muertas.
- "La pausa se puede agregar después del primer exploit." Si la ruta de instrucción no existe en cadena antes de la crisis, no puedes inventarla a tiempo.
- "Sin culpa significa sin responsabilidad." Sin culpa significa arreglar sistemas y procesos; los elementos de acción todavía tienen propietarios y plazos.
- "Un solo proveedor RPC premium es suficiente." Los puntos únicos de falla se convierten en Sev-2 en días de mantenimiento del proveedor. El failover y las verificaciones de estado son requisitos del producto.
- "Los postmortems son opcionales si ya hemos parcheado." Sin RCA y prevención, la misma clase de falla regresa bajo una nueva lista de firmas.
Preguntas Frecuentes
¿Qué es la respuesta a incidentes de producción de Solana en una oración?
Es la práctica coordinada de clasificar fallas en cadena y fuera de cadena, contener daños de fondos y UX con palancas preconstruidas, mitigar hacia adelante sin revertir el ledger, y convertir cada evento en prevención duradera.
¿Cómo se diferencia una transacción fallida de una interrupción?
Una transacción fallida tiene una firma o resultado de simulación y una clase de error de programa o tiempo de ejecución; una interrupción es a menudo una indisponibilidad para múltiples usuarios causada por RPC, red o infraestructura dependiente sin una única causa raíz del programa.
¿Qué debe capturar el personal de guardia en los primeros cinco minutos?
Clúster, síntoma, firmas y slots, ID de programa, proveedor RPC, si se movieron fondos, y despliegues recientes o cambios de autoridad; luego asignar roles de comandante, ingeniería y comunicaciones.
¿Cuándo debo pausar el programa y cuándo solo hacer failover de RPC?
Pausa cuando los fondos o el estado crítico están en riesgo por lógica en cadena o explotación; haz failover de RPC cuando la evidencia apunte a la salud del proveedor, límites de tasa o latencia de slot con saldos en cadena saludables.
¿Puedo revertir un programa de Solana como un despliegue de servidor web?
Puedes re-desplegar un binario verificado anterior al mismo ID de programa si posees la autoridad de actualización; no puedes borrar cambios de cuenta finalizados que ya se ejecutaron bajo la versión errónea.
¿Por qué es importante la simulación durante los incidentes?
La simulación expone logs y uso de cómputo sin gastar tarifas de mainnet en reintentos ciegos, y separa los bugs detectables por preflight de los problemas de aterrizaje y confirmación.
¿Cómo ayudan las configuraciones de RPC multi-proveedor en los incidentes?
Permiten enrutar alrededor de 429s, fallas regionales y mantenimiento de un solo proveedor; las verificaciones de estado y los disyuntores evitan reintentos en cascada que empeoran las interrupciones.
¿Qué debe incluir un playbook de exploit en cadena?
Pausa pre-desplegada, claves de administración de "romper cristal" o multisig, procedimiento de autoridad de actualización, captura de evidencia para direcciones de explotadores, plantillas de comunicación y una ruta a un parche verificado bajo presión de auditoría.
¿Cuán pronto deberíamos escribir un postmortem?
Redacta la línea de tiempo mientras la memoria esté fresca (el mismo día cuando sea posible); completa la RCA sin culpa con elementos de acción después de la contención, y publica hechos para el cliente en un SLA fijo de Sev-1.
¿Qué hace que un postmortem sea sin culpa?
Explica las condiciones del sistema y del proceso que hicieron probable la falla, sin avergonzar a los individuos, y aún así asigna correcciones concretas con propietarios y fechas.
¿Cómo se relacionan las listas de verificación de prevención con los incidentes?
Cada Sev significativo debería dejar monitores, puertas de CI o simulacros en una lista de verificación para que el próximo lanzamiento demuestre que la brecha está cerrada antes de que los usuarios la redescubran.
¿Dónde encajan los feature flags?
Las flags del cliente y del backend deshabilitan rutas de instrucción rotas más rápido que las actualizaciones en cadena; emparejalas con una pausa en cadena cuando los fondos aún puedan moverse a través de otros clientes.
¿Cambia @solana/kit la respuesta a incidentes?
Kit 7.0.0 mejora la tipificación de RPC, la simulación y las rutas de envío, pero la clasificación, el compromiso, el failover y la autoridad de pausa siguen siendo preocupaciones operacionales y de diseño de programas.
¿Qué toolchain deben asumir los runbooks?
Fija scripts y ejemplos a Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0, y vuelve a simular después de las actualizaciones.
¿A dónde debo ir después de esta página?
Usa Depuración de Transacciones Fallidas y Interrupciones de RPC e Infraestructura para las dos rutas no de exploit más comunes; abre Respuesta a Incidentes en Cadena y Rollback y Mitigación para eventos de riesgo de fondos; cierra el ciclo con Listas de Verificación de Prevención y Postmortems Sin Culpa y RCA.
Relacionados
- Depuración de Transacciones Fallidas - logs, simulación, errores Custom y disciplina de reintento seguro
- Interrupciones de RPC e Infraestructura - failover multi-proveedor, verificaciones de estado y tormentas de límites de tasa
- Respuesta a Incidentes en Cadena - pausa, bloqueo de autoridad y actualización bajo fuego
- Rollback y Mitigación - re-despliegue verificable, flags de cliente y comunicaciones al usuario
- Listas de Verificación de Prevención - monitores, simulacros y puertas de despliegue de Sevs pasados
- Postmortems Sin Culpa y RCA - línea de tiempo, causa raíz y elementos de acción asignados
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0.