Mejores prácticas de solución de problemas en producción
Un resumen condensado de las 25 mejores prácticas más importantes extraídas de cada página en esta sección. Runbooks almacenados junto al código, no en búsquedas de Slack.
//
Busca en todas las páginas de la documentación
Un resumen condensado de las 25 mejores prácticas más importantes extraídas de cada página en esta sección. Runbooks almacenados junto al código, no en búsquedas de Slack.
Comandante de Incidentes Único: Un IC designado decide la gravedad, la contención y la reversión - los hilos de Slack paralelos sin IC desperdician los primeros 15 minutos.
Contención antes de RCA: Pausa el despliegue en tienda, activa los interruptores de corte, y comienza la reversión OTA en T+0 - el análisis de causa raíz se ejecuta en paralelo, no primero.
Gravedad por impacto en usuarios: SEV1/SEV2 se vinculan a la ruta de ingresos y % de usuarios afectados - no por volumen de alertas o ansiedad ejecutiva.
Etiqueta cada señal con identidad de versión: Nativa version+build, OTA updateId, channel, y runtimeVersion - consulta Mejores prácticas de observabilidad.
Canales de comunicación separados: Canal de incidentes de ingeniería vs canal de comunicación curado - las macros de soporte deben coincidir con el texto de la página de estado.
Checklist de primeros 15 minutos: IC, confirmación de alcance, palancas de contención, enlaces del panel de control, escriba asignado - Conceptos básicos de incidentes móviles.
Agrupa antes de leer stacks: Ordena Sentry por huella digital y dist - los 3 clústeres principales generalmente explican >90% del pico.
Bisecciona OTA vs nativo: Bloqueos en un dist → OTA; todos los dist en una release → binario nativo; todas las versiones → backend.
Los stacks simbolicados son obligatorios: Los fotogramas Hermes no simbolicados bloquean el triaje - source maps en cada compilación de producción de EAS.
Registra la id del grupo OTA conocida como buena: Cada ticket de publicación de producción almacena el anclaje de reversión - Mejores prácticas de actualizaciones OTA.
Objetivo de reversión OTA en menos de 15 minutos: Decisión para el jefe de canal verificado - practica trimestralmente en el canal de preview.
Verifica la reversión de tres formas: eas channel:view, dispositivo Updates.updateId, migración de Sentry dist durante 60 minutos.
OTA no puede corregir bloqueos nativos: SIGABRT y módulos nativos faltantes necesitan eas build - no agotes la ventana de reversión en la palanca JS.
Banderas de funcionalidad antes de la reversión del bundle: Errores de lógica aislados - interruptor de corte primero; defectos en todo el bundle - reversión de canal.
Pausa el despliegue por fases/etapas temprano: La contención del despliegue de tienda es de minutos - Lanzamiento por fases y reversión.
Disciplina de la sala de guerra de compilación: Lee la fase del log de EAS primero - credenciales, prebuild, compilación, firma - una hipótesis por reconstrucción.
Recordatorios de calendario de credenciales: La expiración del certificado de distribución de Apple y la clave de carga de Play causan SEV2 en la semana de lanzamiento - propietario nombrado requerido.
Delisting de tienda es SEV1: Legal y ejecutivo en la primera hora - ingeniería es dueña de la cronología técnica, no del correo de política externa.
Las comunicaciones ejecutivas usan rangos: ETA de envío binario es propiedad de ingeniería; la duración de la revisión de tienda es un rango - nunca prometas revisión a las 5pm.
El escriba captura la cronología UTC: Las decisiones con marcas de tiempo superan la memoria post-incidente - captura el mismo día antes de que el equipo se disperse.
Post-mortem en 5 días hábiles: SEV1/SEV2 requieren RCA de múltiples capas - JS, nativo, OTA, backend, tienda - Plantilla de Post-Mortem.
Elementos de acción con verificación: Propietario, fecha de vencimiento y métrica que prueba la solución - máximo 5-7 elementos o la propiedad se diluye.
Actualiza runbooks en el repositorio después de incidentes: Añade a las páginas de solución de problemas y docs/incidents/ - no a un cementerio de Google Docs.
Define disparadores de reversión antes del lanzamiento: Libre de bloqueos -2% abs, pago -1% abs - alineado con SLOs para aplicaciones móviles.
Runbooks junto al código en el control de versiones: site/reactnative/troubleshooting/ y docs/ota-rollback-card.md viajan con las ramas - los anclajes de Slack se pudren.
Conceptos básicos de incidentes móviles para IC y primeros 15 minutos. Si hay pico de bloqueos: Triaje de pico de bloqueos. Si se confirma OTA incorrecta: Reversión de emergencia OTA.
Runbook de reversión documenta la mecánica de OTA y los disparadores. Las páginas de solución de problemas añaden comandos de incidente, bisección bajo presión, salas de guerra de tienda/compilación y post-mortem - la capa humana alrededor de los comandos.
Sí - ejecuta ejercicios de reversión OTA y triaje de bloqueos en preview antes de confiar en producción. Los fallos de preview son SEV3; los fallos de producción son SEV2+.
Sentry con release + dist, seguimiento de sesiones, source maps, y logging de sesión-inicio de updateId - triaje viable mínimo por Sentry para React Native.
Oncall móvil es dueño de la contención de bloqueos/OTA. Operaciones de tienda se une para pausa por fases, bloqueadores de envío, delisting y plazos de política - Respuesta a incidentes de tienda.
Versiones de stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0, y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 16 jul 2026