Listas de verificación de prevención
Los incidentes se repiten cuando las correcciones permanecen en los registros de chat. Estas listas de verificación convierten los elementos de acción posteriores al análisis en monitores, puertas de control de CI y simulacros trimestrales para que las transacciones fallidas, las interrupciones de RPC y las rutas de explotación se detecten antes de que los usuarios tuiteen sobre ellas.
Cómo usar esta lista de verificación
- Ejecuta el Nivel 1 antes de cualquier promoción de programa o frontend en mainnet.
- Agrega los elementos del Nivel 2 dentro de los 30 días posteriores a cada incidente Sev-1/2.
- Vuelve a ejecutar el Nivel 3 trimestralmente y después de las actualizaciones importantes de Agave o Anchor.
- Registra el resultado (aprobado/fallido) en tu ticket de lanzamiento; bloquea el despliegue en caso de fallos del Nivel 1.
Nivel 1 - Detección y Monitoreo
-
Velocidad de TVL / saldo de la bóveda: Alerta cuando el saldo cae > X% en Y minutos en los PDAs del programa.
- Propietario: Equipo de backend / indexador
- Herramienta: Indexador personalizado o webhook de Helius
-
P95 de aterrizaje de transacciones: Envío sintético cada 5 minutos; alerta si p95 > 30s durante 10 min.
- Propietario: SRE
- Herramienta: Trabajo cron de
@solana/kit+ Grafana
-
Tasa de error del programa: Relación de errores
Customfallidos con el total de txs para tu ID de programa.- Propietario: Ingeniero de guardia
- Herramienta: API de Explorer o filtro Geyser
-
Salud del proveedor de RPC: Retraso de slot, tasa 429, recuento de desconexiones de WS por proveedor.
- Propietario: Infraestructura
- Herramienta:
rpc-health.sh+ PagerDuty
-
Verificación de tarifas prioritarias: Alerta si la oferta de tarifa mediana cae a cero durante ventanas de alto tráfico conocidas.
- Propietario: Equipo de cliente
- Herramienta: Métricas de la aplicación
-
Cambios en la autoridad de actualización: Alerta sobre cualquier
set-upgrade-authoritypara IDs de programas de producción.- Propietario: Seguridad
- Herramienta: Regla de indexador o notificación de Squads
-
Simulacro de indicador de pausa: Prueba trimestral de
set_paused(true)en un clon de devnet en < 5 min.- Propietario: Líder del programa
- Herramienta: Runbook
incident-pause.sh
Nivel 2 - Pruebas y Puertas de CI
-
Regresión LiteSVM / Surfpool: Reproduce txs de exploits conocidos contra cada PR del programa.
- CI:
anchor test+ fixture de LiteSVM 0.6.x
- CI:
-
Puerta de sincronización de IDL: La generación de código del cliente falla si el hash de IDL difiere del programa desplegado en devnet.
- CI: Comparación de hash en GitHub Actions
-
Compilación verificable en el lanzamiento: Hash de
solana-verifypublicado en las notas de lanzamiento.- CI: Artefacto requerido en la etiqueta
-
Simulación de humo: Las 10 principales rutas de usuario se simulan sin errores en devnet antes de la promoción.
- CI: Puerta manual nocturna + pre-mainnet
-
Ruta de actualización multisig: Sin despliegue directo desde laptop a mainnet; solo propuesta de Squads.
- Proceso: Firma de la lista de verificación de lanzamiento
-
Prueba de actualización de blockhash: La prueba de integración del cliente afirma que la reintentos usan un nuevo blockhash.
- CI: Jest/Vitest con RPC simulado
-
Presupuesto de límite de tasa: Prueba de carga de la ruta de lectura al doble del tráfico de lanzamiento esperado contra RPC de staging.
- Herramienta: k6 o locust
Nivel 3 - Runbooks y Cultura
- Definiciones de Sev documentadas: Sev-1 incluye pérdida de fondos; árbol de escalada en Notion/git.
- Enlaces de runbook de guardia: Cada alerta enlaza a una sección de runbook, no a la página de inicio de una wiki.
- Plantilla de post-mortem sin culpa: Almacenada en el repositorio; rotación del facilitador programada.
- Claves de "break-glass": Ubicación, custodios y revisión de caducidad cada 90 días.
- Plantillas de comunicación: Mensajes preescritos de pausa, reversión y resueltos para Discord/X.
- Contactos de terceros: TAM del proveedor de RPC, línea de emergencia del auditor, plataforma de recompensas.
- Registro de simulacros de incidentes: Fecha del último simulacro y brechas archivadas como tickets.
- Macros de soporte al usuario: "Transacción atascada" y "Simulación fallida" con enlaces al explorador.
- Verificación del hash de génesis en el pipeline de despliegue: Bloqueo del clúster incorrecto en CI.
- RPC de respaldo en el paquete del cliente: Variables de entorno para primario/secundario validadas en la compilación.
- SLA de elementos de acción posteriores al incidente: 90% cerrados en 30 días o revisión ejecutiva.
Aplicación de la lista de verificación en orden
- Nivel 1 (1-7): Observabilidad - sin detección, los incidentes son reportados por el usuario.
- Nivel 2 (8-14): Prevención en CI - detecta regresiones antes de mainnet.
- Nivel 3 (15-25): Sistemas humanos - las herramientas fallan sin runbooks practicados.
Preguntas frecuentes
¿Cuántas alertas son demasiadas?
Si el equipo de guardia reconoce < 20% como accionables, ajusta los umbrales. Empieza estricto después de los incidentes, relaja con los datos.
¿Qué transacción sintética se debe ejecutar?
Transferencia mínima o ix de programa no operativo contra RPC de producción con tarifa prioritaria: solo mide el aterrizaje.
¿Importan los monitores de devnet?
Sí, para la pre-promoción; los monitores de mainnet son obligatorios para los fondos de los usuarios.
¿Quién es el propietario de las actualizaciones de la lista de verificación?
El comandante del incidente actualiza dentro de las 48 horas posteriores al post-mortem; el gerente de ingeniería revisa trimestralmente.
¿Debería la lista de verificación bloquear un hotfix?
La pausa/mitigación de Nivel 1 nunca se bloquea; la lista de verificación completa se aplica antes de volver a habilitar el tráfico.
¿Cómo vincular con las métricas DORA?
La tasa de fallos de cambio y el MTTR mejoran cuando los elementos de detección y reversión se aprueban.
¿Cuál es un buen umbral de alerta de TVL?
Comienza con 3-5% en 5 minutos para préstamos; ajusta según el tamaño del protocolo y el ruido.
¿Son aceptables los RPC públicos para sintéticos?
Utiliza el mismo nivel de proveedor que utiliza la producción, o los resultados serán engañosos.
¿Cómo documentar los fallos de los simulacros?
Archiva un ticket por cada paso fallido; un simulacro fallido cuenta como un incidente casi perdido.
¿Cuándo retirar un elemento de la lista de verificación?
Cuando sea reemplazado por automatización con 90 días de historial limpio; documentar en el post-mortem.
Relacionado
- Depuración de transacciones fallidas - decodifica los fallos que las alertas muestran
- Post-Mortems sin Culpa y RCA - fuente de nuevos elementos
- Métricas DORA para Web3 - mide la mejora
Versiones de la pila: Esta página se escribió 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 y LiteSVM 0.6.x.