Un bug crítico de checkout se publica a las 2 a. m. del viernes. Para el stand-up de la mañana, la dirección quiere un plan de recuperación, pero la corrección sigue en la cola de revisión de la App Store. El backend está bien, el CDN sirve contenido y el equipo de ingeniería tiene un parche probado. Aun así, los usuarios no pueden completar la tarea para la que abrieron la app.
Ese incidente revela el significado de disponibilidad de la app. No se limita a si existe una ficha en una tienda o si los servidores responden a las comprobaciones de estado. La disponibilidad depende de que los usuarios adecuados puedan acceder a una versión funcional, completar la tarea principal y recuperarse rápido cuando falla un release o una dependencia. La revisión de la tienda, la distribución gradual, el comportamiento en tiempo de ejecución, la entrega por red, los controles de cumplimiento y la seguridad del rollback contribuyen al resultado.
Tabla de contenidos
- Qué significa realmente la disponibilidad de la app
- Por qué las apps se caen en primer lugar
- Decisiones de arquitectura que mejoran el uptime
- Monitorización, MTTR y MTBF en la práctica
- Lanzamientos en tiendas vs. actualizaciones Over-the-Air
- Rollouts, rollbacks y entrega de Live Updates
- Restricciones de seguridad y cumplimiento sobre la disponibilidad
- Checklist práctico de disponibilidad y preguntas frecuentes
Qué significa realmente la disponibilidad de la app
Una definición operativa útil es la proporción de tiempo de uso esperado durante el cual los usuarios pueden completar la tarea principal de la app. Una app de compras puede tener una infraestructura saludable y aun así no estar disponible si falla el checkout. Una app de colaboración de escritorio puede arrancar correctamente y seguir sin estar disponible para un equipo si la autenticación o la sincronización fallan.
Cuatro métricas para hacer la promesa medible
Disponibilidad es la métrica principal, pero puede ocultar fallos parciales. Un proceso puede responder a las sondas mientras los usuarios ven pagos fallidos, pantallas en blanco o una navegación inutilizable. Combina el uptime con tasa de consumo del error budget, que muestra con qué rapidez un incidente consume el margen de fallos asociado a tu objetivo interno de disponibilidad.
Una SLA, o acuerdo de nivel de servicio, convierte ese objetivo en una promesa. Los equipos suelen expresar esa promesa como un objetivo de disponibilidad mensual, como 99.9% o 99.99%, pero el número por sí solo no define la experiencia del usuario. También necesitas reglas claras sobre qué cuenta como una transacción no disponible, qué regiones se incluyen y cómo se mide la funcionalidad degradada.
MTTR, el tiempo medio de recuperación, mide el tiempo entre la detección de un fallo y la restauración del servicio o flujo de usuario afectado. Incluye el diagnóstico, la aprobación del release, la propagación y la verificación, no solo el tiempo que un desarrollador pasa cambiando code. MTBF, el tiempo medio entre fallos, mide con qué frecuencia ocurren los fallos durante el período de operación.
Regla práctica: Rastrea la disponibilidad a nivel del recorrido central del usuario y usa el uptime de la infraestructura como evidencia de apoyo.
La fiabilidad y el rendimiento están relacionados, pero son distintos. La fiabilidad pregunta si el sistema sigue comportándose correctamente con el tiempo. El rendimiento pregunta qué tan rápido responde. Una app que carga lentamente está degradada, mientras que una app que se cierra al iniciar o no puede completar un checkout no está disponible para ese usuario.
Para una visión operativa más amplia, combina estas métricas con prácticas de monitoreo de salud de la app. La clave es tratar la disponibilidad como un problema de SLA probabilístico. Una release puede pasar la revisión y las pruebas normales, pero su ventana de entrega real depende de la volatilidad de la cola, los controles de rollout, las condiciones del dispositivo, la geografía y el tiempo necesario para emitir una corrección segura.
Por qué las apps se caen en primer lugar
La mayoría de las caídas en móviles y escritorio se dividen en tres familias. Cada una tiene un síntoma, un patrón de detección y un canal de recuperación diferentes, por lo que un solo dashboard de uptime no le dirá al equipo qué hacer a continuación.
Fallos de gating en tiendas
La primera familia existe antes de que el binario llegue a los usuarios. Un envío a iOS puede ser rechazado o retrasado durante la revisión. Un paquete de Android puede ser retirado tras una violación de políticas. Una publicación gradual puede dejar de expandirse si las señales de crash empeoran. En cada caso, el equipo de ingeniería puede tener un build válido, pero los controles de distribución determinan quién puede instalarlo.
La escala de Apple convierte esto en un problema de plataforma, no en un caso aislado. En 2024, su equipo de App Review revisó aproximadamente 7,77 millones de envíos y rechazó aproximadamente 1,93 millones, mientras que cerca de 295,000 fueron aprobadas más tarde tras corregirlas. Apple también eliminó más de 82.000 apps tras detectar infracciones después del lanzamiento, según se recoge en Datos de rechazo de la Apple App StoreEl síntoma visible suele ser una versión antigua aún en uso, mientras que la vía de recuperación es una nueva versión corregida en la tienda.
Fallos en runtime
Los fallos en runtime ocurren tras la instalación. Las regresiones de memoria nativa pueden provocar crashes al arrancar. Un bundle de JavaScript puede fallar tras un release apresurado. Un deep link roto puede dejar a los usuarios atrapados en una pantalla inválida, y un cambio en el certificate-pinning puede rechazar peticiones legítimas en clientes antiguos.
El retraso en la detección va desde telemetría de crashes inmediata hasta tickets de soporte tardíos. La vía de recuperación depende de la capa que falla. Los defectos nativos suelen requerir un nuevo binario en la tienda, mientras que los defectos de JavaScript, configuración, copy o assets pueden corregirse mediante un canal de Live Update controlado si la arquitectura de la app lo permite.
Fallos de red y edge
La tercera familia incluye errores de CDN, fallos en la migración de DNS, limitaciones regionales de API y errores de handshake TLS en sistemas operativos antiguos. Estos incidentes pueden afectar solo a una región o a un grupo de dispositivos, lo que hace que la disponibilidad agregada parezca saludable mientras una audiencia significativa no puede avanzar.
| Familia de causas | Ejemplo típico | Retraso en la detección | Canal de recuperación |
|---|---|---|---|
| Control de la tienda | Rechazo de la revisión o aprobación retrasada | Estado del envío o informes de usuarios | Envío corregido a la tienda y respuesta a la política |
| Crash en tiempo de ejecución | Bundle roto, deep link o regresión nativa | Analítica de crashes, fallos de sesión, soporte | Rollback, live update, cambio de configuración o nuevo binario |
| Network and edge | Fallo de API regional, CDN, DNS o TLS | Probes sintéticos y monitoreo de usuarios reales | Redistribución de tráfico, recuperación de dependencias, corrección en edge o fallback del cliente |
La ruta de recuperación más lenta define el resultado práctico de disponibilidad. Las directrices de revisión de la tienda indican que el 90% de las envíos se revisan en menos de 24 horas, pero informes independientes describen retrasos más largos durante las horas pico y para apps nuevas o actualizaciones importantes, a veces llegando 24 a 48 horas o más de 72 horas. El análisis del tiempo de revisión en la app store importa porque una corrección puede estar técnicamente lista mientras los usuarios siguen expuestos.
Decisiones de arquitectura que mejoran el uptime
La disponibilidad mejora cuando el sistema tiene menos puntos únicos de fallo y más formas de dar una respuesta útil cuando fallan las dependencias. Empieza por los cambios que reduzcan el radio de impacto evidente y luego añade controles que preserven los flujos de trabajo principales bajo estrés.
Elimina primero los supuestos locales
Ejecuta servidores de aplicación stateless detrás de un load balancer. Guarda las sesiones y el estado duradero en servicios compartidos en lugar de en una sola instancia, para que el tráfico pueda moverse si falla un proceso o una zona. Añade health checks que distingan liveness de readiness. Un proceso vivo puede seguir sin poder servir tráfico porque su pool de base de datos está agotado o una dependencia necesaria está fallando.
La redundancia active-active entre regiones elimina la dependencia de una única copia activa. Usa DNS ponderado o global load balancing para desviar el tráfico, pero prueba el failover en lugar de tomar la configuración como prueba. Los pares de regiones deben estar suficientemente separados para reducir fallos correlacionados; la ubicación exacta dependerá de requisitos de latencia, legales y de consistencia de datos.
Evita que las dependencias tumben la app
Envuelve los servicios externos con circuit breakers. Define timeouts explícitos, limita los reintentos y devuelve un fallback útil cuando un proveedor va lento. Una vista de solo lectura en caché puede mantener la navegación mientras las escrituras esperan. Un feature flag puede desactivar las recomendaciones sin desactivar el checkout. Una cola local puede retener las operaciones de escritura elegibles hasta que vuelva la red, siempre que el producto pueda explicar el estado pendiente de forma segura.
Una dependencia debería poder fallar sin que falle todo el flujo del usuario.
El chaos engineering convierte estas suposiciones en evidencia. Realiza game days en los que se terminan pods, se aísla una región, se satura una dependencia y se prueba la ruta de rollback. El resultado valioso no es un informe de una caída dramática, sino saber qué alerta se dispara, quién toma la decisión, cómo se mueve el tráfico y si el cliente aún puede realizar su tarea principal.
Los equipos que trabajen con patrones de resiliencia regional pueden usar esta guía de despliegue multi-región como punto de referencia. La arquitectura eleva la disponibilidad base, pero no puede eliminar las colas de la tienda ni hacer desaparecer una actualización insegura del cliente. Los controles de distribución siguen necesitando su propio diseño.
Monitorización, MTTR y MTBF en la práctica
Un programa de disponibilidad maduro combina tres perspectivas de la misma experiencia de usuario. Sondas sintéticas ejecutan recorridos con scripts de forma programada, monitorización de usuarios reales captura lo que experimentan los clientes instalados, y análisis de crashes identifica fallos de estabilidad por release, plataforma, dispositivo y cohorte.
Las comprobaciones sintéticas responden a si una ruta conocida funciona desde ubicaciones seleccionadas. Los datos de usuarios reales revelan fallos que la cobertura sintética pasa por alto, como una versión específica del sistema operativo o una condición de red regional. El análisis de crashes muestra si un nuevo build cambió la estabilidad del cliente, pero los equipos deberían combinarlo con la latencia del backend y los errores de transacción, en lugar de tratar los crashes como si lo explicaran todo.
Alerta ante cambios, no ruido
Los recuentos absolutos de errores generan alertas débiles en sistemas grandes y pasan por alto cambios significativos en cohortes pequeñas. Usa deltas de tasa de error frente a una línea base reciente y luego separa las alertas urgentes por severidad. Un fallo en el checkout debería avisar a la guardia principal, incluso si la tasa de error general de la app se mantiene baja. En cambio, una función cosmética puede generar un ticket.
Las alertas de burn-rate dan una vista operativa del SLA. Usa una ventana rápida para la detección urgente y una más lenta para la confirmación, siguiendo el principio de múltiples ventanas de la práctica SRE. Los umbrales exactos deben reflejar tu tráfico, el daño al usuario y la tolerancia a las falsas alarmas.
El MTTR debe incluir toda la cadena de recuperación. Si el equipo corrige code rápido pero espera la revisión, la propagación o la adopción por parte del usuario, el MTTR de cara al usuario sigue siendo alto. El MTBF ayuda a ver si las correcciones de emergencia repetidas están aumentando la frecuencia de fallos en lugar de mejorar el producto.
Haz que el runbook sea ejecutable
Los dashboards no recuperan apps. Un runbook debe indicar el responsable, los criterios de decisión, la acción de rollback, los canales afectados y la query de verificación. Los ingenieros deben poder identificar la última versión buena conocida y revertirla sin reconstruir el historial de releases durante un incidente.
Para equipos que construyen un sistema de señales más amplio, la guía de observabilidad de apps es un complemento útil para los checks de uptime básicos. La prueba operativa es simple: ¿puede el ingeniero de guardia identificar la cohorte afectada y reducir el impacto en los usuarios antes del siguiente escalado de soporte?
Lanzamientos en tiendas vs. actualizaciones Over-the-Air
La entrega por store y la entrega over-the-air resuelven problemas distintos. Un release en la store es la vía correcta para code nativo, integraciones con el sistema operativo, entitlements, permisos y cambios en SDK. También deja el fix sujeto a revisión, checks de metadatos, requisitos de firma y el comportamiento de instalación del usuario.
El phased release de Apple avanza automáticamente a través de 1%, 2%, 5%, 10%, 20%, 50% y 100% etapas, con cada etapa avanzando cada 24 horas. Los desarrolladores pueden pausar la progresión durante hasta 30 días acumulados, pero los usuarios que ya recibieron el build lo conservan, por lo que un rollback implica publicar una versión que lo supere, no retirar el binario instalado. Estos mecanismos están documentados en la guía de despliegue gradual.
Un canal OTA puede entregar bundles de JavaScript, configuración, textos y assets sin esperar al ciclo de revisión de la tienda. Los equipos pueden segmentar cohortes por versión de la app, geografía, entorno o perfil de riesgo. Esto hace que OTA sea valioso para defectos por encima del puente nativo, pero no convierte el code nativo en code reemplazable de forma remota. Un crash nativo causado por un binario o SDK sigue requiriendo una publicación en la tienda.
| Dimensión | Lanzamiento en tienda | Actualización Over-the-Air |
|---|---|---|
| Mejor opción | Shell nativo, permisos, SDKs, integración con el sistema operativo | JavaScript, CSS, configuración, textos y assets |
| Aprobación | Sujeto a revisión de la tienda y verificaciones de políticas | Utiliza los controles de entrega y firma propios de la plataforma |
| Acción del usuario | Suele requerir instalación o actualización desde la tienda | Puede aplicarse en un ciclo controlado de lanzamiento o actualización |
| Revertir | Requiere un binario posterior tras la distribución | Puede redirigir una cohorte elegible a un bundle anterior |
| Riesgo principal | Latencia de revisión y propagación del binario | Fallos de firma, compatibilidad, segmentación e integridad |
Una estrategia por capas mantiene estable el shell nativo y mueve los fixes elegibles por un canal OTA firmado. Capgo es un ejemplo de este modelo: entrega bundles cifrados y firmados con segmentación por canales para aplicaciones compatibles con CapacitorJS y Electron. Los equipos que evalúen la frontera entre ambos caminos también deberían revisar store updates versus direct updates.
Rollouts, rollbacks y entrega de Live Updates
La entrega segura comienza con una cohorte pequeña, umbrales de salud objetivos y una versión anterior que se pueda restaurar sin debate. Un despliegue canary o por fases debe iniciar con un grupo interno y una audiencia de producción limitada, y ampliarse solo cuando las señales de crash, errores de transacción, instalación de la actualización e indicadores de soporte sigan siendo aceptables.
Los bundles diferenciales reducen la transferencia innecesaria enviando solo los assets modificados en lugar de reconstruir todo el payload. Las asignaciones de canal separan el dogfood interno, los usuarios beta, los anillos de producción y los flujos específicos de clientes. Esa separación permite a un equipo probar una corrección en condiciones reales de dispositivo sin exponer a todos los usuarios a la vez.
Condicionar la expansión a la evidencia
Usa un registro de release que indique el bundle, las versiones nativas compatibles, el responsable, las señales de salud y el objetivo de rollback. Antes de cada expansión, verifica:
- Compatibilidad: El bundle funciona en cada shell nativo soportado y no depende de una capacidad no disponible.
- Integridad: La actualización está firmada, verificada y asociada al canal previsto.
- Salud: Las señales de crash, error, latencia e instalación se mantienen dentro de los límites declarados por el equipo.
- Recuperación: La versión anterior está disponible y la acción de reasignación ya se ha probado.
- Comunicación: El equipo de soporte y respuesta ante incidentes sabe qué cohorte recibió el cambio.
La entrega de live updates acelera el ciclo de recuperación porque combina bundles servidos desde el edge, reasignación de canales y una acción de revert. Capgo soporta estos patrones de entrega para apps de CapacitorJS y Electron, incluidos bundles firmados, actualizaciones diferenciales, control de canales y observabilidad de releases. La decisión de diseño clave no es solo la velocidad: es garantizar que un push rápido no pueda saltarse la compatibilidad, la propiedad de la aprobación ni la protección de rollback.
Regla de release: Nunca optimices la velocidad de rollout a costa de saber exactamente qué usuarios recibieron el cambio y cómo volver atrás.
Los equipos deben documentar si una actualización se aplica en el siguiente arranque, cómo se comportan las descargas interrumpidas y qué pasa cuando el dispositivo está offline. Más detalles sobre reversiones seguras en estas estrategias de rollback para los live updates de Capacitor.
Restricciones de seguridad y cumplimiento sobre la disponibilidad
Los equipos regulados no pueden definir la disponibilidad como «publicar la corrección lo antes posible». Deben preservar la confidencialidad, la integridad, la auditabilidad y el cambio controlado mientras restauran el recorrido del usuario. Un equipo de fintech puede necesitar controles de pago y pruebas sólidas de la publicación. Un equipo de atención sanitaria debe proteger la integridad de los datos cuando la red o un servicio dependiente no está disponible. Una implementación gubernamental puede restringir de dónde se originan las actualizaciones y qué entornos pueden recibirlas.
La tensión práctica es entre velocidad de recuperación y control de cumplimiento. Un CDN OTA de terceros puede acortar la ventana de entrega, pero una organización de fintech puede no poder utilizarlo hasta que se evalúen la postura de seguridad del proveedor, los controles de acceso, los registros de auditoría y los requisitos contractuales. Una aplicación sanitaria puede permitir el rollback solo si el bundle revertido sigue firmado y el evento se conserva en un historial de publicaciones auditable.
| Marco legal | Impacto clave en la disponibilidad | Restricción en la entrega de actualizaciones |
|---|---|---|
| PCI DSS | Los flujos de pago requieren resiliencia controlada y manejo protegido de transacciones | Las actualizaciones requieren pruebas, control de acceso y verificaciones de integridad |
| PSD2 | La autenticación de pagos y la continuidad del servicio definen el diseño de la recuperación | Los cambios deben preservar los controles de autenticación y pago |
| HIPAA | El comportamiento ante caídas debe proteger la información de salud y la integridad de los datos | Los fallbacks y rollbacks requieren acceso controlado y auditabilidad |
| FedRAMP | Los entornos aprobados y los procesos de cambio limitan las rutas de despliegue | Los orígenes, aprobaciones y registros de actualizaciones deben cumplir con los controles de autorización |
| RGPD | La gestión de incidentes y la protección de datos personales afectan las decisiones de recuperación | Los equipos necesitan cambios trazables y un proceso de respuesta ante la exposición de datos |
El firmado de Code es esencial para los bundles de Live Update. Usa canales separados para cada entorno, restringe quién puede publicar, verifica la compatibilidad antes de la instalación y mantén un historial de versiones. La residencia de datos regional, la retención de logs de auditoría y la garantía del proveedor pueden determinar si un canal de entrega es aceptable, incluso si su rendimiento técnico es sólido.
Los equipos de seguridad también necesitan evidencia de pruebas repetibles. Un recurso sobre pruebas de penetración SOC 2 automatizadas puede ayudar a los equipos a definir cómo encajan las pruebas automatizadas en la validación de controles. No sustituye la revisión de arquitectura, la aprobación de cambios o los simulacros de incidentes.
El equilibrio sensato es una vía rápida controladaPreaprueba clases de update elegibles, firma cada artefacto, registra cada asignación y reserva los cambios nativos o de alto riesgo para el proceso formal de cumplimiento y las tiendas.
Checklist práctico de disponibilidad y preguntas frecuentes
Usa esta lista como una auditoría operativa. Cada punto debe tener una respuesta clara de completado o no completado, no una declaración vaga de que el equipo "apoya" la disponibilidad.
- Define el SLO: "Done" significa que la transacción principal del usuario y la ventana de medición están documentadas.
- Mapea las dependencias: "Done" significa que cada API crítico, servicio de identidad, flujo de pago y componente de edge tiene un responsable.
- Separa readiness de liveness: Hecho: las instancias no saludables dejan de recibir tráfico antes de que fallen las solicitudes de los usuarios.
- Probar el failover regional: Hecho: el equipo ha probado el movimiento de tráfico y verificado el comportamiento de los datos.
- Añadir degradación controlada: Hecho: las funciones no críticas se pueden desactivar sin bloquear la tarea principal.
- Instrumentar la salud del cliente: Hecho: los crashes, fallos de update y cohortes afectadas son visibles por release.
- Configurar alertas por cambios: Hecho: las variaciones significativas en la tasa de error alertan al responsable adecuado.
- Crear anillos de rollout: Hecho: las audiencias internas, beta y de producción tienen asignaciones explícitas de canal.
- Firmar artefactos OTA: Listo significa que el cliente verifica la integridad y compatibilidad del bundle antes de instalarlo.
- Define los triggers de rollback: Listo significa que el equipo tiene condiciones objetivas para detener la expansión o revertir.
- Nombra la acción de recuperación: Listo significa que el ingeniero de guardia puede ejecutar y verificar el rollback desde el runbook.
- Revisa los controles de cumplimiento: Listo significa que los responsables de seguridad y compliance revisan los permisos de entrega según evoluciona el producto.
Preguntas frecuentes
¿Cómo equilibrar la latencia de revisión de las tiendas con la velocidad de los hotfixes? Usa la vía de la tienda para cambios nativos y una vía de Live Update controlada para fixes elegibles en la capa web. No fuerces un workaround de JavaScript para un defecto nativo, y no esperes a un envío a la tienda cuando un bundle firmado y compatible pueda resolver el incidente de forma segura.
¿Cuándo superan los phased rollouts a los canary releases? El phased rollout funciona cuando la tienda controla la distribución y el equipo necesita una exposición gradual en la base instalada. Un canal canary ofrece un control de cohortes más fino si el sistema de entrega lo permite. Ambos enfoques fallan si los health gates y la responsabilidad del rollback no son explícitos.
¿Cómo se calcula un uptime realista durante interrupciones regionales? Mide el recorrido del usuario por región y pondera los resultados según el uso esperado. Un promedio global puede ocultar una interrupción grave para un segmento, así que publica tanto la disponibilidad agregada como la experiencia regional.
¿Qué diferencia hay entre MTTR y MTBF? MTTR mide la velocidad de recuperación tras un fallo. MTBF mide el intervalo entre fallos. Un equipo puede mejorar uno mientras empeora el otro, así que rastrea ambos junto con datos de releases y dependencias.
Reevalúa la lista de verificación trimestralmente y tras cambios importantes en la base de usuarios, el alcance regulatorio, el shell nativo o los canales de actualización. La disponibilidad de la app es un contrato operativo en movimiento, no una casilla de verificación de arquitectura de una sola vez.
Si tu equipo de CapacitorJS o Electron necesita una ruta controlada para actualizaciones firmadas de JavaScript, CSS, configuración y assets, Capgo ofrece canales de Live Update dirigidos, entrega diferencial, historial de releases, logs de actualización a nivel de dispositivo y protección contra rollback. Visita Capgo para evaluar cómo una estrategia de entrega por capas puede acortar las ventanas de recuperación sin eludir la gobernanza de las tiendas para cambios nativos.
